Reactive MVC and the Virtual DOM
futurice.com
futurice.com
For me it's a matter of not chasing the latest hot tech, and instead using the right tool for the job and sticking with it.
I also avoid using kitchen sink style frameworks. I'm much happier going vanilla JS and using small light weight libraries that do one thing well. The upshot to this is that you can often swap out a library with a newer one without a complete application rewrite (something that can't be said of frameworks).
At the moment I'm rooting for Polymer/Web Components, even though I'm not sure I'm on board with all their design decisions, if only because it seems to be likely to generate enough consensus to be a stable platform to build on for the next several years. But even that isn't something I can actually use today to get work done.
If you're doing a simple system, it's really fine to stay with the old server-side rendered techniques. Otherwise, just pick one based on a few hours of research -- any of the front runners is going to be a good enough choice. (Angular, Ember, React)
There have been some statement to the effects that both communities are now even stronger because the people who are only interested in the hottest new thing are all gone, and what's left are people who just want to get work done well.
Lack of support for SSE and websockets means that a Rails app with these features involves bolting on other moving parts such as EventMachine.
As it stands I don't see a better view layer solution then React, but I think you'd be best served learning it without using JSX so you can see exactly what it does. JSX tricks some people into thinking React is some sort of markup processor.
The older generation view solutions are usually string based templates with embedded DSLs to manipulate the resulting DOM. React divorces itself from the DOM totally and allows you to programatically generate and compose the view. Components and the separation from the DOM are React's great features.
Both Ember and Angular are trying to figure out how to integrate the React functional feel into their new versions and are taking notes. I just don't see them improving on React though at best they will copy.
React proves that if you try to make as much as possible of your application referentially transparent (or "pure" if that can be said about an UI), you avoid a lot of complexity.
I think the underlying appeal of virtual dom is not so much the internal gymnastics that it performs to enable efficient rendering, but that it leverages knowledge rather than code, i.e. we already know how for loops and functional composition work already, and these things are baked into the language, so there's no need for a framework to re-implement them. I talked about this idea in a presentation I gave at TorontoJS ( slides are here http://lhorie.github.io/mithril-presentation-oct-js-tech-nig... )
I think if we want any hope in taming high churn, we need to be able to focus on core principles so that we can find the right axioms, and only produce code if it's an inevitable requirement to achieve that goal.
When I'm inevitably rewriting the frontend in a few years, or creating a new one, I imagine the current state of the art is going to be different enough that the decision doesn't really matter. I feel justified in this after seeing how much Angular 2 is going to change things.
var modelItems$ = new Rx.BehaviorSubject(null); var itemWidthChanged$ = new Rx.Subject(); var itemColorChanged$ = new Rx.Subject(); var removeClicks$ = new Rx.Subject(); var addOneClicks$ = new Rx.Subject(); var addManyClicks$ = new Rx.Subject();
As someone unexperienced with the Rx library, this is completely unreadable.
[1] http://binarymuse.github.io/react-primer/build/index.html?6 [2] http://staltz.com/mvi-example/
In React you can use the PureRenderMixin [0] to avoid re-rendering subtrees if the arguments passed in are the same. In virtual-dom there's something similar called Thunk [1].
I did a partial implementation of the demo here [2] using Thunk. You can see that it performs much better than React for many thousand items. Adding items is also faster using virtual-dom.
[0] http://facebook.github.io/react/docs/pure-render-mixin.html
The optimisation that the React version has that is not applied in the virtual-dom version is list keys. http://facebook.github.io/react/docs/reconciliation.html#key...
I don't know if virtual-dom provides an equivalent feature, but I imagine it would be straightforward to add if not.
And virtual-dom also supports keys.
[0] https://github.com/BinaryMuse/react-primer/blob/gh-pages/dem...
Do you have a link to the source for the virtual-dom version?
Although I like the new pattern the author presented I almost dismissed it because the performance was significantly worse than the react example.
The cool thing is that rendering is totally separate. Virtual dom? If that floats your boat, cool. You can just as easily bake Knockout into the mix and you'd be flying through implementation. It'd be both easy and flexible. Could probably componentise the UI very easily too. I dig it.
In tests where the View is isolated from the browser and from the Model-View-Intent cycle, virtual DOM events will actually not exist at all, because there is no user interacting with the view. Virtual DOM events only happen, and only make sense, when everything is plugged in and executing in the browser with user interaction.
This one does.