Why the jQuery Creator Uses React and Typescript - John Resig

Celebrating our 800th episode with the creator of jQuery, John Resig, who revolutionized web development by simplifying DOM interactions and inspiring modern browser standards.

Welcome to Syntax! Today, we have two exciting things to share. First of all, it's our 800th episode. We are thrilled to have reached this milestone, and we want to thank everyone for tuning in. To celebrate this special occasion, we have a special guest from our GOAT list—the Greatest of All Time list. Every now and then, we dip into this list to invite someone who has made significant contributions to web development. Today, we have John Resig, the creator of jQuery, among many other achievements. We are excited to have him on the show to discuss jQuery, his current projects, and his thoughts on the modern JavaScript landscape. Welcome, John, and thank you for joining us.

John: Thank you so much for having me. It's very auspicious to be here for the 800th episode. 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. That's where a tool like Sentry comes in handy. It helps you capture, find, and solve all the errors, issues, and potential performance problems in your application quickly. We use Sentry extensively on the Syntax site to stay on top of any issues that might arise. If you're interested, head over to sentry.io/syntax to sign up and get two months for free. It's well worth it.

Host: Surprisingly, I bet that probably 20-30% of our audience has never used jQuery, especially newer developers. John, could you give us a quick rundown of what jQuery is and what the JavaScript landscape looked like when you created it?

John: Sure. When I first created jQuery, it was a library designed to simplify DOM interactions. This included manipulating the DOM, traversing it, mutating it, and even some network-related tasks like Ajax and animations. It was a useful library that made these interactions simpler and helped overcome browser inconsistencies and bugs. I started working on it in 2005 and released it in January 2006. At that time, I was building various ajaxy web applications during the Web 2.0 era and was frustrated by the browser inconsistencies. Each browser handled network requests and DOM traversal differently, which was a major headache. So, I created jQuery to provide a single, simple API that would work across all browsers, eliminating the need to worry about these inconsistencies.

John: jQuery was not the first JavaScript library; there were several before it. I was particularly inspired by the Prototype.js library, which was widely used with Ruby on Rails at the time. There were also other smaller libraries that influenced me. jQuery ended up having a huge impact because it addressed a significant need. Nowadays, I don't use jQuery anymore because I'm part of a large team at Khan Academy, where we use React and other modern tools. However, I know that many people still use jQuery, and I'm happy that it has had such a positive impact and that people have found it useful.

Host: jQuery was one of those things that we sent off to sea with a salute. We often have to explain on this podcast that the reason we don't use jQuery anymore is not because it wasn't good. In fact, it was so good that it inspired browser standards to evolve and incorporate many of its features.

jQuery revolutionized web development, making JavaScript accessible and paving the way for modern browser standards.

We are doing all the sorts of things that you would see at many other big companies, and I think people are definitely still using jQuery. I see it online a lot. I'm happy that it has had such a good life and that people have really enjoyed it and got a lot of use out of it. jQuery was one of those things that we sent off to see, but we all saluted it. Often, we have to explain on this podcast that people say, "Oh, jQuery was such a hard time in web development. I'm so glad we don't use it anymore." We have to explain 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 standards to come up to speed. Now, it is at a point where we don't necessarily need it anymore. There are still quite a few people who are on projects built on top of it and find it not worth moving, or who still prefer the simplicity of the API over the built-in stuff.

I first want to thank you because I don't think I could have gotten into JavaScript at that era without something like jQuery. I came from more of a CSS and HTML background, and getting into JavaScript was hard enough as it was. Having something like jQuery felt very approachable. When you wrote the first bit of jQuery, did you have any inkling that it would ever be used on most websites in the entire world? Certainly not. In the early days, I did a lot of promotion, marketing, and advocacy. It was an open-source framework, but I wanted people to use it. I thought it would be something that people appreciated. However, when you look at the number of people writing JavaScript seriously in 2005, it was very small. JavaScript was considered a toy language. I remember going to conferences in those early days, like 2006 or 2007, and there would be some companies talking about performance in JavaScript. It was so rare and exceptional that it was noteworthy when someone actually cared about this stuff.

Nowadays, not only is it beyond optional, but you also have to have this knowledge as a modern web developer. You have to think about performance, accessibility, and all these other important aspects of shipping an application. The industry as a whole has grown so much in the past 20 years. It's a good thing that we don't have to worry about relatively minor issues that jQuery covers. I will say that jQuery still solves the animate slide down better than most frameworks and libraries these days.

Did you see that is finally changing though? I was looking up the allow discrete animation things, and very soon we will be able to animate the height of Auto, which is going to be significant. Allow discrete and starting style are the two big ones. Wes and I talked about those a lot at my JS Nation talk. Those properties are incredible. I'm curious about the jQuery community as well because honestly, I think that the jQuery community is why I'm a web developer today.

Good documentation and a strong community can turn a simple library into a movement.

Stumbling along doing some WordPress stuff, I eventually got into the jQuery chat rooms and was amazed by the whole community. I attended a conference where I got to meet John, and I was very star-struck at the time. It was an amazing experience. I'm curious about what you did to make jQuery such a significant thing. There was a board of directors, funding, and people got paid to work on it, which is a whole other aspect aside from actually writing the JavaScript.

In the early days, I believe jQuery was the first library to have documentation. It sounds absurd now because no one releases a library without documentation, but at the time, JavaScript libraries were just pieces of code you had to read through to understand. From day one, I wanted to ensure the library's success by writing documentation and building up the community. One exceptional thing we did was have people whose job it was to manage community outreach, support, and onboarding. This was very impactful.

It's fun to see where a lot of the folks from the jQuery team ended up. Many are now at Microsoft, Meta, or running other significant projects. The importance of building and fostering that community, ensuring people know where to get answers, was crucial. Nowadays, it's simpler with GitHub issues and Discord, but back then, it was harder with mailing lists and jQuery Forum software. Helping with onboarding and understanding the software was impactful.

That's how I got my start, making quick YouTube videos explaining common hiccups people hit. The power of good documentation is unbelievable. As for plugins in jQuery, they were a big part of the community for me. The first real thing I ever shipped in open source was a jQuery plugin. Were plugins intentionally a community-growing thing, or was it just to allow people to extend and ship their own things?

Building a strong community around your project can lead to incredible growth and collaboration.

Plugins were there from day one. jQuery would return a jQuery object, and every call would return another one, allowing people to add whatever they wanted. As time went on, we realized people needed access to some internals, so we exposed documentation and internals for more powerful plugins.

In the early days of jQuery, the community quickly began creating plugins within the first few months of its release. People were making powerful plugins, and those who demonstrated exceptional work were often invited to contribute directly to jQuery. This approach helped build and foster a strong community. For example, jQuery UI and jQuery Mobile, collections of UI and mobile components respectively, originated from community contributions. The developers behind these projects were brought in and supported to make their work official, thus enhancing the community's offerings.

When asked if any money was made from jQuery, the response highlighted that commercialization of JavaScript libraries has become more sophisticated in recent years. The speaker did not make money directly from jQuery but joined Mozilla in January 2007 as a developer evangelist, focusing on documentation and public speaking. It was only after a few years that they were allowed to work on jQuery as part of their job, which lasted for about a year and a half. This was the closest they came to making money from jQuery.

By 2011, the speaker left Mozilla and stepped down from working on jQuery due to burnout from maintaining such a widely-used open source library. Maintaining jQuery was very tiring work because any change, even a bug fix, could break some website somewhere. This made the work aggravating and challenging. Additionally, the speaker felt they were in a peculiar place in their career, having only shipped applications they built personally and never working on a team to build and ship an application. This led them to join Khan Academy, driven by an interest in education and the opportunity to work on a team.

From managing teams to coding millions of lines, my journey at KH Academy is all about evolving tech and architecture.

Stepping away from work can be refreshing, allowing one to focus on something else. Speaking of work, let's discuss your tenure at KH Academy. You've been there for approximately 12 to 13 years. What exactly are you doing there?

Currently, my title is Chief Software Architect. I oversee the architecture for KH Academy, including both web and mobile native platforms. I recently stepped down as the manager of the front-end infrastructure team, and we now have a new manager who assists me. However, you can still consider me the PM for that team, as I help drive the direction of our projects.

My day-to-day responsibilities are split between working on the overall architecture for KH Academy from an engineering perspective and focusing on front-end specifics. This includes not just front-end related tasks but also working on LLMs and other architectural elements like server deployments, build processes, and the general application architecture. I am very passionate about front-end development, including build systems and CSS frameworks, and I have strong opinions on these topics.

I am still actively coding, currently working on some internationalization projects. People often ask on Twitter if I am still coding, and a look at my GitHub, which is solid green with commits, confirms that I am.

Regarding the tech stack at KH Academy, the back end is built on Go and runs on Google's Compute Platform (GCP). We use GraphQL and employ a federated approach across our services. The front-end tech stack is extensive, with millions of lines of code. We were the first consumers of React outside of Facebook and Instagram, and some ancient parts of our application still use jQuery, although these are rarely touched.

We have legacy React code dating back to the create-react-class era and have been working on upgrading it. Recently, we transitioned from Flow to TypeScript, a significant project given the scale of our codebase. Our build processes use Vite for development builds and Webpack for production builds, although I aim to change this soon.

We're transitioning to modern frameworks and tools to improve performance and maintainability.

We are currently working on a significant project to transition our system to modern frameworks such as Next.js and Remix. Our existing setup, which includes custom route management logic using React Router, predates these advanced frameworks. Personally, I am inclined towards adopting the upcoming React Router that integrates with Remix, as it seems ideal for our needs. However, this transition will require substantial architectural changes.

On the CSS front, we are still using a CSS-in-JavaScript framework called Aphrodite, which we developed at KH Academy. We are now considering moving away from it. The main issues with Aphrodite are its runtime performance and incompatibility with React Server Components. Modern libraries compute CSS at build time, which is more efficient. We are exploring alternatives like CSS Modules or Panda CSS to generate CSS at build time. Notably, we are intentionally avoiding Tailwind due to its impracticality for our large, existing codebase.

Regarding our transition from Flow to TypeScript, although Flow had certain features and performance advantages, the widespread adoption of TypeScript made it a more practical choice. The market effects and the availability of TypeScript types for new libraries outweighed Flow's benefits, making the switch imperative despite the challenges involved.

GraphQL simplifies data management and boosts efficiency, making it ideal for both large companies and personal projects.

Incrementally faster flow is often lost every time a new library is adopted, especially when there are no types for it in Flowland. This becomes a huge hassle and the impact of these market effects is hard to overstate. Eventually, we realized that this was ridiculous and we couldn't keep doing it. Unfortunately, it was imperative to undertake this painful project.

I want to ask about GraphQL as well because I know you wrote a book on it. Every single time we have someone on the podcast who talks about GraphQL, they mention that it works really well for large companies with lots of services. GraphQL is excellent for a federation layer, which acts as a single layer to join them all. Is that where you see GraphQL these days?

I don't think it's necessarily exclusive to large companies, but for us, it makes it very easy to manage our development style and processes. For an individual just making a project, GraphQL could still be helpful. Going back to the world of writing REST endpoints, where each endpoint has to be custom-made, seems less efficient. Being able to define your schema upfront and have access to all the data needed through resolvers is much more convenient.

It also depends on how much you're invested in using types. If you're just throwing code out there without caring about tests or types, then GraphQL might not be for you. However, the benefit of having typed queries is incredible. It allows you to know every part of your application that will break if a field is changed, enabling refactoring that is not possible in a REST-style world without custom types.

Personally, I find GraphQL useful even in my side projects. When I return to a project months later, the schemas and types help me remember what I was doing and prevent me from breaking things. GraphQL is self-documenting, and tools like playgrounds make it simple to understand your data at all points.

React's ecosystem is unbeatable for building versatile apps across web and mobile with a single codebase.

Regarding frontend frameworks, I know you used jQuery until you adopted React. What was your frontend framework journey like? Did you try other frameworks and not like them?

I've experimented with other frameworks personally, but I keep coming back to React. The model matches really well for me; I understand what it's trying to do. I've tried other frameworks, but I don't want to mention them because sometimes when someone in my position mentions them, it becomes the title of the show. I think the React model meshes well for me. There's a huge ecosystem of stuff built on top of React, where you can choose from various component libraries. I've also done React Native work, and we're in a world now where you can build an application and ship it on mobile native (iOS, Android) and web using the same codebase and components, all in React. I think that's wonderful.

There are other frameworks that people really like, and I'm not going to yuck their yum. For myself, I'm still digging into React. However, there are parts of React that have gotten so complicated, like server-side rendering. At this point, you almost have to use a framework; there's no point in trying to roll your own. We just finished upgrading to React 18 from React 16, and I know React 19 is coming out. In our codebase, it gets complicated. We do our own server-side rendering layer, but I want to move to something else. Realistically, we might have to use a framework like Remix or React Router. They have made a lot of good architectural choices, and some of those decisions are being rolled back into the React RSC (server component) decisions, which is smart.

There are certain things, especially with suspense and other features, that make server-side rendering really complicated. Some architectures are now impossible to do in an RSC React world, and maybe that's for the best. For example, our Aphrodite won't work in that world. I wish the React team would provide more guidance on the correct way to build and ship an application, rather than just suggesting using one of the blessed frameworks like Next.js or Remix.

Khan Academy's mobile apps use React Native but share minimal code with the web platform due to their different scopes.

Remix and React Router are great; we really like them, and they're fantastic. We totally love Ryan here too. The Khan Academy mobile apps are all React Native. That's awesome! However, even though it's React Native, we don't have very much shared code between the web platform and the native platforms.

Part of the challenge is multifold. The thing we do have shared is that they're both using the same GraphQL schema. The underlying data, queries, and mutations are the same. However, the scope of the native applications is much smaller than the full website. The mobile apps are focused on material for learners, such as exercises, videos, and articles. In contrast, the full website includes teacher tools, reporting, and district features, which don't make sense on a mobile device. If we were to optimize for a mobile viewport, we would probably just do it on the web, not on mobile.

Khan Academy is interesting compared to other companies because the majority of our users are on Google Chromebooks. Chrome crushes everything, with Firefox being less than 1% and Safari a few percent. Chromebooks dominate schools, which is our primary user base.

Regarding state management, we leave that to the teams to decide. Some teams use Redux, although most have moved away from it. We use Apollo for GraphQL, with some teams using Apollo's internal cache management and state. However, many teams are just building their own state using React Hooks or providers. The tooling in React itself has gotten good enough that most teams are just using whatever is built-in.

As a previous Mozilla employee, I have some thoughts about Firefox and its current state. When I was at Mozilla from 2007 to 2011, the offices were in Mountain View, across the street from Google. Mozilla employees had Google badges and could use the Google cafeteria. Google would give funding to Mozilla because of the search bar placement. Mozilla was very tightly tied to Google.

Google didn't just build a good browser with Chrome; they leveraged their entire ecosystem to dominate the market.

Before the release of Chrome, it was evident that Google was building a browser. Although the specifics were unknown, it was clear that something significant was on the horizon. When Chrome was finally launched, what was unexpected was not just the quality of the browser, but the extent of Google's support behind it. Google pushed Chrome aggressively, even advertising it on google.com and launching initiatives like Chromebooks to ensure Chrome's omnipresence. This strategy effectively sucked the oxygen out of the room for any other browser in a Windows environment. The only reason Safari remains relevant is its tight integration with Apple's ecosystem. Despite my preference for Firefox, I find myself using Chrome because it has become almost a necessity.

We received some questions from listeners, including one from Killian Vov, the creator of an impressive project called Polyan. Polyan is a tool that loads websites in different browser widths and identifies accessibility errors, among other features. Killian asked about the need for jQuery in 2024, essentially questioning what aspects of web development are harder than they should be today.

Accessibility remains a significant challenge. While there are great tools like Axe for automated analysis, many accessibility issues require human intervention. These issues often involve higher-level problems that automated tools can't detect, such as navigation difficulties for screen reader users. The solution lies in training designers and engineers to create and implement accessible designs, although this is not a simple fix.

Performance is another challenging area. Creating a fast application is difficult, especially when using popular tools and libraries like React. These tools can result in large applications that are hard to optimize. Many frameworks are essentially black boxes, making it difficult to understand and improve their performance. Even with optimization attempts, the resulting code can be complex and unfamiliar to those used to standard React practices.

Mastering React requires more than just basic tutorials; true optimization demands deep understanding and advanced techniques.

Whatever it is, it's a huge thing. Firstly, you don't understand how to optimize it, like what are the ways in which it can be optimized. Secondly, 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 plain React, there are all these frameworks now, like the Million JS and stuff like that, attempting to do optimization on React. It's worthwhile, but at the same time, you end up almost writing code that would look foreign to someone who is writing normal React. You have to have your state behave in certain ways and memorize every single object. This highlights the gulf between what you would learn in a basic tutorial about how to use React and how to actually write React in a way that is extremely performant and fully optimized.

We had a couple of questions similar to the one about JavaScript sprinkles. Instead of going all in using a React application, there's this other idea, kind of like jQuery was, which is to 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? Absolutely, I think that's definitely still valid. It depends on the kind of site you're trying to build. If your site is relatively static and you're not building a "quote-unquote" application, then minimal JavaScript makes a ton of sense. There are frameworks like Astro that are extremely useful for that sort of thing. You can write your little bit of JavaScript, and if it turns out you don't need it, it just compiles it away and you never ship it to the client. That's beautiful because you don't have to think about it. In some ways, it's easier to do than ever. You could have that little bit of JavaScript to do the pre-compilation or whatever you need to do.

I have a fun question: why the dollar sign in jQuery? That was kind of the indicator that you were using a jQuery function. The reason I picked the dollar sign actually came from Prototype. The Prototype JavaScript library had its own dollar sign function. I didn't realize you could have a function named dollar sign prior to seeing Prototype. Their function was a shorthand for getElementById. You just passed in an ID, and it would do getElementById and then query it. I'm fairly certain that the very first release of jQuery was actually made as a drop-in replacement for that. If you provided it, it would do getElementById and return that, and if not, it would treat it like a CSS selector. Of course, that gets complicated because if you put "body" in there, are you getting the thing named with the ID "body" or the body tag? It didn't fly for the long term, but that's part of the reason why I picked the dollar sign.

Debugging caching layers can turn your hair gray!

I found out that the BMW head system has RxJS running in it, and I’m pretty sure your name was in the license of jQuery. Did you ever get any random calls from people about it?

Absolutely, it got better at a certain point because I transferred ownership over to the jQuery Foundation. At that point, it was copyright jQuery Foundation, and my name wasn’t in there anymore. In the early versions of jQuery, it was copyright John Resig. People would be like, "Oh yeah, you hacked my website, and what’s your name doing in here?" Or they would find scam websites, search through them, and find my name, thinking I was scamming them. It was a mess. I’m so glad my name’s not attached to it in the literal sense anymore.

I do think it’s funny. I got very used to seeing stuff that uses jQuery UI, for example. I still come across applications using jQuery UI, and I can spot that in a millisecond. It has a distinctive feel.

Do you have any crazy debugging stories or anything that almost made you quit coding entirely?

Back when I started, it was IE6 at the time, or even before that. The earliest version of jQuery supported IE5 for Mac. When I started coding, it was forever ago, pre-console log probably. I remember when console log came out in the early Firebug. I was doing browser stuff in high school around 1998-2000. I had an Angel Fire site and was just doing that sort of thing. I remember when I first heard about CSS in that time frame, and it was mind-blowing.

At Khan Academy, we’ve hit some wild stuff over the years, especially with caches going wrong. We do server-side rendering and cache everything in Fastly, using it as a CDN. We pre-render requests, serve up an old version, and render in the background to give the updated version. We do server-side rendering for logged-out users but not for logged-in users. Logged-in users usually use the full application, so there’s not much benefit to pre-rendering. Logged-out users might just be hitting us from Google and want to view one page quickly.

Debugging cache issues gave me gray hairs, but building tools to ensure correct server responses was worth it!

Understanding the caching layers was complicated. Our software would run on our servers, rendering stuff, and then there would be multiple layers of CDN caching. There’s caching on the servers closest to ours and the servers closest to the user. On that layer, we were trying to figure out why we were getting the wrong content and wrong stuff. We needed to determine where in the stack things were getting cached incorrectly. Oh my goodness, I feel like I got so many gray hairs from that stuff. It's not JavaScript per se, but it's the sort of thing where coming up with the debugging stack to help you understand this stuff is crucial. I remember building tools because we weren't sure when things would get cached or not. I had to build tools to send tons and tons of requests to ensure that every request was coming back correctly and not going off to a different server at some point, resulting in a malformed response.

We had that issue with the syntax website alone. We would randomly get a different theme because someone would switch their theme, which would then clear the cache render. Consequently, a random page would display a different theme. We even joked about making a t-shirt that says, "Cache ruins all my evenings," as a play on the phrase "Theot Tang."

Going back to what we were discussing earlier, is there something you wish React did better? Something that stands out to me, which I don't see talked about much, is server-side rendering. Many people have moved towards using Cloud functions for rendering, which makes sense due to the benefits. You no longer have to worry about state across renders because you load all the code into memory, execute it, and then it's done. However, if you try to do anything else, like running a server and reusing that server code, there's a lot of work needed to ensure you aren't polluting the state across renders. There are no linters or tooling to help with this, and it complicates things further.

I've been writing my own linters for this, but a lot of it is highly application-specific. This might be one reason why Cloud functions, such as Cloudflare or fast compute Edge GCF, are popular—it's just so hard to write your own server that is stable and not polluted across renders.

Alright, let's get into the last section here, which is our sick picks and shameless plugs. I could talk to you forever about this; it's super interesting to hear about the internals of Khan Academy. I've always wanted to do a show like "How It's Made" for these things. Anyway, let's get into sick picks and shameless plugs. What do you have for us today?

I had a hard time deciding, but some software I've been really enjoying lately includes Biome. Biome is awesome for linting and code formatting. It's so fast and good, and I've been able to move a lot of my simpler ESLint stuff over to it. I also mentioned Remix again. I really like Remix; they've done a very good job with the design of the API. I'm excited to see where they go, especially with adopting RSC in upcoming versions.

Lingui JS is the internationalization framework that gets it right, especially for large-scale, multilingual projects.

I think one thing I'll give a shout out to that is definitely less well known is Lingui JS. This is a framework for doing internationalization, and it's very good. It's one of the few internationalization libraries that are actually made correctly. A lot of frameworks don't consider performance, but Lingui does. They have macros for both Babel and SWC to pre-compute and render out a lot of stuff ahead of time. I just want to give a shout out to that because it's not as popular as some of the other React internationalization frameworks. It's kind of up and coming, but I think it's done right.

When it comes to performance issues with internationalization, there are a couple of key points. Most frameworks assume you're building a website with just two languages, like English and Japanese. However, at KH Academy, we have around 60 languages. Many frameworks assume you can embed every single language in the page, which would multiply the size of our application by 60 times, making it unsustainable. Additionally, there are issues with loading the files correctly. We built our own internationalization framework that predates many current solutions, and we're now moving over to Lingui. Our previous method involved post-compile steps where we would swap out all the strings and create JavaScript bundles for each language, minimizing overhead. However, this approach is antithetical to how most frameworks work, so we're transitioning to something like Lingui. Many frameworks assume fewer languages and are willing to load more strings or follow a waterfall pattern, which is inefficient.

Thank you for spending some time with us to talk about web development and JavaScript. Absolutely, thank you for having me. It's been awesome.

Watch: youtube.com/watch?v=aE9mIWqC8cs