Also, as far as I'm aware, ClojureScript hot reloading tools actually unmount the component. This may be OK because state is restored from one source, but it's not as nice-looking because DOM is thrown away on every update, and it flickers.
Anyway, I'm looking forward to learning more about ClojureScript. A lot of exciting things coming from there.
If you find a way to make it work with System, let me know!
If you are a web developer (front-end/back-end), and you haven't switched to React yet, take this for a spin, and read "Facebook just taught us all how to build websites" (https://medium.com/@ericflo/facebook-just-taught-us-all-how-...), and watch 'React - Rethinking Best Practices' by Pete Hunt (https://www.youtube.com/watch?v=DgVS-zXgMTk).
The distinction between the back-end and front-end is a product of the complexity introduced by the web with its 'worse is better' mix of badly integrated tools. It made building user interfaces a dark art with all its quirks:
- a layouting system that had an active vendetta against humans
- Connascence introduced by Server <-> Client communication (Server Model <-> API View <-> JS Model <-> JS View)
- declarative views that were ill-suited for web-apps (logic-less templates, what a lie!)
- cross-browser incompatibilities
- difficulty in implementing client-side routing
- immature developer tooling
But worst of them all was DOM mutation and spaghetti code, which was in reality a fundamental deficiency of the development model itself, and not because web developers the world over were being deliberately irresponsible.
React is changing all that with the help of ES6. It simplifies web development both in concept and in practice. In a few years, building UIs would be just another part of writing software, and competent Full-Stack developers would cease to remain unicorns.
Here are a few things that React approaches differently that makes all the difference:
- templates are a bad idea. views are constructed imperatively, not declared. (plug: http://www.jasimabasheer.com/posts/on-react.html)
- the basic unit of a front-end system is a 'component'. A component knows how it is rendered (HTML), how it is styled (CSS), how it behaves (JS), and has explicit knowledge of the data it handles (states and props).
- everything should be programmable: even HTML and CSS. (https://speakerdeck.com/vjeux/react-css-in-js)
The React team seems to be looking at what makes web development actually hard and are thinking outside ill-advised conventional wisdom (like separation of concerns. whose concerns anyway?). For example, Relay (https://gist.github.com/wincent/598fa75e22bdfa44cf47?), removes the need for writing custom API end-points for each of our components. A component already knows the data it needs, but today we leak that info across the component hierarchy and to the server, creating a lot of accidental complexity.
Another example is Webpack (http://webpack.github.io/), which changes asset management on the web by making it completely programmable. All your static assets should have the same bundling conveniences that your JS has. Webpack also makes react-hot-loader possible with Hot Module Replacement.
React seems to have finally figured out the right direction to take the web to. Exciting times.
I don't prefer them over React, but I agree they make this stuff easier. React Hot Loader is a hack after all ;-)
I don't get this. Sure, components seem sound but often a component is dependent on its context. So a component in the header may need different margins for example than one in the footer. How is this handled in React where the components seem really isolated?
In plain CSS, you can specify a specialized parent -> child rule that affects the component just in this context. Or you can have two different classes for the two cases. You can also define two distinct container elements that compose the same underlying component, but the container takes care of the margin depending on the context.
With React you have the entire repertoire of programming abstractions to solve this problem with, while traditionally we had to work within the confines of CSS's cascade.
But in cases where internal layout of the component is very different, we have to make a call between adding conditionals within a component vs giving distinct names to the different cases and extracting multiple components. I veer towards having more explicit names in my codebase and so extracts new components more often than I litter existing ones with conditionals.
Also, in practice, components are surprisingly self-contained and independent of context.
One way is to mix two different sets of styles for the element.
Set 1 gives the element the general styles of the component itself.
Set 2 gives the context-specific styles that are only used in that one instance.
It's just like using two different classes. E.g. `.button` and `.firstButtonInHeader`. And then having an element like <button class="button firstButtonInHeader">.
React isn't against templates - the existence of JSX is counter to this. React does choose to consume templates in an imperative form (via React.DOM), and JSX is meant to ease this flaw in productivity by giving tooling that corrects this unnatural form of development (for most frontend engineers).
React is also not against separation of concerns - even in the talk by Pete Hunt linked, he merely has a different view on what constitutes the concern of the view layer. His viewpoint is that the template and the state of the component are intertwined heavily, so as to stress that Facebook's approach with React does not break that principle.
JSX templates are templates in the sense they do minimal string interpolation. Everything else is taken care of by programming language abstractions. They include control structures: conditionals and loops, and primitives for abstraction: variables, functions and objects. A template 'programming' language on the other hand is a suboptimal mix. For example, Angular's templating language reminds me of Greenspun's 10th rule, which with suitable modifications, can be read like this:
Any sufficiently complicated templating language contains an ad hoc,
informally-specified, bug-ridden, slow implementation of a
turing complete programming language.
>It seems going back to the method of handling data updates through onchange events in a manual fashion would be a colossal step backwards from say, knockoutjs.
It's not exactly "manual fashion" because React updates everything according to `state` for you. If you have many interdependent fields, make them update `state` correctly, and React will keep them in sync with it.
In fact I find it easier to make complex input logic with one-way bindings because the data always flows one way. It's a tad more code to write, but you see exactly where your updates are happening and what's causing them.
Two-way binding tends to get very complicated as soon as you need more complex logic. One-way binding doesn't have this problem.
Although even though ReactLink works it a.) feels like quite the hack (i.e. not very composable) and b.) is a more code to maintain still when it comes down to it.
If they deliver something concrete and simple it could be great. But there are way too many questions at this point to even start to get excited.
So, I guess I'm looking for a technical summary of what this does exactly because I don't understand the benefit.
You get much faster prototyping, collaborative tools out of the box and even a debugger with a timeline out of the box (you just have to save your state at every change and have a little scrollbar to scroll through your states). This is very very powerful.
The site does say:
> React Hot Loader will keep it mounted, preserving the state.
but I agree that it could be more explicit about how it's useful.
From the paper, adding a navigability aspect between UI and executing code is something that is fairly straightfoward to do and very useful.
My current live programming work is over stateful code (meaning the code that is being live edited involves side effects). It is difficult to support that in existing programming models, however.
This gives huge productivity boost when developing complex nested UIs because you can quickly tweak CSS/JSX without blowing away all the state (like modal windows, tabs, loaded data, etc).
Gadzhi (you may know him as the designer behind Sublime Spacegray theme, http://kkga.me/) helped polish the logo and added the outer animation. It's currently in CSS but I plan to to move it into the component as well.
Logo source code: https://github.com/gaearon/react-hot-loader/blob/gh-pages/_i...