Just the slides aren't enough to sell me here, I'm sure the missing video to go with this fills in the holes.
Buuut. "Problem - UI is complex - because DOM not Reactive - what if it was reactive - random code sample", is just non-sequitur out of context.
DOM programming is inherently "reactive" - it's event based.
Furthermore, I think it's nice that tools like React.JS exist that "free the developer from manually programming the DOM", but that's exactly what Angular.JS offered too. Automatic binding and updating yada yada. Why is this author flaming Angular.JS? Was it because its leaky abstraction turned out ugly over time? Well the same fate is awaiting React.JS and its "minimally leaky abstraction".
Leaky abstractions never remain "minimally leaky" over time. The fact they're leaky from the very start shows the model was flawed to begin with.
Angular.JS does manual compare between two large model objects to detect changes and emit model update events.
React.JS does manual compare between virtual DOM and real DOM and emits DOM update events.
They both try to solve the hardship of having to update your DOM, via an abstraction that only works well in specific circumstances and incurs irreducible runtime overhead when behind the scenes structures have to be compared over and over and emit update/change events.
Sometimes the problem is in the platform. But even more often a bad developer blames the platform for their own inability to architect their app cleanly and thinks leaky abstractions are the answer.
The reason UI programming isn't reactive is because reactive systems are immediate mode (describe the whole state at any point in time) and the Dom (hell, most UI toolkits) is retained mode (stateful). So you need to abstract that away somehow and that abstraction is guaranteed to be leaky to some degree.
The thing that separates react from the rest (disclaimer: I work on react) is that these leaks are pushed to the edge of your system (that is, you need an external signal to re render) rather than threaded throughout your system (like requiring everything to go through $scope for one). We have seen massive dev efficiency gains because this removes many limitations for not much downside.
Incidentally I was just watching one of your presentations on YouTube to understand the reasons behind React's design choices.
The thing I still can't understand is why we need to model the UI around emulation of immediate mode.
Two big reasons:
1. The fact is when you want to create a meaningful animation between one state and another, you need to be aware and in control (as a developer) of what exactly the change is. Diffing may produce one possible valid state change delta for the developer to work with, but no guarantee it'll be the correct one. So what does that mean for animated transitions? Is immediate mode dooming them to either not be used, or to be semi-arbitrary depending on what the diff engine decides?
2. Fact is that the browser usually has no access to the full server-backed state of the widget that it's rendering. Instead, the communication with the backend that powers said widget (say a chat box) is in the form of delta state changes. You don't get the full chat log from the server every time someone sends you a chat message, you get the change only: new message from x.
So if we need to be "state aware" and communicate with "state change events" so to speak with the server anyway, why suddenly drop that knowledge and pretend all the state is local by emulating immediate mode rendering?
It doesn't feel like less work. It feels like more work, and less possibilities (said animations in point 1).
Thumbing this from my phone so can't go into as much depth as normal.
1. The diff algorithm is deterministic and accepts that some widgets are stateful. You can tell the system which items to preserve and which ones to destroy by providing an identifier. This is essential complexity in the current world we live in (global dom state tied to element instances like focus). If we were to throw out the Dom spec and rebuild it we would not need to do so much.
So you can animate by tweeting a value and rerendering/diffing every frame. Facebook look back video editor works this way.
2. Yes, but delta updates are imperative mutations over time and humans are really bad at keeping track of them so we should try to isolate them as much as possible. We have a separate system that coalesces these deltas into consistent views of the world which are then passed to react. This is also the role of systems like rx.
One way to think about it is like rest. People like rest because it is predictable: URL refers to the same resource always and refreshing the page always works consistently and you never need to think about deltas.
I tend to model and see all communication (at all levels) as message passing and not as resource/state snapshot passing, but the web has worked fine with the latter concept so far. So React's architecture certainly provides value in such situations.
Totally get you on that. I think that message passing is valuable because it forces you to decouple systems in a way that reduces shared state. But for complex apps this means that you will probably have to introduce some sort of coordination system, which is where things start to get complicated. If you can pull "time" out of the equation (ie look at complete state snapshots rather than messages over time) it can make things a lot easier. Obviously not appropriate for everything, but has worked well for us when building UIs.
No problem btw, fire away if you have any more questions!
One approach to the animation issue is to use CSS transitions. This way your code is just responsible for setting the new value (which can be done by Om/React or any other approach) and then the browser is responsible for making the animation happen appropriately (and efficiently, with full hardware acceleration, etc).
This is, for example, the approach suggested by Kevin Lynagh for use with his awesome C2 library which is like D3.js for ClojureScript and which comes with no built in animation support whatsoever:
I'm not a front end developer and so I don't spend too much time on this type of stuff, but when I have had occasion to use it, I found this approach much more pleasant than oldschool jquery style approaches to animation.
At around 30:00, he talks about why Angular's two-way binding is evil, and why React's approach makes more sense. In short, two-way binding means there is no single “source of truth”. That makes debugging and non-trivial interaction very difficult. React solves this problem by always having one source of truth—component's `props` and `state`.
Maybe you should look a few things up before jumping in.
> Why is this author flaming Angular.JS?
If you are a proponent of it and you think you are defending it here, you might actually be doing it a bit of disservice.
He made the point that Angular JS is complex and showed a list of new concepts it introduces -- services, directives, etc on top of the already existing ones, controllers and so on. It is a personal opinion. You don't think it is complex, ok, share your opinion, it doesn't mean the author if "flaming" anything.
> They both try to solve the hardship of having to update your DOM, via an abstraction that only works well in specific circumstances
They both solve a similar problem with some differences. Author thinks one does a better job sometimes.
> . But even more often a bad developer blames the platform for their own inability to architect their app cleanly and thinks leaky abstractions are the answer.
Are you implying the author is a bad developer? Can you show that. So far you haven't
Buuut. "Problem - UI is complex - because DOM not Reactive - what if it was reactive - random code sample", is just non-sequitur out of context.
DOM programming is inherently "reactive" - it's event based.
Furthermore, I think it's nice that tools like React.JS exist that "free the developer from manually programming the DOM", but that's exactly what Angular.JS offered too. Automatic binding and updating yada yada. Why is this author flaming Angular.JS? Was it because its leaky abstraction turned out ugly over time? Well the same fate is awaiting React.JS and its "minimally leaky abstraction".
Leaky abstractions never remain "minimally leaky" over time. The fact they're leaky from the very start shows the model was flawed to begin with.
Angular.JS does manual compare between two large model objects to detect changes and emit model update events.
React.JS does manual compare between virtual DOM and real DOM and emits DOM update events.
They both try to solve the hardship of having to update your DOM, via an abstraction that only works well in specific circumstances and incurs irreducible runtime overhead when behind the scenes structures have to be compared over and over and emit update/change events.
Sometimes the problem is in the platform. But even more often a bad developer blames the platform for their own inability to architect their app cleanly and thinks leaky abstractions are the answer.