I'm not an Ember dev (I generally can't justify a clean slate project) but I do have opinions on the web development landscape:
The primary source of incidental complexity in frontend development is synchronizing state. The two main places that's happened is synchronizing state between the model and the server and between the DOM and the model. You can see this in the whole history of web development: cookies, sessions, continuations (/wave Seaside), the shift client side (not having to sync viewmodel state, just model state), the MVC shift (restricts where you state interacts), componentization (ditto).
I believe the vDOM/diffing approach is the end of the line in the model->DOM chain. The only place I've found where it doesn't work cleanly is when the output has to be looped back into the model (Rich Text Editor and DnD layout builder) and even that is workable. Otherwise the abstraction has not leaked and reasoning about component behavior has remained local to the component (it's possible to screw this up but that's not the fault of the approach). Once the view layer is written, data goes in, DOM is in the correct state.
Server synchronization remains a problem. The current approaches like Meteor/Derby/Firebase aren't unreasonable but they're rooted in the same place-oriented temporal logic as two way data binding. I don't know what the solution is here. The most promising lead I've run across is Convergent/Commutative Replicated Data Types (CRDTs) from the distributed systems researchers.
In the shorter term, I expect CSP (go channels) to gain acceptance as a replacement for callbacks/promises. It's reasonable to implement the model in javascript on top of generators and is roughly as powerful as functional reactive (FRP) approaches but more accessible to non-functional programmers. There are other efforts like the js streams effort so this might not be the answer but I do expect the community to stumble into a stronger async model than promise chaining.
I'm not particularly bullish on Web Components. Having scoped CSS will be very nice but the rest is focused on problems I don't see as important. I believe the core problem with widgets on the web is customization. There's a lot of web components material on encapsulation but I haven't seen a good explanation of how I can tweak the classList on a node in the shadow DOM for a use case the author didn't anticipate. I've used widget systems (netWindows, Dojo, Ext, YUI, Sproutcore) and have re-implemented many components for this and similarly minor reasons. Encapsulation by itself doesn't do a whole lot for this, I've implemented drop down combo boxes a dozen times. The x-tags/polymer interoperation demos are neat and I think that's the goal but the parochial nature of js libs means it's not something I'd really like to put into one of my projects. Smart people work on this effort so I feel like I'm missing something or not the target audience.
I feel the web components hype in particular to be pretty bizarre, though I feel it's died down recently. Too often the current generation of web people refuse to acknowledge how much has come before as far as Dojo/YUI etc.
What use is a component when every design wants it to look different? Consider the effort it would take to make the native chrome [type=date] datepicker styled however your site desires. That's a relatively low-controversy component compared to tab selectors, pill selectors, who knows what. At some point, it feels better to just write your own and have full control over the style and the lifecycle.
> What use is a component when every design wants it to look different?
You can do a lot with CSS, particularly if the component's CSS has a clean divide between structure and appearance. It's pretty common to want a component to do everything but that one thing, to trigger an event here, to need a wrapper div around the search results, etc. The problem is that everybody's just one thing is different and trying to accommodate them all gets you YUI2.
Re-implementing things winds up being the easiest route but I don't want to re-implement things. Building a business analytics or admin CRUD screen does not fill me with joy. I've been thinking about this problem for years. I really want to solve the problem, at least for my own use, so that I can slap boring stuff together without backing myself into a corner. The dream is to be able to slap everything together then customize and not have it suck.
My best attempts thus far have been in React where I can build override points into my components by having them take additional classes and optional subcomponents. It works (hoorah for composition) but the problem is in describing the input data and events so that you don't need to know the internal implementations of everything. I think the solution there is something along the lines of go interfaces or clojure's protocols and that there's a similar separation of concerns available in sass for the CSS side of things. I poke at it every so often but get distracted by other things.
The primary source of incidental complexity in frontend development is synchronizing state. The two main places that's happened is synchronizing state between the model and the server and between the DOM and the model. You can see this in the whole history of web development: cookies, sessions, continuations (/wave Seaside), the shift client side (not having to sync viewmodel state, just model state), the MVC shift (restricts where you state interacts), componentization (ditto).
I believe the vDOM/diffing approach is the end of the line in the model->DOM chain. The only place I've found where it doesn't work cleanly is when the output has to be looped back into the model (Rich Text Editor and DnD layout builder) and even that is workable. Otherwise the abstraction has not leaked and reasoning about component behavior has remained local to the component (it's possible to screw this up but that's not the fault of the approach). Once the view layer is written, data goes in, DOM is in the correct state.
Server synchronization remains a problem. The current approaches like Meteor/Derby/Firebase aren't unreasonable but they're rooted in the same place-oriented temporal logic as two way data binding. I don't know what the solution is here. The most promising lead I've run across is Convergent/Commutative Replicated Data Types (CRDTs) from the distributed systems researchers.
In the shorter term, I expect CSP (go channels) to gain acceptance as a replacement for callbacks/promises. It's reasonable to implement the model in javascript on top of generators and is roughly as powerful as functional reactive (FRP) approaches but more accessible to non-functional programmers. There are other efforts like the js streams effort so this might not be the answer but I do expect the community to stumble into a stronger async model than promise chaining.
I'm not particularly bullish on Web Components. Having scoped CSS will be very nice but the rest is focused on problems I don't see as important. I believe the core problem with widgets on the web is customization. There's a lot of web components material on encapsulation but I haven't seen a good explanation of how I can tweak the classList on a node in the shadow DOM for a use case the author didn't anticipate. I've used widget systems (netWindows, Dojo, Ext, YUI, Sproutcore) and have re-implemented many components for this and similarly minor reasons. Encapsulation by itself doesn't do a whole lot for this, I've implemented drop down combo boxes a dozen times. The x-tags/polymer interoperation demos are neat and I think that's the goal but the parochial nature of js libs means it's not something I'd really like to put into one of my projects. Smart people work on this effort so I feel like I'm missing something or not the target audience.