The Next Wave of Web Frameworks is BYOJS

The next wave of web frameworks is BYOJS. Hi, my name is Brandon Roberts. You can follow me on Twitter at Brandon T. Roberts, where I tweet out GIFs, I talk about sports and I block people sometimes. So you can follow me there. I am a maintainer on the NGRX project, which is a set of reactive libraries for Angular applications. I am also a GDE, which just means I've been around the Angular community for a while and been able to contribute some cool things there. I am also a developer experience engineer at AppRite. So for the agenda for this talk, I want to cover the history and evolution of building web applications and the different stacks that I've used over the years. I'll talk about the next wave of web frameworks and sort of the meaning of BYOJS. And I'll talk about what that means through the lens of the Astro project. So first I'll talk about the history and evolution of building web applications. As I mentioned before, this is from my point of view, which has been a number of years. Your mileage may vary here. So let's just get that out of the way up front. But I think we'll have some similarities along the way. So let's get into some of the history for building web applications. We have traditional server side applications, which we'll talk about, client side applications, and more modern server side applications before we get into the next wave. So for traditional server side applications, let's talk about some of those. There's PHP, which is still a favorite amongst developers. There's also another old school pick is classic ASP, which is similar to PHP, but using more of a.NET like syntax. There's also.NET MVC, which is another framework from Microsoft used to build web applications with a more clearly defined separation between model, view, and controller. This also came along as a way to serve up HTML application using various templating languages. And of course, there are many others that came along the way. These server side frameworks did all the processing on the server and just returned the HTML. If there was any JavaScript functionality on the pages that we were building, it was more or less sprinkled in as inline scripts or lightly bundled JavaScript files concatenated together. This was usually done using the well known jQuery library back in the day. So now we get into client side applications. So when more JavaScript was being introduced into these applications, we started seeing more bundlers get involved in the process to optimize the process of shipping JavaScript to the users. Open source tools such as Gulp, which is a toolkit that uses a streaming build system. There's also Browserify, which one of the early tools that allowed developers to use Node.js style modules and compile and use them in the browser. Require.js, which is a module and file loader system that also uses Node.js style imports. And System.js, where it used standard ES modules that could be loaded in the browser. And with the evolution of web applications being built for client side applications, more web frameworks came along the way. Web frameworks such as Backbone, which was an early MVC framework for building client side applications. There's Ember, which heavily leans on conventions and integrations for building web apps. There was AngularJS that integrated in with existing HTML with things such as directives. Angular its successor, which targeted more general applications. React introduced in 2013, which really changed the way we thought about building UIs in JavaScript. And there's Vue that has come along and paved its own way as a tool to build web applications. And of course, there are many other web frameworks that have came along in this space. So for modern server side applications that were built in JavaScript, in the React space, we have ones like Next.js, which is the largest React framework to date for building applications. And newcomers to the space such as Remix, which kind of combines some of the things from client and server together in a more cohesive way. In Angular space, we have things such as Universal, Angular Universal to render client side apps on the server. And for Vue, we have tools like Nuxt. And there are other ones in this space also. Building JavaScript applications also brought the need for more advanced build systems. And so some of these systems just made it easier to bundle JavaScript to ship to the client. And this also made shipping full client side applications a lot easier. Webpack probably being the most notable to date, which is with its rich set of plugins and customizability. There's Rollup, which is a module bundle for JavaScript that compiles small pieces of code into something into more larger bundles, such as a library or an application. There's also Veep that has come and taken the web landscape by storm with its speed and extensibility through plugins. And it also builds on top of Rollup and is built in a different language, but is used for building JavaScript applications. If you're in the monorepo space, there's tools like Lerna, which kind of orchestrates build tools and has been around for a number of years. And tools like NX that have modernized open source monorepo development. And there are others in this space also that have come along as build system or tools to help developers ship web applications. Because at the end of the day, we just want to get back to shipping code and shipping applications to users and providing good user experiences. So next up, I'll talk about the next wave of web frameworks and ways to ship applications with JavaScript that have come along. So we can start with the why we have this shift in traditional server side applications to shipping only or the majority of applications using JavaScript and getting some of the new tools that are out there. One thing that really came along was the idea of or tools that let you measure performance for web applications and give you more insight into that process. There's also the rise of the Jamstack, which is looking into what the definition of that is and how the different tools in that space. And what I'm calling at least for this talk the static first or HTML first web. We have tools that measure how quickly and how long it takes for a page to load. There are also lots of well-known tools out there. I'm using web.dev as a reference for the metrics that we use to measure this. Now Lighthouse is a tool that you can use also to measure web performance for a given application. And I'm just listing some of the metrics we can use to do that. There's time to first byte. And time to first byte is a metric that measures the time between the request for a resource and when the first byte of the response begins to arrive. There's first contentful paint, which measures the time from when the page starts loading to when any part of the page content is rendered on the screen. There's also largest contentful paint, which is a pretty important user-centric metric for measuring perceived load speed because it marks the point at which the page load timeline when the page's main content has likely been loaded. There's also the time to interactive metric that measures when the page starts loading when its main sub-resources have loaded and the user is capable of responding to user input. So using these tools and metrics have allowed us to gain better insights on how we're using or overusing JavaScript in the applications. Larger bundles means more JavaScript process and HTML has always been the fastest way to get content to users. So we wanted to look for a better mix there. So what are some of the tools in the next wave of building applications with JavaScript? We have the JAMstack and I'll talk about what the JAMstack is and how it provides some tools for building web applications with JavaScript. I'll talk about SSG or static site generators, talk about server-side rendering, and then we'll talk about the static or HTML-first web applications that are cropping up or frameworks that are cropping up now to help us ship code. So there's the JAMstack and the definition of the JAMstack has evolved over the years. It started out looking something more like this where the JAM and the JAMstack was capitalized and it meant represented, talked about using JavaScript to enhance pages, APIs to most commonly use things like serverless functions for offloading data fetching from the client or integrating more code into the client there, and markup, of course, HTML for rendering content on the page. These days, JAMstack is more now defined as an architecture that's designed just to make the web faster, more secure, and easier to scale. And it builds on many of the tools and workflows that developers use to help them be more productive. And that's just coming from the JAMstack.org page there for the definition. So static site generators are focused on pre-rendering where the pages are rendered at build time and served on the client without any HTML included there. In the JAMstack, they're also focused on decoupling APIs and services from the client side applications and enhancing these pages with JavaScript because the HTML is already rendered instead of using the JavaScript to render the page in its entirety. There's also server side rendered applications which fall in this space where the pre-rendering is done on the server and then sent to the client. And after the page is rendered, the client side JavaScript is loaded and rehydrating the page to make it more interactive. And this is also where we are still shipping a single or maybe a few bundles to the client to handle this in the client side application. And as I mentioned before, this provides faster time to interactive metric if we're measuring like the performance of the page itself. So each one of these tools have kind of moved in that direction of trying, of course, trying to get the content and data as quickly to the client as possible. I always also mentioned that HTML has always been the quickest way to get there. So these new wave of tools are moving to what are called static first web or HTML first web where the primary way is rendering HTML and then adding some JavaScript in some unique ways there or not even adding JavaScript at all for the different types of websites that we're going to build. Some of these tools include QUIC, which is a relatively new HTML first framework that renders all the HTML using SSR and only at a very granular level only generates the JavaScript that you need. There's also Speltkit that uses server side rendering with progressive enhancement to actually enhance the page where you still get the benefits of HTML first and with the additional functionality there. There's also Eleventy, which was created as a JavaScript alternative to Jekyll. This also ships zero client side JavaScript up front. Another tool that I recently found out about is called EELS that's new in this space. And then there's Astro, which I'll talk about further that is a static site generation tool that has additional integrations. As I mentioned before, EELS is relatively new and was kind of inspired by Astro. But the biggest thing we want here is balance where we still get content to the users as quickly as possible while providing a rich user experience for web applications. So next up, I want to talk about this new static first or HTML first web through the lens of the Astro project. Now, Astro is a static site generator that also has recently added support for SSR server side rendering. Ships zero JavaScript out of the box when it's rendering the app pages in your website. It promotes things such as the islands architecture and uses partial hydration, which I'll get into further. It has integrations. And then we'll talk about what that means in the world of BYOJS, as I call it. So as a static site generator, you're dealing mostly with websites here. So you are building things like landing pages, marketing sites. There's also blogs, things that don't require a lot of user interactivity or maybe just a little bit of user activity, interactivity, and just general making a just general differentiation between websites and web applications. As I mentioned before, Astro ships zero JavaScript by default. So it uses server side rendering or user service rendering to render these components on the page. And it does that by stripping all the Java using the rendering the page at build time and stripping all the JavaScript away from the page and only shipping you back the markup so that you can use that with your styles to present that data to the user. Now, there are areas where you, as I mentioned before, it supports partial hydration. So there are areas where you will need some interactivity. And it uses that by only providing or only loading what's needed for the client at that particular time. So each specific component has maybe has a certain set of JavaScript functionality. And these include examples like an image carousel or an autocomplete search bar or even a mobile. These are things that when rendered on the client, you still want to have some JavaScript there to, like I said, kind of enhance that experience. And as I mentioned before, the islands architecture is the idea of using partial hydration to build entire websites. And this is an alternative to the common process of building a website, like a complete in JavaScript and shipping that entire bundle to the user, whether this be a single bundle or maybe a few lazy loaded bundles. But we still get those components loaded individually for the website or maybe a small web application itself. And all these things are loaded in isolation. That way, they aren't connected to each other in any way. So they don't have any dependencies on what's needed to be loaded for those. So looking at an example page, we have some distinct areas here. We could have a header page where the header is loaded independently on its own island, a navigation bar on the side that may have its own subcomponents there, and the main area to display content for the page. And as I mentioned before, all these things are considered islands and isolated and loaded independently from each other. So this islands architecture, the components in the islands architecture also make use of these different directives. And these are directives that when loaded, used on the components, they can tell you when the page is loaded to load the component, when the component is actually visible on the page to not load the JavaScript until that component is there, or if the user is browsing the page and they are idle, then to load those components. So definitely making use of deferring that as far as possible for showing that to the or loading that JavaScript for the user. So what does this mean in terms of the BYO.js that I've been talking about, mentioning during this talk? So BYO.js is bring your own JavaScript framework included there. And Astro does this through integrations. So Astro is different that you can bring your existing knowledge of your framework of choice and Astro knows how to integrate with those web frameworks and render those components on the page statically and add interactivity to those components later when you need it on the client. So you get a little bit of the best of both worlds. Astro supports just about all the commonly used frameworks that support components out there, such as React, Vue, Svelte, Solid, and more. There are more that I've just listed here. They also have APIs that would allow you to potentially integrate any JavaScript framework into an Astro application. You can learn more about the Astro project at astro.bio where you can read more through the docs, learn more about the integrations, and see how it can help you build websites faster there. So definitely check that out. So to recap, I talked about the history and evolution of building web applications using traditional server-side, client-side applications and frameworks. Talked about the next wave of web frameworks, some of that are out there today, such as using the Jamstack and other tools in that space. And talked about the Astro project. You can find out more about Astro at astro.build to read more about the docs and get more interested or even get involved in the project.