CodeChat 036 - Colin Megill Brings Up Strong Reasons to Use React.js

Play CodeChat 036 - Colin Megill Brings Up Strong Reasons to Use React.js

The Discussion

  • User profile image
    Rob Eisenberg

    Clearly I am biased, but let's think about this.

    For years we have been saying that it's a bad practice to put JavaScript code in your HTML. But Facebook comes along and tells you that you must put HTML in your JavaScript code and we just accept that as ok? Clearly this breaks separation of concerns, makes it harder to work with a designer, destroys the declarative nature of HTML and forces you to work with a non-standard language: JSX.

    The big problem with React is that it encourages developers to abandon web standards. First off, you aren't using JavaScript, you are using JSX. Second, instead of learning the real DOM APIs you are working with their virtual DOM, which is different. You can even see that events and properties are named different sometimes. Next, you are asking developers not to invest in upcoming standards like Web Components, which actually solve the problems that React is trying to solve. Also, don't use CSS, use a non-standard JavaScript API...never-mind that there are browser standards being worked on (such as ShadowDOM and Scope Styles) that allow you to do the same things, but without the non-standard library.

    In recent years the community has developed a solid way to address browser issues. You work based on web standards. When the standard isn't implemented, you use a polyfill. Any library or framework for developing apps should be built on top of that approach. We should not adopt libraries or frameworks that advocate, either explicitly or implicitly, circumventing web standards or throwing them out entirely. We should endeavor to progress the native web.

    As web developers, we need to think very carefully about the consequences of adopting various libraries or frameworks. We should adopt those which are based on standards and committed to them.

    Recently, I've had conversations with developers who work on IE and Firefox. Both seemed to indicate that React was actually thwarting them as browser developers by taking developer focus off of the standards-based solutions which were in development. They indicated that the delay in bringing Web Components to the browser was actually linked to React's disengaging web developers from the standards and focusing them on React's components instead. That's bad for all of us.

  • User profile image
    Rob Eisenberg

    A quick follow up: I'm not saying that you should never use React. What I am saying is that you should be careful about using a framework that takes that approach. You should use it strategically, only when necessary...and you should do so with the intent (and plan) to pull the entire library out in a year or so when the native, standards-based technology hits browsers. React is not a long-term solution.

  • User profile image
    Ryan Roemer


    I think the "HTML in JS" is one of the common horror reaction when first looking at React. (And I know that was certainly my thought upon first seeing it).

    _But_, diving into React, there are these two fundamental wins that you get from the virtual DOM (which is the real magic behind what looks like "just HTML in JS"):

    1. Developers are not responsible for updating the DOM, the framework is. In highly performant, large scale apps updating only the very narrow portion of the DOM that you need to is exceedingly hard. Even for very, very advanced developers. And even in Backbone.js, Angular, Ember (pre-virtual DOM). With a virtual DOM framework like React, you design your web components according the organziation / decomposition that make sense to a _developer_ and the framework takes care of the most efficient DOM render for the _application_.
    2. You get a real, sensible, and understandable server-side render story. And it's very nearly for "free". You import your client code into a Node.js app and server-render. Step one: no "white flash" before the single-page applciation starts up. Step two: the JavaScript bundle downloads and start taking over, and React determines "I was server-rendered, just set state and don't re-update the DOM" and from that point on you are in a single-page application without additional real page loads. You get (1) a fast, seamless user experience from HTML (not JS) load, and (2) SEO compliant code with a trivial amount of extra work.

    And those two fundamental reasons are why the frontend world is rapidly moving to virtual DOM (Ember and I think soon Angular). It's an idea whose time has come (and predates React, but React has brought it to our popular attention).

    For browser compatibility, React apps are IE8+ compatible with es5-shim/sham + htmlshiv. And that's going to meet the vast bulk of acceptable browser support matrices for organizations.

    So, for me as an old-school Backbone.js developer, this is the first time in years I have been excited about a new frontend framework. (And disclosure -- I work with Colin) And I love the projects we develop now that are React-based.


  • User profile image
    Khuzema Turab

    Doing things in non-standard way is bad for all of the web developers. Especially a heavy weight like Facebook putting its weight behind it, is step backward.

    I am sure some will have great success with react for their project specific requirements, but generalizing it and blocking web standard is not right.



  • User profile image
    Rob Eisenberg


    I'm not trying to say that there aren't some positive performance wins from React. What I'm trying to say is that it encourages bad web development practices and is actually hindering the development of web standards which are designed to solve some of the same problems. The browser vendors actually said that to me. It's not good to see so much emphasis put on a library that help developers work against the native web and slows down the progress of improving the actual dom.

    It's important to know that using a virtual dom is not the only way to do efficient updating of the DOM. Aurelia doesn't have a virtual dom, and is even more efficient with most updates than React. Why? Because we have an observer-based model which doesn't need to do any diffing. Our observer model pushes all dom updates onto the Microtask Queue which effectively batches all updates to the DOM. The difference in our case is that we are actually using and encouraging working with the real DOM, using HTML, JS and CSS as they were intended to be used. We just add an efficient observer-based batching model on top of that. So, we work on top of the standards, not against them. That's really important.

    This notion that the front-end world is rapidly moving towards a virtual dom just isn't true. It's hype. Unfortunately, the average web developer doesn't understand how these things work or that there is even such a thing as the Microtask Queue. Most people don't know what is planned with Object.observe, WebComponents or even that MutationObservers exist. Why? Because they are busy learning frameworks that don't also help them learn the native web. So, use React and learn their dom...but you still don't know anything about how the real dom works. That's a serious problem. Actively pushing people away from learning and using web standards isn't acceptable.

    One of the problems is that the React team has actively pushed back against web standards...trying to move people away from using Web Components or ShadowDOM. That's just bad for everyone.

  • User profile image

    I agree with Rob. So how can we bring awareness to the general community on these standards. Can we have some more of the web standards  content on Ch9?

  • User profile image
    Earl Suminda

    me too agreed with Rob. React is super fast, but seems need to write more lines of coding and lots of manual works. I don't like to keep my html in js file.

Add Your 2 Cents