
Ember.js 1.13.0 and 2.0 Beta Released - makepanic
http://emberjs.com/blog/2015/06/12/ember-1-13-0-released.html
======
ffn
I, for one, am glad Ember is still going strong. And, as a heavy emberjs user,
most of these changes feel like a step in the right direction. But after
reading through the change log blog, I have several questions (not complaints)
for the core team (in case Dale / Katz and cronies are reading this):

1\. What happened to the server fast-boot thing? I was under the impression
you guys wanted to ship it with 2.0; has that feature been scrapped / moved
into a separate project altogether?

2\. There was no mention of the deprecating changes to the initializer API
(i.e. the splitting into instanceInitializer and vanilla initializer). Have we
gone back to the old initializer API in 2.0?

3\. With the removal of action bubbling, do we now have to manually bubble up
actions that start in some nested controller but gets handled in application
route? For example, say you have an AdminUserController and it has an action
that generates an ephemeral flash message, but you handle flash rendering in
your application route. Do you now have to laboriously put an actions: {
handleFlash { ... } } on every route along the way?

~~~
wycats
> What happened to the server fast-boot thing? I was under the impression you
> guys wanted to ship it with 2.0; has that feature been scrapped / moved into
> a separate project altogether?

SEO-only FastBoot shipped in canary a while ago (as the `ember-application-
visit` feature). It is designed to work with the FastBoot addon
([https://github.com/tildeio/ember-cli-
fastboot](https://github.com/tildeio/ember-cli-fastboot)).

Rehydration, the big enchilada, depends heavily on the Glimmer work, and
should begin momentarily.

> There was no mention of the deprecating changes to the initializer API (i.e.
> the splitting into instanceInitializer and vanilla initializer). Have we
> gone back to the old initializer API in 2.0?

We're sticking with the split-apart API we shipped a few releases ago. It's
important to make FastBoot efficient with real-world addons.

> With the removal of action bubbling, do we now have to manually bubble up
> actions that start in some nested controller but gets handled in application
> route? For example, say you have an AdminUserController and it has an action
> that generates an ephemeral flash message, but you handle flash rendering in
> your application route. Do you now have to laboriously put an actions: {
> handleFlash { ... } } on every route along the way?

We're starting with more laborious (with services as an escape valve), but
have some ideas for conventional situations where you could get away with less
ceremony. Stay tuned! (by which I mean, there will be RFCs in the near future
addressing this kind of issue).

------
adwhit
I am excited about this release. Once things have settled down I think Ember
2.x will have a much shallower learning curve than 1.x.

However it is a shame that routable components haven't made it in yet. I'm
about to start a new, medium-sized Emberjs project, but I'm unsure whether to
wait another 6 (or maybe 12) weeks for this feature. Any suggestions?

~~~
sergiotapia
You can dive right into Ember with this book with zero previous experience:
[https://pragprog.com/book/mwjsember/deliver-audacious-web-
ap...](https://pragprog.com/book/mwjsember/deliver-audacious-web-apps-with-
ember-2)

I've read lots of Ember books and have seen a couple of screencasts including
CodeSchool's Warming up With Ember and hands down this book is the best I've
read. There's also [https://leanpub.com/ember-
cli-101](https://leanpub.com/ember-cli-101) \- but I'm not sure if the author
has updated it to use pods and components since the last time I've read it.

It's in beta, but in it's current state it's good enough.

The idea right now is to create as much as you can as self-contained Ember
components and pod structure. I know that doesn't make much sense if you're
new to Ember, but imagine your project structure being:

    
    
        /app
          /login
          /register
          /profile
            /profileedit
          /forgotpassword
          /about
          /contact

------
hliyan
Oh dear:

    
    
       EMBER 2.0 BETA
    
       Model-View-Controller is replaced by Model-Route-Component-Service.
       Two-way bindings are replaced by data down, actions up (DDAU).
    

I haven't delved into the details, but it looks like things are starting to
move in the direction of React. I'm not entirely surprised. We recently built
a full scale app with Ember and Ember Data. Now looking back, React with
Backbone feels it could have been an equally good (if not better) choice.

~~~
Nemcue
> React with Backbone feels it could have been an equally good (if not better)
> choice.

Superficially it might "feel" like a better choice, but objectively it would
have been worse if you're doing anything non-trivial.

The backbone router is severely lacking compared to the Ember Router. Same
thing with having a lot of models with relationships between them. Sure there
might be Backbone-related projects that try to tackle it — they are all way
worse than the Ember equivalents. In my opinion they either lack tests,
functionality or have terrible architecture.

I think it's a huge merit of the Ember community that they're moving in this
direction. They saw something that worked better and weren't ashamed to say
"Well that's better than what we have. We're going to do that instead".

Going by track-record and where they are today, Ember would in my mind be a
great choice for any company that wants to start building web applications.
Ember-CLI is a huge productivity boost, and I bet any company doing more than
a few SPAs has had to build something similar; and it probably ended up way
worse than Ember CLI.

I find it very unfortunate that web developers have all put their eggs in the
Angular basket. From my point of view the rationale for choosing Angular today
seem to be the network effect of readily available developers, and not so much
the merits of the framework itself.

The Angular team realised they could do things better, and rewrote their
entire framework. The Ember team realised they could do things better, and is
incrementally moving towards that while letting you migrate your app with it.

~~~
hajile
Most React devs use react-router which is heavily inspired by ember's router
but the JSX-syntax makes it easier to work with IMHO.

That said, I think Ember's an excellent choice and basically on par with React
(it's up to your development style).

~~~
lobster_johnson
It's been a while since I used react-router, but I think this is one place
where the Flux flow is better.

Navigation is state, so we built a store to track it. It mediates between a UI
model (which abstracts the window location and pushstate stack) and an
internal state. Routing involves dispatching an action to request a specific
URL, and changing the view to the navigation state is handled by the app's
root "application" component, which then sends parameters onward to its
current "view" component. There's a simple mapping of route names to views.

~~~
girvo
We built a very similar component for React, hooked into Flummox. The nice
part is that async "just worked", and having the entire router available as a
Flux store with actions that you can fire to change the page made integration
powerful.

We also added some extra little code to make it run on the server: the <Link>
component renders down to an <a> tag, and the router runs correctly, so
everything works isomorphically, and as a neat bonus the bulk of the site
works without Javascript enabled.

------
aikah
Nice, contrary to some I believe competition is good and the more the merrier,
so I 'm really really impatient to test the Ember.js 2.x beta.

------
nailer
I don't use ember, but random observation: out of the big frameworks, ember
seems to be the one people most often use because they chose it, and because
of the community. Well done Ember folks.

------
UserRights
Here is an interesting story about the flarum forum dev and their switch from
ember to mithril due to extensibility problems and performance. Hopefully the
auhor will blog some more about his experiences.

Mind the bloat if you do not want to sink the boat.

~~~
Nemcue
You didn't provide a link. I assume you were going to link the blog post
announcing their switch to Mithril — that didn't contain any rationale behind
it.

I did find this however, which goes into details about why Ember was not a
good choice for them: [http://discuss.flarum.org/139-introducing-flarum-s-
fast-new-...](http://discuss.flarum.org/139-introducing-flarum-s-fast-new-
front-end#p345)

Seems to be a well based choice. Doesn't seem to have anything to do with
performance though.

While Mithril is probably a lot more extensible and easeier to work with since
there's a smaller API surface, seeing "templates" like this makes me sad:

    
    
      view() {
        return m('div.text-editor', {config: this.element}, [
          m('textarea.form-control.flexible-height', {
            config: this.configTextarea.bind(this),
            oninput: m.withAttr('value', this.oninput.bind(this)),
            placeholder: this.props.placeholder || '',
            disabled: !!this.props.disabled,
            value: this.value()
          }),
          m('ul.text-editor-controls', listItems(this.controlItems().  toArray()))  
        ]);
      }

~~~
empyrical
Has anyone made a JSX transformer that plays nice with Mithril? Seems like it
would make using that api you provided a snippet of less painful

~~~
insin
You can use Babel's JSX transformer for HTML elements by sticking this in a
.babelrc file:

    
    
        {
          "jsxPragma": "m"
        }
    

You'll also be able to use it for Mithril components when the next version of
Mithril is released. Relevant issue:
[https://github.com/lhorie/mithril.js/issues/632](https://github.com/lhorie/mithril.js/issues/632)

------
alexnewman
Native. Want

