Why the jQuery Creator Uses React and Typescript - John Resig

Welcome to Syntax. Today, we have, 2 things. First of all, 800th Node. So soaked that we're on the 8 100th episode of syntax. Thanks to everybody for tuning in for that.

And to celebrate the 800th episode, we went on to our what we have is John, I didn't tell you this, but we have a what's called a goat list, which is the greatest of all time. And every now and then, we'll dip into that and be like, who can we get on the podcast that is, a goat? Right? Like, someone that has, done a lot for web development and whatnot. So we have John Resig on today who is, probably you all Node, the creator of jQuery among many other things, but probably most well known for that. And we're here to have him on today to talk about, both jQuery as well as, like, what's going on, what are you working on these days, and the thoughts on what the modern JavaScript landscape looks like. So welcome, John. Thanks so much for coming on. Yeah. Thank you so much for having me. It's very auspicious to be here for,

for 800.

And if you're working with the modern web, you're inevitably going to hit errors because, let's face it, this stuff has gotten complex.

And with that, you're gonna want a tool like Sentry on your side to make sure that you can capture and find and solve all of the errors, issues, and potentially performance problems in your application and solve them quickly. In fact, we use this just endlessly on the syntax Node to make sure that we're staying on top of anything that could arise for us. So if you're interested in that, head on over to century.i0 forward/ syntax. Send up a good 2 months for free. It's well worth it.

Alright. So, surprisingly, I bet that probably 20, 30% of our audience has probably actually never used jQuery just because of they've only been a developer. I'm curious if you run into to developers these days who who maybe have never used it. So, do you mind giving us a quick rundown of what is or what what yeah. What is jQuery and, like, what the JavaScript landscape look like at the time of you creating it?

Yeah. So jQuery, when I first created it, was a library for simplifying Dom interactions mostly. So, you know, you're manipulating, the Dom. You're traversing it. You're mutating it.

And then have a little bit of, you know, networks of Ajax stuff mixed in there, and some animations. Just a a useful library that made a lot of those interactions simpler, and it kinda papered over any sort of browser inconsistencies and bugs that existed. So yeah. Well, I guess Wes I was first working on it, it was 2005 and released January 2006.

And at the time, you know, I was building various Ajax y web applications. It's like that that the time guys all web 2 ESLint o Mhmm. Yeah. Stuff that was going on. And I was building a bunch of things, and I was really frustrated by the browser inconsistencies, that existed. I was just, you know, the the if you're gonna do network Wes, it was different in every browser. If you're gonna do DOM traversal, it's different in each browser. Yeah. Everything was different. Everything was broken and subtle different ways. So Yeah. You know, I made jQuery as a way to kinda simplify all that. I have a single API that was hopefully simple and easy to use. And then, yeah, does not have to worry about the browser inconsistencies.

So, yeah, I I definitely jQuery was not the 1st JavaScript library. There were a number of JavaScript libraries that came for. I was really inspired by the prototype JS library, which, was, you know, I guess, primarily at that time being used as part of Ruby on Rails and and all that. Yeah. Yeah. But that was yeah. There were a number other, like, smaller libraries that was inspired by as well. But yeah. Yeah. It it it's it ended up having a huge life because people this it got a need for people that, I I'd say that now nowadays, it can be used for folks. You know, I don't use jQuery anymore. I haven't used jQuery in a long time.

And it's mostly because, you know, like, I'm on a, you know, Khan Academy on a big team with a ton of engineers. We're using React. You know, we're doing all the sort of stuff that you would see at, many other big companies. And I think people are definitely still using jQuery. I I know I see it ESLint, you know, a lot.

But yeah. Yeah. And I'm I'm happy that it's had such a a good life, and the people have really enjoyed it and got a lot of use out of it. Yeah. Yeah. Jquery was one of those things that had, like,

a, like, a like, we sent it off to sea, but we all, like, saluted it being like Yeah. The reason often, we have to explain on this podcast that people are like, oh, takeaways. It was such a hard time in web development. Like, I'm so glad we don't use it anymore. And we have to explain to people that the reason we don't use it anymore is not because it wasn't good. The reason we don't use it anymore is because it inspired the browser it was at a point where we don't necessarily need it anymore. There's still quite a few people who's either are quite a few people who's either are on projects that are built on top of it and it's not worth moving or who still prefer

the simplicity of the API over the the built in stuff. Yeah. And and so when you okay. So I I first wanna thank you because I don't think I could have gotten into JavaScript at that era GitHub something like jQuery. Because I I came from, you know, more of a CSS and HTML background, and getting into JavaScript was hard enough as it was. But, like, having something like jQuery felt, like, very approachable.

When you wrote the 1st bit of jQuery, did you have any inkling that it would ever be used on most websites in the entire world?

Oh, I mean, certainly not. I mean, in the early days, I did a lot of, you know, promotion and marketing and advocacy to try use open source framework, but I wanted people to use. I thought it'd be, you know, it'd be something that people appreciated.

But like, I I think something that was kinda wild is that Wes I when you look at the number of people who are writing JavaScript in 2005 JS like a serious thing, it was very very small. Very small. Like like, JavaScript was a toy language. Node. People weren't treating it like a serious like, I remember going to conferences in those early days, like 2006 or 7. And there would be some companies there being, like, hey, we were, like, you know, this is what we've done to, like, think about performance ESLint JavaScript. And it's just like it but it was so rare and so exceptional that has to be noteworthy that someone actually cared about this stuff.

And and and I think that's what people don't, I think, fully realize that nowadays, not only is it's it's it's beyond passe. Like like, it's it's it's, like, you have to have this knowledge and you have to have it as a modern web developer.

It's no longer optional to, like, not think about performance, not think about accessibility, not think about all these other things that are very important to shipping an application.

And, yeah, and I think the industry as a whole has grown so much in, you know, the 20 ish past years. So, yeah, anyway, I think it's a good thing that we don't have to worry about what are relatively minor issues that jQuery covers, in the scheme of things. Yeah.

I will say that jQuery still solves the animate slide down better than most frameworks and libraries these days. Wes years. Yeah. I know. That's the one thing I look back on fondly very much so. Yeah. Did you see that JS finally changing, though?

I forget what it was. I was looking up the, like, allowed create,

animation things. And very soon, we will be able to animate height of auto, which is gonna be Yeah. So allowed to and starting style are the 2 big ones, Wes. And I I talked about those a lot in my, JS Nation talk. So if you find that online, I'll post it in the show notes. But, yeah, those those show on that. Properties are incredible. Yeah.

I'm curious about the, like, jQuery community as well because, honestly, I think that the jQuery community or I know that the jQuery community is why I'm a a web developer today because I was kinda just stumbling along, doing some WordPress stuff, and then I got into the jQuery chat rooms. And then I was like, wow. This is a whole community. Mhmm. I went to a conference. I got to meet John. It was I was very starstruck at the time, and, like, that was amazing. And, like, I'm curious what you're in I don't know if you have any thoughts on, like, what you did to make jQuery such a thing. Right? Like, there was a board of directors. There was funding. The people got paid to work on it. I believe that's a whole another thing aside from, like, actually writing the JavaScript. Right? Yeah. I think

so it's interesting. I think, like, in the early days I mean, I believe and, yeah, we'd have to do some archaeology to confirm this. But I believe that JPRO is the 1st library, and this sounds silly in retrospect, to have documentation.

Really? I mean I mean, it sounds really it it it it sounds absurd because nowadays, no one release a library without documentation. But, like, at the time, you know, JavaScript libraries, they were just it's like, oh, here's a pilot code. You know, read through it if you wanna understand it. And it that's what it was.

And and so I think from day 1, you know, I wanted to ensure that the library was going to be successful. So that meant, you know, writing documentation, building up that Sanity. And and I I think one of the things that we did that was rather exceptional was actually start to have people whose job it was inside the, J. Crew community was to sort of manage the community outreach, and work with community members, work on support, work on onboarding, you know, people who are using it.

And stuff like that was I feel very, very impactful. It's, you know, it's fun to see where a lot of the folks from the jQuery team ended up you know, for these and I would say other JavaScript frameworks where where you have folks who is like, oh, you know, they're oh, they're at Microsoft, or they're at Meta, or they're, you know, oh, they're running this thing, you know, or Vercel, or whatever the thing JS. Like, it's so it's but it's, I think the the importance of building that community, fostering that community, making sure that when people are having a problem, that they know where they can go to get an answer. And and again, like, I think nowadays, you know, it's a lot simpler. You Node, I'm sure a lot of projects have, you know, GitHub issues, and then they have a Discord or something like that, wherein just go and get your questions answered. I think back in the day, it was a lot harder. It was, you know, mailing lists or, you know, for a long time, we had a jQuery forum software that we ran. And anyway, it is just but I think that's the sort of software. It helps anything to help with onboarding, helping people understand and get over the humps is is impactful.

Yeah. Yeah. That's kinda how I got my whole start, actually, because so many things were just buried in forum conversations.

So I just started making quick little YouTube videos explaining common, like, hiccups people hit. But it it is such a, I don't know. The power of good documentation is is pretty unbelievable sometimes.

As far as, like, plug ins go in jQuery, I know that was, like, a big part of the community for me Wes the vast ecosystem of plug ins. Maybe the 1st, like, real thing I ever shipped in open source was a jQuery plug in. So, was plug ins, you know, intentionally to be a community growing thing? Or was it just, hey.

I I know people can extend this as much as they want and and ship their own things? Like, what was the intention behind plug ins, and when did they arrive in jQuery?

Yeah. So plug ins were there on day 1. Like, I I think I think I realized right at the start because essentially, it was just, you know, jig, jQuery would return a jQuery object, and then every call to a jQuery object would return another one. So, like, it was just it it I'm just like, okay. Well, we could just have, you know, expose the prototype and people can add whatever they want onto it. You know, if they wanna add a new method, go to town. And I think as time went on, we realized, oh, okay. People need access to some of the Vercel. So we can expose document and expose some of the internal so people can make even more powerful ins. But the I think, you know, we were people were making plug ins, like, within the 1st couple months of jQuery being out there. Wow. And and what was interesting is a lot of those people who were making the plug ins, I could see they're doing good work and be like, hey. Do you wanna just come work on jQuery? Encourage them to come do that. So that in and of itself built and fostered a community. So, like, you know, jQuery UI, the collection of, like, UI components, and jQuery mobile collection mobile components, all that sort of stuff came from Sanity, then it kinda we brought it in, brought the devs in, and be like, hey. Let's, like, support this. Let's make it official and real you know, kind of bless it and and give you know, help provide it to the community.

Did you ever make any money from J Crew? Because it was such a massive thing. You've got it. And you look at, like like, Bootstrap. People are making bang from Bootstrap themes or or Tailwind. People are making bang from don't ever remember that being a thing in the jQuery world. Was it? No. I think

I think commercialization of JavaScript libraries has gotten a lot more sophisticated.

Yeah. In in in recent memory, I think didn't really make I'm I'm I'm honestly trying to remember if I ever I might have made I Wes, so the thing is I I've never made money directly. I joined Mozilla in January 2007.

But my job at Mozilla was a developer evangelist. So it's mostly, you know, documentation, public speaking, stuff like that. And, so during the course of that, I Wes I'm just you'd be speaking about, you know, jQuery, the conferences and things like that. And it wasn't until I was there for a few years that they warp like, oh, okay. You can work on right now. Like like, you can, like, get paid to work on JAKE. Right? So I did that for about a year and a half, 2 years or so. And so that's that's about as close that that that was me making money off of Jake Roy JS that I had a job that I can work on Jake Roy for a period.

But the thing is is that, like, I left Mozilla in 2011, and I stepped down from working on jQuery for a couple of reasons. I mean, I was pretty burnt out.

Maintaining open source libraries, I don't know. It Oh, yeah. It's very, very tiring work. And and with something like jQuery where it was so widely used, any change at all would break some website anywhere. It would it it was a bug fix, it would break someone's website because they were relying on the bug working in a certain way. Yeah. It didn't matter what you fixed, you broke something. And so it it ended up being the most aggravating work. And then, of course, the the every byte matters. So every time you couldn't add features. So if you're adding features, people get upset because you're now increasing the size. If removed stuff, people get upset. If you make anyway, it's just it's a sort of thing where I'm like, okay. I'm not really having fun working on this. And, but then additionally, I think I was in a weird place in my career where the only applications I had shipped were ones that I had built personally on my own. And I never worked on a team building and shipping an application.

And, so a lot of the things that I was putting into jQuery or software supporting was was done in the abstract. I hadn't done it myself. And and so that's the sort of thing where there when I joined Khan Academy, I did so just because, one, I was very interested in education, getting to work and focus on that. But then, additionally, getting to work on a team, shipping and building stuff was actually very exciting prospect for me. I wanted to be able to focus on that. Yeah. Being able to to set aside the introductory stuff I had it was in good hands. There was a nonprofit. There Wes a whole team running things, and it I knew it Wes gonna be in good shape. Yeah. I put a lot of time in it pnpm ensuring it would be successful.

But then yeah. Then I could, like, carefully step away and be like, okay. Now I can just go work on something else.

Yeah. That's great. And let's talk about that. So you have been at Khan Academy for, what, probably 12, 13 years. Yeah. 13 years. What are you doing there?

Yeah. So my title these days, I'm a chief software architect. So I'm the head of architecture for Khan Academy, and I'm also the front end architect that is inclusive of both web and mobile native. And, yeah, I think I used to be the manager. I stepped down just recently. I used to be a manager of the front end infrastructure team, as well.

We now have a new manager who's, who who's helping me, but I'm, you could you could just call me the PM for that team. And then that I'm helping to drive the direction of, of what's work being worked on there.

And so I ESLint my day to day JS sort of split between working on the architecture for all of Khan Academy for the the Wow. You know, from the engineering side.

And, that includes not just front end related stuff. Like, we're doing a lot of stuff with LLMs and stuff there. Then, of course, our our overall architecture of, you know, what servers were being deployed on, our build processes, and, you know, the general architecture of our application.

But then also, you have the, you know, front end specific stuff. Obviously, I care about that, stuff a lot. I'm very passionate about it. Yeah. Yeah. So, yeah, I have lots of opinions about, you know, build systems and, you know, CSS frameworks and, you know, all these sort of things that we that we're using and or not using. And but yeah. Yeah. So this is just stuff. And I'm still still coding.

And these days, I'm working on some internationalization, stuff. And but, yeah, just it it depends what what projects they're doing.

Yeah. A lot of people are asking on Twitter, like, what are you working? Are you still coding now? And, like, you go to your GitHub. It's solid green. You know? Like, just, commits all day long.

So I'm I'm curious what the actual tech stack at Khan Academy looks like. Yeah. Yeah.

So back end is Go, and we're running on Google, Google's compute platform, GCP. Mhmm. And we use GraphQL, and we have a number of Go Vercel, and we we do a federation.

So GraphQL federated across all those services.

Okay. And and then on the front end so okay. I'll I'll just preface this by saying a couple of things. One is is that our front end tech stack is huge. It's like Mhmm. Multiple lines of lines of code. Okay. Like and and it's gone through look okay. So we were the 1st consumers of react outside of Facebook. And it's Wow. Really? Yeah. Very first. And and the thing is is that, like, I there are some ancient parts of our application that are actually are still using Jquery. The but we there are things that, you know, like dev admin stuff that Deno one touches. Yeah. Like and, but we have legacy React Node. You know, like, that Lisbon we've been, you know, working and upgrading. Well, so we have Vercel all dating back to the, create React class era Oh, yeah. Of stuff. Oh, yeah. Before classes.

Yeah. Yeah. Pre classes. Before classes. Yeah. And now, you know, functional and then hooks. Like, we have we have every generation of React code in our application.

And, and so, like, for example, like, one of the big shifts we just made in this last year is that we had bet on flow for TypeScript.

Not to be the wrong bet. And and so, like, in the last year, we moved to TypeScript. So, like, but like that was a huge project because it's like moving multiple millions of lines of code to TypeScript in a way that isn't disruptive for folks.

Yeah. I think there's what so we're we're and and the text tech stack in the front Deno, so we're using TypeScript.

We use Vite for our builds. At least on the currently Vite for our dev builds, webpack for our our, prod builds. We're gonna Mhmm. That's something I wanna change here, soon.

Node, again, one of the things I'll I'll mention is that a lot of our our stack and especially our build systems, when we first built them, they predated webpack and all of that. Like like, we were doing our own custom build stuff.

Mhmm. And so we went through from custom build stuff to webpack to v.

And what I'm trying to get us to now and then addition, this is the same thing on the the front end, like our routing layer. Like like, we're using React router.

But this, again, all predates Scott of the modern generation of, you know, Next. Js, Remix, all these really nice frameworks. Yeah. So the actually, the big project that I'm working on right now is getting us onto one of those frameworks, essentially. Yeah. You know, so so, like, removing our custom, you know, route management, you know, logic. And I personally, I'm leaning towards having us go on to what's the the the upcoming React router that's gonna be Remix. Yeah. You know, that that I think I think that would be probably ideal for us.

But I guess, you know, we'll, you know, we'll see. But I think there's a lot of architectural changes we have to make to get there. And then additionally, like on the CSS side, we're still using the CSS and JavaScript framework that we made at Khan Academy called Aphrodite, but we're wanting to move off of that. Like, we, and that's the thing that we're in the process of figuring out. It's like, okay, are we should we just go to, like, CSS modules, or should we use other CSS and JavaScript thing? Maybe like Panda CSS or something like that? So that's something that we're we're also trying to, you know, reconcile.

But yeah. So there's a lot of technical decisions. Yeah. Yeah. Can I ask what the

what issues you're hitting, or why do you wanna move off of your,

CSS and JS framework? Yeah. So okay. So a couple things. So at least so with Aphrodite, again, like, since we were an early early user of React, at that time, CSS and JavaScript up to and says, I think Aphrodite I don't know if it was the first. It was maybe one of the 1st CSS and JavaScript libraries. And, at least for React.

Mhmm. And it there's a couple issues. Node is it's it's slow at the run time. Like like Mhmm. Like, you have a run time library, you know, where where things are being computed at run time. All the modern libraries are all it's all computed at build time. That that would makes a ton more sense. Like, even if you strip out all the runtime stuff, you Node have to worry about any of that.

And so one is so we're shipping code. The production, we don't need to be. It's slow to to render. We don't need we we don't want that.

Now, of course, React Vercel components are also pushing our hand here. Like like, Aphrodite just does not work in a React server component world. And we we wanna be using RSC.

So that's a case where we need to be moving to something else where we can generate all the CSS at build time. And whether that is, you know, moving the CSS modules, or like I said, like, something like Panda CSS or something like that Wes it's all done at build time. And I would think I will say is that we're intentionally not looking to move to tailwind because I I think there I I don't know what we would do if we were starting over. Like like, if, like, if you Yeah. Right. Yeah. You know, if we may wave a magic wand. But the promise is that moving from, again, multimillion line code Bos of already using CSS and, you know, CSS like things, like, it's not practical to move to something like Tailwind. It's so different as a concept.

So anyway so I think that's the sort of case where yeah. I think we we need to find something that we could incrementally move over or or at least, you know, write code mods that Wes can, like, programmatically

Totally. Move our existing things over. Yeah. Yeah. That tracks for sure. Yeah. You mentioned that you bet on Flow and they're now have converted to TypeScript.

I'm curious about, like, your your thoughts and opinions on TypeScript versus Flow. Did you prefer Flow even after using TypeScript, or how do you feel about it now?

I think I think there are certain things in flow that we liked. And you have certain language features, but also the performance. Flow was definitely faster. And it's just one of those things where we're just like, even though it's TypeScript is Wes, quote unquote, in some ways, the the the fact that everyone uses TypeScript makes it better.

And and it doesn't matter how much incrementally faster flow is. Like, we would just it that that is lost when every time you adopt a new library, there are no types for it in Flowland.

You know, like Oh, yeah. Like, it it just it it's a huge hassle. Like, you know Yeah. I think people it's it's hard to overstate the impact of the sort of those market effects that happen.

And and so, yeah, eventually, we're just like, yeah. This is ridiculous. We can't keep doing this, unfortunately.

Yeah. We had to it it was it was it's just imperative. We had to do it even though it was a painful project.

Man, I wanna ask about the GraphQL as well because I know you you wrote a book on GraphQL.

And every single large company with lots of services, and GraphQL is really good for a federation layer, which is sort of a a single layer to join them all. Is that where you see GraphQL these days?

I mean so I don't think it's necessarily exclusively so, but I think that for ESLint a company like we are, it it makes it very easy to do this sort of thing. And GraphQL really benefits this. A bit of, our our our style development and our various processes. And, I mean, obviously, it depends on like like, if you're, like, an individual just making a project and you're just trying to ship your your thing, maybe GraphQL could be helpful for you. Like, you know, I I I mean, thinking about going back to the world of, like, writing Wes endpoints where each endpoint, you know, after, like, custom make my, you know, my get and my post and I have to think about every field that's coming in. And I don't know. I wouldn't go back to that personally. But just because I think, you know, being able to define your schema upfront and just be able to just wave your hand and be, like, great. I have access Wes all the data that I Node, and I can have on my resolvers, give me everything I want. And not only that, I think it also depends on how much you're bought into using types in general.

So I think if you're just like fly by to see your pants, just this. I don't know. I'm just throwing Node out there. I don't really care if the test pass or or if there are tests or whatever. And after that, you know, whether types Yarn if I have types or not, then, yeah, GraphQL is not for you. Absolutely. Mhmm. But I think the benefit of being able to have typed queries Wes you can Node, like, if you change a field, every single part of your you're gonna know every single part of your application that is going to break if you change that field. That is incredible. That is that that allows you to do refactoring that you couldn't possibly do in a REST style world unless you have some other custom TypeScript REST. But at that point, just do GraphQL. So I'm like, I don't know. I think that's the sort of stuff where it's, I find so I find GraphQL to be useful for myself personally in my side projects even when it's just me. Because, honestly, when I'm doing side projects, I'll work on it and then I'll come back to it months later. I'll be like, what was I doing? And, like, those all those that scheme JS those types, those save me. Because then I'm like, oh, right. That's what I was doing, and I don't, like, mess myself up and, like, break things because I can, you know, have that context. Yeah. Yeah. I do love how GraphQL JS CSS self documenting

and the tools, the the playgrounds, all that stuff. It just makes it really, really simple to understand your data at all points. I I know you said you were you you used jQuery up until maybe not up until you used React. But what was, like, your front end framework journey? So I'm sure you use jQuery quite a bit, and now you use React. Was there anything in between there Were there things you tried or didn't like? What was that journey like for you?

So I guess with jQuery, it was a lot of when I joined Khan Academy, there we were doing jQuery backbone, which is then also handlebars and stuff like that. Marionette, maybe. Yeah. I think the so, I mean, I've experimented with other stuff personally, but, like, I think I still just keep coming back to react stuff. I don't know. I think the model matches for me really Wes. Like, I under I understand, like, what it's trying to do.

And I think that I again, like, I've tried other frames. I I don't I don't wanna mention them because I think sometimes when some of my decision mentions For sure. It's gonna be the title of the show if you do. Yeah. Exactly. I tried view and it was I just couldn't say that to him. He was like, oh, no. No. No. I mean, I don't know. Like, it's just Yeah. Yeah. I think I think the React model meshes well for me. And Mhmm. And I think that, again, this is a case where there's a huge ecosystem of stuff built on top of React things, where you can just you have your choice of, you know, component libraries you can use just from anywhere. And I think, you know, I've done, you know, React Native stuff, you know, for example. And we're we're in this world now where, you know, you can build an application and ship it on mobile native, you know, Bos, Android, and web using the same code base, same components, everything. And it's all React. I don't know. I don't it's something that is I think is is wonderful. So I think that's the sort of thing where I mean, there's there there's other frameworks. People really like them. I'm not gonna, you know, yuck their yummy. I'm gonna think. And, like Yeah. So, yeah, I think, at least for myself, that's I'm I'm still digging it. Yeah.

Yeah. Is is there any part of React that you don't like or you wish would improve or change?

Oh, gosh. I mean, I think I think it's gotten so complicated to do, like, correct, like, service side rendering, with React. The at this point, you have to use a framework. Like like, there's no there's almost no point in trying to roll your own. And, like, the thing is, like, what we're currently doing so, we actually I feel about everything is what we just finished upgrading to react 18. Like, we were on React 16, and I know React 19 is coming out now. But, like like, you know, it just and again, in our code base our size, like, it it gets complicated. And Mhmm. So we do we do our own Vercel side rendering layer.

And but, you know, I wanna move to something else. But realistically, I'm gonna I think we just we're gonna have to use a framework. Again, like I said, I'm I'm thinking I'm leaning more towards Remix, you know, React Router at the moment. I think they made a lot of really good architectural and I know a lot of those decisions have been started to get rolled back into so the React RSC, you know, Vercel component decisions, which I think is is is smart.

I think that in general though, there there are just certain things that I think it it it's especially, you know, with suspense and all these things, it just gets really complicated to do service side rendering right.

And I think that JS a result, there's been certain architectures that are just pretty much impossible to do now in an ROC React world.

And maybe that's for the ESLint looks like like, you know, like our Aphrodite is not gonna work in that world. And Mhmm. I think that's a case where I kinda wish that the React team was willing to provide a bit more hand holding about what what the correct way was to build and ship an application, and not just hand waving off to, oh, you have to use Node of these 2 blessed frameworks.

Totally. And which is what they're doing right now. It's pretty much of Yeah. You use Next. Js or or Remix or I don't know. Read the source code, I guess, is your option. So yeah.

Do do you have any reservations about using React Router given that, Ryan Florence was the was, deep into MooTools?

Oh, yeah. Not at all. Is there any there?

No. No. I mean, yeah, all these. Yeah. No. All these works are great. I mean, it's Yeah.

Yeah. It's it's like I said, it's funny to see where people are popping up these days, who's working on what frameworks or what companies and being, like, oh, yeah. Right. Yeah. I guess Wes were both working on stuff around the same time, you know, Wes it, you know, May 2010 or who knows Wes, but Yeah. No. Yeah. I mean,

yeah, Remix and React Router are great. Yeah. Really like it. They're fantastic. Totally. Yeah. We love Ryan here too. So And,

the Khan Academy mobile apps are all React Native then? Yes. Yep.

Oh, that's awesome. And what what does that look like? How much, like, how much code is shareable between the web platform and and the native platforms?

Okay. So that that's the rub then. They saw that Wes don't have even though it's React Native, we don't have very much shared code realistically. Yeah.

Okay. I think part of the challenge here is it's it's multifold. I I think the thing we do have shared is that they're both using the same GraphQL GraphQL scheme and all that stuff. Mhmm. So the underlying data and queries and mutations and all that is is the same.

But I think I think there's a couple things that with the the native applications.

The scope of the native applications is much, much smaller than the full website. It's pretty much just focused on material for learners. So, like, you can, like, do an exercise, watch a video, you know, read an article. It's like it's pretty small. Whereas the full website is like, oh, well, there's, you know, there's all these teacher tools and reporting and districts and all these sort of things that honestly don't really make sense on a mobile device.

And so, like, we just have, you know, like and if we were to, you know, optimize for a mobile view port, we might just do it on web. We wouldn't do it on mobile. There's not much point in having it be on a device. And I think one thing that's makes Khan Academy a little interesting when compared to other companies JS that if we look at our browser user agent breakdown, like, we are self I forget what the current numbers are. The majority of our users are on Google Chromebooks.

Wow. Yeah. That makes sense. Yeah. Like like like Chrome like like Firefox is less than 1% for us.

Safari is like a few Vercel, but then I I've I've maybe it's a little bit more than that. But, like, it's like Chrome crushes everything. And out of that JS mostly Chromebooks. Because again, we're primarily being used in schools, and Yeah. Chromebooks dominate schools. So it sounds like yeah. Yeah. Wow. And what about,

state management? Do you use something that works with your GraphQL data fetching layer?

Yeah. So I think that's something that we leave to the teams to make some more decisions about. Some teams Yarn using Redux. Although, I think most of them kind of moved away from that at this point.

Some teams Wes do use some Apollo for for GraphQL. We use we have a couple different GraphQL solutions. But some use Apollo uses use Apollo's internal cash management and Scott, there.

But then, honestly, at this point, a lot of teams are just building their own Scott, just using, you know, react hooks and stuff like that, or using providers, or, you know, whatever the thing is. Yeah. Like, I I think at this ESLint, the tooling in react itself has gotten good enough that most teams are just using whatever's built in. Yeah. Just state. Beautiful. Cool.

As a previous Mozilla employee, what do you think about Firefox and the the sort of state it's in today?

Yeah. I mean, it's interesting. So, you know, when when I you know, so I was at Mozilla 2007 to 2011, and I remember when okay. So the it's interesting because Mozilla, the offices I I worked remotely in Boston, but the main offices were in Mountain View, literally across the street from Google. And the the offices themselves, the office building was owned by Google, and like and and Missoula was just, you know, a a tenant there. And all I remember all the Mozilla employees had Google badges to go they could go use the cafeteria at Google, and Google would give funding to Mozilla because of the search bar placement and all those so like the the Mozilla was very tightly tied to Google. And I remember there was a period, I forget exactly what years, where certain key employees just decided to go work at Google. And you're like, okay. Well, this person specializes in, like, browser rendering performance.

What could they possibly be doing at Google? And it's like, well, obviously, Google JS building a browser. That's all we think they could possibly be doing. So, like, that was Before, like, Chrome? Yeah. So that was so Chrome, like, the Wow. Yeah. Wow. So like, we didn't know what it was gonna be, but obviously, we knew it was coming.

And so, you know, it comes out. But I think what we didn't anticipate, or at least Wes I didn't anticipate, is that not just that they would build a good browser, but that they would push their full Google might behind it. Now, like like like they would advertise Chrome on Google Scott. Like, you load a Google Hangout, like, download Chrome. And, like, they would really push it very Yarn. And and then they would do initiatives like Chromebooks and stuff like that to, like, get, Chrome, you know, absolutely everywhere.

So I think I think, realistically, it just sucked the oxygen out of the room for any other browser to exist in a Windows world. And, you know, I think the only thing that keeps Safari alive is that it's, you know, it's tightly bundled to whatever Apple shipping. You know, like, that's that's the thing that saves it. And so yeah. It's it's it's disappointing. I think, you know, I I liked Firefox. I, you know, I think it's a good browser. You know, I don't but I don't use I'd use Chrome. You know? Like, I think that's Yeah. Unfortunately, where you kinda gotta be.

Yeah. Totally.

We had some questions from listeners. In fact, here's a question from Killian Volkoff who actually wrote the really incredible, testing browser, Polypane. I don't know if you ever heard of Polypane.

It's a really sweet project. You should check it out because it, it it'll if you load up your site, it'll load up your site, obviously, in the, different browser widths, but it also tell you every accessibility error on your site. It'll show you the OG images. It's it's just a really cool product. So, Killian's the man. And he asked us or he's he's asking you, where is the need for jQuery 2024? And he doesn't mean necessarily, like, jQuery as it was. Basically, what he's asking is what's harder than it should be today in web development?

That's a good question. I think there are a number of things that are still very hard, unfortunately.

And but I don't see the obvious.

Like like, you just we mentioned, like, like, accessibility, for example.

So obviously, there are great tools that exist for accessibility. You know, there's like axe and stuff like that. They can do automated analysis and looking at, you know, things like, oh, you know, this text that looks like a button doesn't behave like a button, or you have your headers in the wrong order, or, you know, semantic HTML kind of stuff. Yeah. But the vast majority of accessibility issues that we find when we're actually doing accessibility work JS is much higher level than that. Where it it's it's like, oh, you know, someone who's, you know, using a screen reader, they have a hard time navigating this site in a way that makes sense to them. And that's something you can't in you know, just automate away. You need to have 2 ends in the loop doing that testing and analysis.

And I think that's the sort of stuff Wes, unfortunately, there's there's no good solution to this other than just doing the hard work of of, you know, training people, you know, getting designers trained on accessibility so they make accessible designs, so that they the engineers didn't build accessible implementations.

But the yeah. I mean, that's not a it's not a gratifying answer. I think Sure. No. It's I do think that for most people, performance is also very hard. I mean, frankly, it's hard for me too. Like, you like, making application that's very fast.

Because the thing is is that I think most people are kinda caught in this situation Wes, like, hey, if you wanna use the tools that everyone else is using, you know, you wanna use React, you wanna use, you know, this library and that library, and pull these things together, and now you have a wonderful Node application.

Then all of a sudden, you know, you have an application that's many hundreds of kilobytes big or whatever it is. It's a huge thing.

2, you don't understand how to optimize it. Like, what are the ways in which it can be optimized? And 3, like, I think a lot of these frameworks, for better or worse, are sort of black boxes. You don't understand what's happening internally and how to make them work faster.

Even if you're using just just plain React, you know, there's all these frameworks Node, like, Wes, if I forget the so called this, like, the 1,000,000 JS stuff like that. Like Oh, yeah. That are like attempting to do optimization on React. I guess that's you know, it's it's worthwhile, but also at the same time, it's like you end up almost writing code that would look almost foreign to someone who JS writing normal react. Like, you know, having to have your, you know, state behave in certain ways and having to memorize every every single object, you know, all these sort of things. So, like, I think that's the sort of stuff where I think there's this gulf between, like, what you would learn in a basic tutorial about, like, how to use React. And then, like Mhmm. How to actually write React in a way that is extremely performant and fully optimized, whatever that means. You know? Yeah.

We had a couple Wes just about, like, similar to the question we had about JavaScript sprinkles, which is instead of going all in using, like, a React application or whatever, but there's sort of this other idea, which is, like, kinda like jQuery was, which is write your HTML and then sprinkle on a little bit of JavaScript, on top. Do you have any thoughts or opinions on that approach these days, and is that still a valid approach?

Yeah. I think that's I think that's definitely still valid. I think it depends on the kind of site you're trying to build. Absolutely. Yeah. I think if your site is relatively static and you're not building up, quote unquote, application, then, yeah, absolutely, that is a place where minimal JavaScript makes a ton of sense. And it's also a a place where there are frameworks, you know, like, Astro and stuff like that, that are extremely useful, that sort of thing, where you can write your, you you know, add a new little bit of JavaScript. And if it turns out you don't need a JavaScript, it just compiles it away and you never ship it to the client anyway. That's beautiful. Don't even have to think about it. It's like Yeah. I think that's the sort of stuff that it absolutely makes sense. And in fact, in some ways, it's easier to do than ever. You could have that little bit of JavaScript to do the precompilation or whatever you need to do and yeah. Just do that. I have a fun question.

Why the dollar sign in jQuery? That was kind of the the indicator that you were using a a jQuery function.

So the reason I picked the dollar sign actually came from prototype.

Mhmm. And so the prototype JavaScript library, they had their own dollar sign function.

And I didn't realize I remember I I didn't realize that you could have a function named dollar sign prior towards seeing prototype.

And their function, you gave it it was a shorthand for get element by ID. So you just pass in an ID and it would do get element by ID and then then query it. And I remember, I I'm fairly certain that the very first release of jQuery was actually I made it as a drop in replacement to that. So then that way, if you provided an ID, it would do get element by ID and return that. And if not, it would treat it like a CSS selector and then do the CSS selector. And of course, that that that gets complicated because then what if you have, like, you put body in there. Are you getting Yeah. The thing name with the ID Bos or you're getting the body tag? You know, like so anyway, it it didn't it didn't fly for the long term. But, like, that's part of reason why I picked dollar sign just because yeah.

I wanted to be a replacement for that functionality.

Yeah. Nice. I I know what I was gonna ask. I'm curious if you have any stories of your name showing up in the license since it's such a widely distributed piece of software.

It's always really interesting to me to pull up licenses. Like, the other day, somebody found out that, BMW head system has RxJS running in it. You know? And, like, I'm pretty sure your name was in is is in the license of jQuery. So did you ever get any, like, random calls from people trying to get support? Absolutely.

And so it got it got better at a certain point because at a certain point, I transferred ownership over to the Jake Wes Foundation. So then at that point, it was copyright Jake Ray Foundation. It Wes my name wasn't in there anymore. Early versions of Jake Ray, it was yeah. Copyright John Resig.

But the yeah, there was yeah. People would be like, oh, yeah.

You hacked my website and what's your name doing in here? Or or people or people would find scam websites or whatever, and then they would see they would search through it and find my name in there and think I was scamming them or something out of I mean, oh my goodness. It was a mess. I'm so glad my name's not attached to it in the literal sense anymore. I mean, I think it's I do think it's Sanity, like, you know, I got very used to seeing, especially stuff that use like jQuery UI, for example.

Like, you know, I I still come across applications that are using jQuery UI, and I can spot that in a millisecond. Yeah. You can feel it. Yeah. It's a distinctive feel. I'm just like, well, I know I know what they're using. And but, like, yeah. It's, Yeah. It's a bit wild.

Wow. Oh, that's great. Do you have any crazy debugging stories, or anything that, like, almost made you quit the coding entirely? Because back when you started, it was what? Was it IE 6 at the time, or was it even before that?

I think the earliest okay. Well, whenever jQuery, we were still supporting IE 55 from Mac, the first version.

When I I mean, when I started, okay. I mean, when I started cutting was forever ago that's, you know, pre, a lot of things. I think the Pre console log probably. Hey. Oh, yeah. Yeah. Yeah. No. I remember when console log came out in the early Firebug.

It's a firebug. But, like, I think I was because I was doing browser stuff when I was in high Scott. And so this was, you know, like, 98, 99, 2000 or so.

And, you know, I had, like, a Angel Fire site and all that sort of stuff. You know, I was just doing that sort of thing. But I remember when I first heard about CSS in that time frame, and it was like, and I couldn't believe it. I was like, I'm like, what is a div? What is this stuff? And I'm like, yeah. This thing it was it was mind blowing.

But anyway anyway, it is yeah. I think I'm sure I have some from, you know, Khan Academy here. We hit some, you know, wild stuff over the years. A lot of stuff about caches and stuff like that. And then there's the caches going wrong is the biggest thing.

Oh, yeah. Jeez. Oh, yeah. Because we do service Node rendering and we, cache everything in Fastly. So we use Fastly as a CDN. So we pre render our or like, the Wes come in, it behaves, very similar to, I think, how Vercel does stuff Node, which JS, you know, we use a lot of the, the good headers with this. Where where it's like stale while we validate and stuff like that. Yeah. So we can, you know, render the page, serve up an old version, but, you know, and, rerendering in the background, and then, you know, give the updated version.

And we do at the moment, we do a lot of stuff where we only do service side rendering for logged out users, but not logged in. Because usually be users that are, like, logged in, they're usually doing the full using the full application and there's really not a whole lot of benefit to prerendering anything. Like, at the point, they're just loading the application, they're doing a bunch of stuff in the application. Yeah. Whereas, like, the logged out users, they might just be hitting us from Google or something. They just don't want to view 1 page real fast, and so we just do service that rendering for them. I remember just the the complicated issues. I guess this isn't JavaScript per se, but understanding the caching layers because we would end up with our our software, like, running on our servers rendering stuff.

And then there would be multi layers of CDN caching, where where there's, like, there's the servers that are closest to ours, and then there's caching on that layer. Then there's the servers closest to the user and caching on that layer. And trying to figure out because we would be getting the wrong content and wrong stuff and trying to figure out where this will stack things were getting cached incorrectly.

Oh my goodness. I feel like I got so many gray hairs from that stuff. It's just like again, it's not it's not JavaScript per se, but that's the sort of thing where coming up with the debugging stack to help you understand this stuff. And I think I remember I was just building tools because, like, because you weren't sure when things went to cache or Node. So I'd have to build tools to just, like, send tons and tons of requests and make sure that every request was coming back correctly.

And that it wasn't, like, going off to a different server at some point and, like, getting some malformed response from the work. We have that with the the syntax website alone. We would just, like, randomly get, like, a a theme.

A random theme. Someone someone would, like, switch their theme, but they would be the one that would head off the cache render. So then, like, a random page would be a different theme.

And, we we should print that shirt. We I have made up a little T shirt that says, cash ruins all my evenings, like a play on the blue tang. So

okay. Here's what I'm going back to earlier. We Wes saying, is there something you wish reacted better? So I think something that's wild to me that I don't see talked about is that again, with Vercel side rendering, a lot of people have pushed towards using cloud functions for for doing rendering, which makes sense. I think there's a lot of benefits to it. Namely, like, you no longer have to worry about state across renders, because you load all the code in the memory, you execute it, and then it's done. And then that that's it. You're not reusing anything.

But if you try to do anything else, like, if you're Node using Cloud Functions, if you're trying to run a server, and if you're trying to reuse that Node, that server code that you have loaded in, there's so much work you need to do to make sure that you aren't polluting the state across renders.

And there's nothing for this. I've seen no linters for this stuff. I've seen no tooling to help ensure that you aren't that you have state, that's coming across. And I think I'm I'm actually kinda wonder if people what are the reason why Cloud Functions have, you know, using Cloudflare or whatever, you know, you know, a faster computer edge, a GCF.

What a part of the reason for that is that it's just so hard to write your own server that is in fact not, that's stable.

That does not get included across renders. But I don't know. I think so that's one thing I would ask for. I've been writing my own linters and stuff for this, but, like, that's, I feel like a lot of it is highly application specifics, which JS, I think, also complicates it. You know? Yeah.

Wow.

Alright. Let's let's get in the last section here, which is, we have our sick picks and shameless plugs.

I could talk to you forever about this. Node have so many. Yeah.

Super interesting to to hear, especially, like, all the internals of Khan Academy.

I I've always wanted to do like a what was the name for that show? Like, how the sausage is made or something like that? Yeah. How it's made. Yeah. How it's made. Yeah. How it's made of all these it's really interesting. Anyways, let's get into sick picks and shameless plugs. What do you got for us for a sick pick today?

Okay. I I had a hard time deciding between. So I think I think some of the things some of the software I've been really enjoying lately, I've been really enjoying Biome.

Biome is awesome for, you know, for linting, code formatting.

It's it's great. It's so fast. It's so good. It's but I've been able to move a lot of my, simpler ESLint stuff over to it. I also mentioned early, Remix. Again again, I really like Remix. I think they've done a very good job with the design, the API design of that framework. I'm very excited to see where they go, especially with adopting RSC, which I know is happening here in the upcoming, versions. And then I think one thing I'll give a shout out to that is definitely Wes one on JS, Lingue JS. So this is a framework for doing internationalization.

It's very good. It's like one of the it's one of the few internationalization libraries that are actually made correctly.

Like, a lot of them, honestly so this is something that really bothers me JS that a lot of the frameworks I don't know what situation people are using them in, but it is not a situation where they're thinking about performance. I'll tell you that. And, and so Lingue JS one of the few that is actually thinking about how to build they they do things like have, macros for both Babble and SWC to, like, precompute and, like, render out a lot of stuff ahead of time. Anyway, I just want to give a Scott yeah. I'll give a something for that because I I think it's it's definitely it's not as popular as some of the other wrapped itinerant frameworks. It's it's kinda up and coming, but I think it's done right. Can I ask you a real quick question? It's like, what are the performance issues that pop up with internationalization?

JS it like that they're the strings are so huge that they have to load?

So I think there's a couple issues. One is most of the issues I see assumes that if you're building a website, it's gonna be like 2 languages.

Like, where you have, like, English and Japanese or whatever the other languages. And but, like, Khan Academy, we have, like, 60 languages.

Okay? Like, almost anything you do is not gonna scale because what's happening is is that they assume they make assumptions about, like, oh, you'll just have, like like, those assume that every single you have every single language embedded in the page or something like that. And it's like, well, we can't do that. We would have we would multiply the size of our thing by 60 x and that's just like, it's not sustainable.

And then additionally, there's a lot of issues around, like, figuring out how to load the the files correctly. So, like like, we actually built our own internationalization framework that predates a lot of this stuff, and we're moving over to Lingvii now.

But one of the best what we did was we did it as a post compile step. Like, we would build our application in webpack, then go through and chain and swap out all the strings, and we would have bundles, JavaScript bundles that were English, JavaScript bundles that were Spanish, etcetera, etcetera. Yeah. And this worked well for us because it meant that we were shipping 0 extra bytes.

Like like, we would it would be minimal overhead. The problem is is that pretty much no framework expects that you're doing this. It's just pretty much antithetical to how every other framework works. And so, like, we're having to move off to something like linguist. A lot again, like, a lot of frameworks just assume that, you know, you are using a lot fewer languages than you expect and you're and you're willing to load a lot more, either load a lot more strings or have a lot more of a, like, a waterfall pattern Wes you're like starting to load a page, wait for all the string JS Node. Okay. Can I continue Node? Wait for more strings to load, etcetera, which is just it's it's just bad patterns. Like, you don't wanna have that.

Wow. Wow. Alright.

Bos. Super informative. Okay. Well, I guess and I guess a shameless plug. I'll give a shameless. Yeah. I mean, I can I gotta think about it? I I mean, I I guess depending on the audience, I'll give I'll give I'll give a Scott at the, you know, Khan Academy. Obviously, that's where I'd work. You know, if you have folks, you know you know, k through 12, you know, and you wanna use it for education, this is this is what, you know, we're working on. And, you know, trying to provide a free education for people around the world. And, like, I think that's something I'm very passionate about. And Yeah. I think it's something that could be useful for a lot of folks. And it it's not, you know, US specific or English specific. As I said, you know, we have a lot of languages, a lot of, around the world. And, yeah. Anyway

Yeah. I I can attest that my,

my, 7 year old loves the kinda kept me out for his iPad. It's one of the very most favorite. So yeah. Yeah. Awesome. Wow. Well, thank you so much for coming on. Thank you. We we asked on Twitter for questions, and most of the replies were I don't have a question, but just say thank you. Like, thank you for jQuery.

Thank you for all that you've done to to shape the web into what it is today, and thank you for spending some time today with us and to talk about, web dev and JavaScript.

Yeah. Absolutely. Thank you for having me. Yeah. It's been awesome, John.

Thanks again.