A single-page app is almost always worse than a multi-page app

User Experience is not just about bottom line, and approaching it from that position is just terrible. People that have to interact with terrible UX don't like those interactions. A 500 error with a bolded text saying "an error occurred" is going to make me never return to your site, because a reasonable user experience for that page doesn't require 10 hours of work.

I'm not sure stateful vs stateless is even the right way to frame it.

With no JavaScript at all, your application is still stateful. Even if an individual HTTP request is stateless, your app as a whole still has state. The state just lives in the database in that case, and each request you make either gives you a view of part or all of its current state or provides data to transition the application from one valid state to another valid state.

Actually, thinking of an application as a series of transitions between valid states is why I enjoy using things like Redux. Used properly, it acts as a gatekeeper that makes it hard to move the application from a valid state to an invalid one. It adds a fair amount of boilerplate, though, which I know some people find frustrating.

Maintaining state on the front end and keeping it in sync with the back end is a pain. But I don't think it has to be. it's just an artifact of us being stuck in a certain paradigm of application development that we don't seem to be able to get out of.

It wouldn't be impossible to design a system that runs over a network, but doesn't require the front-line application developer to think about the network. It sounds like something Alan Kay might have worked on at some point. :)

I envision a Smalltalk-ish environment where, in my application running in a browser, I send a message to an object telling it to save itself. And when it receives this message, it transmits itself across the network, validates its data, and persists itself into a database. Maybe an object database like Gemstone/S. But the application developer wouldn't have to worry about all the details most of the time. Just tell the object to save itself, and it'll report back whether it was able to or not, so you can update the application accordingly.

I'm sure I'm overlooking a ton of potential pitfalls, of course. I think we can do a lot better than we're doing right now, but I'm not 100% certain what better looks like, or quite how to get there. Maybe I just need to watch a few Bret Victor talks for inspiration and then get to work trying to build something. :)

Totally agree with you. There is a huge benefit having a clean API which works for a variety of clients (native / mobile / desktop) and a corresponding variety of team members instead of maintaining 2 different view sets on your backend, without even talking of the specific issues you can find yourself in in web development (browser specific features / inputs / styles / ...). And you still can't do any real native apps.

You can have the best of both. The simplicity of multipage apps with the feel of SPAs. Turbolinks is one example that comes to mind.

Or if you want the full power of React, Redux, AND the simplicity of Turbolinks/PJAX. You can use https://jho406.gitbook.io/breezy/ which is Turbolinks for React Redux Rails, you can build SPA without APIs, just by treating JSON as a navigational format.

Full disclosure, I'm the author and I've been trying to get some feedback on the project.

That's like saying that if you have to kill a fly, why opt for swatter when you can use a bazooka?

After spending some years building an SPA webapp, I'm really missing the simplicity of stateless HTML. The front-end framework my colleagues picked really likes to carry state around, like between pages, which has caused numerous hard-to-find bugs. These bugs are triggered when you do certain sequence of actions across multiple pages. That stuff should be impossible. We really ought clear all state between pages, but apparently it's harder to fight the framework to do this. Carrying state around is just fundamental for it.

I'm currently on hiatus from that project to work on a small one that's needed quick. So far, I haven't used a single line of javascript, and it's a multi-page form. I can add, remove, and edit rows from an HTML table without javascript or server side state. Instead of an autocomplete input, I used an input and search button and had the server return a page with search results to select from. State is maintained through inputs, hidden or not. Different submit buttons perform different actions, but they all send all fields to be re-rendered in the next page.

I gotta say, it's just refreshing to do things this way after so much time. It's super-responsive not having to load and run bunches of javascript. It's also cool to see the forward and back buttons work for free, without any special consideration on my part. I can use them to replay every action I've taken in the form, all additions, edits, and removals of rows in the aforementioned HTML table, and the different form pages.

Were I asked to do things "prettier" (to somebody else's standard of what's pretty), I would just use minimal javascript. There is no reason to go all-in with a front-end framework just for a dynamic datepicker.