21–30 of 36 posts
... 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.
- 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 h…
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 complain…
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.
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.
- 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 h…
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 complain…
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...
Earlier quoted context omitted.
Google Places and Google DoubleClick use it (larger than discourse will ever be :).
Sure, but neither is open source.
Earlier quoted context omitted.
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.
Plus it is nice to see the little tricks that are done to make the code more readable or improve the overall design.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
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…
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.
The convenience of having a 1:1 companion OSS package on the server-side to hook up with an ember-app is great.
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?