(One of my summaries of the May 2023 Dutch PyGrunn conference).
Single page applications (SPA) suck! Stop building them! (He worked on them for the last 12 years :-) )
The promises of SPAs: UI is a function of the state. A unified API for UI and native apps. Nice composability. Better long-term maintentance. And faster development because you can split in backend and frontend teams.
6 years later… 2.5MB minimized javascript. Page speed perfomance sucked.
The negative side of SPAs: Performance is bad. Complexity is through the roof. Display logic in your app logic. Business logic creeps into your clients. The codebase is split. And the tech split makes people feel helpless.
The backenders are excluded from the frontend so they just start to care about the API. The frontenders complain about the unusable API that doesn’t care about the frontend…
Back to jquery? Never. It takes only two years instead of six years for your code to go bad. Composability doesn’t even exist as a word in jquery. Logic spread out everywhere.
We need a modern interactive site. What do we actually want?
Composability.
Understandability.
Server-side html rendering and a minimum of javascript.
Empowered backend developers.
He demoed “twinspark”, a small javasript library that can replace parts of an html page from URLs. On click or on hover. He wrote the javascript in some 200 lines of code. So “hover over this element and then replace it by what this url returns”. Super-lightweight, super-simple. Composable: it is all just your own template.
He extended it a bit and it is now 2000 lines of code and 8kb minified.
They use it instead of their former SPA now, they’re a big Ukraine online retailer!. The html page is 2.5x smaller. The javascript 80x smaller. And suddenly the browser is fast! The old site made browsers weep.
So it is good for the frontend. Is it also good for the backend? Well, there’s no weird state management. Simple request/response model. And you can add interactivity without javascript.
He showed a couple of nice examples.
The downsides? The frontend developers hate being forced out of their job. And keeping the same API for web and apps is harder. Figuring out proper patterns takes some time: we’re very used to single page apps, it takes getting used to again. And if you have really complex multi-step behaviour: that’s easier to do in React.
But… in their big webshop, there’s only one complex multi-step process that’s hard. All the other parts, like the order form, are now simpler. It is approachable. It is fun. It is fast.
“htmx” is an alternative. It has a much bigger community (but was started after his project… and misses some features). “Unpoly” is an alternative, too. But it is much bigger and more complex.
You can also look at the “live view” mechanism: phoenix, laravel, rails. Websockets. In demoes, it is mind-blowing. But the behaviour under load is questionable. And state is kept in memory on the server: you’ll need lots of them.
My name is Reinout van Rees and I program in Python, I live in the Netherlands, I cycle recumbent bikes and I have a model railway.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):