Live data from Hacker News

AngularJS versus Ember

eviltrout.com

131–140 of 163 posts

Re: AngularJS versus Ember

#131
post #93

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…

What problems did you encounter with dirty checking?

The way AngularJS works is that it allows you to use plain ol' JS objects all over the code and allows you to implicitly/explicitly set-up "watches" on these JS objects. Whenever the value of the object changes, your app is given a chance to react to it. When you use these objects in your view, the "reaction" is implicit, i.e. the view gets automagically updated.

However, the process of checking whether JS objects have changed, is not very pretty. AngularJS maintains a copy of every object in the "scope". After every "digest cycle", Angular compares the copy of each object with the previous known state/value and figures out what changed. (I'm sure internally they're using really tight loops & optimized code to make this fast).

A "digest cycle" is triggered after every event that may possibley change the state/value of the tracked JS objects. Eg. a keypress, an HTTP event, a click, etc.

When you have several-thousand bindings, each digest cycle gets computationally very intensive and the app starts to feel sluggish. Typing a key in a form-field and waiting for it to appear on the screen, can also lag. Please note: this happens if you have several-thousand bindings on one page -- something that is actively discouraged in the Angular world.

In my case, I was building a dashboard app, where the nature of the app required me to show several thousand data-points with the option of "zooming-in" or "zooming-out" from data points (not in the visual sense).

Later, I realized that this limitation is easily overcome if you stop using the implicit two-way data bindings provided by Angular for such cases. If you know that those JS objects aren't really going to change with every digest cycle, it's best to not use {{ var }} to display them in your views and come-up with a custom directive that does NOT set-up a watcher on the variable. The downside is that you have to manually update your views whenever the underlying data does actually change -- not very different from how EmberJS does it.

Re: AngularJS versus Ember

#132
post #76
post #13

As a gentle reminder, Fred Brooks said "there are no silver bullets" in software ( http://en.wikipedia.org/wiki/No_Silver_Bullet ). Even without knowing the details of this article, I believe it's unlikely that "not even close" is at all accurate. There likely are advantages, but from my experience (10k+ LOC apps on each Ember, Angular, and Backbone) no one MVC (or MV-) framework is inherently better. They all have s…

What a cop-out. I am pretty sure you prefer Angular but are just too pussy to say it. Maybe you think people will think less of you for preferring the framework that is less complex. I assumed 'not even close' would mean this guy would be siding with AngularJS. Its sad but many people have the mistaken belief that programming languages and frameworks that are harder to use are more sophisticated and therefore better.…

>> What I am sure of is that a system that is less complex and easier to use is better engineering.

I agree. I think this is what made the success of very popular libraries (such as Jquery), but also protocols like email and the web.

I've been trying very hard to use Ember on a couple small projects, and I found it very hard not to get frustrated by how difficult it is to execute some trivial tasks.

Part of the problem, I believe, is the way I learn. I usually read a quick tutorial, hack a little bit, read a bit more, hack more, read the full documentation, hack a real project (and getting into the wire of the API at this point). It's a bit oversimplified, but I believe you get the picture.

However, with Ember, it seems to me like it's hard to get started and running without having a full understanding of the full system and how everything fits together.

So yeah, in the end, maybe if you know every part of Ember and how it intrinsically work, then that's an awesome framework to work with. But for the others, like me, who learn in a more spiral-ish way, I think Ember makes it very hard to get shit done and appreciate the value of the framework.

And please, don't get me wrong, I admire programmers who can read the full documentation first.. A good analogy might be the manual (man) on Linux. I know people say RTFM all the time. But for me, it's really more about googling non-stop to get a feeling on the quickest solution for my problem.

I guess it's just a different way to learn and approaches solutions to problem. I know a couple excellent programmers who would just go reading the man and figure everything by themselves.

That being said, not sure why you're being so aggressive in your statements.. I feel you had very valid arguments but these are totally buried under this arrogance.

Re: AngularJS versus Ember

#133

Earlier quoted context omitted.

This is a pretty ridiculous conspiracy theory. (Is it a conspiracy if there's only one actor?) To spell out the question in a different way: I have an object that represents some kind of object, like a User, for example. On every page, I display the user's name. With the 'long lived object' strategy, I fetch the User on the first page load, and display it. The JS object then sticks around, and as I navigate, the same…

In Angular, there is a powerful concept called services. Services are used when you need to share data between controllers, like your example. Angular services are guaranteed to be singletons, but instead of passing references around, you use dependence injection instead. Ember is fun and kids like it, but grown ups appreciate the superior design in Angular.

Your kids vs grown ups comment is ENTIRELY uncalled for. If you can't justify something based on the merits, then you have no business going for ad hominem attacks. If you can make your point without ad hominem attacks, then you should.

FYI according to Stack Overflow, Steve is in his late 20s and has been a professional developer for several years. I'm in my mid-40s and have been a developer since the last millennium. Both of us have been on this site longer than you, and have much higher reputation here. Neither of us are kids. Assume that we can understand your actual substantive points, make them, and move on.

Re: AngularJS versus Ember

#134
post #28

Earlier quoted context omitted.

My question is then: why are people purposely choosing not to use the advantages of client side MVC code? You can't trust the client. Therefore a good part of the logic MUST be built on the server side. When you've had to build that logic once, building it again on the client side is a maintainability problem of exactly the same kind that you decry with Angular.js. Except worse, because frequently the client and serv…

I'm mostly talking about sharing data in this post. If you have a user object from the server, why would you need to retrieve it again as you navigate around? It's already been given to you from the server. Secondly, client and server interfaces are not as symmetric as you indicate. Discourse has much more validation logic on the server than the client. We generally "assume success", because the vast majority of requ…

If you have a user object from the server, why would you need to retrieve it again as you navigate around? It's already been given to you from the server.

I will never forget my first interactions with a team who took this line of argument seriously. They were an outsourced team who had been given a spec for a website. They said they were on track. Our product team went down to talk to them. The most memorable quote was their lead developer saying, "We will just have to train our users to not hit the back button." Almost as bad was, "We have no idea how to support IE." (Over half of our business was IE, and many of our users were casual browsers.)

There is a legitimate debate between rich client-side applications and keeping work on the server-side. Anyone who tells you - either way - that one approach is obviously the right thing to do simply lacks full perspective.

But personally I've been burned enough by people who want to create complex client-side interactions with serious UI mistakes that I have a certain reflexive caution about arguments for pushing everything to the client.

YMMV (and apparently does).

Re: AngularJS versus Ember

#135
post #37
post #28

Earlier quoted context omitted.

My question is then: why are people purposely choosing not to use the advantages of client side MVC code? You can't trust the client. Therefore a good part of the logic MUST be built on the server side. When you've had to build that logic once, building it again on the client side is a maintainability problem of exactly the same kind that you decry with Angular.js. Except worse, because frequently the client and serv…

Thank you for the excellent and succinct answer! > My question is then: why are people purposely choosing not to use the advantages of client side MVC code? I didn't understand this question (it seemed too obvious to me and felt like a bait to get into a broader discussion). In both Ember and Angular apps you still have a 'model' that is stored outside of the DOM, the only difference is how the model is works, which…

The question was obvious to me. The advantage of client-side code is responsiveness. Everything is loaded, there is no need to go back to the server. Better yet, you can create UIs that couldn't be created otherwise. For instance consider gmail's keyboard interface. Just hitting keys you can navigate through email, delete some, label others, choose to reply to more. Without hitting a mouse. It is a wonderful UI, but only is possible with client-side code. Which is likely to be saner if you have a good client-side MVC model.

Re: AngularJS versus Ember

#136
post #132
post #76

Earlier quoted context omitted.

What a cop-out. I am pretty sure you prefer Angular but are just too pussy to say it. Maybe you think people will think less of you for preferring the framework that is less complex. I assumed 'not even close' would mean this guy would be siding with AngularJS. Its sad but many people have the mistaken belief that programming languages and frameworks that are harder to use are more sophisticated and therefore better.…

>> What I am sure of is that a system that is less complex and easier to use is better engineering. I agree. I think this is what made the success of very popular libraries (such as Jquery), but also protocols like email and the web. I've been trying very hard to use Ember on a couple small projects, and I found it very hard not to get frustrated by how difficult it is to execute some trivial tasks. Part of the probl…

I've been trying very hard to use Ember on a couple small projects, and I found it very hard not to get frustrated by how difficult it is to execute some trivial tasks.

Funny, I felt the same way about AngularJS. I had been working for a few months with Ember. I was building a new internal tool and wanted to learn Angular but I found a lot of the concepts poorly explained in the documentation.

Re: AngularJS versus Ember

#137
post #128
post #86

The fact that Google is backing AngularJS is a nice bit of reassurance. But are any of their current apps using AngularJS in any way? I realize most of their major apps, such as GMail and documents, pre-date Angular...but they must use it, or parts of it for something prominent, right?

> The fact that Google is backing AngularJS is a nice bit of reassurance Really? google frame ? google reader ? (...) they dont give a f.. While Angular is quite complete feature wise , the UI responsiveness of a AngularJS application is not that great. At least that's my personal experience.

What do you mean? Have you ever used http://angular-ui.github.io/? These are all excellent in my experience.

Re: AngularJS versus Ember

#138

Earlier quoted context omitted.

...fair. What's your take on points #1, #2, #3 and #5?

You CAN make Angular work like Ember, but you have to add a lot of code to do what Ember encourages you to do off the bat. What you are suggesting is good practice but something that I suspect very few Angular developers do as it's not encouraged by the framework itself. If you follow the guides on the official Angular site, they're done none of the things you suggest.

Umm.. nothing in #1, #2, #3 or #5 requires any extra code.

If you're argument is about what Ember 'encourages' vs what AngularJS 'encourages', that is your opinion and not a weakness in the framework.

I think it's great you've taken some time to learn AngularJS, and I think if you dig a little deeper you will be pleasantly surprised with what you find.

Re: AngularJS versus Ember

#139
I haven't played with EmberJS too much, but read several times that debugging can get pretty nasty (the poster mentioned something about a run-loop if I remember correctly?).

Did you encounter similar issues or do you rely mostly on unit tests for debugging?

Re: AngularJS versus Ember

#140
post #132
post #76

Earlier quoted context omitted.

What a cop-out. I am pretty sure you prefer Angular but are just too pussy to say it. Maybe you think people will think less of you for preferring the framework that is less complex. I assumed 'not even close' would mean this guy would be siding with AngularJS. Its sad but many people have the mistaken belief that programming languages and frameworks that are harder to use are more sophisticated and therefore better.…

>> What I am sure of is that a system that is less complex and easier to use is better engineering. I agree. I think this is what made the success of very popular libraries (such as Jquery), but also protocols like email and the web. I've been trying very hard to use Ember on a couple small projects, and I found it very hard not to get frustrated by how difficult it is to execute some trivial tasks. Part of the probl…

I was being aggressive because I feel strongly that people like this man are supporting and being wishy-washy about Ember simply because they are afraid that they will look bad if they admit that Ember was difficult to use.

And I forgot that language like that simply was not accepted on this website unfortunately. However, I believe that the aggressiveness was warranted because there are quite a large number of organizations losing a lot of money on the basis of a poorly informed engineering decision.

Next time I will hopefully remember to be more political and use acceptable language when I feel so strongly about something.

Thank you for your honest comment.

Post reply on HN