The First Age
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.
The Second Age
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.
Forming the ecosystem: frameworks
The shift left in JS tooling
The Third Age
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.
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
[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.
[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.
The death of JS?
[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.
[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.
[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?
[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.