Ask HN: What about a hybrid between a single and multi page app?
Is there a best practice between these two approaches: a single page app vs a server generated multi page app? I’m mainly looking to optimize developer productivity.
Were there trade offs or limitations with those libraries?
If you want to go more SPA-like (and you really need that) you may want to look at Mithril (https://mithril.js.org/index.html#introduction). This is a light way to go SPA vice React (awesome but steep learning curve; all kinds of tooling needed).
We've built things like this: Most pages are server rendered using whatever you like (We use Go with Echo framework) the same server also hosts JSON APIs that allow the interactive Intercooler or AlpineJS arts to get either HTML fragments or JSON data. You can grab JSON with Intercooler too (http://intercoolerjs.org/attributes/ic-transform-response.ht...).
We've done search, DB apps (CRUD workflow), content sites, etc. exactly this way with a focus on developer productivity (very few libs to learn), user experience (ultra fast and SPA-like where needed), and performance (no giant JS balls to download, parse and activate).
EDIT: Just found this amazing example using MithrilJS to do very high speed updates of a bunch of data elements on a table page: https://raw.githack.com/MithrilJS/mithril.js/master/examples...
Hope this helps you.
The main trade-off is that you aren't going to be able to so something hyper-interactive stuff like a game. If you try to push it too hard it will end up being a mess. OTOH, the closer it is to a traditional web app, the easier it is to use.
There are a bunch of examples of common web patterns here:
In an ideal world with a decent project and team setup, there should not be much difference. If, however, there are a lot holes to plug with every change (eg missing tests, process overhead, manual integration or deployment), productivity will suffer.
But you specifically mentioned focus on developer productivity — note that developers might be more productive if they work on stuff they want to work on too (eg. developers not familiar with "modern" JS frameworks might be motivated to work on a SPA using them). Perhaps you can establish better what your developers would be more productive at long term by doing a survey to establish what technologies are they interested in learning, and what they feel they know best today? And then you can make a call for what will be only a moderate push forward (i.e. do not have everyone do everything anew).
I get your point with hype but I think SPAs are long past the hype today — they have their use, and can provide some code structure clarity and organisation as well. But to get to a seamless experience like gmail.com is a gargantuan effort (the same holds true for non-SPA web pages, but the focus there is different, and they can be more efficient even if they are not seamless).