Hacker News Reader

Comment by taeric | Hacker News Reader

As soon as you find yourself storing a lot of state in your UI, you have already lost the complexity battle.

Granted, for some UI, this is hard to avoid. Those are much fewer and far between than given credit. Most state for a browser should be easily holdable in the address. If you find you can't do that, are you sure it is relevant state that your user cares about?

View on HN

Users want responsiveness instead of page reloads between every action. It’s pretty simple, and it’s what almost all customers (and their designers) ask for when getting a web app made.

The idea that there’s a mythical user out there who absolutely demands serverside rendering is a bizarre figment of HNs collective imagination.

> Users want responsiveness instead of page reloads between every action.

Then implement that. There are much more lightweight ways to achieve this than going full react. Especially with modern JS this can even be implemented from scratch.

Take HN as an example. Inline replying, voting etc. is undeniably convenient, but there is no way there shouldn't be a full page load when going through paginated results, or opening the comment thread to a post. That requires a couple lines javascript, no bloated js-framework-of-the-month. And the page stays completely usable without JS. A lot of stateful webapps out there aren't any more complex than this, structurally. Bonus: You get a fully working, predictable back button in your browser for free.

I would just like to chime in to say that users expect links in webpages and not in apps. I fully expect the webpage of hacker news to behave the way you describe, because it's a webpage.

I recently used the best webapp I've ever used - LucidCharts. That was an app, and, as such, I didn't have the expectation that everything I did generated a new link, or that I could even link to certain things. BUT, they also struck the balance of providing web behaviors for things where I expected them.

As Rails + Turbolinks has shown, unsurprisingly, users don't care what renders your page. As you said, they just want it fast.

Server side rendering HTML and serving it up works perfectly fast for pretty much every site which is read only content or forms. The of 3rd party scripts running on every page are the issue.

Also as a major negative against SPAs, once a script is loaded - it's going to be ever present on every page afterwards - enjoy explaining why payment details page needs 20 3rd part scripts running on it. Not possible to unload scripts.

Nah. For the users that like your JS-based responsiveness, a properly designed server-side HTML is likely to render faster. There have been demos that show that on good connection, a server roundtrip and re-render of styled HTML will be faster than AJAX and client-side renders.

And for the users on weak machines or connections, the reload version at least works, unlike the JS one.

The "users love AJAX" argument is both silly and honestly also a bait&switch. It's not really because of AJAX that people build their sites in JS frameworks.

Reply on news.ycombinator.com