4 ms·

This goes into great depth explaining what has become a tired argument. No, you don't need React for everything. Yes, there are lots of benefits to rendering st

by _bxg1 7y ago

This goes into great depth explaining what has become a tired argument. No, you don't need React for everything. Yes, there are lots of benefits to rendering static HTML if your interface doesn't have much dynamic state. And yes, React can still be a useful tool in the right context. Those who say you should use it for everything are naive. Hopefully your team lead who's making these decisions isn't naive. It's possible they are. I really don't think that anyone who's been in web dev for more than a couple years still disagrees with the above points.

mychael 7y ago
You're arguing with an imaginary straw man. Is someone credible in the React community saying everything should be be done in React?
- csande17 7y ago
  There aren't many people in the React community who are explicitly arguing that everything should be React. But there seem to be very few things that the React community believes are a poor fit for React. Take addons.mozilla.org. It's a simple, tiny website with a list of browser addons and a button to download each one. Perfect fit for server-rendered HTML, right? Nah, front-end developers rewrote it in React. [1] Or blogs. Blogs are just a collection of text pages with occasional images and links. Surely you should use static HTML for those, right? Well, okay, but only for the initial page load; after that, make sure you let React take over so it can "improve" your page navigation. [2] [1] https://blog.mozilla.org/addons/2017/10/25/test-new-look-addons-mozilla-org/ https://blog.mozilla.org/addons/2017/10/25/test-new-look-add... [2] https://www.gatsbyjs.org/blog/2017-07-19-creating-a-blog-with-gatsby/ https://www.gatsbyjs.org/blog/2017-07-19-creating-a-blog-wit...
  - Dockson 7y ago
    You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative. Browse around this [1] website and tell me it is not a better experience than your bog-standard html + vanilla js concoction. Also every time this is brought up the developer/content editor experience is entirely neglected, when in reality it is a big consideration when creating something other than your own dev-blog that you update once a year. [1] https://reactjs.org https://reactjs.org
    - TeMPOraL 7y ago
      > You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative. Yes, instant page navigation without flickering is better than the alternative - instant being what you get from reloading a static HTML page, alternative being React. Seriously, fetching, parsing and displaying a tiny bit of HTML is fast. As fast or faster than the React virtual DOM shenanigans, once you account for the computational load the framework adds on top of your simple page.
      - Dockson 7y ago
        Real life is not code golf. We do not build things entirely for ourselves. We build things for our employers, for our co-workers, for our family members and for our friends. We build to create value for someone and value is not a one-to-one correlation with the weight of a site in KB. If I can make it easier for me and anyone working with my site in the future by sacrificing 50-150 KB then I will take that deal any day of the week. That is what abstractions are for. That is why we do not work in byte-code. We pay for convenience in clock-cycles and disk space.
        TeMPOraL 7y ago
        Arguably, using React where a static HTML with maybe a little bit of vanilla JS would do, is code golf. HTML and CSS are not bytecode. They're high-level abstractions, hiding a very complex renderer underneath. Sometimes you need to build another tower of abstractions when this doesn't suffice - like when you're trying to build an application with complex GUI in the browser and you need an adapter between DOM and a more suitable GUI pattern. But displaying text and images communicating a message is not one of those cases.
        Dockson 7y ago
        We do not rebuild the tower of abstractions for every site that uses them. I do not personally implement React from scratch when I use it for any of my sites. I get all of the benefits for none of the effort. You do not seem to acknowledge factors other than straight up performance, as is evident by what you are picking and choosing from my comments, so obviously it is not attractive to you.
- JMTQp8lwXL 7y ago
  There is no clear line between "what can be obviously done with vanilla HTML/CSS" and "that problem definitely needs React". So, most people opt for something like React to enable the capability, in case they need it. There's nobody purely saying that 100% of everything should be in React, but that's effectively the outcome.

by _bxg1 7y ago

mychael 7y ago

You're arguing with an imaginary straw man. Is someone credible in the React community saying everything should be be done in React?

csande17 7y ago
There aren't many people in the React community who are explicitly arguing that everything should be React. But there seem to be very few things that the React community believes are a poor fit for React. Take addons.mozilla.org. It's a simple, tiny website with a list of browser addons and a button to download each one. Perfect fit for server-rendered HTML, right? Nah, front-end developers rewrote it in React. [1] Or blogs. Blogs are just a collection of text pages with occasional images and links. Surely you should use static HTML for those, right? Well, okay, but only for the initial page load; after that, make sure you let React take over so it can "improve" your page navigation. [2] [1] https://blog.mozilla.org/addons/2017/10/25/test-new-look-addons-mozilla-org/ https://blog.mozilla.org/addons/2017/10/25/test-new-look-add... [2] https://www.gatsbyjs.org/blog/2017-07-19-creating-a-blog-with-gatsby/ https://www.gatsbyjs.org/blog/2017-07-19-creating-a-blog-wit...
- Dockson 7y ago
  You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative. Browse around this [1] website and tell me it is not a better experience than your bog-standard html + vanilla js concoction. Also every time this is brought up the developer/content editor experience is entirely neglected, when in reality it is a big consideration when creating something other than your own dev-blog that you update once a year. [1] https://reactjs.org https://reactjs.org
  - TeMPOraL 7y ago
    > You put "improve" in quotes as if instant page navigation without flickering is somehow worse than the alternative. Yes, instant page navigation without flickering is better than the alternative - instant being what you get from reloading a static HTML page, alternative being React. Seriously, fetching, parsing and displaying a tiny bit of HTML is fast. As fast or faster than the React virtual DOM shenanigans, once you account for the computational load the framework adds on top of your simple page.
    - Dockson 7y ago
      Real life is not code golf. We do not build things entirely for ourselves. We build things for our employers, for our co-workers, for our family members and for our friends. We build to create value for someone and value is not a one-to-one correlation with the weight of a site in KB. If I can make it easier for me and anyone working with my site in the future by sacrificing 50-150 KB then I will take that deal any day of the week. That is what abstractions are for. That is why we do not work in byte-code. We pay for convenience in clock-cycles and disk space.
      - TeMPOraL 7y ago
        Arguably, using React where a static HTML with maybe a little bit of vanilla JS would do, is code golf. HTML and CSS are not bytecode. They're high-level abstractions, hiding a very complex renderer underneath. Sometimes you need to build another tower of abstractions when this doesn't suffice - like when you're trying to build an application with complex GUI in the browser and you need an adapter between DOM and a more suitable GUI pattern. But displaying text and images communicating a message is not one of those cases.
        Dockson 7y ago
        We do not rebuild the tower of abstractions for every site that uses them. I do not personally implement React from scratch when I use it for any of my sites. I get all of the benefits for none of the effort. You do not seem to acknowledge factors other than straight up performance, as is evident by what you are picking and choosing from my comments, so obviously it is not attractive to you.
JMTQp8lwXL 7y ago
There is no clear line between "what can be obviously done with vanilla HTML/CSS" and "that problem definitely needs React". So, most people opt for something like React to enable the capability, in case they need it. There's nobody purely saying that 100% of everything should be in React, but that's effectively the outcome.