Mind blown ... part two

Last week I mentioned how I had had my mind blown by Every Layout - a book on how to use CSS to build your page layouts that works extremely simply, without clunky responsive breakpoints.

A few days later, Dan Hobbs messaged me with a link to a video by Rich Harris. Incidentally, if you know any accountants, ask them to get in touch with Dan, as he's launching a new service just for them.

In the video, Rich, who works for the New York Times, mentions Hotwire but sort of dismisses it, citing a Github page which doesn't properly update as an example of why that style of update isn't quite right. My immediate reaction was "actually Github isn't using Hotwire and Hotwire makes that easy". But Rich's point stands - you have to remember to update those other parts of the page.

I first wrote in Ruby on Rails all the way back in 2005 and was hooked. As I say I'm pretty conservative when it comes to tech but Rails felt like the right way to do things.

And while Hotwire is the perfect fit for how Rails works, giving you the responsiveness, flexibility and client-side performance of one of those JavaScript frameworks whilst keeping the advantages of Rails, I finally think Rails' time might be over.

I looked at Svelte a few months ago and I liked it, even if the syntax is a bit odd in places. But Svelte is just a component framework (albeit one with accessibility and transitions built in, which is amazing). This last week I have been reading the documentation for Sveltekit - which is the framework for apps that sits around Svelte.

And it's truly fantastic.

Every page is a Svelte component. And using composition, you then load up other Svelte components inside that page. So far, so normal (albeit still better than Rails' pages and partials approach).

What made me happiest is routing. In Rails, you draw your routes into a config file. Same goes for most Javascript frameworks like React and Vue. One big file (or component) with (for large apps) a whole load of tedious code that's kind of divorced from the rest of your application.

In Svelte, you use the filesystem for your router.

Your accounts page is in router/accounts/+page.svelte, an individual account page is in router/accounts/[id]/+page.svelte (the folder name in brackets denotes a parameter - which then gets passed into the page component and javascript as params.id).

Any JS that's related to the accounts page is in router/accounts/+page.js. +page.js has access to the routes, the URL, the cookies and all the standard web-stuff we're all used to. And the results from +page.js are made available to your component as a data propert.

The really clever bit comes when you include /router/accounts/+page.server.js. This is a server-side only javascript file that runs when the page is invoked. The results from +page.server.js are then serialised and passed into +page.js on the client. So your +page.server.js can call into the database, load the relevant data, then your +page.js can take that data and create a client-side object which gets passed into the +page.svelte component to do with what it wants. All the stuff that Rails does, but cleanly and simply distributed across both sides of the network divide.

And then you can add directives for each page - is this page rendered on the server or on the client? If it's server-side rendered, it does the rendering and then is "hydrated" (has all the fancy stuff added) when it reaches the client - giving you the advantages of server-side frameworks like Rails with the advantages of client-side frameworks like Vue. Some pages can be marked as static, so they're rendered once on the server and then don't have to be re-rendered till they're invalidated. Others can be client-side only, so they're just delivered by your web-server and then do their work in the front-end. And some (probably most) will be marked as mixed - where both server-side code can be locked away, keeping your secrets safe, and client-side code can do all the interactions and fun stuff.

I'm just blown away by Sveltekit. It's so clean, so simple and yet keeps all the benefits of both client and server-side applications. And, after 18-odd years, it finally makes Rails feel antiquated.