React and the economics of dynamic web interfaces
nczonline.net
nczonline.net
The DOM isn't (that) slow; it's all the crap we do to it that makes it slow.
React's strongest selling point is its ergonomics: It frees the developer from having to write huge swaths of code that they otherwise would be with most previous libraries/frameworks.
It achieves that with its immediate mode rendering: you no longer have to reason about how to transition the DOM from one state to another (in nearly all cases).
Our shops avoided Angular altogether due to the complexity with larger apps, and used few other frameworks and libraries instead.
Trying various real world React examples frankly seems to involve more code, and the learning curve for React+Flux/redux/etc is really not trivial for a lot of people.
Overall, my recommendation is to use the simplest approach that works, and start adding libraries/frameworks only when they add clear value.
On the plus side: - It makes applications significantly more declarative, which is a readability win for me - It simplifies applications with rich history awareness. - It is fairly easy to reason about (particularly as compared with Angular) and debug. I find it conceptually more straightforward than backbone as well.
One issue I have with the article is that it reads like React was the first framework to bring componentized and encapsulated UI elements to the party, when in fact that was the norm for frameworks before Backbone and Angular. Specifically Dojo and YUI where heavily focused on components.
React pushed more on components acting as pure functions of state to DOM, but that style was not totally uncommon before React. Even in many old MVC frameworks, the best practices would lead to "stateless" views, and often controllers that act as pure functions for ease of testing.
I would say popularizing those functional principles, even if React actually implements them somewhat loosely, is Reacts best contribution. Eventually I think those principles will make their way into Web Components implementations, and we'll have interoperable components with React-like internals interoperating with any other off-the-shelf web component.
The point about attachment/detachment handlers also applies to Angular directives by the way. So it is extremely misleading to claim that React is revolutionary because of this. I think Angular was revolutionary, the only real new thing that React brings to the table is that you can have your HTML inline with your code - Some people think that this is the "secret sauce" which makes react so modular and makes its components so well encapsulated, but it is not - Polymer achieves the same level of encapsulation without combining logic with markup.
React is just one of multiple good alternatives which may be better in some scenarios and worse in others.
Developers are being too idealistic about this. I think the web would be a better place for developers if we were more aware of the irrational nature of hype.
I dont have anything against React but I don't like hype. Hype is just excitement in the absense of reasoning. It's the result of good marketing and nothing more.
To me that's a feature
Our framework does this, without virtual DOM. You build apps by placing reusable components on pages. The pages honor existing web conventions -- so everything works like on the web. But then the framework manages HTML5 history for you, and even swaps javascript/stylesheets in and out as you load pages. It loads the code for pages and components on demand, as you navigate the app, and doesn't need a monolithic js and css file (although you could have one). Part of sticking to web standards is you can do things like caching on CDN, or even support caching files inside a PhoneGap bundle, so they load instantly on a "native app", which you can make.
http://qbix.com/platform/guide/pages
All this does not require a virtual DOM. React and Mithril are great for virtual DOM but you don't NEED it. In fact, the fastest approach to components re-rendering themselves is:
1) Have the constructor insert the HTML elements, eg by rendering a template, and store references inside the component to the elements it might want to update.
2) When some of the component's state changes, simply requestAnimationFrame and make a batched update, using the same convention as react's "render" method. Only the components whose state changed will update. That's what Angular does: dirty checks the state instead of the DOM.
3) Traversing parents and children should be done via the component object tree, not the DOM.
And voila. You have the speed you need, where you need it. The main challenges are other things, like registering/unregistering events, activating/removing components while navigating pages, caching, retaining data until you don't need it anymore etc. And for that you need a framework.