The road to Ember 2.0 RFC

by steveklabnik • 12 years ago

156 60 12 years ago

tomdale5• 12 years ago

Needless to say, we’re incredibly excited about this release. If you’re in a hurry, you can just skim; the bolded sentences and code samples are the important takeaways.

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...

inglor2• 12 years ago

The RFC process sounds very nice but be careful. PHP has been doing it for a while now and while it's working out nicely for them in some regards - pretty much every php person I talked to involved with it hates 'internals' with a passion.

tomdale5• 12 years ago

We do development of new features behind feature flags, and have automated tools to help enable, disable and strip them. We're planning on moving to a model where we do an approximately annual "garbage collection" pass on the framework (corresponding with a major version bump) and simply nuke all of the code that has been deprecated since the last major version release.

porker• 12 years ago

There is a long history behind the hating of 'internals' in PHP land. The RFC process has improved matters, but can't get rid of all the poison that already existed.

inglor2• 12 years ago

I love how they didn't do what Google did with Angular and did a big rewrite.

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.

kuni-toko-tachi3• 12 years ago

Google doesn't have a choice with Angular. They have to rewrite it because the original is a wrong approach.

simplify• 12 years ago

I'm curious, could you expand on this?

nomnombunty2• 12 years ago

Hi Tom, I have been a long time supporter of Ember. I been using it since 2012 and I really like the way its going. However, most companies are looking for Angular.js developer these days. As a result, I am using Angular.js for work and Ember.js for my own projects. Hopefully the 2.0 release will bring new momentum to the framework. I am really looking forward to it!

tomdale5• 12 years ago

Thanks! We know how important stability is, especially for companies that are not technical by nature. We hope this announcement demonstrates our commitment to stability without stagnation, and allows people to make the case to their boss that we'll be around for a long time.

nomnombunty2• 12 years ago

I really appreciate all the work the Ember core team put into the framework. It is definitely an uphill battle competing with Angular.js and React.js which has the support of Google and Facebook. The problem is that Ember and Angular both have similar features and management would need a compelling reason to switch to Ember :(

ollysb2• 12 years ago

You should begin moving your app to Ember CLI as soon as possible.

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?

wycats2• 12 years ago

Yes, we do exactly this at Tilde and it works well. This sounds like a good blog post and possibly some released code that people can use.

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 :)

ollysb2• 12 years ago

Yes a blog post on that would be great! (Personally I'd love to see rails move to broccoli instead of the asset pipeline but I guess that won't be for a while if ever).

onionbagle• 12 years ago

+1 I would love to see better rails integration with Ember CLI. It seems pointless to use ember-rails with the direction of ember relying on ES6 modules.

jurre• 12 years ago

I'd love a blog post about this, I've struggled with it and given up in the past, but I'd love to migrate our ember-rails app over to cli!

chrism_• 12 years ago

another +1 - a blog post on this would be great, we are using Ember CLI with Rails too.

iamstef2• 12 years ago

Author of ember-cli here (and previously the maintainer of ember-rails), this is essentially how my team uses ember-cli at work. Purely as a development harness and deployed to work nicely alongside a rails app.

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.

colinramsay2• 12 years ago

I'm not familiar with Ember but just skimming this document highlighted something - they're going to have a dependency on Ember CLI, a commandline tool for with generators, dependency management, asset management, etc.

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!

ef4• 12 years ago

ember-cli is such a vast usability improvement that you would be hard-pressed to find a single developer who's tried it and would prefer not to use it.

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.

tomdale5• 12 years ago

Hey Colin,

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.)

[1] https://github.com/broccolijs/broccoli

colinramsay2• 12 years ago

Cool, that's what I was hoping for then - just a bit of glue for some best-of-breed tools and not re-inventing the wheel!

lfischer• 12 years ago

‘One-way data binding by default, with opt-in to mutable, two-way bindings’. It looks like React’s emphasis on unidirectional dataflow has made converts!

steveklabnik2• 12 years ago

They specifically refer to React a number of times in the text, yes.

iamstef2• 12 years ago

it has!

StevePerkins• 12 years ago

They mention HTMLBars in passing, but mostly emphasize the fact that support for the current Handlebars syntax won't go away in 2.x. Three cheers for JavaScript frameworks with reasonable attitudes toward backwards-compatibility (!)... but as someone who HATES the current Handlebars syntax, I'm wondering if they've also committed to having HTMLBars fully ready-to-go at 2.0's launch? I know that "pieces of it are in place" in the beta right now, but will 2.0's date depend on it being fully ready?

tomdale5• 12 years ago

HTMLbars will land well before 2.0, most likely in the next release. We've been doing the integration piecemeal to ensure that we don't break production apps; we want everyone to get to experience the new awesome.

wycats2• 12 years ago

It's worth noting that the very next release (1.9) is already locked and loaded (it branched to beta). So when Tom says "next release" he means 1.10.

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 :)

mixonic• 12 years ago

We've started using the term HTMLBars to mean a collection of changes to the Ember rendering pipeline. In the current release (1.8) we've added metal-views (a renderer refactor), in the next release (1.9) we will be adding Streams (a data-binding refactor), and in 1.10 we hope to land parts of the new syntax and the DOM-based templating engine.

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

dongraham• 12 years ago

Looking forward to all the great new features. Your commitment to the regular release cycle has made a huge difference to our team. We're backing ember all tge way.

bl4ckm0r32• 12 years ago

For all of you who wondered for so long on wether to go Angular or Ember... now you can stop wondering and start coding :)

msie• 12 years ago

Judging from some of the comments, people are still wondering.

bl4ckm0r32• 12 years ago

That's why I tried to help them :)

josho2• 12 years ago

Is Ember really the right path forward? Or simply a stepping stone to a better (yet to be discovered) solution?

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?

josho2• 12 years ago

Having reflected on my own question for the past 20 minutes I'll add the following.

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.

neftaly• 12 years ago

I'm excited to see where concepts from isomorphic JS and stuff like browserfy will end up. Obvious stuff aside, imagine what you could do with a fully-baked unified model and a bit of P2P glue...

blakeley• 12 years ago

https://github.com/voltrb/volt is a new ruby framework that does exactly what you described

bithive123• 12 years ago

This isn't exactly the question you asked, but I recently accepted that client-side applications are the future and spent some time with Ember (which as a Rails developer I wanted to like) and AngularJS (about which I was skeptical because it looked like nothing I'd seen before).

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.

cpursley• 12 years ago

Same boat as you. I wanted to like Ember; everything on paper looked great. But with Angular, things just clicked and have allowed me to be more productive than ever.

brownie3003• 12 years ago

Two weeks...

csallen3• 12 years ago

I've been using both Ember and Ember Data for almost two years now for pretty much everything (mostly contract work and personal projects).

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.

lbotos• 12 years ago

You seem to be as good a person as any to ask:

What are you building? Are these apps? Are these just blog sites? Portfolios? Admin sites?

gavinjoyce• 12 years ago

We began rebuilding Intercom with Ember.js in April this year. We now have 12 engineers working with Ember and both the pace of development and the quality of our output has been amazing. Ember bills itself as 'A Framework for creating ambitious applications' and we've found this to be very true. We upgrade to the latest point release every six weeks or so and this process has been painless.

grayrest2• 12 years ago

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.

Sivart13• 12 years ago

There's a lot of stuff here that I agree with.

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.

ulisesrmzroche• 12 years ago

I would consider coupling your server and client a major step backwards (again) for application architecture.

everydaypanos• 12 years ago

In love w/ Ember. i kind of liked habdlebars tho..

stephen_g• 12 years ago

I love the new attribute binding just working like you expect. It took me a fair while when I was first learning Ember to find the bind-attr helper, and things like using variables as part of URLs is a bit annoying currently.

sytse• 12 years ago

Great to see that Ember core is not suffering from the Not Invented Here syndrome and is inspired by good things from React. Kudo's and love for Ember.

lightblade• 12 years ago

No mention of how htmlbars will affect famo.us integration?

The road to Ember 2.0 RFC

Related Stories