Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AngularJS versus Ember

eviltrout.com

Post reply on HN
Print view View original

31–40 of 163 posts

Re: AngularJS versus Ember

#31

Post by rgo »

I personally don't like either one, but at the end I'm using AngularJS because it's simpler and has a lower entry barrier, bringing several features that I desperately wanted to have in one webapp: routing, templating and a simple mvc for pushing data from the server to the client with websockets.

I have the feeling that, by choosing the simpler framework, I can better maneuver around future complexities as I better understand what sits under the hood. Ember, which seems more elaborate than Angular, tries to anticipate solutions to problems I have yet to encounter. Maybe I'll regret it later. I don't know.

The reason I don't like either, or any framework in particular, is that none seems to really make a sane toolchain out of html, css and js.

Re: AngularJS versus Ember

#32

Post by moomin »

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.

Re: AngularJS versus Ember

#33

Post by EvilTrout »

btilly wrote: post #28
EvilTrout wrote: post #23

Earlier quoted context omitted.

> In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. My question is then: why are people purposely choosing not to use the advantages of client side MVC code? All of a sudden we have access to all these awesome features of long lived applications and people are choosing patterns that d…

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 requests do go through correctly. So if you submit a spam post for example, we'll show it in the client side view right away, but once the server asynchronously replies a failure, we'll display an error message and remove it. This can be jarring in the case of a failure as you'll see something appear then go away, but the vast majority of the time it doesn't happen.

The client side interface should do what it does best - display stuff quickly and avoid server round trips as much as possible.

Re: AngularJS versus Ember

#34

Post by mbesto »

EvilTrout wrote: post #23
yajoe wrote: 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…

> In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. My question is then: why are people purposely choosing not to use the advantages of client side MVC code? All of a sudden we have access to all these awesome features of long lived applications and people are choosing patterns that d…

why are people purposely choosing not to use the advantages of client side MVC code?

You're questioning the decision making behavior of developers. Developer stereotypically like to think in black and white and therefore as developers we assume that all developers follow one uniform pattern.

To answer your question - I don't know, but this is just like asking why people like chocolate ice cream over vanilla. Here's my theory - Angular.js is "by Google" and therefore has a larger community.

Re: AngularJS versus Ember

#35

Post by edanm »

EvilTrout wrote: post #23
yajoe wrote: 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…

> In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. My question is then: why are people purposely choosing not to use the advantages of client side MVC code? All of a sudden we have access to all these awesome features of long lived applications and people are choosing patterns that d…

I don't think your view on this is correct.

Having the server contain the "single true source" is important for many reasons, most of them being the main benefits of the web in the first place - automatic backups of everything, automatic sync of everything, etc. And if you're backing up everything to the server anyway (e.g. every action requires a REST call to the server), then the server is in any case acting as the source of truth, which means it can also do some business logic processing.

That's not to say the client is "dumb" by any means, but you'll be talking to the server anyway.

Re: AngularJS versus Ember

#36

Post by vectorpush »

At that point, what was the advantage of Sinatra? You were basically running a Rails application.

I disagree. I've built many applications using both frameworks and Rails is overkill 80% of the time, especially in front-end heavy apps where most of your routes are GET/POSTing JSON data.

Re: AngularJS versus Ember

#37

Post by yajoe »

btilly wrote: post #28
EvilTrout wrote: post #23

Earlier quoted context omitted.

> In many (not all) Angular applications, the server is responsible for the model (think a Parse or other REST-style backend), and the Angular app is simply responsible for rendering it. My question is then: why are people purposely choosing not to use the advantages of client side MVC code? All of a sudden we have access to all these awesome features of long lived applications and people are choosing patterns that d…

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 seems orthogonal to 'advantages of client-side MVC.'

I wonder, though this is speculation, if this question and post are some kind of elaborate troll. EvilTrout hails from Forumwarz, which is a game that may use these techniques every day:

Forumwarz is a parody role-playing game that takes place on the Internet. In fact, Forumwarz is the Internet...in game form.

Magical dragon-faeries? Flaxen-hair'd elflords? Dank scary dungeons, reminiscent of Grandpa's basement? Kids' stuff. In Forumwarz, you can pwn trolls in ridiculous web forums...buy hacked warez from shady Russian websites...or upgrade your skills with breast implants, malt liquor and antidepressants.

Re: AngularJS versus Ember

#38

Post by edanm »

Interesting article. I don't have much Ember.js experience, but one of the web apps we recently built was built in Angular.js. We found it pretty good to use, but were seriously hampered by the lack of "best practices" and the not-too-hot documentation.

We did try to write it in Ember first, but found it much harder, both because of a much bigger lack of documentation, and because the versions weren't very stable and broke from RC to RC.

Re: AngularJS versus Ember

#39

Post by onli »

vectorpush wrote: post #36

At that point, what was the advantage of Sinatra? You were basically running a Rails application. I disagree. I've built many applications using both frameworks and Rails is overkill 80% of the time, especially in front-end heavy apps where most of your routes are GET/POSTing JSON data.

Note the "At that point". The author claims that if you use sinatra and install ActiveRecord, and basically everything else that defines Rails, you are just running Rails without running Rails. He is right.

I like to write my own SQL-Queries, so Sinatra is the better choice. But if you'd want to use an ORM, why not directly use Rails?

Re: AngularJS versus Ember

#40

Post by EvilTrout »

ldn_tech_exec1 wrote: post #29

This is a typical reaction from someone who hasn't used AngularJS to build a complex web app. I would strongly suggest you check out our boilerplate for building complex web apps with AngularJS, which uses Backbone for models and AngularJS for UI and data binding. http://brandid.github.io/parse-angular-demo/ "In AngularJS, every time you visit a route, it passes an idand has to resolve it in your controllers." - not…

You can't possibly argue that using Backbone for models is idomatic AngularJS.

If you're arguing that with a bunch of extra code on top of AngularJS it does what Ember does out of the box, that was kind of my point.

Post reply on HN