4 ms·

What's Coming in Ember.js in 2014

107 points by makepanic 13y ago

ben336 13y ago
Inventing their own build tools instead of using a Grunt plugin seems like a severe case of NIH for ember. I'd be curious to hear their rationale beyond "the currently-available options all have fatal flaws that make them unpleasant to use as your app gets larger."
- iamstef 13y ago
  Many of us are currently using a grunt-based system, see: https://github.com/stefanpenner/ember-app-kit https://github.com/stefanpenner/ember-app-kit The need for improvements actually came out of that project, feel free to read pending issues for further context and rational.
- wycats 13y ago
  In general, I've come to believe that it's very easy to look at decisions as "severe cases of NIH" by looking at available tools and assuming that something must fit the bill. Especially in the young ecosystem that is JavaScript, there are often areas where the existing out-of-the-box solutions just don't satisfy the use cases of other open source projects. As Stef said, our first attempt was to build a grunt-based build solution, and it may still be possible to do so, but it wasn't as simple and drop-in as you might expect. When the work to build on top of existing solutions becomes significant, it's not longer an obvious and "severe case of NIH" to consider more home-rolling. Sometimes those home-rolled solutions even become useful for the broader ecosystem (for example, git). I don't think that Ember should build a huge, monolithic build tool system tightly coupled to Ember. We're already looking at bringing together the best in breed of existing tools and working with people who are building other tooling components that satisfy some of our needs. We absolutely plan to use bower for package management, for instance. NIH is a really easy accusation to throw out, but real life, especially with large open source projects and young ecosystems, is hardly that simple.
  - ben336 13y ago
    Fair enough. I think the "tightly coupled to ember" part is what left a bad taste with me. Obviously the ember community is free to use whatever they want. But if the build tool is only useful for ember (and the "ember" name in the example cli indicates that will be the case) it seems like it might struggle longterm to keep up with grunt or other more broadly applicable build system.
    - iamstef 13y ago
      Your concern is noted, and is also a concern of ours. Rest assured the ember-cli will only be a small veneer providing a curated experience of community tools. The reason for the proposed tight coupling within the ember-cli is to ensure we can provide a stable, performant development experience.
aaronbrethorst 13y ago
Despite the imminent End of Life status of Windows XP, we will continue supporting Internet Explorer 8. We know many Ember.js users still need to target enterprise and education customers, who will be on IE8 for some time. It'll be interesting to see if the Angular folks end up having to walk back their v1.3 removal of IE 8 support. Also, I'm very pleased to see the Ember folks adopting a more 'realistic' attitude. Edit: Also, where's Ember Data?
- argonaut 13y ago
  I doubt it. It's not like IE8 is dropped by Angular. If you want to use Angular with IE8, use v1.2.
  - machty 13y ago
    Most folk would consider that "dropped", no?
  - aaronbrethorst 13y ago
    If you want to use Angular with IE8, use v1.2 Right, that's the problem.
  - tomdale 13y ago
    Of course, you are always welcome to stick with older versions. But given that Angular will not be following SemVer until 2.0, it seems likely that compatibility issues between the point releases will quickly isolate you from the greater Angular community.
  - orand 13y ago
    Too simplistic. Yeah that's a fine solution today. But it's not fine a year from now. This has a big impact on decision-making for any project that actually matters and will therefore be around for a while. Dropping IE8 support + the "don't worry, it's free" Dart port make me very concerned about committing to Angular for anything I might be maintaining 2 to 5 years from now.
    - 13y ago
hablahaha 13y ago
Yay EmberConf! Anyone have any idea where it might be? Sidenote, this was really fun to read for some reason, like eating a bunch of little mini cookies.
Bahamut 13y ago
EMBERDART Just kidding. I laughed. This progress for Ember is really making me interested - I will probably do my next big app with Ember. I'm happy to see that they are moving away from requiring jQuery & swapping Handlebars to HTMLbars, which will help reduce Ember's JS required footprint, which is massive currently. Nice integration with ES6 also sounds promising. One thing I fight with Angular so far is with asynchronous loading of modules/controllers/directives/services/etc. - while I love Angular, its not good for lazyloading. I'm a bit wary since I have found that I don't like convention over configuration personally, but I am liking some of the high level decisions made recently to refine Ember.
adamnemecek 13y ago
I have a small suggestion for the Ember.js team. When I was trying to learn Ember, I was looking at the source code of the Discourse project and I noticed that they do some things that are AFAIK discouraged (e.g. referencing App.__container__ directly). Idk how much effort it would be to keep an eye on the project and submit an occasional pull request but doing that might be a good idea. Discourse is probably the first place where people go once they have read the docs and want to see Ember in action. And seeing these hacks might reflect badly on the framework even though it's not Ember's fault.
weeksie 13y ago
Honestly, Ember has been incredibly frustrating to get going. Mainly in the area of testing—it's a nightmare. The documentation is nicely formatted but missing a lot of context. For such a large project, it needs more than API docs and the overviews are not especially useful. Using it with Rails is a nightmare, you have to fiddle with ember rails and if you want to use anything but Handlebars it's a huge hassle (tags, what? I thought we'd collectively moved past that to things like Haml, Jade, Thin, etc. . .) I love where it's headed and I like a lot of the ideas, but it's been pretty aggravating to get up and running.
- machty 13y ago
  Re. Haml: try emblemjs.com
- shanusmagnus 13y ago
  Thank you! It's good to hear someone else say it. I've made a couple of runs trying to come to terms with Ember; invariably the docs are wrong, and various examples don't work with the currently-released Ember build; and then Googling turns up some other docs for some other version. Maddening to try to figure out what the current reality is. The third party ecosystem also seems very sparse -- would pay money for the Ember equivalent of Two Scoops of Django, although I'll probably just try Angular instead of waiting to see if things get better. Seems to be vastly more resources for Angular and the rate of development seems much quicker.
- krob 13y ago
  I love angularjs, way more consistent api, it actually does what you expect.
- Mc_Big_G 13y ago
  Don't use the asset pipeline. Compile your assets and then you can just drop them in the public dir. I use the ember app kit which can build a production distribution.
- samratjp 13y ago
  I started a major rewrite for a Rails App that I'm converting to Rails API + Ember with Ember Data. Yeah, the learning curve has been huge and Ember Data pretty much didn't help things. But, I've stuck with it and everytime I struggle with something (happened first with routing nested resources - still feels a bit magic sometimes), I take a step back and look at the Ember way of doing things and I usually become enlightened with the very well thought out decisions. For those of you struggling with Ember Data - this is your best friend - https://github.com/emberjs/data/blob/master/TRANSITION.md https://github.com/emberjs/data/blob/master/TRANSITION.md probably the best documentation on the matter. If you got Active Model Serializers, use the right serializer on Ember data side to get going. IF you're using Ember Rails - be sure to check that it's pulling the latest Ember Data. I like that there are more tutorials and demos coming out but seriously, we need some more non-trivial UI examples. Maybe after my project I'll write up a blog post if anyone here is interested.

107 points by makepanic 13y ago

Inventing their own build tools instead of using a Grunt plugin seems like a severe case of NIH for ember. I'd be curious to hear their rationale beyond "the currently-available options all have fatal flaws that make them unpleasant to use as your app gets larger."

iamstef 13y ago
Many of us are currently using a grunt-based system, see: https://github.com/stefanpenner/ember-app-kit https://github.com/stefanpenner/ember-app-kit The need for improvements actually came out of that project, feel free to read pending issues for further context and rational.
wycats 13y ago
In general, I've come to believe that it's very easy to look at decisions as "severe cases of NIH" by looking at available tools and assuming that something must fit the bill. Especially in the young ecosystem that is JavaScript, there are often areas where the existing out-of-the-box solutions just don't satisfy the use cases of other open source projects. As Stef said, our first attempt was to build a grunt-based build solution, and it may still be possible to do so, but it wasn't as simple and drop-in as you might expect. When the work to build on top of existing solutions becomes significant, it's not longer an obvious and "severe case of NIH" to consider more home-rolling. Sometimes those home-rolled solutions even become useful for the broader ecosystem (for example, git). I don't think that Ember should build a huge, monolithic build tool system tightly coupled to Ember. We're already looking at bringing together the best in breed of existing tools and working with people who are building other tooling components that satisfy some of our needs. We absolutely plan to use bower for package management, for instance. NIH is a really easy accusation to throw out, but real life, especially with large open source projects and young ecosystems, is hardly that simple.
- ben336 13y ago
  Fair enough. I think the "tightly coupled to ember" part is what left a bad taste with me. Obviously the ember community is free to use whatever they want. But if the build tool is only useful for ember (and the "ember" name in the example cli indicates that will be the case) it seems like it might struggle longterm to keep up with grunt or other more broadly applicable build system.
  - iamstef 13y ago
    Your concern is noted, and is also a concern of ours. Rest assured the ember-cli will only be a small veneer providing a curated experience of community tools. The reason for the proposed tight coupling within the ember-cli is to ensure we can provide a stable, performant development experience.

aaronbrethorst 13y ago

Despite the imminent End of Life status of Windows XP, we will continue supporting Internet Explorer 8. We know many Ember.js users still need to target enterprise and education customers, who will be on IE8 for some time. It'll be interesting to see if the Angular folks end up having to walk back their v1.3 removal of IE 8 support. Also, I'm very pleased to see the Ember folks adopting a more 'realistic' attitude. Edit: Also, where's Ember Data?

argonaut 13y ago
I doubt it. It's not like IE8 is dropped by Angular. If you want to use Angular with IE8, use v1.2.
- machty 13y ago
  Most folk would consider that "dropped", no?
- aaronbrethorst 13y ago
  If you want to use Angular with IE8, use v1.2 Right, that's the problem.
- tomdale 13y ago
  Of course, you are always welcome to stick with older versions. But given that Angular will not be following SemVer until 2.0, it seems likely that compatibility issues between the point releases will quickly isolate you from the greater Angular community.
- orand 13y ago
  Too simplistic. Yeah that's a fine solution today. But it's not fine a year from now. This has a big impact on decision-making for any project that actually matters and will therefore be around for a while. Dropping IE8 support + the "don't worry, it's free" Dart port make me very concerned about committing to Angular for anything I might be maintaining 2 to 5 years from now.
  - 13y ago

hablahaha 13y ago

Yay EmberConf! Anyone have any idea where it might be? Sidenote, this was really fun to read for some reason, like eating a bunch of little mini cookies.

Bahamut 13y ago

EMBERDART Just kidding. I laughed. This progress for Ember is really making me interested - I will probably do my next big app with Ember. I'm happy to see that they are moving away from requiring jQuery & swapping Handlebars to HTMLbars, which will help reduce Ember's JS required footprint, which is massive currently. Nice integration with ES6 also sounds promising. One thing I fight with Angular so far is with asynchronous loading of modules/controllers/directives/services/etc. - while I love Angular, its not good for lazyloading. I'm a bit wary since I have found that I don't like convention over configuration personally, but I am liking some of the high level decisions made recently to refine Ember.

adamnemecek 13y ago

I have a small suggestion for the Ember.js team. When I was trying to learn Ember, I was looking at the source code of the Discourse project and I noticed that they do some things that are AFAIK discouraged (e.g. referencing App.__container__ directly). Idk how much effort it would be to keep an eye on the project and submit an occasional pull request but doing that might be a good idea. Discourse is probably the first place where people go once they have read the docs and want to see Ember in action. And seeing these hacks might reflect badly on the framework even though it's not Ember's fault.

weeksie 13y ago

Honestly, Ember has been incredibly frustrating to get going. Mainly in the area of testing—it's a nightmare. The documentation is nicely formatted but missing a lot of context. For such a large project, it needs more than API docs and the overviews are not especially useful. Using it with Rails is a nightmare, you have to fiddle with ember rails and if you want to use anything but Handlebars it's a huge hassle (tags, what? I thought we'd collectively moved past that to things like Haml, Jade, Thin, etc. . .) I love where it's headed and I like a lot of the ideas, but it's been pretty aggravating to get up and running.

machty 13y ago
Re. Haml: try emblemjs.com
shanusmagnus 13y ago
Thank you! It's good to hear someone else say it. I've made a couple of runs trying to come to terms with Ember; invariably the docs are wrong, and various examples don't work with the currently-released Ember build; and then Googling turns up some other docs for some other version. Maddening to try to figure out what the current reality is. The third party ecosystem also seems very sparse -- would pay money for the Ember equivalent of Two Scoops of Django, although I'll probably just try Angular instead of waiting to see if things get better. Seems to be vastly more resources for Angular and the rate of development seems much quicker.
krob 13y ago
I love angularjs, way more consistent api, it actually does what you expect.
Mc_Big_G 13y ago
Don't use the asset pipeline. Compile your assets and then you can just drop them in the public dir. I use the ember app kit which can build a production distribution.
samratjp 13y ago
I started a major rewrite for a Rails App that I'm converting to Rails API + Ember with Ember Data. Yeah, the learning curve has been huge and Ember Data pretty much didn't help things. But, I've stuck with it and everytime I struggle with something (happened first with routing nested resources - still feels a bit magic sometimes), I take a step back and look at the Ember way of doing things and I usually become enlightened with the very well thought out decisions. For those of you struggling with Ember Data - this is your best friend - https://github.com/emberjs/data/blob/master/TRANSITION.md https://github.com/emberjs/data/blob/master/TRANSITION.md probably the best documentation on the matter. If you got Active Model Serializers, use the right serializer on Ember data side to get going. IF you're using Ember Rails - be sure to check that it's pulling the latest Ember Data. I like that there are more tutorials and demos coming out but seriously, we need some more non-trivial UI examples. Maybe after my project I'll write up a blog post if anyone here is interested.