The way we write JavaScript in 2030 will be completely different than in 2020. Here's why: the slow death of IE11 and rollout of ES Modules will converge toward a new generation of JavaScript tooling. These tools are faster, typesafer, and polyglot, leading to both a better developer and user experience. Change is afoot!
Transcript
Intro
Hi everyone. My name is Shawn, also known as Swyx on the Internet. And I'm here to present this idea, this decade long thesis that I have, that's called The Third Age of JavaScript.
So what's the story so far? You can break JavaScript's periods up into two or three different ages. The first age was from 1997 to 2007. There was a lot that was happening in 2008. There was a world crisis going on. So you could vaguely start picking things up again in 2009, going onto 2019. 2020 was another random mix of events, but there were still a lot of news going on. And now we're well into the 2020s. And I want to talk about that. I want to try to categorize things in a neat little bow. Obviously, history is never as neat as historians put it. But, we can actually talk about different themes and speculate on what themes are to come.
Ages of JavaScript
[01:13] So the rough table of contents that we're going to cover today, we're going to cover the first age, the second age, and then the two components of the third age I really would like to talk about, which is ES modules and the death of IE11, as well as polyglot tooling, and collapsing layers of tooling. And then the death of JavaScript. Potentially what comes after the third age of JavaScript because the story doesn't end there. But, maybe it transitions into a different story.
The First Age
So the first age of JavaScript, 1997 to 2007. For those who want to know more about the origins of the JavaScript, you should actually hear it straight from the horse's mouth from Brendan Eich. He gave this really great talk at Dot Conf on a brief history of JavaScript. And the real insight here is that JavaScript was based on a lie. Netscape actually attracted him to build JavaScript telling him that he could build scheme in the browser. And when he arrived, they told him, no, you actually have to build a Java like clone that really isn't Java at all.
[02:17] So it's a very interesting period in JavaScript's history, which is a very formative period, as well. So there was this very hot period of formalization. So I marked the start a JavaScript in 1987, technically went back a few years before that, but ECMAScript 1, 2, and 3 were pumped out in fairly short order. And then there was a long period of silence where, essentially, there was a civil war where we didn't really agree on the direction of ECMAScript 3.1 or ECMAScript 4.
And, essentially, the way that the community started dealing with it was to have two tracks. So one was, they started building compile to JS dialects of Java. So, there's some straight up forks like ActionScript Qt, JScript, or a WMLScript.
[03:05] These are not compatible with JavaScript at all. Or you could stay within the bounds of JavaScript and just modify the heck out of it. So you can have jQuery, dojo, and MooTools. Obviously, jQuery did end up winning in the end.
But I think 2008 was still a pivotal year, despite not being a gray zone in terms of the way that I view my time chronology. I really liked this idea of the Oslo Meeting, where, they actually, everyone who was prominent in JavaScript at the time got together in Norway and resolve this dispute between or the schism between ECMAScript 3.1 and ECMAScript 4. And had some kind of roadmap towards harmony, which is ECMAScript 5. So they said, all right, instead of this evolutionary approach of 3.1 or a revolutionary approach of 4, let's take the best of each world and just come to some kind of concession so that browsers can start making a step ahead again.
[04:05] If you want more details on this, you should check out the manuscripts of JavaScript: The First 20 Years. It's just kind of a book slash talk that was submitted for the proceedings of ECM on programming languages that was supposed to happen last year. And, it's 200 pages. So no one's read it. I've only skimmed it a little bit. But this is the story of JavaScript from the authoritative authors, Brendan, who made JavaScript and Alan Morris Bach, who was the principal editor for ES 5 and 6.
The Second Age
[04:37] Then we'll talk about the second age of JavaScript. So if the first age of JavaScript was about forming the language, the second age of JavaScript is about the community, the ecosystem. In 2009, all these things happened in the same year. We reach ECMAScript 5, the harmony specification, but then we also had this weirdly common JS syntax that was proposed that became the eventual dominant module syntax in Node.JS and in the browser. There was Node.JS itself was launched in 2009. And as well as npm was also launched in 2009. So all these things that we take for granted today was invented in the same year.
There are different sections to the community. So I'm going to break out a few of them. So the first was runtimes. You can track the gradual evolution of being able to run JS everywhere. You could run JS in a browser. Chrome OS was started in 2009, which is wild to think it's that young. Electron, you can run in a desktop, you can run it on phones, and then you can have specialized runtimes just for Android. And, that's a really interesting low-level engineering thing that's going on. Obviously, there's probably other runtimes that I don't even know about. So let me know in the comments, if there are, that you think I should touch on.
[05:49] The second part of the ecosystem I want to touch on is the emergence of build tools. So the way to help you compile and build and bundle your JavaScript. So Google Closure compiler and CoffeeScript both have emerged in 2009, as well. Very, very significant year for innovation. There was Grunt, Webpack and TypeScript round about the same time in 2012ish, 2011. Gulp and Traceur came out in 2014. And Rollup. And Babel replaced Traceur well as the newer versions of Bundler's Rollup, Parcel, and Bazel came out in the subsequent three years.
Forming the ecosystem: frameworks
[06:24] Frameworks also came out. So we had, before Angular and Backbone, we had a bunch of others. But, let's just call it the start of the second age of JavaScript with Angular and Backbone. Meteor came on and tried to be full stack with its own UI layer called Blaze. React and Vue came out 2013 and '14 and Svelte came out in 2017 but was essentially reinvented in 2019. That's the history. It's over 10 years of runtimes and build tools and frameworks.
The shift left in JS tooling
And there's one more trend, which I like to call out, which is this idea of a shift left in JavaScript tooling. I've done two separate talks on this. One on Svelte and The Great Space Elevator, talking about the evolution towards compile upfront, or compiler only frameworks, as well as growing a meta language, the importance of developer experience and developer tools for frameworks. So this was presented at React Rally 2020.
The Third Age
[07:23] So now we come to the third age where we basically do an rm -rf on legacy JavaScript. Some kind of leader actually did a nice mock image of this. I never played this game but I heard it's lots of fun. But, essentially the two assumptions here, that are going away, is that common JS, there's the build target for all of our tooling, which introduces a lot of bloat. So we're going to move to ESModules and it's going to be assisted the slow death of IE11. And I'll give you my updates on those trends. And then the second theme that we talk about is JavaScript tooling. That we start writing JavaScript tooling, not in JavaScript anymore. We now write it, most of it, in TypeScript, but also increasingly in Rust and Go, as well as the collapsing layers of the different jobs of the tool.
The Third Age: ES Modules
[08:14] So first I'll talk about the ESModules and the death of IE11. So for those who don't know, what is an ESModule, is really just to import and export syntax that you might be seeing in a lot of your code that you might not actually know is being compiled away Webpack. So Webpack is acting as a sort of interpreter into environments that don't actually have the import and export ESModule native language.
But, now both browsers and no JS have essentially this capability unflagged. There's still some nuances like using MJS, the Michael Jackson script, if you want to specify that you're working in modules. And there's some kinks to work out there. But and large, this ecosystem is moving over. If you want to read a really good primer on this, you should check out the MDN docs on ESModules. And I think the V8 team also has a really good document on ESModules, according to them, as well.
[09:18] So there's some nuance here and there's some more development to be done. But it's coming along and it's looking really good. So there are limitations that people should be aware of. For example, you can't really just build a ESModules and ship them in production in any of significant size. Even the VA team recommends that there's a bottleneck of a loading pipeline when you're loading 300 modules in. So, if you start building any significant kind of app, you probably don't want to do this. But it probably will be fine for a website. But you can still use a dev only, un-bundler, like Snowpack or Vite, or WMR. And I think that's also a really good solution. So that's something that you see refreshing a lot of the tooling in JavaScript, now, today. That you don't have to bundle for development so your development refresh cycles can be a lot faster. It can be constant time refresh instead of having to rebuild the entire projects every single time you save.
The one hurdle with this, of course, is IE11, the elephant in the room. There's support across the board for the ESModules native spec, but not for IE11. So part of the adoption of IE11 is very contingent on the death of IE11. So on the top left, this is a screenshot of analytics.gov.us. And the key number to watch is the percentage visits from Internet Explorer. The US digital service has actually identified the 2% mark as the critical benchmark level where they support browsers. It used to be 3.6% in November 2020 when I first started writing about this thesis. It is now fallen to 2%. So it's fallen steadily and we're probably at about the time. And I think that the US government could drop IE11 this year. And I think that's a very big deal because that's a catalyst to say that, okay, if the US government has dropped IE11, we can drop it now at work. Obviously, a lot of other people in the ecosystem have gone ahead and agreed with that decision. So the Vue ecosystem has agreed to drop IE11 support. Agular has agreed to drop IE11 support as well as a bunch of other peer companies like Skillshare, Twitter, GoDaddy, WordPress, Drupal, Daily Motion, LinkedIn, and of course, Microsoft itself. It's also really helps this setting an edge. So the new Microsoft Edge where they have IE11 compatibility mode. So even if your app needs to be running IE11, you don't have to visit IE11, you don't have to use IE11 most of the time.
[12:03] And I think that's a really big catalyst for adoption as this gets rolled out across some of the larger enterprises that require all these IE11 apps and don't have the budget to rewrite all those things just to upgrade browsers.
So adoption is slowly happening for ESModules, both in the browser. So here's a screenshot of some stats from browser adoption of ESModules. It tripled in 2020. And I think it's going to do very well in 2021, as well. As well as in Node.js because it's mostly driven Sindre Sorhus who authors half of the ecosystem in Node.js, where he's just going to just transition all of his libraries over to ESModules. So if you want to use his stuff, you have to use ESModules inside of node. And I think it's happening in a coordinated fashion because everyone senses that the time is now. It's been a long, long time coming, ever since the first idea of standardization was floated in whenever this picture was taken with Addy Osmani. But, it's coming. It's really coming.
Third Age: New tooling
[13:09] Okay. The next part of the third age of JavaScript is the change in tooling. So Brandon Dail, used to be from Facebook, called it, in 2018, saying that in less than five years, most popular JavaScript tooling will not be written in JavaScript. And I think this is mostly come to pass, but in different degrees. So the two assumptions that were being cleared right now is that JavaScript tools should be written for JS developers JS developers so that they can contribute. The reality is that they do not. So we should optimize for hot paths and speed rather than ease of contribution people who don't actually end up contributing. And the other assumption is that of the Unix philosophy. Each tool should do one thing well.
So let's talk about those in turn. So the first is that whether we should only write JavaScript. The easy answer is most people have just opted into writing TypeScript. So here's an example of how much of the React ecosystem has switched over to TypeScript. I've been monitoring it. So React router, Next.js, Yarn, Storybook, Apollo, Gats as well, have all switched over to TypeScript. And yeah, these are the results from the state of JavaScript surveys. And, the adoption of TypeScript has been extremely strong. You can basically say that TypeScript has won at this point. But TypeScript is, design, very JavaScript like.
[14:32] So what about the other languages that we want to optimize even further? Here's ESBuild benchmark. ESBuild is a Webpack competitor. And it's about a hundred times faster than the next fastest alternative, according to their own benchmarks. So take it with a grain of salt. But, it is somewhat faster, for sure. And, that basically comes from having a compiled language at its core.
And that's a very interesting observation because you also see that in Rust. You see that being adopted in Deno, in Relay, and in Volta. And these all have significant Rust percentages in their code base. And I think what's happening is this idea that we should explore polyglot tooling. So we used to have this concept of pure tooling, where you will write the external API in JavaScript, and you write the core JavaScript, as well. But it doesn't make sense to write the core in JavaScript because it's a hot path that gets executed again and again. And no matter how much optimization you can do, you can probably do better compiling it to binaries or you can also do stronger type checking. So, it's more stable core. So whatever it is, you can switch over your core tool to a systems language and benefit from optimization there. But you still leave your external API in a scripting language like JavaScript. So this idea, I call systems core scripting shell, I think this is the pattern that we're going to move towards for a lot of our core tooling. That we're going to have Goal, Rust or maybe TypeScript if we have to, and then a JavaScript exterior.
[16:04] If this sounds like heresy to you, I think it's because we're changing our concept of what exactly a tool, one tool, for one job means. So, this is a really good blog post that I found from Benedict Evans on platforms and bundling, where when word processors came out, they actually had different functionality and different plugins for word counts, footnotes, and charts. These are all separate products from separate companies that you have to go out and buy for 50 to $100 each. Can you imagine buying a word processor today and not having word counts and not having footnotes? No. So today it just comes all bundled. How many plugins and how many different little tooling do you want in a word counter? I think the definition of what the one job is changes over time. And that's what we're seeing happening in JavaScript today.
So when you look at all these tools that we're so used to putting together, why are they all different tools? And why do they have different plugins for each of them? Why do I have eslint, Babel, Prettier, TypeScript plug in, instead of just having one set of ecosystem tooling that just works well together and has single EST passes and all that optimization that can happen if you have a holistic view of what the job of JavaScript bundling is. So that's a little bit of what happens.
[17:25] So our first reaction for this was actually very simple. This is something I covered in a previous talk called Creating Create React App, which is that we just swept everything under a rug. We will say, sitting on Webpack is too hard to make a React App. So let's just sweep everything under a single dependency. And then you would just install Create React App. And, that's a magical improvement in developer experience, but we just swept the complexity under the rug. The moment we need to deviate from it, you had to eject and now you're left with all that complexity again on that configuration.
I think that's continuing to happen. This is my other thesis called React Distros, swyx.io/react-distros, if you read that blog post. But we're continuing to do that. We're sweeping that complexity under more rugs. So Create React App does that, NextGen and Gats does that for routing. And then Blitz.js And RedwoodJS does that including other custom components and state and data frameworks. But, we're starting to build on top of React as a stable boundary, rather than trying to reinvent frameworks all the time.
[18:29] As we're collapsing tooling, I think this pitch is actually really cool. This is another blog post that I have, but essentially if you look at Rome's investor slide deck, you can see the exact same chart of why all these different tools. Let's just combine them into one tool. And you can see this in Deno as well, which tries to collapse that into the no JS layer, which I think is a super interesting approach.
These two, I think it's no coincidence, that these two are now venture capital funded. And I think that's another interesting innovation as well. In the first and second age of JavaScript, it was very independent, open source, volunteer movement. But, now in the third age of JavaScript, I think there is some sense that we need a sustainable business model for great open source to be built. And I think the money is there to back it up. So if you want to start at third age of JS developer tool project, talk to me, I can put you in touch with everyone and I would be interested in funding you myself.
The death of JS?
[19:26] Finally, we'll talk a little bit about the death of JavaScript because what happens after the third age of JavaScript? And I think the best source on this is actually a joke talk Gary Bernhardt on the birth and death of JavaScript, which is an excellent, excellent exploration of what happens after JavaScript, essentially. I think that's something that Brendan Nike started to talk about as well. I had this conversation with him about what the universal virtual machine could be. And he says, it's probably WebAssembly. He has started, instead of saying always better JavaScript, he started saying, always better JavaScript and WebAssembly.
And you're starting to see that it's some of the tools that we push out. But WebAssembly is also not a magic pixie dust. I don't think it will completely do away with JavaScript forever. But it is very appropriate for some use cases. And I think it's worth exploring for large apps like Figma.
[20:24] So that's the overall thesis. This is a very short talk, but hopefully it's given you some perspective on where we've been, what we're going through right now, and hopefully where we'll end up. So I love your comments and questions. So I will be in the chat for this conference. And if you want to learn more about how to spot trends and also bet on technologies for your career, you can check out my book at learningpublic.org. Thanks very much for having me and enjoy the rest of the conference.
Questions
[20:51] Liz Parody: The first one is to speak in standups, meetups, and conference with 36%. One, you can practice those just applying to a conference like this. JS Nation, Git Nation, React Conference. You can apply to conference. That's a good way to improve that skill. Self care and prioritization. Very important, too. Writing, blogging, documentation, design, and docs. That's one of the skills I want to improve. And negotiation is the last one with 12%. It seems that there's a lot of good negotiators watching this conference. So, that's really good. The number one is speaking. Now, let's see some of the questions. One is Brian Hough: How do you master technical blog writing? I find it's hard to balance the high level versus the technical. What do you define as a technical blog post? Shawn?
[21:50] Shawn Swyx Wang: That's an interesting question. I don't think you ever master it. Just do it a lot and try to be better than you were yesterday. And after a few years of doing it, you'll be really good. Why are you trying to be perfect or master it? Just do it better than you were before.
[22:12] Liz Parody: Yeah, that's, that's a great answer. Practicing, everything you get better and improving. Another question from Stark Anderson is: Keeping your code smaller in terms of file size can keep decrease the loading times. How do you balance between keeping your code short and keeping it actually readable?
[22:31] Shawn Swyx Wang: I see. I love this question. So I think the React core team's answer of composability really resonates with me here. You should be able to break down your code into logical code blocks. And if it's too long, then you have too much going on in your head. So you should be able to abstract things into reusable functions. Actually, you don't even need to reuse them. You can just take chunks of code out and separate them so that you can abstract them into a single function that you don't have to break that obstruction nicely until you need to look into the implementation detail. Composability of code is my answer of keeping code short and readable.
[23:14] Liz Parody: That's a good answer. Composability. Now, you know. What's actually the conclusion of the death of JavaScript composer?
[23:34] Shawn Swyx Wang: There is none. It's just an observation. I view myself as a JavaScript journalist. And the goal of a journalist is to write the first draft of history in the sense that, when we look at our web dev careers, 20, 30 years down the road, when we're retired and we're sick of programming anymore, what are we going to say about the 2020s? This 10 year period from 2020 to 2030. We can already see some hints of what's going on. And I think my role here is just as call out. I think there some trends that are very interesting. And these are things that I would invest in personally. So I would just share them. And if you agree, then that's great. If you disagree, let me know and we can have a conversation about it. I'm not trying to push some conclusion onto you.
[24:17] Liz Parody: Okay. Thank you. Leah Cheek, ask: Thank you. Very interesting. When do you get feedback in early stage of plugin?
[24:27] Shawn Swyx Wang: Where do you get... Oh, okay. Twitter is a big source of my feedback. I prototype a lot of blog ideas on Twitter. And, if I see some traction, then I flesh a tweet into a full blog post. But, sometimes a lot of people have questions on where to start if you don't have any followers. And this is called the cold start problem. I would say you can join blogging accountability groups. Together with my book, I have a community that, where we support each other with our learning in public and our writing efforts. You can join a community, whether it's a paid community or a free community just among your friends to share a feedback.
The other thing I encourage people is to, I have this essay called pickup what they put down, which means if you want other people to care about what you write, then make sure you're writing about something that they care about. And one way to guarantee that they care about stuff is just look at something that they've just released. Let's say the React core team, yesterday, just released their roadmap for React Suspense. If you want to write something, they'll probably read it and they'll probably give you feedback on it. So, that's a way just to respond quickly to something that someone else wrote. And you have a much higher chance of feedback than if you just publish some random document that nobody really was looking for, asking for.
[25:50] Liz Parody: Thank you. That was a really great answer. Daniel Burch ask: How can you improve... Sorry. How can you improve explaining complicated technical ideas during daily meetings of code reviews?
[26:05] Shawn Swyx Wang: Oh wow. That's interesting. I don't really know if I have figured that out. I think the venue of a daily meeting, or a daily standup, is not the right place to explain complicated ideas. I really like the Amazon way of having a one pager or a six pager to write down the full narrative of a concept. And before what we, I worked at Amazon, we would call this a business review meeting. We would actually sit down and have 10 minutes of just reading that writeup. Basically, try to write it down instead of just coming up with it off the cuff because when you write things down, you really get to organize your thoughts.
[26:48] Liz Parody: Thank you. Buto asks: How do you balance DX and UX? Tools, providing great DX, but default, they lack of optimization in production that Gats and Next can provide. But Next and Gats are default slower than Vite and so the whole DX is diluted due to the lack of speed. How would you balance it?
[27:13] Shawn Swyx Wang: This is a more complex question than that post. Actually Gats and Next are going to move on top of the next generation build tools, like third age of JavaScript. Tools like Vite. So they'll eventually get there. We are just in a phase of transitioning tools because of this new age of JavaScript. The way I think about it is that we create better DX to create better UX. And these tools are always changing and they're always different teams trying to improve it.
[27:29] Liz Parody: Thank you. And the last question will be from Pedro Flores, who asks: Do you feel once we'll get enough traction to eventually replace JavaScript?
[28:00] Shawn Swyx Wang: Yeah. The final piece of the talk was about this question. I think the answer is, basically, no. JavaScript will always have a place. But WebAssembly will replace some of the jobs that we are using JavaScript to do. And primarily, first, it's going to be used to port over code written in other languages. But, eventually we're also going to find ways to optimize the hot paths of code that we're running in JavaScript. But ultimately, the layer around what we can do for users and to interact with the DOM is still probably going to be owned JavaScript. So eventually you'll probably have to learn a JS language. And then compile to JS language to do your work. And yeah, I think that's the natural state of things. I don't think WebAssembly will kill JavaScript.
[28:50] Liz Parody: Thank you, Shawn, for this great talk and for all these great answers. Now you have to pick your favorite questions to give the book. Thank you very much.
[29:02] Shawn Swyx Wang: I want to give a shout out to Brian Hough, I think, the first question for breaking the ice and asking a really good question. I want to answer it in more detail actually, but we don't have time.
[29:14] Liz Parody: Okay, Brian, you have a book. Yay. Thank you very much.
[29:18] Shawn Swyx Wang: We'll get in touch and I'll send you the book. Thank you so much for asking all the great questions.
Liz Parody: Thank you, Shawn.

There was a time before React, and there will be life after. If you tie yourself too closely to any technology, you might trap yourself and miss the next wave. Let's zoom out from the state management library du jour — what timeless lessons can we learn from React? In the talk I'll discuss lessons I've learned from studying React that I will take with me for the rest of my career.
Transcript
Intro
Hey, React Summit. I'm here to offer seven lessons to outlive React. So the premise for this talk is that React is older than jQuery was when React was first released. And jQuery isn't dead. It's still powering a huge amount of the internet, but it's just no longer as cool as it once was. That fate will come for React some day as well. And we should try to think about what will last beyond the React. So as we look at React on its ascendancy, and coming into its very mature phase, we should think about what lessons we learned from its enormous success.
[0:52] So hello, I'm Swyx. I work in a bunch of different things, and I do a lot in the React community. But mostly I give React talks, which is the most relevant qualification for this conference. And a lot of these talks are focusing on individual elements of React, but this is the first talk to really cover the overall philosophy, which I think can take away from that. If you want to dive into individual details, these talks are really good to cover the technical foundations from which I draw a lot of these principles.
    
7 Lessons
The seven lessons upfront are presented here. We'll talk about the reconciler, API surface area, API design, optimizing for change, testing, DevTools, and community.
Reconciler
[01:35] So the first part is that the reconciler and scheduler pattern is probably a really good idea for a bunch of different jobs. And this actually comes from Jordan Walke, which is his original insight. That, "Whatever it is your program produces, pixels, files, anything, just make your program regenerate the whole thing every time, add caching and structural sharing to make it fast. And that's it."
And obviously that's a lot of the original pitch, which I captured from the original JS conf talk. And that's the way that React sort of differentiated itself from the beginning. But maybe it's also overlooking the other MVP of React, which is scheduling, right? Which is the other part. And we are seeing a lot of innovation now when you switch over from old React to concurrent mode React. You start to get the benefits of time slicing, which is talked about a lot. And if you want to further primary on scheduling in React, definitely check out Philipp Spiess's, blog posts, which are featured here.
[02:30] This scheduler is actually starting to see implications beyond React. So the React core team actually split out the scheduler package into its own package, in the hopes that other frameworks might be able to use it. And they're working with the Chrome dev team, that's Shua from the Chrome dev team, to maybe build it into the browser. So if you want React built into a browser, this is the start.
But overall, I think this actually encapsulates the idea of a DX/UX mullet. That's my term for it. Where you have immediate mode in the front and retained mode in the back. So immediate mode, like just re-render the whole thing every single time for both the front end, the user, as well as the developer. And retain mode, which is the system in the middle, which actually retains the state.
[03:12] And this is actually true for a build system. So Jared Palmer is actually working on a build system where he has the exact same pattern. And you start to see this pattern over and over again, in GraphQL, ETL pipelines, Netlify, and a lot of other different aspects of life, where you have a developer working with a system and you want to make it fast, but also easy to reason about.
Minimal API surface area
Okay, second lesson, minimal API surface area. This one of course comes from the seminal talk Sebastian Markbage actually laying out this philosophy. And he basically, based on his experience of working with MooTools, says that a lot of library patterns are just too big and their data is just too much API, and they're not going to last. And it's actually hard to undo once you've actually created that API. So his solution is to just never try it in the first place. And you prefer an explicit and a repetitive API rather than an implicit one.
[04:03] The trade-off, of course, is that we'll have a lot more boiler plate. But you see a lot of this examples in how React grows over time. So React actually voluntarily removed its own proprietary class format for ES6 classes. You can actually see that React design use, like for example with hooks, where you can see the third-party hooks, like the user defined hooks, are on the same level with the first-party core hooks. And that's a concept that comes from Guy Steele's, talk, Growing a Language, which I highly, highly recommend. And also you can see that React tries to collapse APIs, right? They'll have these three very common component class APIs, and collapse it into GDSFP. And then also they write a blog post to remind you that you may not need it, especially if you use functions.
So just less and less API over time. And I really appreciate the React core team for that. But there is a cost, which is that you give up, there's no routing solution. No state management solution. No styling and all that that comes with React. And this is stuff that other frameworks take for granted and that React developers struggle with. So there is a cost to that. We'll comment on that in a future lesson.
API design
[05:20] But lesson number three is that API design is language design. And this is very similar to the previous point, but distinct. And the emphasis here is naming, and the way that people talk about React.
So Lee Byron actually had a huge contribution to this even before he is he co-founded GraphQL, sitting down and actually nailing the concepts, the actions, the operands, and the notifications. You can see the result of that in the design API choices of React. And these are the ones that we're familiar with. But they've changed a lot over time, but there's still a grammar that's been established that we can come to expect and recommend. And it makes sense to us as React developers. It helps us think in React, based on the language. And that's a part of the Sapir-Whorf hypothesis, which is that naming actually helps to shape our thinking. Or the words that we use helps to shape our thinking.
[06:13] You can also see this in hooks, right? The way that use whatever is a very common naming syntax for hooks, or a recommended naming syntax for hooks. And just the name of hooks itself. Like these are all the other 50 other names that were considered for hooks before they landed on hooks. And partially it's with the consideration that, yeah, you want something that's one syllable so you can refer to it in daily conversation. That's also an API that humans use instead of computers.
And overall, I think maybe Dan put it the best. He says, "UI before API." You want to start with the end result, and then you work backwards to create the APIs that help you get there.
[06:52] But here's the other principle that's really interesting as well. He says, "hacks and then idioms." Which means that he's willing to let users hack around whatever you have rather than building in an extra API just to accommodate them.
And here it's very clear what it is, if you're of a certain generation in React, where you have a lot of wrapper components just to inject something with Redux or like GraphQL. And this pyramid of doom, I love adding in a little in there, just to symbolize how deep it really goes.
[07:28] There are a lot of solutions that try to result in fixing this. Well, there's a lot of solutions that actually result in this, and you just don't have a choice, because React didn't really give you another way. See if you wanted to inject states, you needed a higher order component. There was a brief evolution for render props. Again, from the same people that were recommending higher order components.
And then I was trying to resolve this big pyramid of doom thing, I actually introduced a React RFC called React.headless component. And all of these were just like ways in which to inject behavior, which were just not really right. And we all realized that hooks were just a much better option towards the end.
Optimize for change
[08:09] Lesson number four is to optimize for change. So this is the final point on API design, which is that you shouldn't optimize for, don't repeat yourself, or you shouldn't optimize for minimal amounts of code. Optimize for change. And here's why.
So the first order of design is that your code should be easy to read and write. You should have all these characteristics. The Pit of Success one is pretty commonly stated, that you want to make the right thing the easy thing. You want to be memorable like Lee Byron making the grammar for React. That's very memorable. You'll need to be guessable. That's a really good tip from John Otander. And you also want to encourage performance, accessibility, safety, and user experience, right? These are all equally important. Don't make any value judgments on which one's more important.
[08:51] But once you've written the thing, then requirements start to change. And that's where second order design comes in. You want to also make it easy to change. If you have very brittle code, then a slight change in requirements will make your code fall apart. So the great API design actually anticipates that you want to rename, copy and paste, unify into abstraction, or break apart in abstraction, to delete or add a hack. Do all sorts of things to your code. And it needs to just not fall apart when you try to do that. So a great API not only lets you fall into the pit of success, but helps you stay there. And that's a really, really good observation.
And that's something that you see a lot in other formats. So two references, I would like to point you to, if you want to look more into this is the Stack Overflow blog, where they call this requirements volatility. As well as Hillel Wayne, who calls this requirement perturbations. Same idea, different takes.
[09:45] The React team solution to solving this is to enable local reasoning. To try to reduce as much global context as you need, and just to focus on the code in front of you. And that should allow you to change whatever you need. Because then you actually don't have to have spooky action at a distance.
You see this in Dan's blog posts, in Sophie Alpert blogging about DataLoader. You can see this in styled components, Tailwind, order relay compiler design. There's a lot of different ways in which you can enable local reasoning that helps to make things optimized for change.
[10:21] I have a lot more slides in this I had to cut out because I don't have time, but feel free to hit me up. Because optimizing for change is a fundamentally really important idea that will last way, way longer than React does.
Test the public API
[10:32] Okay. Lesson number five. Test the public API. Very, very simple one. You should write tests, not too many, mostly integration. Don't test implementation detail.
This was obviously very, very important for React, because React undertook a huge rewrite of the whole code base, but kept the tests. And the tests actually outlasted the code base. And that's not something that's very insightful for your apps.
[10:57] Obviously they also implemented this little tracker thing, for Is Fiber Ready Yet, where they actually tracked the completion towards the rewrite. And it's just a really motivating thing to see for the React code base, that has actually spread as a movement towards React apps, right?
So we've seen Enzyme sort of relatively declining compared to the React testing library, and that's as it should be. Because obviously the testing library has this focus on testing only the public API of components. That's what the users will use. And that's the only thing that you should really care about for your tests. It makes it so much less brittle, compared to what was there before.
DevTools
[11:35] Okay. Lesson number six. We're moving along to DevTools. DevTools are not optional, and you can see how much React emphasizes DevTools. So of course the React official DevTools, the Chrome plugin, is maintained Brian Vaughan on the React core team. And he does an amazing job. I don't know how much I'd pay for this, but I would pay for this. And you should learn all the intricacies if you want to debug.
React also uses codemods. This is not optional for React, basically because the React team actually has to maintain the tens of thousands of components that are in the Facebook code base. And you have to upgrade all of them whenever they change the APIs. So of course you have to automate these things and we, as the React community, get the benefit.
[12:16] The React dev warnings, it's something that is really taken to the limit with React. So you can see the React overlay, or you can see lint warnings and you can see it in the console. We even have error codes, so you can see nice errors in production, but not have extra weight in the final build out artifacts. And that's a very nice decoder experience, which I wish them more developer tools copied.
You can't automate everything. So it's nice to introduce some fixtures. I really liked this as a way to learn React as well, because you can start to toggle on feature flags and change different browsers and see how the behavior changes. It's just a really nice way to manually test things having everything in place. So you don't have any time setting it up.
[13:06] And finally, the last step is kind of like a meta-tip. Tools to hold DevTools to help you build dev tools. So for React, because it's building a library that's going to be embedded into millions of other applications, they need to keep the bundle size small and to never increase them unintentionally. And it's something that we can actually borrow for our apps as well. We should be aware of what we're building and shipping, and should be aware of big regressions. So DevTools are not optional.
Community
[13:38] The last lesson is that we should not neglect community. We want to build the community as well. This is obviously, it goes back right to the beginning of open-sourcing of React. Actually, Jordan Walke actually had to introduce JSX because he was being ignored internally within Facebook.
And then once he introduced JSX, they really liked it a lot better. But then the exact opposite happened when they open-sourced it to the public. This is Jordan, deer in the headlights, trying to introduce JSX and to a very bad reception. And here's Pete Hunt trying to rescue it, saying, "Hey, it's optional, guys. Don't worry so much."
[14:18] Anyway, I think we eventually came around to the idea. But the core of it is that, the whole early core team really listened to feedback. They were on IRC, on Stack Overflow 24/7, and they replied to every single piece of criticism viewing them as their fault.
And that work in the community paid off. They started to bring over a lot of users. In particular, David Nolen, from the ClojureScript community who built Om and really started to hype up React quite a bit. And I think that's a lot of legwork that is maybe forgotten to time. But I think if we're starting to create our own projects that we want to be as popular as React, we need to start to pay attention to the community, just like they did. And that's a lesson that we take along with us.
[15:02] Also, we need to start solving pain points. So one of the big pain points was, React is so small that it doesn't solve the rest of the applications, and people started to make memes and jokes about it. So then Dan Abramov actually went and created, Create React App, and that's a story that I tell in a separate doc called Creating Create React App.
But in general, the story of this is basically that it's a distribution of React, right? You bundle React with other things. Next.js and Gats bundle it with routing, and Blitz and Redwood bundle Next.js, and so on and so forth. You can bundle and bundle and bundle.
[15:36] What we're really seeing here is a cooling down in the creative destruction of frameworks, and the maturation and deployment of React. And we're starting to build on top of React rather than trying to compete with React. The contract for React starts to shift, right? Now the main thing that React ships is not features, it's stability. Of course, the S-curve is not the end. It can start to S again, when concurrent React is fully out.
So the seven lessons that we covered are all of these. I think it's going to be a bit hard to remember if there's seven. You know our working memory is only three to five.
So here's my breakdown. First, you have a core idea of whatever your library or framework is going to do. Then you want to work on the interface between the developer and your core library. So that's your API design. Then you want to productionize it working on the testing, working on DevTools. And then finally you want to humanize it, to make sure to meet people where they are. And that's the seven lessons. That's not the only seven lessons that you can learn from React, and there's more on the way. The React team is very generous in sharing their lessons on concurrent React. And so you should pay attention to those.
But overall, the meta-lesson I want to leave you with, is that you should fall in love with problems because the solutions come and go, but the problems will always remain.
That's it. If you want to learn more about these principles, which I think will last our entire careers, you should check out my book at learningpublic.org. But otherwise, thank you so much for having me and see you in the rest of the talks. Bye.
Questions
[17:04] Ali Spittel: Looks like most people say minimum API surface area, and optimize for change. We got a lot of ties on these, like 36%, 36%. So split down the middle. Was that what you were expecting from this question?
[17:18] Shawn Swyx Wang: The API surface area, I think so. I think it tracks with what people respond to very well. Yeah.
[17:27] Ali Spittel: Cool. Awesome. Well, we've got a bunch of questions for you, but I wanted to start with one. And that is, what are you up to now? In your introduction, I was like, you were a senior developer advocate for AWS, but I know that you moved on, because that's the team that I'm on. So what's up, what are you up to now?
[17:46] Shawn Swyx Wang: Oh, they put you in charge and I had to peace.
[17:49] Ali Spittel: That's a joke, everybody. He left before I became the manager, so.
[17:58] Shawn Swyx Wang: No, yeah, of course. No, I really... Anyway, so yeah, I've just joined Temporal.io. It is a backend microservices orchestration startup. So very, very different to what I normally do. And I wanted to, I guess, broaden out. But then also take my bets on a small company. We're a series A, very early stage and hoping to be the next big, I guess, backend orchestration startup. And if you ever have worked on long-running tasks, like sagas for the backend, this is something that you should really check out. But I'm not going to plug it at a React conference. So I had to come up with a different talk for this one.
[18:41] Ali Spittel: No, that's awesome. That's really, really cool. We have more questions too. So this one's from Juan Segebre: "What are the common pitfalls and mindsets that avoid us to optimize for change?"
[18:54] Shawn Swyx Wang: That avoid? Sorry, I didn't...
[19:01] Ali Spittel: I would guess that it's help us to optimize for change. Or that make us avoid change. One of the two.
[19:08] Shawn Swyx Wang: Because that's supposed to be good. We're not trying to avoid it. Hang on. I'm pasting my slides and my links in the Discord, that's where I have it. And I don't know if there's any other channels that should be posting it. But if anyone wants to follow up on all the resources I pasted, you can follow up there. But yeah, essentially... There's so much, right? I think just thinking about your design thinking about what changes could come in and wreck your day, is essentially the idea. And so it can be as small as things like, relying on the order of arguments. So if you notice in React, props don't really care about the order of arguments. And that's because it basically is an options object, which is something that, if you look at one of my favorite talks, Simple Made Easy, Rich Hickey, relying on the order of something is actually complexity. It actually makes you need to remember what comes after what. Whereas if you put things in independent order, you free yourself up. But then it goes as big as sort of, are you co-locating data and making things easy to delete, right? Because append-only code is a major source of technical debt. If you're scared to delete stuff, because you don't know what global effects it is going to have, then you have essentially what I call technical mummification. Because you're just slapping bandage after bandage after bandage. And you just end up with a mummy of technical debt. And yeah, so there's a lot of ways to optimize for change. And I plan to write a bigger article on this in the future. But I wanted to stick it in there, because to me, it is such a fundamental philosophy of React, that they really think about this very, very deeply. And in fact, I think it's something that you learn from Facebook engineering in general, because GraphQL and DataLoader has the exact same principles.
[21:06] Ali Spittel: That's awesome. And people should definitely follow you on social media to see all your blog posts. Because it's so, so impressive how you just like write about things. You get articles out, and you see a topic a couple of times and you write about it. And I think that's awesome.
[21:24] Shawn Swyx Wang: Yeah. I call it the three strikes rule. I think people have a barrier towards when they should write about something, because they feel like they need to be an expert on it to write about it. Or they have the complete opposite. They spam out every single waking thoughts. And those two extremes are not very ideal, right? Because you're either publishing too much, or you're publishing too little. So my three strikes rule is, once you refer to an idea three times, you should try and blog about it. Because that's stuck around just long enough to prove that it's probably going to stick around a bit longer in your mind. But it's not too long that you've sort of gotten bored with the idea, or it started to lose relevancy. I'm trying to promote this concept. Just to be less precious with your blogging, and just get it out after three strikes.
[22:11] Ali Spittel: I love that idea. I'm such a perfectionist that it is so hard for me to actually press publish on anything. I take notes on everything, but that's a great...
[22:20] Shawn Swyx Wang: Yeah. You're a very polished writer. I think that's something that we have to understand as content creators, your blog conveys an expectation of the amount of work that goes into it. And now, I think if you deviated from that, people would kind of feel uncomfortable with it. So I think you need to find a different outlet, right? Where you can experiment more, and where people don't expect you to have that level of polish. I'm a fan of actually using different outlets for different purposes.
[22:48] Ali Spittel: Oh, I love that. I love that. You're giving me all the advice here. I love the digital garden idea too. People seem really into that, especially in the egghead community. So I should dive more into that. You did already post all your resources, which is incredible. That was our next question. Then the next one is from Sasha: "Are there any specific frameworks new and improved based on these lessons on the rise that you foresee might replace React in the future?"
[23:17] Shawn Swyx Wang: Whoa, I didn't want to go there, but I really like Spelt, and I think it's an incredible alternative to React these days. And we are holding a conference in two weeks. So you can come check out Spelt on it. It's on YouTube. But I think it's general for open source. If you're working in dev marketing, or if you're starting an open source project. Or if you want to bet early on open source, I think these are the things to look out for. These seven lessons, they're not the only lessons and I'm interested in other people understanding what they can draw from React. Because React is one of the most successful open source frameworks in the world. Everyone's interested in replicating the success for their own thing. And so, yeah, I mean, my company, we're implementing these ideas at Temporal. Temporal's an open source framework that came out of Uber, and we're trying to sort of commercialize and popularize that. I think it's just useful generically. Pretty much the only front-end specific observation was the first one, which is more about reconciliation and scheduling. Which is a very front-end framework focused thing. But then you realize that you can apply that to other things. So I featured a tweet Jared Palmer saying, he's using the exact same ideas for a build system. And that's nothing to do with the dom or frontend. But I mean, that's great. It's the same software engineering principles that you can reuse again and again. I think that's my ultimate point, which is, anything that you learn, you're not learning the API. I mean, you can learn the API, but really the thing that will stick with you, even after that framework has gone, is the principles. Right? And we should try to learn from that, because that will stack and last our entire lives. So really, really valuable thing to learn.
[25:01] Ali Spittel: That's awesome. That's awesome. Have you tried any of the other like newer frameworks? You talked about Spelt, but have you tried to Hyperapp any chance?
[25:09] Shawn Swyx Wang: No. What is it?
[25:10] Ali Spittel: It's a super lightweight framework that allows you to use JSX as well, but it mirrors the Elm architecture, which I really enjoyed. Do you know Elm, like the frontend...
[25:24] Shawn Swyx Wang: Yes, I actually, I have read Evan Czaplicki's undergrad graduation thesis, which is the basis for Elm. And it is the most impactful undergrad... I don't remember my own undergrad thesis.
[25:37] Ali Spittel: I remember mine, I scribbled a ton of tweets, and it was all about how people discuss different politicians on social media. But yeah, that's a super, super interesting insight. But yeah, Hyperapp. It's written in JavaScript, but it has the Elm architecture. I really like it, because it's lightweight. I like the Elm architecture, but I find the programming language kind of hard to use. So I don't know. That's a fun one. This one is from Katray: "How do you come up with a good naming system when that's not really your strong suit? How much time it should be spent on that?"
[26:17] Shawn Swyx Wang: I have a blog post on how to name things. So I've actually tried to answer this question, because it's one of the known hard problems, right? We should have some perspective on naming things. And if you say that you are just not good at it and you don't try, then you're essentially just giving up before you start. And I don't think that's a very productive way of handling things. Because you're going to have to name things, right? That's a lot of what we do as part of coders. So I don't know. What was the question again? Did I answer it? I mean, a lot of my answers are just like, "I have a blog post for that." And that's a good way to do it, because that's a good leverage of time. Because I spent hours on that thing, and I'm not going to give it in this little chat. But if people are really interested, they can go look it up. Yeah.
[27:08] Ali Spittel: Yeah, yeah, yeah. It's almost like your second brain leak. You don't have to remember all these things because you've written about them in the past. Your first blog user is yourself. So the question was about coming up with a good naming system and how much time should be spent on it, which I think you answered.
[27:22] Shawn Swyx Wang: Yeah. Yeah. I mean, I'm really inspired how the React team thinks so hard about naming. That means nothing to the computer, but it is everything about communicating between humans, right? That's a lot of what good API design is about. So I posted a screenshot in my slides of how many names they considered before landing on hooks. It's not an accident that it's such a simple, single-syllable name that vaguely… A lot of people have problems with the name hooks. Okay? And I had some problems with it. But it was good enough. It conveyed the message, and it was useful. And that's what they're aiming for. That's something that, I think with some practice, you can at least avoid bad names, which is good. And I think probably step number one is to avoid multiple very different names for the same concept. And you can just understand what the more generic abstraction you're trying to name is as well. I don't know. How to name things. That's a hard one.
[28:27] Ali Spittel: Yeah. Yeah, yeah, yeah. Definitely an unsolved problem. Okay. So going back to that first question, they changed their wording. "We want to optimize for change. What things prevent us from doing this? What misconceptions? That way we can try to move away from them."
[28:47] Shawn Swyx Wang: Oh, okay. Got it. What can prevent us from doing this? What misconceptions? Interesting. I haven't really thought about this. I don't know. I don't know if there's anything... Doing the opposite, essentially of everything I recommended. Yeah. I think this comes to sort of API design and coupling, and how, when you make certain choices. So a lot of this is contained in the Simple Made Easy talk Rich Hickey, because he actually has a table. I cut this out of my talk because I had to cut it for time. But there's actually a table of fundamental choices, API design choices, that lead towards simple design. And fundamental API choices that lead toward more complex design. And I think it's just a real truth that if you just avoid the more complex ones, that helps to understand what leads you towards optimizing for change. Honestly, there's a lot of truth in the fact that you're relying on order. And order can mean sort of hierarchical order, as well as sort of sequential order. And I think once you make your asynchrony, your data fetching, your rendering, your styling, independent of order, then you enable local reasoning. And that is ultimately what the Facebook team, and it's ultimately something I agree with, ultimately what they think helps optimize for change. Avoiding globals, I guess, is one of those very cheap answers, but sometimes globals are really nice. So I don't know how I feel about globals. I think limited use of globals is probably the right way to phrase this. And then everything else, just try to keep things sculpted to the locality of where you change it. Which is, the way, one reason I really like Tailwind. Because Tailwind sculpts styling directly to the element, as though you're using inline styles.So that's a really fascinating technology, which I hope more people are exploring.
[31:09] Ali Spittel: That's awesome. That's awesome. Okay. We got about a minute. And so I want to pivot to your book instead of your talk. What are your three favorite pieces of career advice for a junior to senior developer? So on the side here.
[31:25] Shawn Swyx Wang: Oh my God. Yeah. For what it's worth, I have 40 chapters. So you're asking me to pick my favorite among...So this is going to be hard. Okay. So let me try to talk about... I think one thing is, open source knowledge essentially, is... I actually have a talk on this on my YouTube where… It's a variant of what I'm known for, which is called learning in public. But this is really sort of laying out your raw materials in the open, and letting people contribute, and evolving it over time. Whereas a lot of people, when they try learning in public, they tend towards finished articles, like a YouTube video, a blog post, that's kind of like a one and done type of thing. I want people to try doing more, build stuff up over time and just go and build something substantial and something useful to yourself and everyone else around you. So that's how I got involved in building the React and TypeScript cheat sheets project, which was literally a reference for me to learn React and TypeScript. That's open sourcing your knowledge. Another one I really like is, it's this idea of good enough is better than best. Stop pursuing the best because you will never be happy. You have to stay on top of other people's news announcements, and you have to care what other benchmarks people think. And focus on what's good enough. What you need and what you know best. Then finally, I guess, one more to just throw out there is, pick up what they put down. A lot of people ask about the cold start, trying to get started in writing and learning in public. And they find that they don't have any traction or no readership. Respond to other people's work. If I just dropped a new book, review it or engage with creators. And you'll find that you have a much higher chance of responding, and becoming a collaborator and eventually a friend. That's my three tips.
[33:28] Ali Spittel: That's amazing. Those are great pieces of advice. Well, thank you so, so much. It's been fun to catch up and also so great to hear your advice and your talk.
[33:40] Shawn Swyx Wang: Awesome. Yeah. Thank you so much for having me and I'll see everyone in the chat.