

React is badly designed - wanda
https://www.pandastrike.com/posts/20150311-react-bad-idea

======
nutate
Good clickbait, but almost nonsensical article. The idea of supporting web
components is great, but it's also a standards process in committee. React and
Web Components can play together
([https://www.youtube.com/watch?v=g0TD0efcwVg](https://www.youtube.com/watch?v=g0TD0efcwVg)),
so why draw some sort of false dichotomy between the technologies.

The thought that went into the virtual dom diffing strategy is an algorithmic
nicety that software in general can and has already benefitted from. React
itself is an implementation of that which provides real workflow improvements
for web and now native platforms. That's pretty awesome and usable right now.
I don't see this as a zero sum game, or as an all in investment strategy
unless you are going into some arcane questions of licensing, the code and the
ideas are out in the open. Ember, mythril, Om have all taken the ideas into
new regions.

Even look at the atom editor, they switched to react for their editor
component, then realized the general purpose dom diffing strategy which is
_very fast_ could still be optimized for their edit window. That's awesome.
That idea is decoupled from react. Learning to read react code takes about 1
day to 1 week. It's pretty awesome.

Also, the canard about reactive programming... uhh... I just don't get what
you're advertising here? That you're willing to use products like docker and
node.js as advertised on your front page, but not react.js because... it's
"bad"? Why so inflexible, why not try all the things and use what works as
time permits?

~~~
ryanisinallofus
On React in Atom: [https://discuss.atom.io/t/whats-the-status-of-react-in-
atom/...](https://discuss.atom.io/t/whats-the-status-of-react-in-atom/11456/4)

Do you have an update beyond this?

~~~
nutate
I use atom as an editor for markdown. But I don't know about if they're using
React in it or not. I don't follow the dev that closely. I am still rather
sure you can develop plugins in react, which is fine.

My point being that require('react'); wasn't the best fit for their editor
window (which doesn't need events to be intercepted, etc), but the idea behind
virtual dom diffing and how they updated their window left an impact. The
concepts behind react got them thinking in a new way, which is ultimately much
more important than their dependency on a 0.x.y release library.

If anything, the design of react was a stepping stone to where they've ended
up now. It wasn't "bad", so much as unoptimized for their specific task. For
me I'm glad it can intercept events (usually), since it simplifies cross
browser compatibility. Atom is essentially one browser version, so it doesn't
need that overhead.

------
insin
> But what has [virtual DOM] got to do with reactive programming? Or embedding
> markup in JavaScript?

It makes it possible to implement React's componentisation model in a
performant manner.

It allows React to not only work in all major browsers _today_ , but to use
its SyntheticEvent implementation to patch up and normalise aspects of their
behaviour which are important when writing webapps.

While React's ideas about data flow might not be new, the componentisation
model it uses to implement them makes it incredibly easy to compose and reuse
UI components, with a well-defined method of passing data between them and
controlling re-rendering.

It allows React components to be easily pre-rendered on the server and
rehydrated to be interactive on the client from the initial markup using the
same codebase, making progressive enhancement easier to implement, therefore
more likely to be implemented.

That's why the virtual DOM isn't the most interesting thing about React,
rather what it enables.

It would be nice if native Web Components just _worked_ everywhere right now,
but they don't. Maybe some day React will just another way to implement the
innards of a native Web Component, but at the moment it's just _better_ then
them.

------
mortenjorck
I understand the motivation for wanting to avoid frameworks when it looks like
a native solution is right around the corner, but that’s just it – it’s not
here yet. There isn’t even _experimental_ support for Web Components in either
the most popular desktop browser or the most popular mobile browser, and the
polyfills are simply nowhere near as mature or well-supported as React and
Angular are for the same purposes.

So yes, you could develop for Web Components today, and it would “work”
everywhere and it would be the platonic ideal of future-proof web development.
It just wouldn’t be very pragmatic.

~~~
nostrademons
Chrome's the most popular desktop browser [1], and Chrome for Android is the
most popular mobile browser [2].

[1]
[http://en.wikipedia.org/wiki/Usage_share_of_web_browsers](http://en.wikipedia.org/wiki/Usage_share_of_web_browsers)

[2]
[http://caniuse.com/#search=shadow%20dom](http://caniuse.com/#search=shadow%20dom)

It passed IE for desktop in mid-2012, and iOS Safari for mobile in late 2012
or early 2013.

I agree with your general point since the all Webcomponents-supporting
browsers are barely a majority. But the web looks very different from it did
even a couple months ago.

------
97-109-107
Why can't I zoom the text on this website in and out?

