Ember.js 1.13.0 and 2.0 Beta Released(emberjs.com)
emberjs.com
Ember.js 1.13.0 and 2.0 Beta Released
http://emberjs.com/blog/2015/06/12/ember-1-13-0-released.html
37 comments
> 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).
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).
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.
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?
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?
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:
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
/contactSam 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/
[0] http://www.samselikoff.com/blog/preparing-for-ember-2.0/
I'd jump right in. The upgrade path has been very gentle for quite some time now.
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).
> 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.
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.
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).
That said, I think Ember's an excellent choice and basically on par with React (it's up to your development style).
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.
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.
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.
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.
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.
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.
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.
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 !
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
Just pure react is great for tiny things, but for large applications you should use React with Flux architecture with alt or flummox or reflux or whatever you like, it simplifies things in the long run.
Of course you would need to do things like ajax or routing, for which there are endless libraries, or you can just go pure XHR. React-Router is terrific for routing.
Of course you would need to do things like ajax or routing, for which there are endless libraries, or you can just go pure XHR. React-Router is terrific for routing.
> 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)
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)
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.
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.
We almost have all the letters necessary to call Ember the SCROTUM framework. "O" opinionated, "U" __, "T" ___
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.
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.
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.
Mind the bloat if you do not want to sink the boat.
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:
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()))
]);
}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
You can use Babel's JSX transformer for HTML elements by sticking this in a .babelrc file:
{
"jsxPragma": "m"
}
[deleted]
That "template" is really not okay.
Native. Want
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?