Old school web tech is the best. I still reach for multipart/form-data every day. Many of my web applications do not even have javascript.
I hope at some point the original pattern is re-discovered and made popular again because it would make things so much snappier:
1. Initial GET request from user's browser against index and maybe favicon.
2. Server provides static/dynamic HTML document w/ optional JS, all based upon any session state. In rare cases, JS is required for functionality (camera, microphone, etc.), but usually is just to enhance the UX around the document.
3. User clicks something. This POSTs the form to the server. The server takes the form elements, handles the request, and then as part of the same context returns the updated state as a new HTML document in the POST response body.
4. That's it. The web browser, if it is standards compliant, will then render the resulting response as the current document and the process repeats.
All of this can happen in a single round trip. Latency is NOT a viable argument against using form submissions. I don't think suffering window navigation events is a valid one either. At some point, that SPA will need to talk to the mothership. The longer it's been disconnected, the more likely it's gonna have a bad time.
The web only has to be hard if you want to make it hard. Arguments against this approach always sound resume-driven more than customer-driven. I bet you would find some incredibly shocking statistics regarding the % of developers who are currently even aware of this path.
I'm increasingly getting to this point as well. I think modern webtech is incredible in many ways, and if properly used could be pretty great but overall and for the most part we are pretty terrible at it. I've started to dread using SPAs because I know it's going to be sluggish and load megabytes of junk, and will still require frequent page reloads when clicking stuff Even though ostensibly it should not.
There's an exceptional beauty in a simple and lightweight website that is just a load and done. I've started doing more with Phoenix and Alpine for the little bits of client-side functionality required, and have been very pleased with it. The most interesting part though, is that users have also been very pleased. They can't explain why in technical terms, but they know it feels better.
Yes, SPAs are absolutely horrid. I tried to use HEY Calendar and the iOS app is just so absurdly slow I went back to the native iOS calendar app.
Maybe it speeds up their dev time but a native app should not feel like a (poorly engineered) web app. Every click loads for a second or two and sometimes it hangs for even longer. I grew to dread adding and managing events.
It’s a shame because even though the app made some questionable design choices, it was in general a breath of fresh air in terms of UI.
I’d like to hope that they’ll fix it, but I know they won’t.
When did you try hey calendar? I've never used anything from hey, but saw a lot of griping about its performance, and eventually saw that they apparently addressed the primary issues.
I was recently tasked with building a PWA to escape the play stores. A vitally important feature was notifications for the messaging system.
Hours of research trying to figure out how to deliver a notification through the PWA, even if the application was closed. Eventually I thought it wasn't going to be possible. But I remembered the HEY products were PWAs, and they had an email product. Surely that has the notification feature I'm trying to replicate? It's a paid service.
... no, I couldn't get their notifications to work, even though I enabled all of the proper settings. Crazy.
However, when I was about to give up and abandon the entire project, I had one of those moments, and got it to work.
I recently had a discussion with some "web developers" that just... couldn't understand how a web application could interact with the server without JavaScript and a REST API. They had never heard of traditional web forms! They didn't even know that was an option.
I wonder how these „web developers“ react, if they discover secret sauces like SSE, the „disabled“ attribute of <input> elements and SSI (server side includes)
I‘d love to be in the same room, when they edit their packages.json, spin up Docker just to create a basic CRUD form
This is good up to a point. If you have only a medium amount of CRUD-like data jn a basic structure in a single user context, this is fine. But when you get into complex relationships, collaborative editing, and unique visual representations of data, this guess right out the window.
The easiest example is probably also the first app to really sell dynamic web apps to the populace: Google Maps. There were meeting applications before Google Maps, and they operated much as you describe--through HTTP round trips--and they sucked. As a user, it was such a pain in the ass to wait for those things to rerender after every click. As a developer, it was such a pain in the ass to field those complaints from those users and know--barring some new invention in browser tech that nobody saw coming (XMLHttpRequest in Internet Explorer)--there really wasn't anything you could do about it.
It's true that a lot of sites go over board with their interactions. But that's not the same thing as needing to ditch asynchronous requests completely.
Modern JS frameworks work in this same way. You just create a form and provide the action which corresponds to one you define in your route file. It even still works without client side JS!
I like form submissions too, but it's not for everywhere.
For example, file uploads using multipart form submissions is a poor user experience - you cannot put in a percentage-complete bar anywhere because there is no way to determine how much data was transmitted.
When a file upload is taking 5m, the user is liable to think that the upload failed, and then retry, or give up. Very poor UX.
Other than that one exception, I cannot really think of any other place in which form submissions are the inferior choice.
You can also have both. Our apps are all spa. Bundled in single js, html and and js file. But we also have an ssr app runner that contains hundreds of thousands cached static html pages. Initial page load is from the ssr. Further interaction pure clientside. This way you have best app like experience and maximum seo. Setup is maybe 400 lines of code.
> Bundled in single js, html and and js file. But we also have an ssr app runner ...
This is exactly the kind of complexity and bloat the GP wishes we can get rid of so that we can return to simpler web applications with forms that do a simple POST and get the updated web page in response.
Basically serverside you have a simple route app that is able to run the web applications through a headless chrome instance. The output is cached in static html files. Now when the initial site is served to the end users browser from then on all interactions are all dynamic. This setup works for all kinds of stacks. Angular, vue, react or just custom.
The logic is pretty simple. No bloated layers of complexity.
To clarify, the headless chrome is because it's ultimately a js-rendered app, so you just pre-render all the routes on the server to get the final html, cache that, then serve the html on any first request. Then when the app is loaded in the browser, it just does everything client-side?
I hope at some point the original pattern is re-discovered and made popular again because it would make things so much snappier:
1. Initial GET request from user's browser against index and maybe favicon.
2. Server provides static/dynamic HTML document w/ optional JS, all based upon any session state. In rare cases, JS is required for functionality (camera, microphone, etc.), but usually is just to enhance the UX around the document.
3. User clicks something. This POSTs the form to the server. The server takes the form elements, handles the request, and then as part of the same context returns the updated state as a new HTML document in the POST response body.
4. That's it. The web browser, if it is standards compliant, will then render the resulting response as the current document and the process repeats.
All of this can happen in a single round trip. Latency is NOT a viable argument against using form submissions. I don't think suffering window navigation events is a valid one either. At some point, that SPA will need to talk to the mothership. The longer it's been disconnected, the more likely it's gonna have a bad time.
The web only has to be hard if you want to make it hard. Arguments against this approach always sound resume-driven more than customer-driven. I bet you would find some incredibly shocking statistics regarding the % of developers who are currently even aware of this path.