Ember.js 1.13.0 and 2.0 Beta Released

http://emberjs.com/blog/2015/06/12/ember-1-13-0-released.html

by makepanic • 11 years ago

122 35 11 years ago

hliyan2• 11 years ago

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.

Tankenstein4• 11 years ago

Every JS framework is moving in the direction of React, because React is (in my experience) the best and most logical we have right now.

geoffroy• 11 years ago

And they acknlowedge it : "We would like to thank React for showing that full re-renders can be made efficient. While we did not their precise Virtual DOM approach, their work with Virtual DOM was extremely influential to our approach in Glimmer." Fair play !

johnsberd• 11 years ago

Are people always using React with another framework or can you build out full applications with just React? Im looking to start another project and want to try React but not sure if it has everything I'm looking for.

Nemcue2• 11 years ago

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.

hliyan2• 11 years ago

You make some good points. Yes, I totally forgot how good the Ember router is. As for CLI, we actually did build something similar (because CLI wasn't mature enough at the time I evaluated Ember) and it's holding its own against CLI quite well.

I evaluated Angular (as well as React) before settling on Ember last year. I disliked that it tried to own the DOM and that the concepts and terminology (e.g. transclusions) make it difficult to onboard new developers who weren't already experienced in Angular. Plus (and this is a personal opinion), both Ember and React application code looked more elegant than Angular apps.

hajile• 11 years ago

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

k__3• 11 years ago

Also it's more of a

Model-Route-View-Controller-Component-Service

Model-Route-Component-Service

switch.

These things were all present before and many people started to merge the view-controller implementations into a component one.

DufusRandy• 11 years ago

We almost have all the letters necessary to call Ember the SCROTUM framework. "O" opinionated, "U" __, "T" ___

steveklabnik• 11 years ago

things are starting to move in the direction of React.

Not just interface wise, but internally: the new Glimmer engine is similar to React as well, but takes advantage of what Handlebars knows about how templates can change to do less diffing. (I think React is gaining something similar soon too)

adwhit• 11 years ago

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?

jherdman• 11 years ago

I'd jump right in. The upgrade path has been very gentle for quite some time now.

bttf• 11 years ago

Sam Selikoff's article on preparing for Ember 2.0 includes a pattern that could easily upgrade into routeable components [0].

[0] http://www.samselikoff.com/blog/preparing-for-ember-2.0/

sergiotapia• 11 years ago

You can dive right into Ember with this book with zero previous experience: https://pragprog.com/book/mwjsember/deliver-audacious-web-ap...

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

UserRights• 11 years ago

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.

Nemcue2• 11 years ago

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

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• 11 years ago

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

constantlm• 11 years ago

That "template" is really not okay.

aikah2• 11 years ago

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.

ffn• 11 years ago

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• 11 years ago

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

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

Tankenstein4• 11 years ago

I'm not really an Ember dude, but i might have some input on 3. In react, when you start, it looks the same way. A bunch of functions passed down like 5 components. Fortunately, there's a way better way, and it's flux. I'm guessing Ember will let you use something like flux.

alexnewman• 11 years ago

Native. Want

nailer• 11 years ago

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.

Ember.js 1.13.0 and 2.0 Beta Released

Related Stories