Live data from Hacker News

AngularJS versus Ember

eviltrout.com

111–120 of 163 posts

Re: AngularJS versus Ember

#111

Earlier quoted context omitted.

Yehuda Katz is on TC39, I'm pretty sure that Ember will be well-posed to take advantage of innovations in JavaScript as they happen. You didn't really rebut anything in his post, just asserted that Angular is 'forward-looking.' EvilTrout makes very specific claims, as someone quite familiar with Angular, you're well-poised to give a real answer, not just chest-puffing.

This may be true, but still Ember forces you to use uses get() and set() while in angular you can just use plain old javascript objects. Basically Angular does dirty checking to keep track of changes while Ember knows of your changes because you are using get() and set()(1). In my opinion this sucks. I love being able to use plain old javascript objects in Angular. Not having to extend every object with ember.observa…

While Object.observe will be a welcome change, that basically means that your app can never be as performant as possible due to the design of the framework that you use for browsers that don't support Object.observe (dirty checking is NOT optimal). Using .get and .set so that all operations happen in a run loop seems like a small price to pay.

While I'm with you and love being able to write my own simple classes and POJOs, ultimately I'll value being able to support users who won't or can't upgrade their browsers.

Re: AngularJS versus Ember

#113

One is 272kb and the other is 78kb. This should be noted at the beginning of any article making such a comparison.

Seriously? I mean, _really_? 200k? This isn't 1998 any more. If it was 2MB, you might have something resembling a point.

Re: AngularJS versus Ember

#114
post #57

Is there anyone out there who has written non-trivial applications (i.e. a _lot more_ than the quintessential todo app) in both, AngularJS & EmberJS and can offer a non-biased opinion? Some time ago, I started off with AngularJS, I liked what I saw (except the dirty checking part) and started building my product / startup with it. I don't have the time to stop all dev and experiment with EmberJS, but would like to kn…

Let me say to start that I'm no JavaScript expert. I don't write JavaScript full-time (we're a small company; I don't do anything "full"-time), though I do like the language and what it can do for web-based client-side programming. I've written non-trivial apps for the same backend, first in Ember, then in Angular. The Ember app is the consumer-driven frontend, while Angular runs the administrative interface. It wasn…

The Ember generators for yeoman are a bit out of whack. For now, I'd suggest you try out Ryan Florence's ember-tools (https://github.com/rpflorence/ember-tools), which can do many of the same code generation type things yeoman can do (we don't handle SASS/etc yet though; there is talk of generating ember-tools in with yeoman some day soon).

Re: AngularJS versus Ember

#115
post #95

Earlier quoted context omitted.

Clojure has most of the semantics you're used to in other languages. http://clojuredocs.org/clojure_core/clojure.core/let (let [username "prollyignored" karma 7] (println username "has" karma "karma points.")) ; prollyignored has 7 karma points. http://clojuredocs.org/clojure_core/1.2.0/clojure.core/loop (loop [n 0] (when ( 0123456789 http://clojuredocs.org/clojure_core/clojure.core/for (for [x [0 1 2 3 4 5] :let [y…

Aha ! Now in, while m+i is less than the length of S, do: if W[i] = S[m + i], if i equals the (length of W)-1, return m let i ← i + 1 .... How would I implement the `return m` part ?

It's pretty much the same as this:

    (loop [n 0]
      (if (= n 10)
        n                 ; true case: return n
        (recur (inc n)))) ; false case: loop with n++

    ;=> 10

Re: AngularJS versus Ember

#116

Earlier quoted context omitted.

Yehuda Katz is on TC39, I'm pretty sure that Ember will be well-posed to take advantage of innovations in JavaScript as they happen. You didn't really rebut anything in his post, just asserted that Angular is 'forward-looking.' EvilTrout makes very specific claims, as someone quite familiar with Angular, you're well-poised to give a real answer, not just chest-puffing.

This may be true, but still Ember forces you to use uses get() and set() while in angular you can just use plain old javascript objects. Basically Angular does dirty checking to keep track of changes while Ember knows of your changes because you are using get() and set()(1). In my opinion this sucks. I love being able to use plain old javascript objects in Angular. Not having to extend every object with ember.observa…

Actually, it doesn't "force" you to use get/set. You can just POJOs just fine w/ Ember, but you won't get property observation or unknownProperty support.

I also question your assumption that Object.observe will be as fast as Ember's observation system. I wouldn't be surprised if it was several times slower.

Object.observe also doesn't support array observation, which is something we support in Ember.

Re: AngularJS versus Ember

#117
post #90

A higher level framework makes you more productive but a single bug can get you stuck for hours, days or weeks. A lower level framework doesn't make you as much productive but you have a better mental model of what is going on and bugs get solved quickly. Keep in mind when choosing a framework.

This is an important point, but I see it differently. Want to become a truly great developer? A real one-percenter? Get in the habit of diving into other people's big, scary codebases when you hit a bug. Learn how things work, learn why they're breaking, and fix it. Who has time for that? That's part of my point. Many people won't invest in their own capabilities in this way. But once you do, you get dramatically fas…

I've been referring to the Django source nearly as much as the docs lately, and it's actually very pleasant to "unmask the magician", as it were.

Re: AngularJS versus Ember

#118
I can't speak much to AngularJS, I've never used it in a project and only spent a few hours playing with the demos. Even if I had, making single one line knocks at either framework is not going to convince anyone of the others value.

That said, I have a pretty large Ember app, I adopted Ember for my app when it was known as SproutCore 2 (before AngularJS was known). Both my app and Ember have gone through a very long, very painful maturing process. But it's finally in a really good place. Ember's patterns are the result of months (years really) of spinning, cycling, iterating and collaborating with developers using the framework. Seeing the process of evolution and open collaboration unfold in the community is just as exciting and thrilling as the state of the framework it's self.

My advice is to try them both and decide for yourself. The only thing I'd ask is please don't assume one is easier or better than the other with only a few hours of use. If you're planning to build a sizable app, please take the time to evaluate them both thoroughly and decide what's best for you.

Re: AngularJS versus Ember

#119
post #97
post #32

I haven't much experience of either framework, but seriously, they're both way too complicated for what they do. Knockout is about the right level of complexity for the problem space, but Angular has the right engineering. But what does it need an IoC implementation for? I'm happy to accept the problem is hard, but I doubt it's so complex it's impossible to decompose.

I use Knockout, too, and it has served me well. All the computed methods and model change detection are trivial in Knockout.

Knockout is only about data binding as far as I know, whereas Angular and Ember are full stack SPA frameworks. Also, while I'm a knockout fan, dealing with observables is not ideal when compared with plain old javascript objects that Angular allows you to bind with.

Re: AngularJS versus Ember

#120

Earlier quoted context omitted.

THIS! This is exactly what I was trying to figure out how to type. Right now ember is especially hard to learn since it is constantly changing and ember-data isn't done yet. As a result there are 5 different ways of doing something and when you get stuck you finally solve it by finding someone else who had the same problem and that is when you learn that the tutorial was for rc3, not rc5. But the huge problem is that…

> constantly changing 1.0.0.rc1 was released on February 15, and (to my knowledge) there has been _one_ backwards-incompatible change since then. > ember-data isn't done yet You don't need to use ember-data: http://eviltrout.com/2013/03/23/ember-without-data.html

It is painful to try to learn something when different articles all say how to do a hello world differently. It doesn't matter the reasons why, it is just harder. I get it now, but don't make it like it is easy for someone to learn.
Post reply on HN