
The road to Ember 2.0 RFC - steveklabnik
https://github.com/emberjs/rfcs/pull/15
======
tomdale
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](https://github.com/emberjs/rfcs)

[2]: [http://blog.endpoint.com/2010/01/state-of-postgres-
project.h...](http://blog.endpoint.com/2010/01/state-of-postgres-project.html)

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

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

~~~
oblio
Maybe a process similar to Django's would be helpful?
[https://docs.djangoproject.com/en/dev/internals/release-
proc...](https://docs.djangoproject.com/en/dev/internals/release-process/)

~~~
steveklabnik
Fun fact: Python's PEP process influenced Rust's RFC process, which influenced
Ember's.

------
josho
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?

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

~~~
blakeley
[https://github.com/voltrb/volt](https://github.com/voltrb/volt) is a new ruby
framework that does exactly what you described

------
inglor
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-tachi
Google doesn't have a choice with Angular. They have to rewrite it because the
original is a wrong approach.

~~~
simplify
I'm curious, could you expand on this?

~~~
kuni-toko-tachi
Automatically 2-way binding everything is a serious mistake since most
elements don't need it and it's a performance hit. Scope and ControllerAs are
in conflict (particularly with ng-if/ng-repeat). Dependency injection is
needless, since Javascript module requires (via Browerify or Webpack) handle
this much better and sensibly. Extremely hard to debug since stacktraces are
useless. Module factories, services, and values are unnecessary, since
Javascript already has established design patterns for these concepts.

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.

~~~
wonderwhy-er
I love Angular for how it allows to seprate concerns cleanly. You view logic
goes to templates and directives. Your data/bisness logic goes to controllers.
When developer writes controller he thinks in terms of data he works with.
When developer writes view he thinks in temrs of how to represent data
available to him from scope.

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...](https://github.com/tastejs/todomvc/blob/gh-
pages/examples/react/js/app.jsx#L56)

------
StevePerkins
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?

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

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

------
ollysb
> 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?

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

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

------
colinramsay
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!

~~~
tomdale
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](https://github.com/broccolijs/broccoli)

~~~
colinramsay
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!

------
bl4ckm0r3
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
Judging from some of the comments, people are still wondering.

~~~
bl4ckm0r3
That's why I tried to help them :)

------
lfischer
‘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!

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

------
nomnombunty
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!

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

~~~
nomnombunty
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 :(

~~~
hybridcivic182
Change your company, or "change your company"

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

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

------
sytse
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
No mention of how htmlbars will affect famo.us integration?

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

