Is this the Third Age of JavaScript?
While explaining the timeline of JavaScript, Shawn Wang comes to an interesting point: that we just started a period that could later be referred to as the Third Age of JavaScript.
By Shawn Wang (AKA swyx)
The Story So Far
The first age of JS, from 1997-2007, started with a bang and ended with a whimper. You all know Brendan Eich’s story, and perhaps it is less known how the ES4 effort faltered amidst strong competition from closed ecosystems like Flash/Actionscript. The full origin story of JS is better told by its principal authors, Brendan Eich and Allen Wirfs-Brock, in JavaScript: The First 20 Years.
The second age of JS, from 2009-2019, started with the annus mirabilis of 2009, where npm, Node.js, and ES5 were born. With Doug Crockford showing us its good parts, users built a whole host of JS Build Tools and libraries, and extended JS’ reach to both desktop and new fangled smart phones. Towards 2019 we even saw the emergence of specialized runtimes for JS on phones like Facebook’s Hermes as well as compiler first frontend frameworks like Svelte 3.
The Third Age
2020 feels like the start of a new Age. If the First Age was about building out a language, and the Second Age was about users exploring and expanding the language, the Third Age is about clearing away legacy assumptions and collapsing layers of tooling.
The main legacy assumption being cleared away is the JS ecosystem’s reliance on CommonJS, which evolved as a series of compromises. Its replacement, ES Modules, has been waiting in the wings for a while, but lacked the momentum to truly take a leap because existing tooling was slow but “good enough”. On the frontend, modern browsers are equipped to handle these in small amounts too, but important details haven’t yet been resolved. The Pika/Snowpack project is positioned to accelerate this future by providing a facade that can disappear as ES Modules get worked out. As a final bonus, IE11 will begin its slow march to end of life starting this year and ending in 2029.
The other assumption going away is that JavaScript tools must be built in JavaScript. The potential for type safety and 10x-100x performance speedup in hot paths is too great to ignore. The “for JS in JS” ideal was chipped away with the near complete takeover of JavaScript by TypeScript and now Deno and Relay are proving that people will learn Rust to contribute to core JS tools. Brandon Dail predicts this conversion will be done by 2023. We will continue to write JavaScript and TypeScript for the majority of surrounding tooling where approachability outweighs performance. Where we used to think about “Functional Core, Imperative Shell”, we are now moving to “Systems Core, Scripting Shell”.
Read the full article here
