The pace of innovation in JS is inspiring. But as someone trying to get back into front-end development after years of doing native apps it's also a little bit discouraging that there's so little consensus on how web apps should be built. It seems like today's hot new technique is tomorrow's discarded anachronism. How do people actually get anything done when it's so hard to build a stable foundation for anything?
On the server side, while JS gets a lot of attention, it should be noted that Rails and Django are both alive and well, still have active communities, and are both being used to write real code.
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.
Things are improving rapidly, depending on the scale you intend to build to mature solutions are available for you.
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.
I'm using React on a toy project and I'm pretty impressed with it so far. Once I got a reasonable environment for editing and processing JSX things have progressed pretty smoothly. Until web components hit this seems like the best option. The library mentioned in the OP seems interesting but I think I'd prefer to stick with React even if only for the much more established community. In the long run I think consensus counts for a lot because most things can be fixed if enough people are willing to chip in to fix them.
I'm looking forward to seeing more implementations of the React ideas! I see the Virtual DOM as mostly a necessary performance hack to let developers - as you say - think of views in a more functional fashion.
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.
> How do people actually get anything done when it's so hard to build a stable foundation for anything?
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).
In principle I like this approach but there are advantages with going with the larger frameworks too. For example, if I build something with Angular, I can take advantage of all the components, tutorials, SO posts etc that the community has generated. If I roll my own solution from a handpicked collection of third-party libraries I forfeit all that. I was until very recently leaning towards using Angular but now that they've announced that Angular 2.0 is practically a rewrite that also seems like a dead end.
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.
We're having trouble getting it right still - that's what it says to me. The proliferation isn't going to stop anytime soon.
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)
Can't speak for other frameworks, but what I've been trying to do with Mithril.js (a new virtual-dom based framework) is to try to keep things as close to the metal as possible, and as grounded on mature concepts as possible.
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.
I've looked at Mithril and I like a lot of the design decisions you've made. I'm just a little reluctant to invest in something so far out of the mainstream. Of course, when the mainstream changes every three months, maybe there's not so much value in following the herd after all?
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.
As someone actively trying to damage his (how did I guess you were a guy?!) community with dismissive, condescending and anti-inclusive hatred, in a community already battling against these problems, I hope you consider making programming not your thing.
virtual-dom may be faster than React.js in benchmarks. However the React example [1] that the author rebuilt with MVI [2] is much slower with many elements. What's the deal here?
The author didn't include an optimisation that the React example has.
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.
This is reaaaally cool. It's pretty much exactly what I've been looking for in a JS framework.
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.
The whole "single concern" analogy fell apart there. "View output: a Virtual DOM rendering of the model, and raw user input events" - it's the only component that does two things. Moreover, if this is just the virtual, unrendered DOM, where do the events come from?
DOM events are being delegated to Virtual DOM event handlers. This is what 'dom-delegator' does, it comes from mercury: https://github.com/Raynos/mercury/blob/master/docs/dom-deleg...
Still, the View doesn't "do" two things. It does just one: renders virtual elements. The virtual element output just happens to consist of two things: the element, and events coming from that element.
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.
