The road to Ember 2.0 RFC
github.com
github.com
The reason this is so long is that we’re doing the 2.0 release through our community RFC process[1]. Change can be scary when you’ve made serious investment in an open source tool, so we want to provide as much detail as we can while leaving open the opportunity to incorporate feedback.
I’d like to thank the members of the Ember core team, who paid out of pocket to spend this past weekend with me in Chicago for the face-to-face meeting where we banged out all of these details. Maintaining an indie open source project can be painful at times, but I think history demonstrates there’s no better way to foster a project that is as aligned with the goals of its users as possible.[2]
[1]: https://github.com/emberjs/rfcs
[2]: http://blog.endpoint.com/2010/01/state-of-postgres-project.h...
Specifically, I remember first picking up Rails and how productive I could be in that environment. I haven't felt the same happen with Ember. Instead it continues to feel like more work, as I have to build a client side domain model, as well as a server side model, and often have to think carefully where the logic should be placed.
Don't get me wrong, Ember is a step in the right direction, and there is a lot to love about it, but at the same time it feels like a local maximum and that there is a better paradigm to be discovered (Meteor perhaps?)
So, for those past the initial Ember hurdles, is Ember fulfilling its promises for you with your projects? Do you disagree with me and see Ember as the right long term approach for rich web applications?
For decades programming languages struggled with how to persist object state. We built custom file formats, tried to serialize object graphs, built ORMs to map to SQL databases, but it took us three generations or so to get ORMs right.
Today's struggle is how to program a distributed application. First we built the server to render dumb html, then got smarter and added some glue like JQuery to the client, now we are onto full fledged client side frameworks. But we haven't fundamentally solved the productivity challenge to generate a rich client experience that leverages the work done on the server. I can't help to think that a unified programming model between the server and client frameworks could become a significant step forward.
After two weeks in each, only AngularJS was paying off (I got architectural and productivity benefits in return for the time I spent learning all those framework things which seem arbitrary at first) so I stopped looking at Ember and haven't looked back.
I like to think of things as lying a spectrum: On one end, you have completely hand-rolled framework-less JavaScript. This requires no learning curve whatsoever, but things may get slow and messy as time progresses and you miss out on the cumulative benefits of a framework. At the other end of the spectrum is something like Ember, which takes a while to learn is is just plain overkill for small projects, but which for big projects starts to pay dividends in the long run.
Ember had a very high learning curve when I first started using it. Admittedly, I immediately jumped into a huge project with it, which is worse for learning than starting with lots of small ones. Still, it took me months before I felt truly productive. Hopefully things have improved since then, but I'd say it was worth it, regardless. I can't imagine writing a substantial Javascript-heavy app without it or something like it. I did that several times in the past, and I always ended up having to basically construct my own ad hoc framework, which takes a ton of time and maintenance.
Comparatively, Ember has its own built-in conventions for routing, views, models, etc, similar to Rails. Once you know how it all works, it's fairly obvious what "the right approach" is to using these features. The result is that your code is more easily navigable and maintainable, both by yourself and by other Ember developers seeing your code for the first time.
As for the back-end, the last few projects I've worked on with Ember, I've spent very little time worrying about it. One has a Rails back-end that basically serves a REST API for the Ember app. After I finished building the REST API, I almost never had to touch the back-end again. The other two projects use Firebase and the Dropbox Datastore Sync API, both of which store data and feed it into the Ember app in real time in a Meteor-esque fashion. And again here, I spend 99% of my time working with front-end code.
So, to answer your question, yes, Ember is fulfilling its promises for me, and I think it's likely to be the right long-term approach. I haven't used Meteor, yet, but it's hard for me to see it being vastly superior to something like Ember+Firebase. And if it doesn't put a lot of thought into handling things like views (and views within views (and views within views within views)), then I can't see it being much of a step forward for writing front-end code.
What are you building? Are these apps? Are these just blog sites? Portfolios? Admin sites?
Before that, I worked on other apps using Ember, as well as one or two more "website-like" projects that are mostly static, but had a few interactive widgets. FWIW I think Ember was overkill for those, and I would've been better off just going with normal HTML/CSS delivered from the server and Backbone for the widgets.
Ember bills itself as "a framework for creating ambitious web applications", and I agree with that use-case completely.
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.
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 fact it's possible to easily migrate a current day Ember code base incrementally is a big win.
I don't blame Google - but this is a nice win for Ember.
If you haven't tried React, please give it shot. Particularly if you are about to make a decision on what frontend framework you will use, or if you are using AngularJS already and recognize that it's approach leads you to ugly workarounds.
I can't emphasize enough that AngularJS is bunk.
One thing I agree with is the useless stack traces which made is extremely hard to debug Angular.
The only thing you need is the last mile transformation from view model to DOM, everything else that AngularJS provides is unnecessary and foolish.
I hate how in Backbone or just jQuery way you have mess of html, javascript and data manipulation in same class... Reminds of how messy frameworkless PHP looks...
Now looking at some React examples I see jsx files that do same mess... Model manipulation, some logic and html code in same file... WTF? How is that good? May be someone can point me to a good example app of using React with good speration of concerns? Classical TODO MVC looks horrible... https://github.com/tastejs/todomvc/blob/gh-pages/examples/re...
Also, some of the points in the RFC are features that depend on the new templating engine but will likely not land in 1.10. We give guesstimates for when we think things will land in the RFC :)
We've worked very hard to make HTLMBars an incremental release, and not a Big Bang rewrite. Partially because of this, it has taken longer to ship than was planned. However I'm personally very happy about how smoothly the transition is going thus far, and if you are a user of Ember.js I think you should feel the same way. :-D
While I'm using ember-cli for thick clients I'm using the ember-rails gem for sites which use a mix (mainly older projects). Has anyone figured out a good way to embed an ember-cli app inside rails?
Because the division of labor with Ember CLI is relatively clear, I expect build tool ecosystems to build integrations with Ember CLI, that shell out to the Ember CLI tools for specific tasks as part of a larger process. We'd of course love to work with anybody trying to do this :)
One of my co-workers has a great related talk: https://speakerdeck.com/lukemelia/lightning-fast-deployment-...
And another related blog post: http://blog.abuiles.com/blog/2014/07/08/lightning-fast-deplo...
I suspect we will want to migrate the ember-rails story to be officially more aligned with the above approaches.
This dismays me a little. Another approach to this kind of thing, but looking at the docs it seems to be an npm+bower+custom magic. In some ways it reminds me of the clusterfuck that is Sencha Command, though at least this is open source.
Can anyone involved in the project shed any light on how this is implemented? It would be good if it was just a thin interface to some standard scripts.
edit: I know this comes across as a little negative, that wasn't really my intention. Sorry about that!
It's in-line with Ember's whole philosophy: anything that we can solve once together in a standard way, we should. Most of the time you are not a special snowflake and you can benefit from the same build stack as everybody else. If you need more, ember addons expose a standardized interface to sharing whatever feature you need.
Not negative at all!
Ember CLI is a relatively small layer on top of a bunch of other open source modules. The core of the build system uses Broccoli[1], which is like a more powerful Gulp.
Dependencies are managed with bower and npm, and we use off-the-shelf npm modules to do the post-processing.
Basically, you should think of it as a curation of what we think are the best-of-breed tools for Ember developers, with a layer of developer ergonomics applied on top. At the same time, we don't do anything to hide the implementation from you. (Each new Ember app generated by Ember CLI includes the Brocfile.js right in the root directory.)