
React Enlightenment - tilt
http://www.reactenlightenment.com/
======
GrumpyNl
The first page, [http://www.reactenlightenment.com/what-is-
react.html](http://www.reactenlightenment.com/what-is-react.html) gives me all
the reasons for not using react. To much work for a simple select, or am i
missing something?

~~~
TheCoelacanth
That's a bit like looking at the source code for Linux's TCP stack and saying
"All that work just to make a TCP connection? I'm definitely not using Linux".

If all you want is a select in React, you can just do `<select><option
value="A">A</option><option value="B"></option></select>`. The tutorial is
showing how to roll your own select-like control using divs. I doubt that it
is much easier to do that using any other JS framework.

~~~
pothibo
Are you really comparing the linux TCP stack with an HTML select tag and
justifying React through that comparison? Are you for real?

~~~
TheCoelacanth
No, I'm saying that implementing something is usually harder than using
something. The tutorial is about how to implement a select; not about how to
use a select.

~~~
pothibo
That's still wrong. Using a <select> is still much easier than using React's
implementation of it.

~~~
artimaeis
> Using a <select> is still much easier than using React's implementation of
> it.

Yes, of course it is. But reading a tutorial about how you could implement
something so understandable as <select> using React is a pretty good guide to
understanding React! At least, to me it seems pretty great.

------
ergo14
I'm still puzzled people choose react over W3C HTML standards like web
components. It just doesn't make sense unless you want to support IE9/10.

~~~
seattle_spring
This comparison may help:
[https://facebook.github.io/react/docs/webcomponents.html](https://facebook.github.io/react/docs/webcomponents.html)

Basically, Web Components exist to solve a different problem than React.

~~~
ergo14
I'm not sure I'm convinced by "different problem explanation" \- in both cases
you produce a reusable component to use in your application.

> WebComponents provide strong encapsulation for reusable components, while
> React provides a declarative library that keeps the DOM in sync with your
> data.

You can use something like reflux with web components to do this too. The fact
that react uses virtual dom is an implementation detail I think.

Maybe I'm missing something obvious here.

Even react tutorial operates with components:
[https://facebook.github.io/react/docs/tutorial.html](https://facebook.github.io/react/docs/tutorial.html)

~~~
peterhunt
Components are not the big story as they've been around since the advent of
UIs and are present in plenty of JS frameworks before and after React. The big
story is the idea of expressing your UI as a pure function of the form f(data)
= view and being able to compose those functions together. Before React, you
couldn't do this in a performant, UX-positive way.

~~~
msane
_The big story is the idea of expressing your UI as a pure function of the
form f(data) = view and being able to compose those functions together. Before
React, you couldn 't do this in a performant, UX-positive way_

Well that is just entirely pretentious.

~~~
peterhunt
How's this pretentious? Certainly wasn't my intent.

~~~
msane
_idea of expressing your UI as a pure function of the form f(data) = view and
being able to compose those functions together._

This is a verbose re-statement of components, which are not new.

 _Before React, you couldn 't do this in a performant, UX-positive way_

Has there never been a performant component based UI framework?

~~~
peterhunt
Maybe I wasn't clear. The big idea is not components. The big idea is
expressing your view hierarchy as a single snapshot in time, and when the data
changes you conceptually throw out the old view hierarchy and re-render from
scratch and React manages the native view updates to ensure that it's fast and
doesn't adversely affect the UX by, say, resetting scrollbar position.

Contrast this with two previous approaches. The first is where you have a
component hierarchy that renders the initial state of the view, but when the
data changes you need to write imperative code to transition the native views
to reflect the new state. The second is traditional data binding, which
doesn't help when you want to change the view hierarchy itself (rather than
properties of existing views) based on an underlying data change.

------
jimjimjim
ot: I saw the title and thought some crazy fool had ported the enlightenment
window manager to reactos. I suspect quite a disjoint venn diagram of target
audiences.

------
lewisjoe
Great resource! Can we have something similar for Redux/Flux? I'm having a
hard time getting my head around those.

~~~
acemarke
FYI, I keep a big list of links to high-quality tutorials and articles on
React, Redux, and related topics, at [https://github.com/markerikson/react-
redux-links](https://github.com/markerikson/react-redux-links) . Specifically
intended to be a great starting point for anyone trying to learn the
ecosystem.

One of the closest items to the "React Enlightenment" book might be "Redux
Without Profanity", a free e-book posted at [https://tonyhb.gitbooks.io/redux-
without-profanity/content/](https://tonyhb.gitbooks.io/redux-without-
profanity/content/) . (Which, oddly enough, I'm suddenly noticing is _not_
already in my list.) The slides at [http://slides.com/jenyaterpil/redux-from-
twitter-hype-to-pro...](http://slides.com/jenyaterpil/redux-from-twitter-hype-
to-production#/) are also a great intro and overview of how Redux works.

~~~
lewisjoe
Thanks for the pointers :)

------
leephillips
For some people, the best things about React are some of the libraries written
on top of it, such as Om for ClojureScript, that allow them to enjoy its
architectural ideas without writing javascript at all.

[https://github.com/omcljs/om](https://github.com/omcljs/om)

