I think the problem here is that you are setting up a situation where it is some binary choice between the insane complexity of SPAs and everything that entails and some random 90s style hand rolled PHP file.
There are a whole bunch of options between those two extremes and I can’t for the life of me think why people don’t talk about them more often.
For example, I think the new Hey.com implementation hasn’t received anywhere near the level of recognition that it probably should have.
It’s an entire email application with a single set of screens that power all web, desktop and mobile apps, does so with all the speed of an SPA, has no need for advanced state management, has the ability to push live updates on a per component basis on any screen and does it all in under 40kb of JavaScript.
But to me the past few years of SPAs are starting to look more and more like a mistake to me where they became the rule when they should have probably been the exception.
Unfortunately it is hard for me to comment on the hey.com web app as they currently have restrictive registration.
The benefit of building with a de-coupled JS frontend (SPA) and an API is that it can extended and adapted far easier than using server-delivered HTML.
If you have an API that delivers JSON/Protobuf/whatever, you can easily make new interfaces to that backend. If you are currently delivering a web app in HTML/JS, but decide you want a native Mac/iOS app written in Swift, you'll just end up building an API anyway.
Sure, there are plenty of websites that wont ever need additional interfaces, but if your goal is to make an app that can easily have new interfaces added to the mix, de-coupling is the way to start in my opinion.
You make a good point, and this is one of the reasons why I really like the Phoenix web framework (of the Elixir ecosystem). It firmly guides you towards building applications where Phoenix is only a single interface to your underlying Elixir application, and the web layer, by design, doesn't contain business logic, but rather just gives you a web-friendly way to talk to the application itself. The community has come up with the mantra of "Phoenix is not your application" to drive this point home.
This approach and separation of concerns also means that building e.g. REST or GraphQL APIs on top of your application is simple, as your web framework has no say in how the data is actually structured or queried.
I hear what you’re saying. I think the main thing I would push back on is the order in which you make those decisions however. Why take on all the additional cognitive overload from the start of the project because you might want a native screen at some point in the future? It’s basically another version of the micro services debate.
I think there is a heavy if unconscious bias among web developers now that the “one true way” to build web apps is to take the same methodologies and frameworks from Facebook and Google usually.
I’m obviously not the first person to point this out but trying to replicate the software development processes of some of the largest companies in the world is in no way correlated with a better anything (user experience, dev experience, code, time to market etc).
In fact I would take it further and say that there are a not insignificant number of new developers especially from the dev boot camp style pipelines who literally don’t even know how to build anything without reaching for one of these tools. We saw the same thing with people reaching for Bootstrap or now Tailwind for a long time and not knowing how to do anything outside of it. This isn’t to give them a hard time, I have been that kind of Stack overflow driven developer myself for a long time. I just think that maybe as an industry we have made some poor choices that have become gospel overtime and it might be worth revisiting that.
To show off their frontend stuff, they left all of the JS available on https://app.hey.com without logging in. I think they plan on open-sourcing their improvements into new updates to Rails and turbolinks, eventually. If you've used Basecamp before it's fairly similar in speed, as far as I can tell (turbolinks + stimulus is responsible for that).
For the record it is worth mentioning that there is a major update pending for that library that handles some of the specific things outlined in the post I referenced above, however, even in its current iteration I think it is a much more sensible default to reach for than say React & Redux would be for a large number of applications.
There is a second library that they have used along side that for handling all of the app specific JavaScript here as well https://stimulusjs.org/
There are a whole bunch of options between those two extremes and I can’t for the life of me think why people don’t talk about them more often.
For example, I think the new Hey.com implementation hasn’t received anywhere near the level of recognition that it probably should have.
It’s an entire email application with a single set of screens that power all web, desktop and mobile apps, does so with all the speed of an SPA, has no need for advanced state management, has the ability to push live updates on a per component basis on any screen and does it all in under 40kb of JavaScript.
Seriously go and look at the source code. I’ve only seen a tiny number of people talking about it like in this post https://dev.to/borama/a-few-sneak-peeks-into-hey-com-technol...
But to me the past few years of SPAs are starting to look more and more like a mistake to me where they became the rule when they should have probably been the exception.