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'm 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'm also a developer experience engineer at App-Rite.

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 the 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 the way up front. But I think we'll have some similarities along the way. So let's get into some 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. Express also came along as a way to serve an HTML application using various templating languages. 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.

Now we get into client-side applications. 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 is 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 clientside applications, more web frameworks came along the way. 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 come 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 this space such as Remix, which kind of combines some of the things from client and server together in a more cohesive way. In the 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.

Modern 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 clients 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 as roll up, 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. Is also V that has come and taken the web landscape a storm with its speed and extensibility through plugins, and it also builds on top of roll up and is built in a different language, but it's used for building JavaScript applications. If you're in the monorepo space, there's tools like Lerna, which kind of orchestrates build tools, and it's been around for a number of years and tools like in X 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 JavaScript, ship applications with JavaScript that have come along. So we can start with the why we have the 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 our tools that let you measure performance for web applications and give you more insight into that process. There's also the rise of the jam stack, which is looking into what the definition of that is and how the different tools in that space. In what we call, 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.

Whitehouse is a tool that you can use also to measure web performance for an application. And I'm just listing some of the metrics you 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 is first contentful paint, which is 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 loads, 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 are using or overusing JavaScript in the applications. Larger bundles means more JavaScript to 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 next tools in the next wave of building applications with JavaScript? We have the Jamstack and I'll talk about kind of 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 like something more like this, where the the Jam and Jamstack was, you know, capitalized and it meant represented that talked about using JavaScript to enhance pages, APIs, to most commonly user, 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 a page.

These days, Jamstack is more now defined as an architecture that's designed just to make the web faster, more secure, 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. And the jamstack, they're also focused on decoupling APIs and services from the client side applications and enhancing these pages with JavaScript because HTML is already rendered instead of using the JavaScript to render the 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 rehydrated 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 on the in the client side application. And as I mentioned before, this provides faster time. Interactive metric if we're measuring the performance of the page itself. So each one of these tools have kind of moved, moved in that direction of trying to, of course, trying to get the content and data as quickly to the client as possible. I should also mention that HTML has always been the quickest way to get there. So these new wave of tools are moving to what is called a 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 they'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 Spellkit that uses server-side rendering with progressive enhancement to 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 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 and has integrations. And then we talk about what that means in the world of BYOJS as I call it. So the static site generator, you're dealing mostly with Web sites 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 Web sites and Web applications.

As I mentioned before, Astra 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 the all the Javas using the rendering the page on the on the at build time and stripping all the JavaScript away from the page and only shipping you back the markup so that you can, you know, use that with your styles to present that data to the user.

And 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 a maybe has a certain set of JavaScript functionality. And these include examples like an image carousel or an auto complete search bar or even a mobile sidebar. These are things that were 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 plea 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, in other words that 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 in 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 or 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 component is low or 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 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 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.build. 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 service or traditional service side, client side, and applications and frameworks. Talk 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.