What's Coming in Ember.js in 2014(emberjs.com)
emberjs.com
What's Coming in Ember.js in 2014
http://emberjs.com/blog/2013/12/17/whats-coming-in-ember-in-2014.html
6 comments
EMBERDART
Just kidding.
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.
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.
Edit: Also, where's Ember Data?
In the comments:
Tom Dale • 2 hours ago
Sorry everyone, I forgot to note that we have a separate blog post on Ember Data on the way. Don't fret! We've got many more exciting updates to share with you soon.
stefanpenner Mod mspisars • 2 hours ago
We have much planned for ember-data, it likely serves its own blog post :)
Tom Dale • 2 hours ago
Sorry everyone, I forgot to note that we have a separate blog post on Ember Data on the way. Don't fret! We've got many more exciting updates to share with you soon.
stefanpenner Mod mspisars • 2 hours ago
We have much planned for ember-data, it likely serves its own blog post :)
I doubt it. It's not like IE8 is dropped by Angular. If you want to use Angular with IE8, use v1.2.
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.
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.
Expecting Angular to support IE8 is highly unrealistic. Angular is innovative and different, IMO. To expect Angular to maintain support for IE8 is to expect Angular to sacrifice speed of development / innovation. Support of IE8 constrains the feature set that is possible in Angular. There's a reason Angular seems to be winning more independent/general developer mindshare than Ember, and this is the reason.
Anecdotally, I've noticed more established/larger tech companies (other than Google) using Ember, and more startups using Angular (with some exceptions like Amazon, which uses Angular). I think this is also a reason.
Anecdotally, I've noticed more established/larger tech companies (other than Google) using Ember, and more startups using Angular (with some exceptions like Amazon, which uses Angular). I think this is also a reason.
If you want to use Angular with IE8, use v1.2
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.
Most folk would consider that "dropped", no?
> Edit: Also, where's Ember Data?
I'd like to hear about this too. When I tinkered with Ember (v1.0) Ember Data seems to cause most of my problems. I still like Ember but it made me wary and I'd probably avoid Ember Data if I went back to Ember.
I'd like to hear about this too. When I tinkered with Ember (v1.0) Ember Data seems to cause most of my problems. I still like Ember but it made me wary and I'd probably avoid Ember Data if I went back to Ember.
Sorry you guys had trouble with Ember Data. Our first conception of Ember Data was that it would act as an ORM on top of JSON, and the architecture would allow developers to build adapters for many different kinds of backends.
Unfortunately, there is no JSON analog to SQL. Every existing backend forms their JSON differently, especially when you start modeling relationships. It would be like trying to build ActiveRecord if every team rolled their own query language for each new project.
We're trying to make this better in the long-term with projects like http://jsonapi.org, and https://github.com/rails-api/active_model_serializers for Rails. We'll get there someday.
In the meantime, we totally rebooted the Ember Data project to make it simple for people to customize how their apps consume JSON APIs. Most people we've talked to have been very happy about the fact that the defaults are simple to override now, and how much simpler the internals have become. We have a small amount of work left to do before we declare a 1.0 final; in the meantime, we've cut a 1.0 beta build that you can get from http://emberjs.com/builds.
Unfortunately, there is no JSON analog to SQL. Every existing backend forms their JSON differently, especially when you start modeling relationships. It would be like trying to build ActiveRecord if every team rolled their own query language for each new project.
We're trying to make this better in the long-term with projects like http://jsonapi.org, and https://github.com/rails-api/active_model_serializers for Rails. We'll get there someday.
In the meantime, we totally rebooted the Ember Data project to make it simple for people to customize how their apps consume JSON APIs. Most people we've talked to have been very happy about the fact that the defaults are simple to override now, and how much simpler the internals have become. We have a small amount of work left to do before we declare a 1.0 final; in the meantime, we've cut a 1.0 beta build that you can get from http://emberjs.com/builds.
Surely you guys know that the single largest barrier to using Ember is Ember-data right?
I thoroughly tested all the available frameworks this summer and I was leaning heavily towards Ember until I tried actually using it with Ember-data and it was very ugly. I looked online and there was near universal condemnation of it from what I could find. Even Discourse didn't use it! I saw this link and thought "I bet they are announcing a completely new and working ember-data" and was surprised to see it wasn't even a topic in there.
Ember-data drove me directly into the arms of Angular and I haven't looked back. I am completely stunned it wasn't your number one priority a long time ago.
I thoroughly tested all the available frameworks this summer and I was leaning heavily towards Ember until I tried actually using it with Ember-data and it was very ugly. I looked online and there was near universal condemnation of it from what I could find. Even Discourse didn't use it! I saw this link and thought "I bet they are announcing a completely new and working ember-data" and was surprised to see it wasn't even a topic in there.
Ember-data drove me directly into the arms of Angular and I haven't looked back. I am completely stunned it wasn't your number one priority a long time ago.
I will challenge your assertion that it wasn't our number one priority. :)
See http://emberjs.com/blog/2013/05/03/ember-data-progress-updat... for the blog post that did what you requested. We've probably fixed most of the issues you hit. You should give us another try!
See http://emberjs.com/blog/2013/05/03/ember-data-progress-updat... for the blog post that did what you requested. We've probably fixed most of the issues you hit. You should give us another try!
Old news unfortunately; I'm specifically speaking of Ember data from July / August 2013 era. It was purportedly worse before that, I don't know because I only looked at it this summer.
I understand many people don't write data centric apps and they full well find they don't need Ember-data or need a very sophisticated Ember-data but try to do anything of substance data wise and it's a nightmare.
I understand many people don't write data centric apps and they full well find they don't need Ember-data or need a very sophisticated Ember-data but try to do anything of substance data wise and it's a nightmare.
I am glad angular (which has no data-layer) satisfies your needs :)
Well, I guess there is the experience of those of us in the trenches actually working with these frameworks and large data centric applications and then there are people who want to argue semantics.
I had the same issues as well. After several hours of hacking away, I noticed that projects (like Discourse) wrote their own data layer instead of relying on Ember Data.
In the comments they say a separate post about Ember Data is forthcoming.
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."
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.
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.
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.
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.
The reason for the proposed tight coupling within the ember-cli is to ensure we can provide a stable, performant development experience.
Many of us are currently using a grunt-based system, see: 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.
The need for improvements actually came out of that project, feel free to read pending issues for further context and rational.
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.
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.
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 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.
For those of you struggling with Ember Data - this is your best friend - 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.
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.
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.
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.
I love angularjs, way more consistent api, it actually does what you expect.
Re. Haml: try emblemjs.com
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.
Sidenote, this was really fun to read for some reason, like eating a bunch of little mini cookies.
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.