7 ms·

I have to question some of this. Hot-loading is not why people use React, it's not even particularly reliable with React, and I often develop without it. The p

I have to question some of this. Hot-loading is not why people use React, it's not even particularly reliable with React, and I often develop without it. The primary reason to use React is that it's an easy API for working within the stateful component paradigm, and goes the extra mile in protecting you from state-related bugs. It still has value even if you drop the stateful part, it's not unheard of to build completely static or server-rendered websites with React without any client-side JavaScript. There are performance penalties when it comes to the initial page load, you tend to win it back when it comes to subsequent user activities. Whether it's worth the trade-off is dependent on your use case. There are also downsides to progressive enhancement, an obvious one is that if your enhanced JS version changes appearance/layout in a noticeable way, you could end up making the website feel slower even though it's technically usable sooner. In addition, what happens to any existing interactions with the non-enhanced UI after the enhanced version suddenly appears? The fact is, you just have to decide what's important. I do agree that not enough developers are giving real-world accessibility and performance enough consideration. But I'm less convinced that there's a way to approach these needs that is superior in all circumstances.

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

taeric 8y ago

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?

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.