 Mike is also another very, very good speaker that I've had the chance to meet a few times already. He's also one of the very few speakers that I personally know that has a parody account because you have a Mike Hartington beard account, Twitter account, right? I do, I have no idea who runs it, but every now and then they just pop in with like a random tweet about my beard. Well, yeah. Well, it is one nice piece of a beard right there. So thank you. So perfect. And Mike, you're working at Ionic as a developer advocate as well, right? Yes, yes. I've been there for a long time. Perfect, cool. Well, we're just about at 110, so I'll let you take it over and go on with your talk about frameworks are dead long live the compiler. All right, yeah. So just make sure that all this stuff works well. Cool. So we're gonna talk about how frameworks are dead and long live the compiler. Like Joel said, my name is Mike Hartington. You can find me online as mHartington essentially everywhere. I'll do my best to respond in the Slack channel after the talk. But yeah, if you have any questions or think of something afterwards, definitely ping me in Twitter. Frameworks are dead long live the compiler or how our best practices are failing and our users are paying for it. I have to include secondary titles all the time because I saw Dr. Strangelob once and I love the concept of secondary titles. So before we dive into this, I do have to say that I love JavaScript. I'm going to talk about a lot about how JavaScript might not be the best thing ever. Kind of perfect timing for the little word association for JavaScript. But I do love the language and I do love everything that you can do with it. Even though I'm gonna talk down on it a little bit. At the same time, I do really love the web. Everything about the web as a platform is probably the only platform that I really like building for and I've built for iOS, Android and some other platforms here and there. But the web is the platform that I feel the most comfortable with and I love seeing the web succeed and get better every year or so. But we have to state the facts and that is the web is bloated. If we look at any kind of website these days, chances are there are dozens of frameworks and libraries that are built into that code base to do something. Now, unfortunately, this is kind of our fault as developers, partially maybe my fault as developer advocate and all of the rest of DevRel is that we advocate the use of all these libraries and all of this JavaScript to generally just create a div. It seems like a little bit of an overreaction but when looking at the amount of JavaScript that actually gets sent down to the users, it's megabytes of uncompressed JavaScript to handle our rendering, to handle our styling, everything else involved with it and then we still have to consider the application JavaScript that we write and this is just framework JavaScript. Generally, Devs are way too much at the browser and the browser is not advancing fast enough to be able to handle this. So, let's take a little bit of a history lesson to kind of understand how we got there. Why is this the status quo and what can we expect in the future to hopefully fix this problem? I'll start by stating my thesis and that is compilers for JavaScript may or may not save the web. I say they may not because it's really going to be up to us to adopt these compilers and these tool chains into our common practices. So, let's dive into the very beginning. So, chapter one, kind of the rise of front end as we know it today. So, in the beginning we had HTML, JavaScript and CSS. HTML being standardized in 93, JavaScript in 95 and CSS in 96. Now, interestingly enough, CSS came out or was first published in 94 but didn't become standard until 96. So, this list may change. I like to think that's why people go HTML, CSS and JavaScript and not HTML, JavaScript and CSS. Either way, these three technologies have been with the web essentially since the very beginning. As far back as we can look with some kind of approximation. So, these technologies have been there since the very beginning and they're the same building blocks that we have today. So, everything that we have has just been building on top of whatever the platform brings us. But back in the early days, the browser really was kind of hostile. Internet Explorer was a thing, need I say more. We had different implementations of the standards, people who were working on competing JavaScript standards that were similar enough and could parse everything the same way but they were completely different languages. We had varying supports for CSS and JavaScript features in general. There are bugs in the languages that just existed and again, Internet Explorer was a thing. Building for the web on the early days of the, in the early days was not really a good idea and using those technologies was often avoided. People use things like Java to build Java applets. We had Flash and ActionScript to build different websites or even just animations. And then a little later on, we had things like Silverlight to kind of bring in the Microsoft kind of perspective. Now that went on for quite a bit and then around 2005, 2006, we started seeing the web get a second breath of life and this was the Ajax revolution and I like to credit Google Maps for probably being the first mainstream app on the web. And it was pretty revolutionary to think that you could search for a business within a certain location and not have to do a full page refresh to render that data. Things that we do every day at the moment are things that we do every day. Google Maps was doing this back in 2005, 2006 and this was like, it didn't reload. This is amazing. Shortly thereafter, JQuery 1.0 was released and this probably was the very first library that most developers these days have used. JQuery painted over all of the differences in the different browsers from Safari, from Firefox, Internet Explorer. You could just guarantee that your code was going to run well in those different environments by having some kind of API that existed on top of it. ES5 was shipped being the first version of JavaScript to actually get released since 1999 because ES4 was completely abandoned. And then we start seeing this explosion of different frameworks in libraries and JavaScript kind of being the big thing. So Backbone, AngularJS, Knockout, Ember, any kind of these library that you might have thought of in the first generation of JavaScript frameworks. Now, the web started to get better with this. People started actually building things for the web using JavaScript and building frameworks to help people build better applications for the web. And at the center of all of this was JavaScript. We were using JavaScript to provide our own semi-module system. We were using JavaScript to re-implement model view controllers. All of this stuff pushed JavaScript to the forefront and developers loved it because it was actually a good language. Now, fast forward a little bit, we start to see the rise of ECMAScript 2015 and mobile. So we start seeing mobile become the more commonplace form factor for websites. The amount of people who are mobile first or mobile only versus desktop, those ratios started to change and people became mobile first primarily. JavaScript also reached a new release point with ECMAS 2015 and framework authors took all the features that came in this release and just kept pushing forward. And generally the general tone of the room was more JavaScript for all the things. Frameworks kept building. So we had our own custom JavaScript based syntax for components. We had our own JavaScript templating language, whether this was Angular's HTML parser or views approach to doing single file components or even react with JSX. We also started seeing JavaScript based alternatives to native DOM because people thought the DOM was slow and that we needed a different approach to working with the DOM. So we created things like virtual DOM and incremental DOM and all these different ways to just say, hey, here's what your old state was, here's the new state, render the new state. And then people thought CSS was lacking in features and not a real programming language. So they decided let's reimplement CSS and do it all in JavaScript. So from having a little bit of JavaScript sprinkled around to having JavaScript for all of this, JavaScript became everywhere. JavaScript started showing up everywhere and it was always in that runtime kind of approach. Everything was done at runtime. All of our calculations were done at runtime. No good. This has led to the web getting big. Now meanwhile, mobile hasn't changed too much in the first years since very first iPhone. Devices, yeah, they get better and your iPhone 10 or iPhone 11 or the soon to be released apparently in it within an hour, iPhone 12, they keep getting better and they keep getting, you know, desktop class performance. But your average user is probably on like a three, four-year-old Android device which has less system memory, less resources than your laptop, which often leads to a browser which has a slower parse and compile time for your JavaScript. So you're working with a device that is slow, right out of the gate and you're trying to throw all of this JavaScript at it, it's just going to crawl which leads to the average load time on certain devices as being close to eight, 10 seconds, which is forever if you think about it. So we have too much JavaScript. We have too much JavaScript for our templating, we have too much JavaScript for our styling and generally too much JavaScript to do virtual dipping and do virtual DOM and incremental DOM, it's just too much. This is where we can insert the famous quote, scientists were too preoccupied to think, if they could, to stop and think if they should. Because we could do everything with JavaScript, we did, but we didn't stop to think if we should do everything with JavaScript and really, let's ask that question. Should everything be done with JavaScript? Maybe, maybe not. Can it be done in a way that's efficient and doesn't have a huge runtime cost? For our current status quo, is this a good experience that we're passing down to our users? I generally don't think so. And if you ask most people, it's not a great experience, especially when you're having to wait, no, eight, 10 seconds for a website to render a list of items. Mobile users, yeah, we all think, oh, well, we work in say the US, Canada, Europe, cell phone and connections are always pretty good. But what about the rest of the world? You don't even have to go to an emerging market. You could just go to a country and be in an area where, yeah, cell phone service is just not that great. Are you gonna be really telling your users to download all that JavaScript then also parse into pilot? Your loading times are just gonna jump up to 14, 15 seconds real quick, not a good experience. So, chapter three, enter the compiler. So we've stated this a few times already, but frameworks and JavaScript, they're everywhere. You are using JavaScript for styling, you are using JavaScript for templating. You might be writing things in actual CSS and using HTML for your templates or handlebars, but all at the end of the day, that's all getting transpiled down to JavaScript. And the average bundle size for JavaScript keeps increasing year over year. From 2019, we're already up 47%. And if you go to httparchives.org slash reports slash state of JavaScript, you're gonna see the actual tracking metrics for how much JavaScript is being sent down over the wire. This is just an average, your actual miles may vary, but keep this in mind that that's a lot of JavaScript being done just to do the very, very first paint. It'd be great if we could reduce that and actually get a better load time because right now all the runtime logic is hurting our users by delaying them, by delaying the actual loading time of our sites. So, this is where a compiler comes in to actually simplify this whole process. So if you are used to working in other languages or JavaScript is not your first language, compilers are not a new concept. For most JavaScript devs, compilers are a new concept. Basically all we're saying is we have some abstraction code that we want to run, throw it through a build tool and then I'll put some efficient JavaScript code or some efficient version of our app. Where the compiler, now that may sound like you're just talking about Webpack or Rollup, what have you. Yeah, but at the same time we can take all the code coming in, pass it through a compiler and then say, okay, we're doing X, Y, and Z, let's replace it with these much more efficient operations that we know ahead of time. So we can start to reduce all of the runtime JavaScript. Imagine all of your CSS and JS libraries being able to be compiled down to vanilla CSS and not have to pay the cost for re-rendering every single time. So we'll dive into this real quick and we'll just kind of look at a hypothetical example. So let's say we have a template for some kind of DOM that we want to render and all we're just saying is we have a div, the inner text is that we had say hello comma and then we're going to use double curlings in this case for some binding. Eventually we're just gonna say at some point there is going to be a property called name that we just want to render here. Now below that we can also have some conditional rendering. Basically if something evaluates to true inside of our class, let's just render that div below it if it evaluates to false, don't even include it. So the class for this component, we just say name equals world, should show equals true. So okay, we'd say hello world and our div would show. Great. Though that's all we're trying to do in this case. What does the actual output of this look like in different frameworks? So instead of trying to pretend to be an expert in every single framework out there, I'm just going to use the one that I know the most and that I can speak with most authority. And that's the Angular. And in this first example, we're going to look at Angular pre 9.0. So anything from Angular 8 to 7654, what have you? Now we have our component essentially isolated into this act component decorator with our template being hello double curlings and in this case, I replace name with title and then a div with this directive called ngif, which all it does is conditionally render the DOM structure it's attached to. So that's great. The class for this component, we just export a class title equals world, should show equals true. So everything looks like it should render well. So the output from this and bear with me this is going to be some fun kind of stepping through code. We're looking at compiled non-production but, or not production code, but not minified. So nothing has been renamed yet. So we have 33 lines here. I'll try to make this quick. Okay, so, oh boy. We have this function called view component one. I'm not quite sure. All right, so we're looking at import module. It's going to return on array. All right, I don't, all right. I don't know what this doubles double theta 1D div. All right, so we have should show. Okay, so I'm guessing that this is the should show div that I want to render later on, maybe. All right, let's step through the next part. Oh, all right. So we have more of this random webpack imported module and obscure references to code, div, hello. Okay, so maybe that's the hello world binding that we're going to generate. Okay, then we have the view component ref though. All right, so that's where that, what's this ng if you container ref? Okay, I'm giving up on that. I don't really understand what's going on there. What? All right, so we have some anonymous functions to check the bindings for should show and title and the value, why can't we just bind to something direct? All right, so this is all just very complicated and no one wants to look at through this. So this leads to code that is difficult to understand, difficult to debug and difficult to tree shape. If you haven't heard the term tree shaking before, it's just a removal of code not used by a program at build time. So we analyze everything and they were able to output more efficient code with less things that we, only including the things that we want to use. So in Angular 8 and earlier, all of that logic, all of those random imports, this is pointing to different functions inside of Angular that are internal, they're very tightly coupled. You can't use one without the other. It just leads to code that is going to always be large, no matter what. And this is gonna pass down to the users leading to slower, slower apps, slower load time and a lot more parse and compile time. Okay, so I said that was going to be Angular 8 and early, let's look at Angular 9.0 and see what they changed. So in Angular 9, one of their big initiatives was to ship a new compiler process called ID. Now they claim it's two parts, it's one part compiler and one part rendering engine where they have basically taken the internals of Angular splitting it up and made it much more decoupled. The compiler process of ID will be able to analyze all the code, all the templates that you pass into it and be able to better correctly understand what pieces it should provide and remove the extra functions that are not used. So again, this is easier to show than explain. We have our same component from before, we just had the hello binding and the ng if. Well, let's look at the ID version. So automatically we've gone from 33 lines of code to 27, but this becomes a lot easier to understand in air quotes, but we can actually kind of reason what's going on here. In the very first part, we have our template with element start and a div. Okay, makes sense. I'm gonna assume that this is a function called element start and we are just passing in the div that we wanna create or the element that we wanna create. We have element text or text, that's gonna be a function, passing in the text that we wanna know and then element end. All right, so we basically just created a div. Pretty awesome. All of these functions though are very isolated and they only know what they need to know. So we have a nice kind of law demeter approach right here. Further down, instead of having some functions for quick comparisons, we just have this .title equals world, this .shouldShow is equal true, so we could replace this logic elsewhere. The rest of our component becomes a lot easier to understand because we're still building off those concepts of single purpose functions that are easier to understand and that can be removed when they're not used. If I didn't render anything, I'm not going to need element start or element text, I will just return nothing. So this becomes a lot easier to understand and a lot easier to reason about what is not being used. So with ID, we have a much better process for taking whatever we want to render and creating smaller, simpler output programs. It's easier to compile, easier to tree shake, the compiler simplifies the rendering process and it becomes easier for us as application developers to maintain but also easier for framework developers to maintain Angular. Now, ID is not the only one in this landscape. I don't even think they're the first ones to think of this idea. Several other frameworks have also created this as well. So the folks from Ember have created something called GlimmerJS, which is the underlying API for Ember components. And they've taken it a step further by saying, what if we just ship bytecode? And then we have a small renderer and then a small runtime interpreter that understands what this bytecode means and how to render that out into the appropriate DOM structure. So they've gone pretty intense with this and their community seems to really like it. I'd be remiss if I didn't mention the project that my company works on, Stencil.js. It is a compiler and tool chain for writing web components. You can take a higher level abstraction around the web components API and then start to use things like decorators to provide expanded functions around your web component. If you don't use certain features of Stencil, well, it's just not included in that final output and it is removed because the compiler is able to understand what's going on. The one who I think is probably leading the way in this is Svelte.js. And if you take away anything from this talk, go play around with Svelte.js for a little bit. It's really, really compelling. They really take that idea of write less code and use a compiler for everything. So every aspect of Svelte is tree-shakeable and the compiler is able to add and remove features as it see fits. So their idea of a Svelte component is a script tag with some markup where we are exporting a title in a should-show property which we can set the default values and then we are rendering out a div and then we are using this if-should-show directive to render out the contents below. Now this is for a single component and the way Svelte works, everything becomes lazy loaded components so your entire component architecture ends up becoming these really small pieces that you can piece together. But when we run this through the compiler, we get something like this and I'm obviously not expecting you to all to understand this. Essentially, we just have a single function that represents that entire component all with JavaScript and it only includes the pieces that it needs and if you are watching this in HD and you can scan through this, you're probably going to understand a little bit of it. When we format it though, we get something that's 245 lines of code coming in at 3 kilobytes. It's just JavaScript. There is no Svelte kind of runtime or Svelte namespace. We just have the JavaScript needed to render this and then re-render when state updates. Svelte's probably the most extreme use case for this and I don't think anyone's ever going to get close to their footprint and their size, but it is definitely pushing people to do more and chase what they've achieved so far. So, let's take a breather. So, let's kind of have a little bit of an epilogue or recap of everything. Our compiler is the future. I kind of hope so. They offer the ability to have better code output without having to change how we write the app. By keeping that Angular example and just changing the Angular version in enabling Ivy, I had to change nothing about my template and the code output was much simpler and much smaller. Compilers also allow us to simplify how we build our apps and how our frameworks get architected. So, we can have a much simpler process for maintaining our tools and having a much simpler process for maintaining our apps. So, compilers in this case are really beneficial. There are trade-offs, obviously. You are changing... You are working in a different set of constraints now than what you would have used before. You are also asking... As a framework developer, you are also asking your users or consumers of frameworks to take on the costs of a build tool and a build chain. And if anything breaks in a build chain, you kind of are, you know, up the creek without a paddle. It's always perfect when Alex Russell tweets something that happens to be very applicable to a talk that you are giving. The ability to get started without a huge tool chain is massively underrated. In this case, they are talking about a library called LeHtml, which is just a JavaScript library. There is no tool chain. There is no compiler. It's just a function. And the thing that really sucks about this is it's not wrong. You know, not having a tool chain is pretty awesome. But at the same time, having smarter tools that can help us build better apps is massively better than having no tools and having to figure out all the stuff by yourself. So I don't know if compilers are going to be the big thing that everyone will use. I don't know if everyone's going to use them, but I really hope that they will. And again, if you take anything from this talk, watch this talk from Rich Harris, who's one of the original authors of Svelte, talking about this same concept and the same idea and how Svelte achieves it. I really want to know where can compilers, you know, take us in the next few years. So thank you for hanging around and listening to me talk. If you have any questions, you know, feel free to ask them in the chat, in the Slack. I'll be hanging around for a little bit. Also, feel free to ping me on Twitter. We love to hear your comments. Thank you. Thank you so much, Mike. That was very interesting. A lot of stuff and a lot of food for thought there. It feels like we do have a common thread, like everybody's talking about how we can reduce the footprint of JavaScript in each one of the talks that we've had today. So that's kind of an interesting thing that I didn't necessarily expect to hear today. It's a problem that happens across every tool chain and, you know, any way that we can all solve it is better. Yeah, that's great. If there are any questions, feel free to ask them in the Crowdcast chat or the Slack chat. I am monitoring each one of them. I've also posted Mike's Twitter, so you can actually ask him any questions over there as well. There is a question, what is the solution for the average enterprise developer building business apps? So the best solution, if you already are using a framework, just use that framework and just keep up to date with the new features and the new versions that are coming out. One of the things that I see people do and they just kind of pushed off as like, oh, we don't have enough time to update to the latest version. And then they end up getting three or four versions behind and to update to the newest version. It takes like a whole another month, two months of just development time to fix things and fix dependencies when if you had just spent maybe two or three days to update and stay consistent and stay up to sync with everything, that is probably the best solution for people who are trying to build apps. Just stay up to date with whatever tool chain you're using. And if you haven't found a tool chain, ask what your developer's background are. Figure out, are you comfortable, are you from a Java background and you need a great JavaScript? Maybe consider Angular. It feels very Java-like and friendlier to that kind of a crowd. If you're not, React, View, they're all pretty good options. None of them are really bad. It's just what's your favorite, what's your taste? Yeah, and I think to your point, I think upgrading from one library or a framework version to another one is a lot easier than it used to be. I remember moving from Angular 1 to Angular 2 was literally impossible. There was no upgrade path. They've made a very good effort to try to make it easier to upgrade. I think I've upgraded like six or seven apps between different Angular versions and it takes less than a day because I'm just running one command and it's just updates for me. So why not? Yeah, that's pretty cool. Thank you so much. That was a great talk. Thank you very much for everyone who wants to learn more. They can follow you on Twitter. Is there any other way to reach you? Yes, you can find me basically mHardington everywhere, GitHub, Twitter, some random sites, YouTube, if you really want to, or Twitch. If you follow me on Twitter, though, I will post my slides there, so incentive to follow me. Perfect. I'll repost your links there. Thank you very much for being here.