Why I love Ember.js(fleon.org)
fleon.org
Why I love Ember.js
http://fleon.org/post/47401547699/why-i-love-ember-js
10 comments
Testacular is now called Karma if anybody has trouble finding the project:
https://github.com/karma-runner/karma/issues/376
https://github.com/karma-runner/karma/issues/376
I agree with most of this, Ember.js is great. However, I'm not so sure on ember-data. It seems like it has great potential and will eventually turn out to be excellent but currently I've found it to be very frustrating when you actually try and use it.
To me ember-data is currently either you use it exactly as we specify and it might work but if you attempt to do anything that even slightly deviates from this then you're pretty much out of luck.
Firstly, it has a trivial to challenging barrier of entry depending on your skills/environment; it requires a working ruby environment and the ability to build ember-data from the git repo.
Then once you start using ember-data you'll most likely find yourself running in to all sorts of problems that involve you delving into the source code to find out what on earth is going off (no docs). Also I fell in to the trap of assuming that ember-data should do something and trying to figure out what was wrong with my implementation when it turns out it can't actually do that. For example, ember-data does not automatically update hasMany collections when you fetch a model with a corresponding belongsTo. Because of this you have to specify every single id of the related models for your hasMany relationship in the parent model's JSON and good luck trying to hack your way around this by appending models to the hasMany collection yourself.
As I said though, it does appear to have promise and to be fair it does not claim to be ready for production. However, I think it is a bit early to be attaching words like "love" to ember-data just yet. Ember.js on the other hand currently seems excellent and when ember-data becomes production ready I think they'll make for a very powerful combo.
To me ember-data is currently either you use it exactly as we specify and it might work but if you attempt to do anything that even slightly deviates from this then you're pretty much out of luck.
Firstly, it has a trivial to challenging barrier of entry depending on your skills/environment; it requires a working ruby environment and the ability to build ember-data from the git repo.
Then once you start using ember-data you'll most likely find yourself running in to all sorts of problems that involve you delving into the source code to find out what on earth is going off (no docs). Also I fell in to the trap of assuming that ember-data should do something and trying to figure out what was wrong with my implementation when it turns out it can't actually do that. For example, ember-data does not automatically update hasMany collections when you fetch a model with a corresponding belongsTo. Because of this you have to specify every single id of the related models for your hasMany relationship in the parent model's JSON and good luck trying to hack your way around this by appending models to the hasMany collection yourself.
As I said though, it does appear to have promise and to be fair it does not claim to be ready for production. However, I think it is a bit early to be attaching words like "love" to ember-data just yet. Ember.js on the other hand currently seems excellent and when ember-data becomes production ready I think they'll make for a very powerful combo.
Thank you for the detailed feedback. Working on Ember Data has been one of the most challenging efforts of my career, but I think that it has the opportunity to dramatically change how people write web applications. Once we've stabilized it, of course. :)
Here are the specific steps we're taking to address your concerns:
1. Thanks to a pull request from Stanley Stuart[1], we now automatically publish builds of Ember Data[2] every time a new commit is pushed that passes our suite of tests.
2. We have begun documenting Ember Data[3] and, while not exhaustive, what we have now is significantly better than just a little while ago. As with what happened with Ember.js, we take documentation very seriously and you should see the Ember Data documentation improve dramatically over time.
3. As we outlined in a recent blog post[4], we are focused on stabilizing Ember Data and do not have plans for new features at this time. If we made a mistake in the initial API design, it was not providing enough imperative trap doors to use when the declarative APIs were not sufficient. We are working on fixing that.
Thanks to our friends at Addepar, we are able to dedicate several full days per week to Ember Data and you should see the velocity of the project increase significantly. Many observers have noticed the recent flurry of commit activity[5]; this was not an aberration but an indication of what the future holds now that we have daytime hours to dedicate to it.
If you have specific suggestions for how to make Ember Data as approachable as possible, please let me know. Like I said, my focus right now is on eliminating bugs, stabilizing APIs, and making sure new developers don't hit frustrating rough spots.
1: https://github.com/emberjs/data/pull/850
2: https://s3.amazonaws.com/builds.emberjs.com/ember-data-lates...
3: http://emberjs.com/guides/models/
4: http://emberjs.com/blog/2013/03/22/stabilizing-ember-data.ht...
5: https://github.com/emberjs/data/commits/master
Here are the specific steps we're taking to address your concerns:
1. Thanks to a pull request from Stanley Stuart[1], we now automatically publish builds of Ember Data[2] every time a new commit is pushed that passes our suite of tests.
2. We have begun documenting Ember Data[3] and, while not exhaustive, what we have now is significantly better than just a little while ago. As with what happened with Ember.js, we take documentation very seriously and you should see the Ember Data documentation improve dramatically over time.
3. As we outlined in a recent blog post[4], we are focused on stabilizing Ember Data and do not have plans for new features at this time. If we made a mistake in the initial API design, it was not providing enough imperative trap doors to use when the declarative APIs were not sufficient. We are working on fixing that.
Thanks to our friends at Addepar, we are able to dedicate several full days per week to Ember Data and you should see the velocity of the project increase significantly. Many observers have noticed the recent flurry of commit activity[5]; this was not an aberration but an indication of what the future holds now that we have daytime hours to dedicate to it.
If you have specific suggestions for how to make Ember Data as approachable as possible, please let me know. Like I said, my focus right now is on eliminating bugs, stabilizing APIs, and making sure new developers don't hit frustrating rough spots.
1: https://github.com/emberjs/data/pull/850
2: https://s3.amazonaws.com/builds.emberjs.com/ember-data-lates...
3: http://emberjs.com/guides/models/
4: http://emberjs.com/blog/2013/03/22/stabilizing-ember-data.ht...
5: https://github.com/emberjs/data/commits/master
I also plan on doing some work to make sure that ActiveModel::Serializers will always work with the latest version of Ember Data. I've been spending much of my OSS time on Resque lately, but this is in my pipeline.
ActiveModel::Serializers is awesome!
The convenience of having a 1:1 companion OSS package on the server-side to hook up with an ember-app is great.
The convenience of having a 1:1 companion OSS package on the server-side to hook up with an ember-app is great.
Thanks! I think so too. :)
That's something I could have written a few months ago before discovering Angular.js. Now, I have no reasons and no desire to go back to Ember.
The main reason why I'm considering giving ember another shot is discourse (discourse.org), which is a pretty large open-source app written in rails and ember. Having a large app that one can reference is pretty invaluable. I'm not aware of any larger apps written in angular.
I can't say specifically how any of these compare in size to Discourse, but there are a number of apps listed here:
http://builtwith.angularjs.org/
http://builtwith.angularjs.org/
Yeah, I'm aware of that site but most of the apps are kind of small.
Google Places and Google DoubleClick use it (larger than discourse will ever be :).
Sure, but neither is open source.
what's the metric that would be good enough? if it's size, google places and doubleclick are bigger than discourse. if it's open source, builtwith.angularjs.org lists more open source code than a single app, that is discourse.
He is talking about having a large open source application that you can browse the code to see how things get structured. A simple TODO app and a real-world app are very different, and most TODO apps would turn into spaghetti code.
Plus it is nice to see the little tricks that are done to make the code more readable or improve the overall design.
Plus it is nice to see the little tricks that are done to make the code more readable or improve the overall design.
A large, open source app. For evaluating how to solve big-app problems, size, on its own, is meaningless, except to show that the hard problems can be done, because it doesn't show how; and open-source, on its own, is meaningless, because it doesn't run into those problems. So adamnemecek needs both to fit his query.
Both are my metric? Is that not obvious? I'd like to see a large scale production ready application that I can learn from. The open source apps from builtwithangular are pretty useless since they are all just slightly more complex than a todo list.
... So you love EmberJS because backbone was the only thing you used before and the only thing you have to compare against?
I've used both Angular and Ember extensively, and AngularJS trounces on EmberJS in both performance and ease of use.
I've used both Angular and Ember extensively, and AngularJS trounces on EmberJS in both performance and ease of use.
What metric are you using to compare performance?
Other than Ember Data, it seems like all the pieces here are things that marionette has. I was super interested to read this, swinging more towards marionette myself, just to get a perspective on what convinced you to change. But there really wasn't much comparion, it seemed to just be you going over the features of ember.
If you don't mind answering here, what made you go so strongly with ember over marionette?
If you don't mind answering here, what made you go so strongly with ember over marionette?
One of the major factors in the debate was community support. Marionette is built on top of Backbone, which meant depending on support of two separate projects. Ember.js, on the other hand is by a single developer. Kind of like why people prefer buying Nexus phones. They are the first ones to officially get updated with the latest Android version. Others might take months before the handset manufacturer decides to update them.
Also, we were certain that we needed view hierarchies, and Marionette provided them too. Back in the day though, it was still in its early stages, and we couldn't really count on it. "What if an API change broke our app with the next upgrade?" we thought. Ember.js on the other hand was pretty much frozen and as in a 1.0 pre2 version. Also, there were many options available, Backbone+Marionette or Backbone+Thorax? It was confusing.
Also, we were certain that we needed view hierarchies, and Marionette provided them too. Back in the day though, it was still in its early stages, and we couldn't really count on it. "What if an API change broke our app with the next upgrade?" we thought. Ember.js on the other hand was pretty much frozen and as in a 1.0 pre2 version. Also, there were many options available, Backbone+Marionette or Backbone+Thorax? It was confusing.
[deleted]
- How fast is your app?
- How productive is your team?
- How productive is Ember community?
- How many Ember libraries do exist in Github?
- How many JavaScript libraries exist in NPM?
- How many of the NPM libraries can be used in client-side?
- How robust is to manage Ember dependencies?
- How simple is to manage Ember dependencies?
- How easy is to debug an Ember app?
- Do you set break points ?
- How easy is to hunt memory leaks in an Ember app?
- What package manager do you use?
- What else libraries do you use?
- Does your code integrate with other code written using Streams, EventEmitters etc?
- How would you reuse Ember in your backend code?
- How replaceable is your code?
- How large is your code?
- Is using large frameworks a best practice in JS community?
- Have you seen alternatives like components http://github.com/component ?I'm glad that, unlike the previous comment thread, you decided not to refer to Ember as "the North Korea of the JavaScript world."
However, what you're doing here might best be described as presenting a series of "loaded questions." You can find out more about this logical fallacy here: https://yourlogicalfallacyis.com/loaded-question
I'm sorry that you feel the need to attack Ember. If you have any specific complaints, maybe we could discuss them over a beer?
However, what you're doing here might best be described as presenting a series of "loaded questions." You can find out more about this logical fallacy here: https://yourlogicalfallacyis.com/loaded-question
I'm sorry that you feel the need to attack Ember. If you have any specific complaints, maybe we could discuss them over a beer?
He does have a point though (the NK reference is hilarious because it's actually not completely off-base, albeit a little over the top).
I looked at Ember again the other day after a long abstinence and to me it has become frighteningly opaque. Even with my prior Ember-knowledge (before Router and {{outlet}} existed in their current form) I completely failed to make sense of a recent tutorial[1].
I wanted to wire the tutorial up with ember-data and add pagination (nothing too fancy), but a series of undecipherable exceptions stopped me in my tracks before I got either working.
A major problem for me was how everything in the "new" Ember is tightly coupled. No longer can I just make an ArrayController, reference it in my template and populate it with standard javascript until I'm ready to drink more of the kool-aid. Or perhaps I can, but it seems to be an anti-pattern now. None of the (few) newer tutorials does anything like that.
It seems I'm now supposed to jump in head-first. I'm supposed to understand all of Ember before using Ember.
Sadly that didn't work out for me, even despite knowing a bit of Ember already. I was constantly stopped by opaque exceptions from the "runloop" which didn't even point to a line of my code. Tracking those down is a Royal Pain In The Ass.
At one point I had enough and just wanted to drop back to "old-style" Ember (who needs a Router anyway!) but quickly gave up on that, too, when it didn't work right away and I realized I'd be completely on my own in that style anyway.
So, from my short (but second) endeavor with Ember I have to conclude that you seem to have turned the learning curve into a perfect square-wave. Every time I made a mistake (even as much as a typo) the useless error messages threw me back a mile. It took only a few of these cycles before I gave up in frustration.
I think you're on a dangerous track here. When I compare my first contact with Ember (about a year ago) with my recent experience then it feels like you're about to re-invent Sproutcore. If my memory serves me right Sproutcore was pretty awesome and powerful, but so opaque and unapproachable that nobody ended up using it.
I really hope this doesn't happen to Ember. I hope you're going to modularize it so newbies stand a chance to start small instead of being bombarded with meaningless exceptions from all directions at once. I hope you'll add narrative guides with little "run" buttons to augment the Reference Documentation that you accidentally filed under "Guides".
I hope you'll try to be more jQuery and less Dojo. More Sinatra, less Rails. More library, less framework.
In short, I hope my next attempt at Ember will be more like the first and less like my last weekend.
[1] http://twbrandt.github.io/2013/02/11/Ember-Quick_Start_Guide...
I looked at Ember again the other day after a long abstinence and to me it has become frighteningly opaque. Even with my prior Ember-knowledge (before Router and {{outlet}} existed in their current form) I completely failed to make sense of a recent tutorial[1].
I wanted to wire the tutorial up with ember-data and add pagination (nothing too fancy), but a series of undecipherable exceptions stopped me in my tracks before I got either working.
A major problem for me was how everything in the "new" Ember is tightly coupled. No longer can I just make an ArrayController, reference it in my template and populate it with standard javascript until I'm ready to drink more of the kool-aid. Or perhaps I can, but it seems to be an anti-pattern now. None of the (few) newer tutorials does anything like that.
It seems I'm now supposed to jump in head-first. I'm supposed to understand all of Ember before using Ember.
Sadly that didn't work out for me, even despite knowing a bit of Ember already. I was constantly stopped by opaque exceptions from the "runloop" which didn't even point to a line of my code. Tracking those down is a Royal Pain In The Ass.
At one point I had enough and just wanted to drop back to "old-style" Ember (who needs a Router anyway!) but quickly gave up on that, too, when it didn't work right away and I realized I'd be completely on my own in that style anyway.
So, from my short (but second) endeavor with Ember I have to conclude that you seem to have turned the learning curve into a perfect square-wave. Every time I made a mistake (even as much as a typo) the useless error messages threw me back a mile. It took only a few of these cycles before I gave up in frustration.
I think you're on a dangerous track here. When I compare my first contact with Ember (about a year ago) with my recent experience then it feels like you're about to re-invent Sproutcore. If my memory serves me right Sproutcore was pretty awesome and powerful, but so opaque and unapproachable that nobody ended up using it.
I really hope this doesn't happen to Ember. I hope you're going to modularize it so newbies stand a chance to start small instead of being bombarded with meaningless exceptions from all directions at once. I hope you'll add narrative guides with little "run" buttons to augment the Reference Documentation that you accidentally filed under "Guides".
I hope you'll try to be more jQuery and less Dojo. More Sinatra, less Rails. More library, less framework.
In short, I hope my next attempt at Ember will be more like the first and less like my last weekend.
[1] http://twbrandt.github.io/2013/02/11/Ember-Quick_Start_Guide...
I had almost the exact same experience. I originally used Ember 0.9.5 for an app and it worked very well. When I moved to 1.0.0-pre I felt that I had to completely relearn everything.
+1 on trying to track down errors. They never point to a line of user code! It's extremely frustrating when something breaks and you have no idea why.
+1 on trying to track down errors. They never point to a line of user code! It's extremely frustrating when something breaks and you have no idea why.
We all are gonna be arrested by the Ember officers soon for this attacks.
Is my telling opinions looks like attacking for you? What is offending you here ? Being not positive?
I don't do that. It's the second comment that I posted, and I criticize many open source projects. Not only yours. This is what people do in open source world.
No need to take this personal and try to reach me because of a comment that I made on HN.
HN is the comfort area of my opinions. I can call any project as north korea or england or norway.
I don't do that. It's the second comment that I posted, and I criticize many open source projects. Not only yours. This is what people do in open source world.
No need to take this personal and try to reach me because of a comment that I made on HN.
HN is the comfort area of my opinions. I can call any project as north korea or england or norway.
Good read, I'm a sucker for those love it/hate it posts.
Still being in the process of playing around with Ember and I really want to like it, but my mine gripe is still the documentation. Take for example the linkTo helper which I wanted to use with the Twitter Bootstrap navigation. I found a few examples on how this could be done, but no API documentation for the helper? The Ember.LinkView documentation does not really help as well.
Maybe I'm blind or just too inexperienced with Ember.Js Views, but something like that really puts me off.
Still being in the process of playing around with Ember and I really want to like it, but my mine gripe is still the documentation. Take for example the linkTo helper which I wanted to use with the Twitter Bootstrap navigation. I found a few examples on how this could be done, but no API documentation for the helper? The Ember.LinkView documentation does not really help as well.
Maybe I'm blind or just too inexperienced with Ember.Js Views, but something like that really puts me off.
I really wanted to like Ember.js, but I had difficulties writing tests for my app and there isn't substantial documentation for it, which was a deal breaker for me.
This.
We're using emberjs right now as well. But the lack of test integration is a huge problem for us. We right some tests with busterjs currently, but none of these tests are unit tests and tell us what exactly went wrong — somewhere.
So not to mis-read my comment: our application works and we deployed to production, and it's being used by customers, etc.. But whenver we need to dive into an emberjs-specific issue (e.g. we had a few regressions to fix which were introduced with the RCs) it gets messy.
If anything, the lack of testing (and currently lack of ideas how to integrate any) is the number one reason why I don't want to use emberjs again any time soon.
ember-data seems fine for us. Lots of conventions to adhere to (otherwise it's no fun at all). Once you figure out the side-loading, you're fine. We had to write a custom adapter so we don't have to repeat the things they call REST on the server.
But that part is solid and seems to work. :)
We're using emberjs right now as well. But the lack of test integration is a huge problem for us. We right some tests with busterjs currently, but none of these tests are unit tests and tell us what exactly went wrong — somewhere.
So not to mis-read my comment: our application works and we deployed to production, and it's being used by customers, etc.. But whenver we need to dive into an emberjs-specific issue (e.g. we had a few regressions to fix which were introduced with the RCs) it gets messy.
If anything, the lack of testing (and currently lack of ideas how to integrate any) is the number one reason why I don't want to use emberjs again any time soon.
ember-data seems fine for us. Lots of conventions to adhere to (otherwise it's no fun at all). Once you figure out the side-loading, you're fine. We had to write a custom adapter so we don't have to repeat the things they call REST on the server.
But that part is solid and seems to work. :)
A big fraction of the Ember community uses ember-rails, and tests using standard Rails tools.
For those of us not using Rails, here's a jsFiddle that shows how to test an Ember.js application: http://jsfiddle.net/ekidd/hCsws/
This includes both unit tests (for models, views and controllers) and full integration tests (using jQuery and chai-jquery to drive the GUI). There are one or two rough edges, which are documented, and which I plan to submit bugs about soon.
For those of us not using Rails, here's a jsFiddle that shows how to test an Ember.js application: http://jsfiddle.net/ekidd/hCsws/
This includes both unit tests (for models, views and controllers) and full integration tests (using jQuery and chai-jquery to drive the GUI). There are one or two rough edges, which are documented, and which I plan to submit bugs about soon.
This is great insight, thanks.
What are some of the differences between Ember.js and AngularJS?
Browse the AngularJS source code and you'll see it littered with jsperf, they care about performance and you'll learn a lot about javascript performance.
You'll write fewer files in AngularJS since you don't need to create a file for every view and model. I'd say I write 60% less javascript.
Testing is easy, AngularJS integrates easily with Testacular, and because you never manipulate the dom directly, all your code you write is logical making writing test code straight forward.
You won't see many tutorials but when you google for specific problems you'll find many jsfiddle examples which made learning AngularJS easier than BackboneJs and EmberJS.