Video details

Shawn Wang - Third Age of Javascript - JSworld 2021

JavaScript
02.23.2021
English

Every 10 years there is a changing of the guard in JavaScript. The First Age started with Brendan Eich and ended with ActionScript.
The Second Age started in 2009 when npm, Node, and ES5 all gave new life to JavaScript.
In the Third Age we will see the confluence of a few megatrends – ES Modules, polyglot tooling, collapsing layers, and the slow death of IE.
Let us explore the implications.
Slides: https://docs.google.com/presentation/d/1Dlow7gHNV6MeZ9CmZR0cbN_wfyIU6UcqBNZI4D6rObo/edit
Sign up for our newsletter: https://www.frontenddeveloperlove.com/newsletter Stay up to date via LinkedIn: https://www.linkedin.com/company/frontendlove/
Powered by https://passionatepeople.io
#unittests #webaudio #unittesting #hiphop #frontendlove or #vuejsamsterdam #javascript #reactacademy #react #microinteractions #designsystems #javascript #artificialintelligence #amsterdam #speaker #conference #frontendlove #frontenddeveloperlove #javascriptconference #frontendconference #vue #angular #react #cfp #theateramsterdam #meetup #conferences #events

Transcript

Hello. This is a talk about what I think is going to happen to JavaScript over the 2020s. So specifically the ten years starting from 2020, all the way to 2030 and maybe a little bit beyond. So a very ambitious talk, and obviously I am going to be wrong, but it's nice to speculate a little bit based on what we know today and to cover that, basically what we're going to cover is where we have started from and where we're going, and then a little bit towards the end. So this talk is in five sections. The first age going from 1997 to 2007, the second age 2009 to 2019. I kind of skipped 2008, but we cover that a little bit. And then the third age is split into part three and part four, which is the two theses that I promote for what I think is going to happen in the third age, which is the rise of Es modules and the rise of Polyglot tooling. And then finally we'll speculate a little bit on how this ends. Nothing lasts forever and JavaScript will have its end day, maybe. So we'll talk a little bit about the first age of JavaScript. This is something that probably if you've been doing JavaScript a while, you know this story well. So I won't spend too much time on it, but it's worth thinking about how it began. I think obviously the best source of it is the guy who started at all, Brandon Nike. And I highly recommend his talk at JS called A Brief History of JavaScript. And it was based on a lie. It's not actually anything to do with Java. Java was just a popular language at the time, but based on the line in another way, which was that when Mozilla invited Brendan Ike to create JavaScript, they were actually promising him that he could put Steve in the browser, which is a language that he really liked, and he never got to do it. It's just an interesting idea, but really the first age is about forming the language, trying to find its ground. So here's all the attempts. I start the count in 1997. Obviously it actually started in 1995, but the formalization was added some sort of ISO standardization. 99 added more features, which are pretty useful at the time. But then the formalization effort really fell apart for the next eight years. And that was a pretty dark period from 1997. Like you had a pretty good start. And then going towards 2007, it wasn't clear that JavaScript was going to survive at all. Like there were all these dialects of JavaScript. Flash was taking over the web, and it was a pretty dark time in JavaScript. So I think you could sort of describe there being two tracks going on in the development of JavaScript, right during the first age. The first was all the dialects, like Action Script, Microsoft J script. I even looked around and there was like QT script and WML script. Windows, sorry, web mobile script, something like that. I don't know. It's more like embedded mobile applications. Anyway, fortunately those things died out during the first stage of JavaScript. The other standard toolkits based on the existing language also started arising, so User Land Extensibility of JavaScript arose. Fortunately, we had that ability, so Jquery obviously was the winner. But also you had Mutuals and Dojo and others. I didn't include extrems and a bunch of other logos in here, but there are two tracks, and the standard one, standardization actually won. I think the really pivotal moment is the one that was kind of like the Hinge moment between the first age and the second age, which I kind of think of as a dark period. There were a lot of other things going on in the world, the financial system falling apart. But surprisingly we reached some harmony because the standards people were trying to do split into two factions. There was an Equiniscript Four faction and then it was an Equisite 3.1 faction. So evolutionary change versus revolutionary change. And the reason that we call Es Five Harmony is because there's a compromise that was reached in Oslo. And the canonical source of this is John Redig's blog post about this since 2008. So I highly recommend checking that out and also checking out this book that was recently published. It's kind of a book, kind of a paper published for the ACM and Programming Languages conference called JavaScript the first 20 Years. And it's by Princeton principal authors of JavaScript 2008 was kind of like really the pivotal moment when it enabled all the other features to come together. Because once we had some kind of consensus on what JavaScript is and how we evolved this language, it got a lot more momentum. And that brings us to the second age, which is the age that we just finished. This is the typo. This is 20 09, 20 19. But what happened in 2009, it was kind of the year of miracles. Common. Js was proposed, and based on Common. Js, NodeJS was announced in Jscon that used Common. Js module system. And because of NodeJS, Isaac Schluter also realized that you needed a no package manager. And of course we also got Es Five Harmony. So that's the pretty remarkable year that we owe to a lot of what we have today. And we accept today as the default way that things are done in JavaScript. All based out of this harmonization effort, the launch of Node. Js, the launch of NPM, the launch of the standardization and proposal of Common. Js. These are all just like fantastic ideas that have lasted us a good decade or more. And you can see this play out in this implication over the next ten years. So we started to have runtimes Chroma apparently was also in the 809 period. We started to bundle that into native platforms. And now a lot of apps in the desktop are just electron apps. And arguably that's been a controversial move, yes, but it's made it a lot easier for JavaScript developers to write desktop apps for sure. And then we brought JavaScript to mobile phones and there was React native, but then obviously there was other efforts like Cordova and other really pioneering efforts there. And then we started to see emerging dedicated run times like Hermes out of Facebook, where it's just running JavaScript on Android and it's so hyper optimized because we need that kind of performance. And it's just a really good opportunity to do that. Apart from Runtimes, we also have build tools. So I didn't know this, but apparently Google Close your compiler actually dates all the way back to 2009, as well as Coffee Script, Grunts, Web Pack, and TypeScript. Also in the sort of the 2012 vintage 2014, you got Galpin Tracer, but quickly Tracer was replaced by Babel, and then we got the newer bundlers as well, like Roll Up, Parcel. And also we had Basil, which is out in about that period. So runtimes build tools and frameworks like you can see how once the language base is standardized, you can start to build so much infrastructure on top of it. Obviously, this is what a lot of us are familiar with because we use frameworks to do our day to day tasks Angular Backbone, Meter, Reactive View and Spells. I don't have much to say about this apart from like, you can see a little bit of progression in terms of what we like to write apps in. We standardize on this idea of the component, a lot of frameworks, like the single file concept. We throw away a lot of the back end scaffolding ideas that Meteor had, which caused a lot of weight. And it's just a very interesting evolution over time. And I'm not sure that we're done. So there's a lot of innovation still to go, but it's definitely a lot easier than it used to be. Okay, so that kind of brings us up to today. I have this little visualization. It's really hard to visualize 20 years of Web technology. So pardon me if I left out your favorite technology. I just did my best. This already took me like three days to pull together all this history. But yeah, there was the first age and the second age, and there was a lot of development. Right. Like once we got the base of the language done, that enabled a lot of this other development to go forward. I think the main thesis is that there's a changing of the guard every ten years in JavaScript, and maybe we don't have the start and end dates. Exactly right. But there's sort of errors of like, all right, this is the thing that all the innovations happening at now and then once there's a clear winner, you build on top of that, and then once there's a clear winner, you build on top of that. And hopefully you're moving ourselves towards more accessible tooling, more developers, building more sources of apps. And there are reasonable arguments against a lot of these, but I think that in general, we have always moved in the direction of easier tooling, and that's enabled more and more developers. That's a good thing. Okay. The other thing I'll point out, which I won't include in this third age thesis, is the shift left in JavaScript tooling. So this is a thesis that basically people have been increasing the developer experience and catching bugs earlier in the development cycle and therefore reducing costs by shifting their error, catching all the way left from runtime to build time from build time to commit to commit time to save time, save time to read time inside of the idea with a language server. So the two talks that I recommend checking out on this is Spelt and A Great Space Elevator, as well as growing a Metal language where you can see this thesis applied to frameworks and Dev tooling. Okay, so the third age is really about clearing away legacy assumptions. And there's two sections to this. The first is clearing away the assumption of common JS and the rise of Es modules, together with the death of I eleven. And then the second part is clearing away the assumption that of just existing JavaScript tooling. A lot of tooling now is not written in JavaScript, and we'll explore that a little bit, as well as they will collapse a lot of layers into a single layer, and we'll explore why that is. It's a pretty simple idea. I think it's just pretty profound in how deeply it's going to change the way that we do JavaScript. Okay, so the first part is the first thesis is the rise of es modules. So for a brief refresher, probably everybody knows what an es module is. You have already used it, but maybe you haven't needed exactly to know why this is a big deal. I certainly wasn't one of those cases. Basically, it's the thing where you put import and export there, but most workflows would have the import and export keywords transpounded by webpack. It's not something that used to be run latency in the browser or a note. It has a lot of benefits, like it's statically analyzable, and if you require it multiple times, it only executes the module once, it's deferred by default. It's strict mode by default. Like all the good things, one of the really challenging ways of evolving JavaScript is that you try not to break the web. There are cases where we've just deprecated behavior, but we really, really try hard not to do that. So there is sloppy mode, the opposite of strict mode, which is the way that JavaScript is by default. But we realized that we wanted a different mode for JavaScript, and we implemented you strict whenever you make an es module that's just automatically opted into the strict mode, it doesn't pollute the global scope, and that's really nice. And it's now supported in browsers. So previously you needed to run your import and export statements through Web Pack and whatever for it to build its dependency tree. Now you don't have to. You're still recommended to, and we'll talk about that later. But it's just a really good evolution. Also, the way that this tax is done, and there are also other benefits that can be realized, but they don't exist yet, so there's no point talking about them because they might not ever come. It's also much faster. So here I have a video. Stay with me. It's only a minute long, but I'm also going to play this at 1.5 times speed. So what we're showing here is how fast is versus Create React App, and this is kind of side by side comparison. I'm doing install time and run times. The installation time is basically a function of the amount of dependencies that are sort of chucked in there by default. But the other thing that we really want to talk about is the runtime. So here I have the project running and it's live in the browser, and this is how quick it is. I put into some gifts here to show how slow Create React App is, because you're not bundling, because Vet and other sort of new age es module based developer tools don't need the time to bundle, or they don't have to bundle the entire graph. They just serve you the files that you requested. And that's a much faster process. And it also scales much better as like a constant time, air quotes version of scaling, rather than having to recompile the entire asset tree, because that's the way that your assumptions work. Okay, so there are limitations to es modules. It's not a cure for everything. So this is a recommendation from the official V Eight bright up on Es Modules, basically saying that your recommendation is to continue using bundle before deploying modules to production. Especially if you have a web app with more than 100 modules, which a lot of web apps are going to have, that especially for UI. If you're handwriting a lot of your modules, then sure, like don't even bundle it, don't bother. But there is overhead for Loading each module. And if you're going to load 1000 modules and waterfall them across your wire because we don't have export maps worked out yet, then that's actually going to be much lower than if you just bundled it. So we always want to optimize for user experience, and for best user experience, you should still bundle in production. But because we're doing local def, we want a fast feedback loop. There's no reason to bundle during local Dev because there's no network to cross you're just on your laptop. It's still an innovation that a lot of new age bundlers are taking advantage of, like Snowpack and V and WMR so I highly recommend checking these out, because these are clearly going to be the future of developer tools, at least. Obviously. How much should we care about developer experience? We as developers care a lot. Our users should not even see it, but it should help us develop faster. The other limitation, of course, is that it's supported everywhere except the one elephant in the room, the big E here, and that is Internet Explorer. It's mostly gone, especially in a lot of consumer sites. So Skillshare, LinkedIn, GoDaddy, Adobe Dailymotion, Microsoft in general, and Twitter and other sites like YouTube have dropped it much earlier as well. But I think the key catalyst for I Eleven really losing steam is going to be the US government. So the US government has a site where it monitors like here's the visit to all the web properties, and 2.6% of the visits are still Internet Explorer, but this is down a full percent since November 2020. So as of time of recording three months ago, within the last three months it's dropped a percent. It's going to be much harder to drop the remaining percent. But basically the US government has a support rule of 2%. Once it drops below 2%, they can actually officially drop support across all US government properties. And that's going to be a big signal to the rest of the market, especially anyone serving government sites that hey, the government's not doing this, that you don't have to. So apart from all your peer companies doing this, banks and social sites and what have you, once the government goes in on it, then I think it's really going to be the death knell to IU Eleven. The other thing which I really like is Microsoft Proactively doing this in the Microsoft Edge browser, offering an Ie compatibility mode. So even if you have applications that require Ie, you can still use Edge mode of time and then use Ie mode just for those applications. And that's for enterprises that really need that. So I really like this strategy. You can see that adoption of Es modules is really happening in 2020. Year alone, it tripled from 1% to about 3.5%. And the key maintainers of the modular ecosystem like syndrome source are just rewriting all their modules for Es modules already. So by the end of April 2021, note ten will be end of life. So everyone will be using note twelve. And note twelve can use Es module. It is happening and this is the time right now to know about it, to start preparing to use the tools that are based with these assumptions rather than the assumptions of the second age of JavaScript. And this is the third age. This is happening right now and I Eleven will definitely be dead by the end of 2030. Okay, so the next thesis, the second thesis of the third age is that we'll have new tooling. So Brendan Dale, formerly from Facebook, says that in five years. In less than five years. So he started all this in 2018. So he's got another three years. Most popular JavaScript tooling won't be written in JavaScript. And that's a fundamental insight here. So there's two insights here for me. The first is that we used to have this insistence that like, okay, to reduce the barriers to entry, we have to have JS tools written by NJS, right. So that they can understand and contribute. And then the other strong belief that we used to have was this Unix philosophy, like each tool should do one thing. Well, both of these are going to go away. So first of all, the very obvious one is that TypeScript took over, right? So most of the react ecosystem rewrote to use TypeScript. They're not just supporting TypeScript, they're using TypeScript internally. And types of adoption in the general state of JavaScript survey is very high, like basically about 11% not using and then the rest are interested or using it. So it's a very good result. I have had PRS and proposals rejected before on concerns of barriers to entry, and now it's just not even a question because it just improves the quality of the software so much. And that's the thing that actually matters. It turns out that most people don't contribute to open source. At least they're not going to contribute on the level of core maintainers. And yeah, we're past the tipping point. So once we have TypeScript core, what about other languages? So Es build is the other big bundler that is really sweeping the consensus. So all the new bundlers like Snowpack and Vs are using Es build under hood instead of webpac for production bundling because it's up to 100 times faster than the existing bundling solutions. Why? Because it doesn't use JavaScript in the core use. Its goal like any compiled language is going to run faster. And I think the core insight is that this is something that we're going to see in every part of our tooling, because why should we wait for this low initialization and all that? So these are other tools that are exploring Rust cores. So Denu is 53%, Rust, Relay is 33% Rust, and Volta is 94% Rust. And these are all just like examples of how JavaScript tooling is increasingly being written, not in JavaScript. And I think this is a generally positive approach. Obviously it's much harder to contribute because I don't know rest and now I'm unable to contribute to the core of these things. But there is still JavaScript in each of these things, right? So I can contribute around the edges. And what this looks like, I think, is what I've been coming to call systems core scripting show, which is that they're external APIs. This is the one that I care about the most in terms as a user, because I want to change it, I want to modify, I want to write plugins to it, and it's only invoked very rarely based on initialization. And the core is the hot path, the code that will run recursively continuously 100 times more than the external shellcode. Right. So the core, if it's in the hot path, why are we still using JavaScript to do it? Why not you switch to a systems language, communicate across boundaries, but once it's inside of here, it runs a lot faster. And that brings the overall speed of the tool to much faster as well. So I think we'll move from pure tools to polyglot tools, and I think that's a generally positive accomplishment because they're just a lot more users than maintainers, and we just need our tools to be much better and faster. Okay, the second part, the death of the Unix philosophy. So this is a really good blog post from Benedict Evans. I recommend you read it called Platforms, Bundling and Kill Zones. This is more about regulation, but I want to make the point about bundling of functions together. In the 1980s, if you installed a word processor on your PC, they would not come with word counts, footnotes, or charts. You could not put a comment in a cell, you couldn't even print in landscape. These were all separate products from separate companies that you have to go out and buy for $50 to $100 each. Imagine if you think about the way we do Microsoft Word today. It's all bundled. It's just one tool. We take this as the standard functionality, right? We don't say like, okay, this doesn't belong in the core. We'll have five different options for printing and landscape or counting the word count. And you see this pattern a lot in cars as well. When new technology emerges, it's very modular. And then we figure out what parts of the modules belong together, and then we just start shipping them as single individual units. And I think that's happening to JavaScript as well. Why are all these things different? Right. Type checking, transporting, formatting, Lenting, testing, and bundling. A lot of them require individual ESC passes, and because they don't know about each other, we're just running ASE five, six times. And that's a lot of the argument of the authors of the new tools. Like, why are we doing that so many times when we can just do it once? And there's a lot of decision fatigue as well. And there's a lot of config files. Right. Who is tired of all the babble es little webpack plugins here and there? And it's a very brittle system, and if any part of it breaks, like, good luck with trying to figure it out, why not have one tool where everything's just guaranteed to work together? That sounds like a utopia. I think that's something that we have been trying to do for the past five years. So here's a complaint that was pretty funny about how hard it used to be to create a React app because you have to wire all these tools together like Webpack and Babble and what have you. And of course, the React team came together and made Create React app, but it basically just took a standard package, JSON and wrapped it up into one dependency. It didn't really solve the speed problem. It solved the initialization problem because all you have to do is NPM install, Create React app. But it didn't solve the speed problem and the tooling of all the configs that you want to manage. So what the new shows are kind of doing is we're continuing this pattern on top of it. So Create Reactive is merging together React and Dev tooling. Then if you add routing, that's how you get next year, as in Gatsby, you've got state data and components and hooks. Then you get Blitz and Redwood JS. And there's just a lot of this like layer after layer after layer of react distributions. But what I'm really interested in is collapsing the really fundamental underlying layer into one single est tool. Sorry, one single est pass and one tooling or one binary. So I think the leading candidates for this are Roam tools as well as Denil, which you can find out more later on as well. So those are just like really interesting ideas where you collapse all the standard tooling into one. And I think it's time. I think we're all tired of wiping these together separately, and I think we are in the process of shifting over to a new generation of tooling, ready to combine all these things into one. So that's what we're looking at really. Another final part is speculation. I don't know what happens to JavaScript by 2030, but in the original impetus for this talk was this amazing talk, and it's really hilarious called The Birth and Deaf JavaScript by Gary Bernhardt, where he basically foretold what I'm exactly telling you, that JavaScript had a life from 1997 to 2035, and it went through quite a few stages. And he predicted the rise of something he called Metal, which is a language that was much closer to the metal that eventually made JavaScript obsolete. And I think he basically called this the universal virtual machine. That's something that Brandon and I also calls it. So the process of going through JavaScript helped us create this universal virtual machine that just runs everywhere, has the security features that we want, and just executes not in an interpretive fashion, but has all the qualities of the language that we like to work with. So Brendan has really started to modify his statement from always better in JavaScript to always be on JavaScript and WebAssembly. And I think the end of the third age will start to reckon a lot more with that. Web assembly is not there yet, but it could very well conceivably be there by 2030. You can start to see examples of this with popular applications like Figma, where their UI is using a lot of this under the hood yeah, so that's a rough overview of the thesis that we are in a third age of JavaScript. Hopefully it's been convincing. There are only two main arguments. One that we're adopting an es module feature and two that we're collapsing on the layers, but you can see the long journey that we took to get there and I hopefully have provoked your thoughts a little bit. If you're working on one of these tools, I really want to know about it because I'm basically self appointing myself as a documentarian for the next ten years and if you're just a user of these tools then I think you have a lot to look forward to. So I welcome your comments and questions. You can reach me at these contact details and if you want to learn more about progressing yourself as a developer spotting megatrends and strategic shifts for your technology choices, you can check out my book at Learning Public.org. Thanks very much and enjoy the rest of your conference.