3 ms·

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 whe

by woah 8y ago

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.

srett 8y ago
> 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.
- abakker 8y ago
  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.
purple_ducks 8y ago
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.
TeMPOraL 8y ago
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.

by woah 8y ago

srett 8y ago

> 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.

abakker 8y ago
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.

purple_ducks 8y ago

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.

TeMPOraL 8y ago

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.