The Third Age of JavaScript

Hey everyone.

My name is Shawn.

I also go by Swyx on the internet and I'm here to talk about this idea that I had, and I call it the Third Age of JavaScript.

And in short, it comes out of the broad sense that every 10 or so years, that there is a changing of the guard in JS.

That is probably due to a mix of some factors, technological shifts, ecosystem maturity and the new generation of developers coming in.

Some new theme takes hold, and that starts to be the dominant investment of the entire ecosystem.

And that helps to move JavaScript forward in some meaningful way.

So we're going to interpret a very broad time span of the history of JavaScript from 1997.

And then I'll share with you my thesis for what's happening this decade, going up to the year 2030, and maybe beyond.

So we explore this thesis in five parts.

First we recap the First and Second Ages of JavaScript.

We'll explain what we mean by ages and what they represent thematically.

And then we'll talk about what's going on in JavaScript right now coming into the Third Age.

There's specifically two sections I'd like to focus on, the rise of ES modules and the death of IE11 and the rise of Polyglot Tooling and Collapsing Layers of tooling, so we can simplify them.

Finally, nothing lasts forever, so we're going to put all this together and take a quick look at what some people are calling the end of JavaScript.

Dun, dun, dunnnn.

So the First Age of JavaScript actually began when Brendan Eich created JavaScript in 10 days in 1995, but I'm really going to only start the clock when we formalized the languages ECMAScript in 1987.

I like to use this chart to show how furiously the standards evolves in the first three years, and then it got stuck in a rut for a long time and now it's picked back up again.

After ECMAScript 1, 2 and 3, there was a attempt and then evolution with ECMAScript 3.1, but then also an attempt to take bigger steps with ECMAScript 4.

So this is a long process of deadlock and we ended the first age in a pretty dark state where this toy browser language didn't seem like it'd be developing any further at the standards level.

In the meantime, people still wanted to make WebApps, so the JavaScript ecosystem fractured into two approaches, modifying the standard JavaScript and splitting off into a dialect of JavaScript.

You can take the dialects path where you conclude that we need more features than JavaScript offers.

So we're just going to invent new syntax or take it a completely different direction for the language.

Or you could even make a browser plugin and use your own language like Microsoft Silverlight.

ActionScript and JScript are probably the two better known JS dialects in this direction, and many of the people active in JavaScript today still got their start with ActionScript and even bet their future on it.

But of course, the other direction that you could take is to modify JavaScript itself, to do what you want.

So since JavaScript lets you modify prototypes, you can do a lot to extend it while working within its boundaries, you can invent new APIs that just kind of work with the constraints that you're given.

So jQuery, dojo, toolkit, and MooTools took that route, and obviously they won.

That's probably the justification for the phrase, always bet on JavaScript, which is going to be very relevant for us towards the end of this talk.

So the first stage of JavaScript looked like a pretty dark time for the future of language standards, and probably most observers at the time would say that this is the natural conclusion to a language that was only designed to 10 days.

But I think the language was rescued in Oslo where the warring factions of ES3.1 led by Microsoft and Yahoo and ES4 led by Adobe and Google, just got in a room and hammered out their differences, finally.

So I was really excited to find this blog post by John Resig on the left, who was actually in the room where it happened in Oslo and gave a recount of how they healed the schism in the JavaScript community.

And that's why we call ES5 the Harmony Edition of JavaScript.

For further details, I highly recommend reading JavaScript the first 20 years, which is kind of like a 200 page book slash paper that was written by Brendan Eich and Allen Wirfs-Brook the chief authors of JavaScript and ES5 and 6 respectively.

Of course, there was a lot of other things going on in the world in 2008.

So I don't really start tracking the second age of JS until 2009.

I do think of 2009 is sort of the rebirth of JavaScript.

It's almost cinematic in that the first act ends with JavaScript's darkest moments with people forking off in different and completely incompatible directions.

And then we get to 2009.

Where in the same year, we not only get one, the final specification of ES5 harmony published; two, the birth of common JS module format; three, Ryan Dahl, introducing Node.js atJS conf.eu, and four, almost at the same time node package manager, the birth of npm.

Of course, Isaac always says that npm doesn't stand for node package manager, but here I have a screenshot of an email from him saying, that's exactly what it is.

This is on a public Google group, you can find this if you want, and there's proof that npm stands for node package manager.

So there you go.

In 2009, a single year basically established the foundations for everything that we use today in JavaScript.

And we're still working on the implications and the mistakes from that.

There's also a real power in thinking about these things in terms of ages and how languages evolve.

In the first age, we're sorting out the basic specifications of the language and then boom, all of a sudden, we're now working on building out the ecosystem around the language.

If we can all do this in one year and it wasn't so long ago, maybe it's time we think about how we are going to reshape things again for the next decade.

So there are three ways in which I think we really saw the JS ecosystem build out.

The first way is runtimes getting JavaScript to run in more and more places.

So in 2008 / 2009 period only we not only got JS running in the server, but also Google Chrome and together with it, the V8 engine, which is incredibly important.

And then we wanted to run JavaScript and native desktop apps too.

So we smushed node and Chrome together and got Electron.

But then of course the desktop was already declining in terms of relevance and every app was moving to mobile.

So then we got React Native and NativeScript to run JS and mobile apps, windows, watches, TV, and I don't know every other device that you can think of.

And then finally, as we came to the end of the Second Age, we had dedicated JavaScript engines like Hermes that are specifically optimized for Android execution and even ARM chips has specialized JavaScript instruction sets.

So we have GS optimization all the way down the stack to squeeze every bit of performance out of our hardware.

The second way in which our ecosystem evolved is build tools and composite GS languages.

We started pretty early with CoffeeScript and Google Closure Compiler.

And then in the 2011 / 2012 we have all this scripting tools and product build tools like Grunt and Webpack and TypeScript emerging in the same period.

Gulp and Traceur came shortly after as initial iterations before Babel and Rollup came along and basically took over.

There are a lot of people who got their start with View Source and JavaScript who were upset at the proliferation of build tools and machine generated JS.

Well, my sense it's that it's a Pandora's box and once we've gone down this path, there's really no going back.

There's just so much we can do with plugins and preprocessing that make it easier to write apps that run on all sorts of browsers and scale with large teams.

I really liked the analogy that Kyle Simpson made recently that the JS that we write and the JS that our machines run are almost parallel lines.

They started looking the same, but then as time goes on, they're just going to diverge more and more because we have just gone past the limits of what a single person can keep in their head at the same time.

There's been a lot of evolution and build tools since then.

We can't really talk about them all, but we'll talk about what's new in the Third Age, compared to these Second Age tools.

I'll briefly comment that there's a clear Shift Left movement in developer experience of JS build tools.

And I've done a couple talks here with regards to both React and Svelte and the total takeover of TypeScript and the Language Server Protocol from VS code.

But this idea of shifting left is not really specific to any frameworks or tools.

If you imagine, from a left to right axis where the left is writing code and the right is deploying code.

It's more expensive if you only catch your bugs in production after you deployed a code.

So the shift left movement is about driving bugs further and further left and catching them earlier, so you can iterate faster with lower bugs shipped.

I recommend you check these talks out if you're interested in seeing how we're pushing the frontiers in this direction.

The third way in which the JS ecosystem is evolving comes from frameworks.

So of course we all love and hate frameworks in different ways.

Angular was the original, big success alongside of Backbone JS.

Meteor was the first full stack JS framework and also the first VC backed one, and that was a very interesting journey as well.

I think we'll see more evolution in funding models as we'll explore the 3rd Age projects.

Obviously React is the predominant framework of our time today.

And Vue and Svelete came along afterwards.

I think the lesson here is that we've evolved to a model where we write front end apps with components with local state, that it's easy to compose.

That's the real evolution here because the JS that we wrote for interactive pages wasn't designed for any of that, it was just imperative and just attached all over the place without any proper organization.

So frameworks help to organize our code.

So that's the story so far, we have multiple threads that ecosystem build out simultaneously going on, and I think it's hard to see when you're living through it year by year.

So what I did was I laid everything out year by year.

So you can see the standards in red, the runtimes in green, the libraries in blue, and the build tool is an orange.

You can see over time that there's just less and less red that really matters, of course, ECMAScript is now on a yearly release schedule, but none of them are as big as ES6 anymore.

And there's more green and orange over time.

So that's us building out more and more runtimes and build tools and even libraries.

That's the brief history of the First and Second Ages.

There's a lot more community development actually happening in a Second Age because we have a stronger foundation to build on that was established in the First Age.

I think it also happens that between ages, there always seems to be a global recession going on.

So between 07 and 09 and 19 and 2020.

So I guess look out for another recession in 2030.

So let's talk about the Third Age now because we're well into the third decade of JavaScript.

I wrote a blog post about this idea and one of my readers Photoshoped, this awesome image from the Third Age Lord of the Rings video game.

And I really love it, so I had to feature it here.

The overarching pieces of my writing is that we're doing the really hard and ugly work of clearing away legacy assumptions that JavaScript used to have, for whatever reason, like supporting IE11 or having a strictly defined Unix philosophy.

My prediction really is that this is the dominant theme for the next 10 years.

And we as a community should really look forward to and heavily invest in these efforts to come out of it in the best shape for Web development.

So there are two driving forces of Third Age which I really focus on.

One we're moving off of informally, specified common JS into standardized ES modules everywhere.

And this has helped along by the death of IE11, which is also going to take place within this decade.

And two, we're going to completely revamp JavaScript tooling, which we've built up incrementally into this mess of logos, such that every project looks like a NASCAR race car, and you need to hire a Webpack specialist just to manage all of this junk.

So I really think this decade, we're going to both simplify that by collapsing it.

And we're also going to make it a lot faster by rewriting the core of our tooling with Compiled Systems Languages, instead of JS.

So first we'll talk about the first driver or the Third Age, which is moving into ES modules and the death of IE11.

So what's an ES module?

Is it just using the import and export keyword?

Most people watching have probably used the syntax of ES modules, but it's actually compiled to common JS by Webpack behind the scenes.

So it's kind of a lie that you're using ES modules.

What we're really talking about here is native ES modules usage in both node and in the browser.

I highly recommend getting familiar with the native ES module spec, since this is going to permeate more and more of our tooling over the Third Age of JavaScript.

The MDM page on this and the VA teams writeup on va.dev is the best resource on this.

You never really appreciate standards work like this until you look at all the niche use cases that you don't really think about until you run into them.

And I've listed some of them on the right here, the key point right now is that it is supported in the browsers, so when you're doing development, you actually don't need to bundle.

And that actually increases the development speed by quite a bit.

There's still a lot of work left to do though with import maps and loader hooks that need to be built into the ESM spec.

But step one of this is us, using it in development.

When I benchmark create react app against feeds, which is the new build tool from the view ecosystem, the startup time was something ridiculous, like 15 times faster.

Once you've tasted the ES modules, future of build tools you could use Vite you could use Snowpack, you could use WMR, there's a bunch of these out there.

Once you use any one of these, the old tools where you have to bundle just to get stuff running in development just feels antiquated, but still don't, don't get too excited.

There are limitations.

So first of all, in production, you're still going to want to bundle, and that's the official recommendation of the VA core team, especially if you're going beyond a hundred modules, because you don't want to a waterfall, thousands of mpn packages into the browser.

The other limitation is that the platform you're running on needs to support ES modules.

And so we have most of these things in green, except for obviously the big elephant in the room.

So let's talk about Internet Explorer.

So I do have good news on that front, but tracking the death of IE11 slowly, but surely.

There's an official end date of support for IE11 in 2025.

But I think the practical end date of IE11 will come much sooner than that.

Let me show you why.

Over the past years they've been some pretty big names like twitter.com.

Dailymotion, LinkedIn, Microsoft, Adobe, GoDaddy, Skillshare, wordPress, Drupal and so on as well as frameworks like Vue, Svelte, and Angular [notice what's missing].

Just a lot of really well-known names dropping IE11 support.

I collect these examples just to help you make the case.

If you work at a peer company to one of these companies that have dropped IE11, and I think it's a matter of collective action with peer pressure.

So that's why I'm very keen on collecting examples of people who have dropped IE support in every industry.

So if you have an industry that's not represented here, please reach out to me.

And I would love to feature you on my list of people who have dropped IE11.

For me, the key metric to watch is this chart on the top left.

This is from analytics.usa.gov, the browser traffic to government websites.

And why I highlight this is because the US Digital Service has a 2% support rule.

So they have to support any browser with market share above 2%.

And that market share is measured by visits to the government websites, U S governments, the IE11 number, it was 3.6% in November, 2020, and it's really dropping precipitously.

Pretty soon going to be below 2%.

It's at 2.0% right now in June, 2021.

So when it goes below 2%, the U S government is cleared to drop IE11 support, and I think that will serve a huge signaling effect to the rest of the market, because if the U S government drops support, it's okay for their vendors to job support, and I think it will cause a massive cascade to end mainstream IE11 support as early as this year.

So let's look forward to that and advocate for it as much as possible.

I think the reason we want this is not just so much for ES module support, but it's also going to allow us to transpile less.

And basically ship much less JavaScript in the long run.

I think the final nail in the coffin is of course Microsoft Edge, which is a huge achievement by Microsoft because they now shipped an IE11 compatibility mode.

So your users can actually use a modern browser most of the time and only drop back to IE when they need to use legacy apps.

I think Microsoft doing this is just a reflection and they're very pragmatic approach to IE11 adoption.

And I really appreciate that.

The other way to track this adoption is in developer adoption.

And you can see that both on the browser and in node JS adoption of ES modules in a browser tripled in the year 2020.

And I think this year is going to go just even higher because the stable version of node now has ES modules, unflagged by default.

And Sindre Sorhus the nodeJS maintainer is writing his 1000 modules in ES modules only.

So, this really seems to be the year that a lot of people are biting the bullet and going "all right, this is painful, but we all got to do it", because a bunch of stars just aligned and now's the time to invest in the esm first future.

So I really want you to be aware of this trend, to help it along, because I think it takes a little bit of effort from all.

So the second driver of the Third Age is a new generation of tooling, that's motivated by a drive towards rewriting our tooling in systems languages, and collapsing multiple layers of tooling into one.

You can map this into the underlying assumptions that have mostly held true in the Second Age of JavaScript.

One, which is that JavaScript tools have to be written in JavaScript so that we can contribute and understand the tools, that's kind of the egalitarian assumptions, so that open source is accessible to the widest audience and everyone can contribute or two the Unix philosophy.

In other words, the tools that succeed at JavaScript with the tools that do only one thing well, and then you can link them up in modular phases with other tools.

And under this mindset, simple tools is the key to simplicity.

I think that's something that we're starting to question as well.

So I'm going to dive into why these two assumptions are falling over.

So I think the first assumption is obviously wrong in one aspect, which is that we're no longer writing pure JavaScript anymore.

TypeScript basically took over the library ecosystem.

Here's me on the left, tracking the react ecosystem library, adoption of TypeScript.

All of these react libraries have their core written in TypeScript.

And of course the interest matrix of TypeScript is off the charts is 72% would use again, with another 60% interested in learning TypeScript.

I think it's a pretty amazing to watch because not too long ago, when I suggested just porting our code base at work to TypeScript to try to reduce bugs, that was really rejected because it would make it harder for people to contribute.

But the simple facts was no one else was contributing anyway, we just needed more help as maintainers to catch our bugs.

So now people have gone all the way to the other extreme and they will file an issue to complain if your project doesn't even ship TypeScript types.

That's an amazing ecosystem shift in the space of just the past two to three years, but TypeScript is still pretty close to JavaScript.

So let's see what happens when we push the for JSON JS assumption, even further and use systems languages.

The first thing to observe is ESbuild's benchmarks.

Esbuild is an alternative to Webpack that's written in Go, and it's about a hundred times faster than parcel or Webpack based on its own benchmarks, of course.

It's also pretty cool that it was written by Evan Wallace, the CTO of Figma as a proof of existence.

He wasn't actually trying to replace Webpack, he was just frustrated with the slowness of our tools.

So he wrote ESbuild just to show the rest of us script kiddies, how much faster that things could be.

And now we're all putting our tooling over on top of it.

We should be clear that the performance of ESbuild partially comes because it skips a few past steps that Webpack takes.

But the central thesis is also true that there are hot paths in the core of every build tool that are run hundreds and thousands of times, and they don't really have to be in JavaScript because nobody touches that except the core maintainers.

So if we rewrote those in a compiled language, like Go, we could see a couple orders of magnitude speed ups and an overall build times.

And once we have that we unlocked a whole new class of behaviors in the stacks above the build tools, which is why it's very key to continue to 'cut the fat' in terms of the necessary evils of a build tools.

So ESbuild is the most mature tool exploring this, but you can also see other up and coming projects use Rust as their core instead of Go.

So Deno, Relay and Volta are all examples with pretty significant chunks of Rust in their core code base, which also helps when you have a need for fearless concurrency and compiling to WebAssembly to run in the browser.

So I think there's a solid case for converting our tooling over to systems languages, and for anything that is a core hot path, that non maintainers never really touch.

We should really be looking at rewriting it in a systems language.

However, we don't have to port everything over.

We can leave a nice outer shell of JavaScript, which can be handy for users to modify and write plugins for.

This is the thesis that I call systems core and scripting show.

And it's really apparent that the performance opportunity that we get from rewriting the Core or just building new tools with different core assumptions can no longer be ignored.

I think this idea is going to be trending a lot more in the Third Age as we get rid of the for JS in JS assumption.

The second assumption is about the Unix philosophy.

The idea that each tool should only do one thing well.

I think what's up for debate today is what that one thing even is.

I really liked this anecdote from Benedict Evans on the left on platforms, bundling and kill zones.

In the 1980s, if you installed a word processor, a spreadsheet program on your PC, they will not come with word counts, footnotes, charts, comments, or printing in landscape mode.

These are all extra plugins that you have to buy in hookup together.

But today, when we think of a word processing program, we just think of the setup on the right.

When I print something, I want all these options available, that's just standard.

And I think that's how technology evolves.

I don't have to buy plugins and wire them together and make sure all the versions work nicely together.

So as software matures, we redefine the job of what the software does into a product with common features instead of a bespoke bundle of products.

The more we use it, the more we understand that all these things just live together naturally in the same headspace of the end user, and therefore they should be made together by the same provider.

We evolved all of this different tooling piece by piece.

And as we discovered the kinds of tools we wanted for production quality software, we got TypeScript and Babel then Prettier and esLint, and jest and Webpack, and these are all great in their own right.

And they are designed to do their job very well, but the intersections between them is where it starts to really hurt.

Especially if you need to maintain your setup over major version changes over time.

I need like 10 different config files just to keep all this in order.

And then moment I break one of them, it's just a mess to debug because they don't all speak the same language.

Also chainging all these things together can be very slow because if you're running all of these tools and they're all parsing your code base with their own ASTs, then you have to wait for all of them to run.

Instead of having a single pass where you have knowledge of every single job that needs to be done through them.

Historically, the way we've dealt with this is to sweep this problem under a rug, by coming up with one abstraction that unifies all of them.

And that is what happened in React with Create React App, which was created just to solve the complex set of problems that we had in 2016.

If you are interested, I did do a talk that goes further into how you can make your own Create React App that you can check out.

But at the end of the day, it's not really solving the problem.

It's just bundling all the complexity up into a single npm dependency, and it's pretty brittle when you want to change anything.

But still that's the general way we've been proceeding in the Second Age of JavaScript, Create React App is just one special case of a React Distro.

So if you combine React with dev tools, you get Create React App.

If you combine React with dev tools and routing, you get Next.js and Gatsby.

If you want states and data or components and hooks, then you get Blitz.js and Redwood JS.

And so on, there are a lot more other react distros, which we'll talk about in my blog posts on this idea.

But I think the way forward in the Third Age of JavaScript is collapsing layers into a single tool.

Here, I'm showing screenshots of the two main tools in the collapsing layers thesis with Rome on the left and Deno on the right.

The screenshots on the left were taken directly from Rome's VC fundraising slide deck, and you can see how you really close I came to predicting it.

Rome is designed to replace all of these logos with zero dependencies.

So it's a monumental task of rewriting the entire universe, from the ground up, as a cohesive unit.

Fortunately, it's created by two of the most impactful developers in JavaScript, open source.

So there's a lot of potential to this project and I recommend watching it very closely.

On the right.

Deno is also doing the same thing, but lower level.

So while Rome will slot in nicely on top of node.js Deno is just rebuilding the runtime layer itself and then building into standard library and package manager and linter and bundler, and all the other tools that you use into the same binary that runs your scripts.

So this is the clearest glimpse of the future that I can provide today.

Don't be surprised in five years from now, you're all going to be using something like this on a day-to-day basis and laughing at how clunky and how much setup that Second Age Tools used to need.

Obviously both of these endeavors are massive undertakings.

So the other thing that's being tried here is more open source funding.

I would say VCs got a little burned by investing a Meteor JS and it not really working out, but I think probably the success of Vercel and next.js Is helping build a little more confidence in the JS and front end dev tools investment space.

The challenge I will lay down for you is to not think that it ends here.

Believe it or not Deno and Rome, just going after the most obvious opportunities out there, but there have to be a lot more outdated assumptions.

So you have to ask, what else do we think is true today that doesn't have to be true in the Third Age of JavaScript?

If we had the chance to build up a world from scratch, knowing everything we know today, apart from faster tooling and lower configuration, what other ideas can you borrow from other languages and domains to bring to JavaScript?

That's the real trick to not take the present for granted and to look inside the negative space for what else should exist.

If you have an idea for this, let me know.

I'd love to hear it and help you spread it.

So part 5 of this talk contemplates the death of JavaScript.

JavaScript is obviously stronger than ever, and I just made the case for a more optimistic decade for JavaScript.

So this is projecting really far out, but I'll indulge just a little bit.

I think the clearest articulation of how all this ends comes from Gary Bernhardt's talk.

Most of you have probably seen it, but I have to mention it because it's such a fantastic talk.

The real prediction in his talk is that we'll finally end up with a new low-level language that runs any universal virtual machine that you can run everywhere.

Brendan Eich has always said that you should always bet on JS to do this.

But he's recently changed his philosophy.

And he actually told me when I questioned him about the universal virtual machine, it's probably WebAssembly now.

So he says, "Always bet on JS and wisdom' now that's his quote.

So I highly recommend watching Gary's talk on the breadth and depth of JavaScript as well as paying attention when Brendan talks about WebAssembly.

This is not the place to go into that, but it's on the horizon, I would say.

So that's the gist.

It's a very broad, overarching historical thesis.

It was still in the middle of it.

I'll probably be wrong on something, but as a developer and blogger, I aim to write the first draft of history.

The Third Age of JavaScript is just a theory and there is going to be wrong or right, but as presented to you for argument or disagreement.

If you want to learn more about spotting mega trends like this, and thinking about how to invest in and bet on technologies, I did write a book about how I've applied my investing background in my tech career.

So you can check out my book@learningpublic.org.

Still.

Thank you so much for having me.

I hope you enjoyed this conference and you enjoyed this trip down memory lane and some speculation into the future.

Thanks for having me.