- 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 ?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?
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 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.
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.
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...
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. :)
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.
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.
I've used both Angular and Ember extensively, and AngularJS trounces on EmberJS in both performance and ease of use.
If you don't mind answering here, what made you go so strongly with ember over marionette?
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.
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.