#1 Inertia.js and the modern monolith
After building with this stack, I couldn’t help but see that some of the promises of SPAs did not add up:
I started thinking if there was a better way. I like building SPAs, especially with Vue.js, but I also like traditional MVC server-side frameworks like Sails, Rails, and Laravel. The idea I had was a way to have both - a server-side-centric workflow that still uses a modern UI framework like Vue.js for my pages.
While I was thinking about this idea, I stumbled upon a project from the Laravel ecosystem by Jonathan Reinink called Inertia.js. Inertia.js was said to be the modern way to build SPAs without needing an API. I knew then this was what I was looking for, and here is why: Like me, Jonathan wanted a way of building SPAs without some of the above problems plaguing them. He wanted a single codebase, and the SPA should be server-driven with a robust MVC framework.
Load pages with the content and say goodbye to endless loading spinners
The way Inertia.js works is that it functions as a lightweight routing library. When a user makes a request to an inertia-powered web app by clicking on a link to visit a page, Inertia.js intercepts that request and makes an AJAX request to your server-side framework (in my case, Sails).
Your server-side code will then respond with the component name for the new page alongside the data the page needs as props.
No more flash of unauthenticated content
Have you ever noticed when you visit a SPA that has authenticated pages, you will see a flash of unauthenticated content? For example, a login button flashes before a dashboard button takes its place on the navbar?
This is no longer a problem with Inertia.js because before the page is rendered, the data it needs is sent down the wire as props, so the page already knows it’s an authenticated page; hence no flashes.
Little or no state management on the client
Let’s face it, state management on the client is hard. With this modern monolith powered by Inertia.js, the states needed by a page are returned with the page as props, meaning that you may not need a client-side state management library.
Sailscasts doesn’t currently use any client-side state management library. At first, I felt like I was doing something wrong. But when I saw popular web development frameworks like Remix confirming that you don’t need a state management library, I felt reassured.
A single codebase
This is more developer experience than it is user experience, but having a single codebase (a modern monolith) made me move quickly. Maintenance of the codebase improved, and also context switching dropped immensely.
I no longer need to route both in the client and on the server as all routing is done server-side. This is a no-brainer for me, as I prefer that the server handles the route definitions.
If you are interested in learning more about this case study, you can watch my Sailsconf 2022 talk.
#2 Astro, static sites and island architectures
With the rise of SPA and “Reactizations” (using React for everything), we’ve sort of abandoned good old static sites.
This is possible today with Astro. I recently took two of my websites - dominuskelvin.dev and The Sailscasts Blog from both being SPAs that were statically generated with Nuxt.js and Gridsome, respectively, to static pages generated by Astro. I wrote extensively about my experience with the rewrite on my blog.
Here are some of the core benefits I experienced with Astro:
You may then be wondering what happens when I need interactivity in an Astro website. Astro made this possible via Islands. Islands are sections of your pages that are partially hydrated, allowing them to be interactive.
Astro does this by letting me bring my framework components of choice into Astro pages and then make them interactive only when the user needs them. For example, I could use Vue.js, React, Svelte or Solid components and make them usable when the page has finished loading or when they are visible to the user.
Modern workflow with Astro components
I know we enjoy the component-driven architecture made popular by React, and we fall into the temptation of passively building everything as a React SPA. With Astro, you get the developer experience you have come to love in frameworks like React and Vue.js with Astro components - a JSX-inspired way of authoring Astro pages.
Out-of-the-box SEO and support for Markdown
One drawback with SPA is that they aren’t great for SEO, and for content-focused websites, SEO is gold. With Astro, since everything is HTML by default, you get amazing SEO out-of-the-box.
I also love authoring content with Markdown, and Astro comes with first-party support of Markdown out-of-the-box. This means, for example, you can use GitHub as your CMS because your content will already be in markdown files.
#3 Qwik and Resumability
Qwik is a new take on server-side rendering for interactive web applications and uses the concept of resumability, the opposite of hydration. While traditional SSR/SSG methods involve rendering an app twice - first on the server and then on the client for interactivity through hydration - Qwik’s resumability avoids this redundancy.
What resumability brings to the table is that instead of doing double work via hydration, your client-side interaction can resume execution from where the server left off. This infers that Qwik will only resume interactivity on the client in a lazy way and only re-render the portions of the app that changes because of fine-grained reactivity with signals.
Qwik is an interesting approach when you want to build a web app, but you want the benefit of SEO via rendering first on the server and a more performant way of handling interactivity on the client.
#4 React Server Components
Partytown’s use of web workers for this task is really impressive, as web workers were made to let you run scripts in the background. So any scripts that are not core to the user experience, resource-heavy or degrade the user experience are offloaded to a web worker, and Partytown makes that seamless.
I think that what really matters at the end of the day as we build our web apps and websites is the ease with which the users can get things done and the experience they have in utilising what we’ve built.
- How I want to build full-stack Sails apps
- Why the world needs Qwik
- Building resumable websites using Qwik
- How to build a Qwik app
- Resumability vs Hydration
- How I prioritise web performance in my development workflow
- How I maximise web app performance with Astro and Preact