I prefer the MPA (multi-page application) approach for most projects. If interactivty is needed, I use REST services and a data-binding framework on the front end.

That's very interesting - I use a similar approach. In my case, it wasn't deliberate. It came about from working on a variety of projects with management that had unclear and frequently shifting requirements.

A monolithic SPA approach turned into too much work when you'd have to throw out a bunch of code one day, replace it the next day with something just similar enough to cause a bunch of refactoring and bugs, etc.

In that context, it's easier to treat each page or major component as its own mini-SPA, then glue them together with a bare minimum of code.

For the same general reason, and to echo other comments, I recently chose Angular over React (or Vue) simply because Angular has a lot of built-in functionality that helps prevent a downward spiral of dependency maintenance from third party libraries and plugins, even if it's a little slower overall on many benchmarks.

This is the first time I've seen the "MPA" phrase used like this, but I think this is my preferred approach too.

Same, as a user I like the feel of going to a separate page.

Can you recommend any such frameworks?

Stimulus is is a pretty good example of a simple JS framework that binds via data attributes. It, coupled with Turbolinks or Pjax, should let you do nearly anything you'd typically use a more popular front-end framework for, for much cheaper. Check it out: https://stimulusjs.org/

Thanks, that looks really cool.

Knockoutjs works well for this, have heard vuejs is similar but haven't tried it.

That's for highly interactive pages of course, for simple pages that just need some regex validation or something, no framework is the best framework.

I find JavaScript (especially React) to be an awesome template framework for non-SPA websites. I've used it in situations where I'm just creating server side template components. The JavaScript ecosystem can be extremely enjoyable for fast development.

Saying you have SPA experience with the latest frameworks makes it easier to get a job.

I understand. I just do not accept the incidental complexity and performance tradeoffs these SPAs mean. I have built several of them over the last couple of years but still like to avoid them as much as possible.

SPA building experience, coupled with popular JS frameworks, sells usually better than the skills of carefully engineering solution for the task.

These "carefully engineered solutions" typically aren't - and instead random js bolt-ons to whatever server side language. UI state is smeared across layers, and ability to test, share and modularize suffers. SPAs usually are better engineered UIs than the alternatives.

Do you have data to back that up, or are you speaking from personal experience? I know how it can go wrong, but SPAs can become a mess too.

I had one project where we built a very beautiful, modern site that had about 50 lines of js in total. Of course your page-change times are going to be around 0.5s with an MPA, but SPAs are often slower than that anyway.

I don't know but with a service worker you could possibly reduce that 0.5 in your MPA further by caching likely next pages ahead of time.

Yes, mainly personal experience. SPAs can definitely be a mess too. Mostly calling out that managing state in one place makes unit testing easier, which usually results in a better quality codebase

The backend has to handle all of the scale. That's where the real difficult engineering comes in and if you're using JS there, you're going to pay a huge price. It doesn't seem like many front-end JS developers understand that pulling data from different places isn't actually a hard problem but instead correctly storing and managing that data at scale is where the actual engineering happens.

State management is hard. That is the core issue.

Note you can still use an MPA and have a dynamic UI using React/Knockout/whatever. It is just usually not done that way and most go full SPA.

Well in a way it makes sense. Its like learning any other technology stack. The core stack may not be the best fit, but its considered a better bet to hire someone with experience in the target language/stack because the learning curve is reduced.

AKA, a developer that knows the same framework your app uses, only has to learn about your specific application rather than all the background libraries/etc your using. Its the same reason for preferring a C programmer for a C position over a ruby programmer (or flip it). Sure the ruby programmer might be awesome and after a couple years more productive, but in the meantime they will be making a bunch of newbie C mistakes, and generally bootstrapping slower.

This is part of the reason i'm in favor of generally reducing the number of languages/frameworks in general use. Its better for everyone if we all agree on some simple baselines even if they may not be the most optimum for any given problem. The efficiencies of repeatedly avoiding a bunch of rookie mistakes (and then having to debug/fix/test them for the next few years) is well worth it in the long run.

Resume driven development works. Unfortunately.