With server-side frameworks, there were so many things that felt unnatural. Why should I have to look up items in a database every single time a user hits a route? Why should I allow every possible string combination in /product/:id or /post/:slug.html when I know ahead of time that there's only a few dozen? Why should I write in a template language that's mostly copying JavaScript's own features?

For client-side the difficulty was that I didn't want to write a heavily dynamic site. In terms of UI, a traditional server would have worked just fine, as you just navigate from page to page. So why should I write it entirely in the client?

I get the reasoning. For one thing, this lightens the load of servers, allowing them to serve more clients at once. But at what cost? Serving multi-megabyte client files in place of multiple requests with much smaller payloads doesn't make a lot of sense.

So I wrote a ton of stuff, and only started open sourcing some of it recently, namely Principia (https://github.com/sdegutis/principia).

The overall approach I took was to create a server-side framework where as much as humanly possible was precomputed and pre-rendered. The framework is built around this by design.

For instance, when the site loads, it creates every route handler as a separate function and places them in a giant map with every known URL. This makes sitemaps super easy and fast, it avoids a database lookup for any request, and it makes for extremely quick HTTP request handlers.

And it turns out JSX is very easily precomputed at runtime if you just create a thin runtime on top of Node.js that compiles TypeScript to JavaScrip and runs it inside a virtual Node module. Which in turn also makes hot-reloading extremely natural to implement.

Overall I've written 3 or 4 websites using this, and I'm convinced it's a better than express.js for many types of sites.