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.<p>I hope at some point the original pattern is re-discovered and made popular again because it would make things so much snappier:<p>1. Initial GET request from user's browser against index and maybe favicon.<p>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.<p>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 <i>same context</i> returns the updated state as a new HTML document in the POST response body.<p>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.<p>All of this can happen in a single round trip. Latency is <i>NOT</i> 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.<p>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.