Comment by voodootrucker | Hacker News Reader

Comment by voodootrucker | Hacker News Reader

Parent Full thread

> The allure of xmlhttprequest was that over connections much slower than today

As someone who implemented a SPA framework prior to "SPA" being a word much less React or Angular, I have to say for my company, it was all about state management.

Distinguishing between web apps (true applications in the browser), and web pages (NYT, SEO, generally static content), state management was very hellish at the time (~2009).

Before that, pages were entirely server rendered, and JavaScript was so terrible thanks to IE and a single error message (null is null or not an object) that it was deemed insanity to use it for anything more than form validation.

However, with the advent of V8, it became apparent as an ASP.NET developer that a bad language executing at JIT speeds on the browser was "good enough" to not send state back and forth through a very complex mesh of cookies, querystring parameters, server-side sessions, and form submissions.

If state could be kept in one place, that more than justified shifting all the logic to the client for complex apps.

I don't know about you, but "cookies, querystring parameters, server-side sessions, and form submissions" to me are an order of magnitude simpler, though dated and not very flexible, than any modern JS client-side state and persistency layer.

See: mobx

Form submissions are brutally bad the moment a back button comes in. I remember so many "The client used the back button in a multi-page form and part of the form disappeared for them" bugs.

They're not if coded correctly and using the correct redirect/HTTP response code.

Yes. You redirect after POST.

Yeah. I remember dozens of edge cases that involved errors and back buttons and flash scope and on at least one occasion, jquery plugins.

Or back buttons and CSRF tokens and flash scope...

Or, let's talk about a common use case. Someone starts filling in a form, and then they need to look at another page to get more information. (This other page may take too long to load and isn't worth putting in the workflow, or it was cut from scope to place the information twice.) So, they go out to another page, then back, and are flustered because they were part way through the work.

So, if you want this to work, you're going to need state management in the client anyway. (Usually using SessionStorage these days, I'd presume?) So, then, we've already done part of the work for state management. You are then playing the "which is right, the server or the client" game.

You accumulate enough edge cases and UX tweaks, and you're half way down the SPA requirements anyway.

Now, hopefully Hotwire will solve a large number of these problems. I'm going to play with it, but the SPA approaches have solved so many of the edge cases via code and patterns.

> but the SPA approaches have solved so many of the edge cases via code and patterns.

Part of the problem has also been ameliorated by larger screens and browser tabs.

> If state could be kept in one place, that more than justified shifting all the logic to the client for complex apps.

Reminds me of saving Rich Text content on the server side. It was nightmare.

Also reminds me of the Microsoft RTF format. It's basically a memory dump of the GUI editor.

The state binded on a tree was never a good idea to start with.

Reply on news.ycombinator.com