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.
That sounds to be completely dependent on the type of team you have: have you asked them what they think?
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.
Our team is solid with a good mix of back end and front end skills. We have a legacy web app we want to modernize. Many people on the team want a SPA but I’m just cautious about blindly following the hype (remember when SQL was un cool until it was cool again).
As a user, I have yet to see a SPA that was an improvement on an old-style multi-request page, so good luck with that! And usually, it is much more of a slow-down with developers liberaly resorting to multiple in-page requests instead of prefetching the data early.
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).
I’ve used this approach - Go with templates TailwindCSS or Bootstrap, and on-page interactivity with IntercoolerJS or AlpineJS. Apps turn out to be very fast, SEO friendly, very easy to maintain and make great use of the optimized browser caching. My two cents. But it depends on what you are building.
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:
It really depends on what you're building. A content-heavy app, search/query type apps, or a basic CRM type app with CRUD workflows can easily be done largely with server side rendering plus Intercooler for the interactive bits you need. Check out some of their examples (http://intercoolerjs.org/examples/index.html) and see if it meets the types of interactions you need.
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).
9 comments
[ 4.2 ms ] story [ 25.2 ms ] threadIn 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).
Were there trade offs or limitations with those libraries?
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:
http://intercoolerjs.org/examples/index.html
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.