
React and the economics of dynamic web interfaces - tbassetto
https://www.nczonline.net/blog/2016/01/react-and-the-economics-of-dynamic-web-interfaces/
======
nevir
Performance is often cited as the "big win" that React brings to web
development; I really wish that wasn't the focus that (what seems like) most
people take.

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

~~~
sjcrank
In my experience the performance benefits are when comparing React to other
libraries/frameworks that also provide some level of developer ergonomics. In
particular, during the early days of React, it provided great performance in
contrast to AngularJS. Not so much when compared to well-written raw
JS/jQuery.

~~~
gedy
An honest question on this: how much are these touted benefits around
ergonomics, code-reduction, and simplicity are relative only to Angular or
vanilla JS?

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.

~~~
sjcrank
In my opinion, there's nothing wrong with using raw JS/jQuery for projects -
with discipline you can keep the code performant and well-structured. On the
other hand, I have found real benefits from React as the project grows in size
(current SPA is 50k lines of code).

Overall, my recommendation is to use the simplest approach that works, and
start adding libraries/frameworks only when they add clear value.

~~~
gedy
Thanks, yes to be clear we did use libs like Knockout, handlebars, requirejs;
and more recently have been using Babel/Webpack with RactiveJS, Riot, et al.
React is nice, but it's not clear that it's "better" imho.

~~~
jordanlev
It sounds like you might be in the right place to benefit from vue.js -- kind
of a modern/simplified knockout. Super lightweight, very easy to learn, and
just a view layer so it's not dictating your overall app architecture.

------
jondubois
Every point made in this article also applies to Google's Polymer framework.
The stuff about having handlers which trigger when an element is attached or
detached, the point about updating only the sections of the DOM which changed,
the speed, the data binding magic, everything... It all applies to Polymer as
well. Except that Polymer was around long before React. Also Polymer doesn't
require any special tooling and no build steps necessary.

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.

~~~
kaonashi
> without combining logic with markup.

To me that's a _feature_

------
EGreg
_React has, ironically, allowed us to once again think about writing web
applications as a series of pages rather than a monolithic blob of JavaScript
code. It 's no wonder that developers have become so engaged with React and
React Router: it's the same mental model as traditional server-only
applications. A page is rendered, some changes are requested, then a page is
rendered with those changes. The only difference is that this can all happen
client-side._

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

------
andrewingram
I don't think performance concerns really got people to avoid DOM manipulation
in practice, but it did mean that more thoughtful developers had to jump
through a large number of hoops to make things perform well.

~~~
omahlama
It's not really DOM manipulation that was avoided, it was the simpe rerender
on every change model that was avoided (for good reason, before React it
performed horribly for anything except trivial applications)

