Don't React (Presentation - Use arrows to navigate)
staltz.com
staltz.com
[1] https://github.com/joelhooks/react-rxjs-angular-di-todomvc
Seems like the author was offended they said they are reactive, and made a non-informative presentation, that comes off as a rant because of the rising popularity.
Edit: looking at his Cycle framework's "Why?" on github, besides the part of 'Rendering separated from View' (arguably, you could say that React's render returns React elements which are virtual-DOM elements equiv), you can use the same approach with React.
My current project's component almost never update themselves, except minor UI changes, which is understandable. apart from that, all the data flow comes from above, and my components change according to it. oh and it's immutable (immutable-js another great fb lib).
That's the thing about React, there's quite a diversity in approaches for handling data, events, user actions, etc.
om and elm.are the future, which is functional and immutable. React is the gateway to those technologies, which have a long and strong academic foundation.
The days of hacking together things on the frontend are over, more sound approaches are needed, and those developers who embrace them will have their pick of jobs and a fistful of cash.
Maybe it fixes all the sucky parts?
It completely changes the way you think about modelling applications and their events. It's closer to Flux on steroids rather than a thin wrapper on top of React.
Anyway, where I live React isn't getting noticed; it's Angular that's all the rage, so maybe the author is fighting the wrong enemy.
I like the idea of reactive programming, but it tends to add a lot of indirection. This is theoretically desirable, but not necessarily pragmatic in reality. A lot of frontend code in the wild is of the throw-away-in-a-few-years nature and it's hard to get mindshare among developers if they're required to learn stuff that feels academic when all they really care about is getting stuff shipped the next day. Being able (forced?) to tightly couple a controller and a view in Angular is one reason a lot of people like it.
I was giving a workshop on FP recently, and you'd be surprised at the number of people who still don't grok `filter`. FRP is still way over a lot of people's heads. Hopefully the industry will warm up more to the concept as React, Mithril, Meteor, etc get more popular.
@staltz WRT Cycle.js itself:
I took a look at the TodoMVC example and was surprised to see intents reading data from DOM element data attributes (e.g. https://github.com/staltz/todomvc-cycle/blob/master/js/inten... ). How does one go about doing non-string parameterized intents? For example, I often need to reference an entity from an event handler and searching for it in a collection by ID seems wasteful. In Mithril, for example, handlers can receive parameters as inputs either via closures from the view or via partial application (i.e. Function::bind). This is especially useful for event handlers that deal with relationships between two or more different entities. Is there a similar mechanism in Cycle.js?
There are also those that understand the concept of filtering at a basic level when reading tutorials about it, but still write for/if loops when it comes to producing actual code and it doesn't occur to them that it's possible to take the anonymous function out of the filter() call and give it a name to start building up a compositional foundation in their codebases.
My point though is that the benefits of FRP are somewhat out of line with the types of problems that people face in the real world.
To me, it's about separation of concerns most of the times, and about handy event operators sometimes (e.g. https://github.com/Reactive-Extensions/RxJS/blob/master/doc/...).
From yesterday, it's now possible to have stateful custom elements, as if they were Web Components: https://github.com/staltz/cycle/blob/fbae9c6610043ef6e46941a... This brings Cycle a bit closer to React, in that a "component" can handle its own events. The overall approach is still different than React, because in React you are encouraged to use components for anything, while custom elements exist in Cycle only when a pure component (i.e. a function returning a virtual DOM element, in React terms, props-only component) is not enough. Hence TodoMVC could be rewritten to use <todo> custom elements.
Using DOM attributes to register IDs is just one technique. Things are evolving fast, and I haven't myself tried to publish/share Cycle just yet, because it's not ready.
PS: I have a lot of respect for Mithril. Unfortunately not reactive as I would appreciate, but Mithril is very fast and very simple to understand.
I fully agree: of course React gets a lot wrong, being a pioneer and all. The way JS often goes, I bet one of the many alternatives that pop up actually will turn out like something. But attacking it like that isn't going to get you many friends.
Yeah, makes me not want to try it. This guy should let someone else handle the marketing.
I can certainly see the merits of trying to gain pragmatic mind share first before the buzzword technology crowd joins in and makes things more complicated.
Is this slide a joke I don't get? The whole presentation seems to focus on terminology and buzzwords more than discussing merits as far as I can tell.
EDIT: The authors commented and I'm going to assume this is an example of missing context.
If you're writing proper tests for React, you don't test directly through the DOM. Using Jest you can mock the DOM to test parts of your component. In my view, a component should not contain everything, only the most essential parts to get a working example of how it functions. Reusable/general functionality is pulled in from mixins or other js modules, which should be testable, without the structure of React, on its own.
> Cannot have post processing steps
This is incorrect, you can create a post processing step in React with a parent component. I used this for a pointer events polyfill in React where it replaces `onPointerEvent` with the appropriate mouse or touch event on a child component.
> Cannot delay rendering after state/props change
You can delay a render by returning false from shouldComponentUpdate, and when you get to the point where you want to render you can use this.forceUpdate().
That being said, React is somewhat misleading as far as Reactive programming goes.
However, if this is the case, then the criticism here against React shouldn't be that they're not reactive, but that they've used "reactive" wrong in their documentation.
Like other commentors, I also don't like the message in the slides and do not think that criticizing a competitor is a good form of marketing. But, I do think we should remember that it's hard to get the full context from slides and to not judge too quickly.
Grunt: 812,465
Gulp: 448,694It reminds me a lot of Gabriel's divide between the New Jersey approach versus the MIT approach---React is far more viral in its current form, but better technology certain lives further down the path.
I went to the Boston React meetup a few nights ago to hear Pete Hunt speak about React. He was a wonderful speaker and described nicely how React learned some of the same lessons that REST did making it superior to basic message passing and bloated/leaky distributed object mechanisms (blech). He also projected a very pragmatic POV from the React dev team---they want things to be right, but they also want things to be functional in the perspective of the way most applications are built today.
I was eager and jumped on some of the problems he suggested the React time was facing trying to integrate something like animation into React. At this point we jump from a sequence of instantaneous updates to a more game-like continuous redraw effort. Pete mentioned that the current effort here was to try to use technology like RxJS observers to get more reactivity and this seems aligned with the OP here.
Personally, I think animation lives most nicely in the domain of continuous time, "true" FRP which is mostly ignored by the current wave of Javascript FRP libraries. Perhaps for good reason since most modern implementations ideas of (again, "true") FRP are challenging to implement efficiently and the semantic model is probably far too large (Zeno processes, difficulty with infinitesimal delay).
But the advantage of FRP is that you can specify things like animation independently of the icky details like event passing and sampling rate and let those be determined at a later time when your FRP eDSL gets compiled into a more refined event-passing network. In other words, FRP languages hide a vast number of irrelevant and muddying details in a way that has a consistent denotation and can (perhaps!) be compiled efficiently into a push/pull message passing network.
We had this discussion a while back:
Actually, constraints are quite explicit compared to imperative assignments.
I believe that constraints are explicit, but their cumulative effect is difficult to predict. A constraint which wipes out some part of the feasible space with lots of vertices can have sudden and dramatic (non-local) impact on the solution. If your solver is approximate or your solution non-linear it might be incredibly difficult to figure out where the solver will ultimately land.
Since you do, I cannot take anything you say about web development seriously.
Annoying :)
I wouldn't use React out of the box, for pretty much the very same reasons outlined in the slides.
Om: A ClojureScript interface to Facebook's React.
This blog post from the same author gives a bit more detail than the presentation slides: http://futurice.com/blog/reactive-mvc-and-the-virtual-dom
Looking forward to seeing the presentation video
If it sucked nobody would be using it.
Anyway it's a logical fallacy "appeal to popularity".
Really? History is filled with stuff that sucks and people still use it.
As an example, J2EE circa 2002-2006 is a good example, with everybody, including its own designers agreeing now that it sucks hard. And yet it was widely used in the enterprise.
Your comeback to the other commenter is even more illogical. He points to PHP (as an example of something arguably sucky that people do use) and you respond that "PHP is not a Javascript framework".
So? Did you really meant your original statement ("If it sucked nobody would be using it") as something that only holds for JS frameworks (and not also for things like programming languages or libraries)?
He's not bashing React, he's educating you about an even better way. If you care about frontend development it would be wise to pay attention.
I quote him
> React sucks
How do you call it? a constructive criticism ?
He's passionate about this stuff because there is a very simple mathematics to frontend development (both declarative UI and immutable state as a function of mutational events) that has been hiding in academic papers and haskell minds that is now coming to the forefront.
There is a better way, and it can reasoned about much better than other approaches.
view m0 = r0
view (m1 = handler e0 m0) = r1
view (m2 = handler e1 m1) = r2
This is the essence of MVC. Mathematically pure and beautiful.
React and Flux are so close to this conceptually, but fall far short of it in actuality.
View is a function of state. State is an argument to view, and should not be mated to view in any other way except as a function call argument to the view - point free preferably.
If you look at the source code of React, there is an important object called Transaction. Transaction is basically AOP. AOP is not needed in JavaScript! Transaction reinvents functional composition. That is why things like Mercury, Mithrill, and Cycle are better,smaller, easier to read and reason about.
I love React, but it is a gateway to an even brighter future. Rejoice that the days of blind monkeys (myself included) writing UI code is coming to an end.
Whether he's brilliant on twitter or not is irrelevant. People are judging the presentation. Even if he's the most brilliant mind in the 21st century, that doesn't shield his work from scrutiny.
Do I have some gripes with React's API? Sure. But it's a good start.
http://computationallyendowed.com/blog/2014/07/20/reactive-m...
Basically: view m0 = r0 view (m1 = handler e0 m0) = r1 view (m2 = handler e1 m1) = r2
Or just down vote and learn nothing.