Live data from Hacker News

AngularJS versus Ember

eviltrout.com

51–60 of 163 posts

Re: AngularJS versus Ember

#51
post #35

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…

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…

Any time you are showing a user a representation of data, be it in a web page or client side rendered template, it is potentially out of sync.

The only atomic source is probably your database, and from the millisecond that you query it, it could be stale.

It is not the same thing as the class of bug I am explaining where you have multiple copies of the same object in memory leading to confusing state errors.

There are some objects that you just don't need to refresh constantly. In ember there's nothing stopping you from calling refresh when you enter a route, it gives you the object and leaves it up to you. If you think it's important to refresh it as the route changes, by all means do so!

Re: AngularJS versus Ember

#52

> Ultimately, I think you should examine your application’s goals. Do you want to build something that pushes the boundaries of what people expect from the web? Is your application going to be super simple, or do you want to add powerful features and maintain it well over time? Yes, thats why I choose Angular over Ember every time. EvilTrout obviously wants to see Ember succeed, I would to if I spent so much time wri…

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.

Re: AngularJS versus Ember

#53
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…

What you're saying is interesting - I just want to make sure I'm understanding correctly.

So, the app functions on its own in the client, and only checks-in periodically with the server to see if anything is not valid?

(As opposed to sending a request to the server for every change.)

So for example: when I submit a comment, it doesn't go to the server right away. It immediately displays successfully in my browser, and could be submitted to the server 2 seconds from now, or something?

Re: AngularJS versus Ember

#54

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.

...fair.

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

Re: AngularJS versus Ember

#55
post #44
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…

> 10k+ apps on each Ember, Angular, and Backbone Have you written about them? I haven't come across anyone who has enough experience with more than one of them to comment broadly.

Am I missing something? 10k apps on each, so 30k apps... meaning "30 thousand applications"? If those three libraries have each been around for ~10 years (have they?), that's like 3 apps on each per day. That seems like an awful lot...

Re: AngularJS versus Ember

#56
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.

If you don't have much experience, how do you know they're too complicated?

Re: AngularJS versus Ember

#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't my intention to use two different frameworks, but we started the Ember one when Angular was really just starting to gain traction. A few months later on the advice of a friend, I thought I'd give it a shot.

The biggest problem between the two isn't really anything about the frameworks. They're very different beasts, and they both have their strengths and weaknesses. The noticable difference out the gate is the documentation. Ember is a mess. It's older, and things keep changing, so documentation gets out of date. Also most of the tutorials and cookbooks online are all for older versions, and that can be very confusing when you're starting out.

I personally find Ember's patterns to be confusing at times, but I also have this hunch that there should be a point I get it and it will all make sense. For example, there's controller, which should manage representations of your models for UIs, and there's views, which manage events in your templates. Right now that's where I always get lost. I have no idea where to put anything. When you click on a button, is it the controller or the view that handles it? The answer appears to be "yes, depending...".

I think this confusion comes from Ember's philosophy: it's trying to be a desktop-like UI kit for web development. That works 80% of the time, and the other 20% introduces "fudge factors" like this.get and this.set. There's also too much magic happening in Ember, which makes it difficult to learn. Things happen based on the names of objects and templates, and then you hook into this magic to override certain steps. Since I don't spend all my time in Ember, when I go back to look at code I've written previously, I'm often lost at where something was updated or triggered.

Angular on the other hand is very straightforward as to where things go. For example, people mention directives. You start off by hooking events and values into your templates in the controllers. After a while, you'll start migrating that code out of controllers into directives, so you can reuse it in many different templates. As your application grows, your templates become filled with reusable directives and your controllers get simpler and simpler. It's a very nice philosophy.

Also, Angular doesn't buck the web workflow as much as Ember. Like I said, Ember is trying to be a desktop-like UI for the web, while Angular feels more like you're just transferring your older, do-it-on-the-server templates to JavaScript. This gives you a lot more flexibility with UIs and animation, but it doesn't completely break the browser, which is why I think Angular doesn't have as many edge cases to deal with as Ember.

On the downside, Angular has this initial easy learning curve, which gets steep later. The basic stuff is easy, and you'll have a web site up in a day or so, vs. a couple weeks to figure out the basics of Ember and get something meaningful online with that. However, Angular quickly gets complicated when you want to dive into complex directives and some of the more esoteric aspects of the framework.

For support, I haven't been hugely happy with Angular. There are more people using it, and there are more blog articles and tutorials out there on it, as well as lots of plugins to add features (like websockets and local storage support). That's great. But the community itself doesn't feel as helpful. Most of my posts to the mailing list went unanswered. I haven't tried Angular's IRC, so maybe that's where I should be.

The Ember folks on IRC are hugely helpful and very friendly. There is a bit of "our way is the best way", but I think that comes from understanding Ember and everything you can do with it and knowing it's probably a more powerful framework in the end. However, the discussion forums are horrible. They're using Discourse, which was written in Ember, and it's nearly impossible to find answers to anything previously posted. Because it's in Ember it's all JavaScript, so nothing is indexed on Google, and the built-in search is awful.

I would recommend if you're starting out and you don't have super, super strong JavaScript skills, you should go with Angular. You'll feel more productive quickly. Ember will be frustrating. If you're an advanced JS developer and you've built desktop UIs, maybe Ember is more your cup fo tea.

Also take a look at http://yeoman.io. It's by far the easiest way to get an Angular "build" system going. Yeoman supports Ember too, but like everything else with Ember, it's a bit tricky (for example, updates to the templates will crash grunt server if there's an error).

Re: AngularJS versus Ember

#58

> Ultimately, I think you should examine your application’s goals. Do you want to build something that pushes the boundaries of what people expect from the web? Is your application going to be super simple, or do you want to add powerful features and maintain it well over time? Yes, thats why I choose Angular over Ember every time. EvilTrout obviously wants to see Ember succeed, I would to if I spent so much time wri…

> EvilTrout obviously wants to see Ember succeed, I would to if I spent so much time writing a big Ember app and see it loosing out in the Javascript framework wars.

If I chose my languages or frameworks based on what was the most popular, I'd be using Java or PHP, not Ruby and Javascript.

Additionally, Object.Observe benefits Ember just as much as it does Angular.

Re: AngularJS versus Ember

#59
post #55
post #44

Earlier quoted context omitted.

> 10k+ apps on each Ember, Angular, and Backbone Have you written about them? I haven't come across anyone who has enough experience with more than one of them to comment broadly.

Am I missing something? 10k apps on each, so 30k apps... meaning "30 thousand applications"? If those three libraries have each been around for ~10 years (have they?), that's like 3 apps on each per day . That seems like an awful lot...

I read it as 10KLOC.

Re: AngularJS versus Ember

#60
post #2

Coming from someone that has used neither framework, I like the write up w/ examples. However, I wasn't convinced that "it's not even close" so maybe a bad title choice.

Would it be on the top of HN if it had a more reasonable title? Is the audience just as complicit as the author in trending towards flamebait?

I was interested in the Ember vs Angular comparison regardless of the title. Also, I've enjoyed EvilTrout blogs in the past.
Post reply on HN