4 ms·

Ember.js 1.13.0 and 2.0 Beta Released

122 points by makepanic 11y ago

hliyan 11y 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.
- Tankenstein 11y 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 11y 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 !
    - Tankenstein 11y ago
      Yup, i really like how the js community doesn't hate on other frameworks/libraries, but instead they use each other's ideas to better their own.
  - johnsberd 11y 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.
    - k__ 11y ago
      React is the "View", so you need something like Backbone to fuel it. Roll your own, use Backbone, Flux (made by FB especially for React) or Reflux (third party. Flux re-imagined).
      - lobster_johnson 11y ago
        I would advise against using Backbone with React/Flux. First, because you don't need it, and secondly, because Backbone is mutable by default, which can cause all sorts of data flow bugs. Once you buy into the Flux methodology (not necessarily Flux as described by Facebook), a lot of the concerns that Backbone handles melt away. You don't need observable collections and models because all state changes are explicit and data moves in just one direction. Given that Backbone's core is just a thin layer on top of XMLHTTPRequest, you're better off just doing XHR yourself, with POD objects for data.
    - xtrumanx 11y ago
      You don't need another framework to build apps with React. But you will need several libraries as React isn't "kitchen sink" type framework like Ember and Angular. In my React-based apps, I typically include react-router for routing and request or superagent for ajax calls. You can also include a Flux-inspired library if you're into that sort of thing.
    - girvo 11y ago
      React + Flux in the form of Flummox (along with react-router for routing) is enough for a 10kloc application I recently wrote for Expedia. If you don't want to make architectural decisions or composing smaller libraries then I think Ember is a better choice, but for us React is perfect.
    - aikah 11y ago
      The only thing you need is Ajax and you have it right here in the browser without the need of a third party library. All the rest can be handled by React and its plugins. That's how I do things, React + raw Xml Http requests. Since JSX is already a layer on its own no need to add yet another layer of complexity.
- Nemcue 11y 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.
  - hliyan 11y 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 11y 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__ 11y ago
  Also it's more of a Model-Route-View-Controller-Component-Service to 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 11y ago
    We almost have all the letters necessary to call Ember the SCROTUM framework. "O" opinionated, "U" __, "T" ___
- steveklabnik 11y 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 11y 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 11y ago
  I'd jump right in. The upgrade path has been very gentle for quite some time now.
- bttf 11y 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/ http://www.samselikoff.com/blog/preparing-for-ember-2.0/
- sergiotapia 11y ago
  You can dive right into Ember with this book with zero previous experience: https://pragprog.com/book/mwjsember/deliver-audacious-web-apps-with-ember-2 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 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 11y 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.
- Nemcue 11y 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-front-end#p345 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 11y 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
    - k__ 11y ago
      https://github.com/insin/msx https://github.com/insin/msx
    - insin 11y ago
      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
aikah 11y 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 11y 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?
- lennexz 11y ago
  I am not (Dale / Katz and cronies) but I read somewhere that major fastboot work will begin after 2.0 beta is released. This will be to align it with glimmer changes. So hold on tight we still have more goodies coming in the 2.x series :)
- wycats 11y 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 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).
alexnewman 11y ago
Native. Want
nailer 11y 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.

122 points by makepanic 11y 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.

Tankenstein 11y 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 11y 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 !
  - Tankenstein 11y ago
    Yup, i really like how the js community doesn't hate on other frameworks/libraries, but instead they use each other's ideas to better their own.
- johnsberd 11y 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.
  - k__ 11y ago
    React is the "View", so you need something like Backbone to fuel it. Roll your own, use Backbone, Flux (made by FB especially for React) or Reflux (third party. Flux re-imagined).
    - lobster_johnson 11y ago
      I would advise against using Backbone with React/Flux. First, because you don't need it, and secondly, because Backbone is mutable by default, which can cause all sorts of data flow bugs. Once you buy into the Flux methodology (not necessarily Flux as described by Facebook), a lot of the concerns that Backbone handles melt away. You don't need observable collections and models because all state changes are explicit and data moves in just one direction. Given that Backbone's core is just a thin layer on top of XMLHTTPRequest, you're better off just doing XHR yourself, with POD objects for data.
  - xtrumanx 11y ago
    You don't need another framework to build apps with React. But you will need several libraries as React isn't "kitchen sink" type framework like Ember and Angular. In my React-based apps, I typically include react-router for routing and request or superagent for ajax calls. You can also include a Flux-inspired library if you're into that sort of thing.
  - girvo 11y ago
    React + Flux in the form of Flummox (along with react-router for routing) is enough for a 10kloc application I recently wrote for Expedia. If you don't want to make architectural decisions or composing smaller libraries then I think Ember is a better choice, but for us React is perfect.
  - aikah 11y ago
    The only thing you need is Ajax and you have it right here in the browser without the need of a third party library. All the rest can be handled by React and its plugins. That's how I do things, React + raw Xml Http requests. Since JSX is already a layer on its own no need to add yet another layer of complexity.
Nemcue 11y 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.
- hliyan 11y 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 11y 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__ 11y ago
Also it's more of a Model-Route-View-Controller-Component-Service to 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 11y ago
  We almost have all the letters necessary to call Ember the SCROTUM framework. "O" opinionated, "U" __, "T" ___
steveklabnik 11y 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 11y 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 11y ago
I'd jump right in. The upgrade path has been very gentle for quite some time now.
bttf 11y 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/ http://www.samselikoff.com/blog/preparing-for-ember-2.0/
sergiotapia 11y ago
You can dive right into Ember with this book with zero previous experience: https://pragprog.com/book/mwjsember/deliver-audacious-web-apps-with-ember-2 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 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 11y 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.

Nemcue 11y 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-front-end#p345 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 11y 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
  - k__ 11y ago
    https://github.com/insin/msx https://github.com/insin/msx
  - insin 11y ago
    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

aikah 11y 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 11y 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?

lennexz 11y ago
I am not (Dale / Katz and cronies) but I read somewhere that major fastboot work will begin after 2.0 beta is released. This will be to align it with glimmer changes. So hold on tight we still have more goodies coming in the 2.x series :)
wycats 11y 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 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).

alexnewman 11y ago

Native. Want

nailer 11y 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.