AngularJS versus Ember(eviltrout.com)
eviltrout.com
AngularJS versus Ember
http://eviltrout.com/2013/06/15/ember-vs-angular-its-not-even-close.html
162 comments
> 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 don't embrace it.
> That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use
I do say in the end that there are viable workarounds. It's an issue of maintainability and consistency. Ember embraces patterns for ambitious applications.
If it works for you I'm glad, I just think we should open ourselves up more to the advantages of rich client side apps and not hold back!
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 don't embrace it.
> That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use
I do say in the end that there are viable workarounds. It's an issue of maintainability and consistency. Ember embraces patterns for ambitious applications.
If it works for you I'm glad, I just think we should open ourselves up more to the advantages of rich client side apps and not hold back!
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 server are different languages and so are harder to keep in sync.
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 server are different languages and so are harder to keep in sync.
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.
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.
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?
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?
It's not as periodic as that.
Ajax by definition is asynchronous. When you submit a post, the Ajax request is fired right away. But we don't wait for a response before showing the post in the stream (success case). We show it right away.
Then WHEN we receive a reply, we check the error status and if it was success, do nothing. If it failed, we revert the UI to the previous state. This is really easy with a client side MVC framework.
The downside is the failure case can be disorienting, as something will appear and then disappear. But the vast majority of requests, say, 99% never fail so the user so we optimize for that case.
Ajax by definition is asynchronous. When you submit a post, the Ajax request is fired right away. But we don't wait for a response before showing the post in the stream (success case). We show it right away.
Then WHEN we receive a reply, we check the error status and if it was success, do nothing. If it failed, we revert the UI to the previous state. This is really easy with a client side MVC framework.
The downside is the failure case can be disorienting, as something will appear and then disappear. But the vast majority of requests, say, 99% never fail so the user so we optimize for that case.
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).
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).
This is exactly the kind of reason frameworks were created; breaking the back button totally sucks. By handling this process for you, the framework can make it much easier to have the behavior you'd expect.
By having a framework "handle this" you teach novice devs that they don't have to think about it and then they do stuff the framework can't fix and wonder why the framework is broken!
In Angular if you need to share global state between controllers you can just create a service that will fetch the object once and then cache it. I would like it if service/provider/factory were a more unified concept as they can be confusing when starting out. However, once you understand how to use them they are straight forward to use and provide a nice way to share code between controllers.
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.
> 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.
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 User object in memory is used on each 'page' to put in the username. No difference.
With the 'mostly server side' strategy, I fetch the User on the first page load and display it. When I navigate around, I then re-fetch the User on every single 'page'.
I am not familiar enough with the details of Angular (and, frankly, Ember, which I'm still new to) to tell you if this maps 1-1 with the way that they work, but it's the two different approaches in a general sense.
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 User object in memory is used on each 'page' to put in the username. No difference.
With the 'mostly server side' strategy, I fetch the User on the first page load and display it. When I navigate around, I then re-fetch the User on every single 'page'.
I am not familiar enough with the details of Angular (and, frankly, Ember, which I'm still new to) to tell you if this maps 1-1 with the way that they work, but it's the two different approaches in a general sense.
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.
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.
Your 'kids vs grown ups' comment just makes me want to learn Angular that much less.
(I will look into exactly what Services are, thank you.)
(I will look into exactly what Services are, thank you.)
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.
You could use NodeJS as your server-side platform and re-use a lot of the same logic bits...
I've worked with both frameworks. You're too quick to judge Angular. Secondly, I suggest you watch Angular 1.2 & beyond:
http://www.youtube.com/watch?v=W13qDdJDHp8&feature=c4-overvi...
For instance, scope will be optional in the future, not only that but the roadmap for Angular Next is very impressive (see around the 44:40 mark).
---
Angular is accelerating; it has more stars/watchers/staff than Ember. Embers' core devs barely have time for pull requests. To the best of my knowledge Ember has no full-time staffers. Angular is fully staffed by Google. Both take contribution from the community.
http://www.youtube.com/watch?v=W13qDdJDHp8&feature=c4-overvi...
For instance, scope will be optional in the future, not only that but the roadmap for Angular Next is very impressive (see around the 44:40 mark).
---
Angular is accelerating; it has more stars/watchers/staff than Ember. Embers' core devs barely have time for pull requests. To the best of my knowledge Ember has no full-time staffers. Angular is fully staffed by Google. Both take contribution from the community.
Angular wasn't invented at Google (it was invented by Angular company, which got acqui-hired by Google) and some Google staffers have mentioned Angular breaks a few documented Google rules for creating Javascript MVC frameworks.
I suspect Angular's popularity has more to do with a logo than features.
- The unnecessary new module system is a massive waste of time and obviously doesn't play well with others
- It's the first MVC framework I've used that can't properly loop over an array or primitives (the partials for the primitives be displayed,but changes to them won't flow back to the parent as Angular can't make a $parent (IIRC) key.
Also: 'NG' just fucking doesn't stand for Angular.
I suspect Angular's popularity has more to do with a logo than features.
- The unnecessary new module system is a massive waste of time and obviously doesn't play well with others
- It's the first MVC framework I've used that can't properly loop over an array or primitives (the partials for the primitives be displayed,but changes to them won't flow back to the parent as Angular can't make a $parent (IIRC) key.
Also: 'NG' just fucking doesn't stand for Angular.
Angular went open source before it turned into 'official google'.
http://en.wikipedia.org/wiki/AngularJS#Development_history
http://en.wikipedia.org/wiki/AngularJS#Development_history
Yep. My issue is that it's 'by Google' according to the logo. As you mentioned, it was designed by GetAngular.
Promoting it as 'by Google' is misleading.
Promoting it as 'by Google' is misleading.
According to angular's FAQ:
> Q: Why is this project called "AngularJS"? Why is the namespace called "ng"?
> A: Because HTML has Angular brackets and "ng" sounds like "Angular".
http://docs.angularjs.org/misc/faq
sigh
> Q: Why is this project called "AngularJS"? Why is the namespace called "ng"?
> A: Because HTML has Angular brackets and "ng" sounds like "Angular".
http://docs.angularjs.org/misc/faq
sigh
Yes, I (would have thought quite obviously, but perhaps not) know that.
The fact there's an FAQ question on an abbreviation should tell you something.
Thanks for the sigh though, and the substantive response to the points raised in the body of my post, it really adds a lot.
The fact there's an FAQ question on an abbreviation should tell you something.
Thanks for the sigh though, and the substantive response to the points raised in the body of my post, it really adds a lot.
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.
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.
That's not a valid assumption for truly ambitious web applications.
For example, I have an Ember application running on both mobile and desktop that gives the user complete read/write access to their data even when the network goes down. When they get a connection again, everything synchronizes automatically.
This is an important requirement for us, and once we implemented it we realized that is has very useful side benefits as well: the entire application feels dramatically faster, because you're very rarely waiting for the server. Changes take effect instantly.
It also makes our backend infrastructure simpler. First, because we can take it down for a bit and nobody will even notice. Second, because once you have a true distributed synchronization algorithm running, adding another redundant server is no more complicated than adding another client. They're actually quite symmetric in many respects, running the same codebase.
For example, I have an Ember application running on both mobile and desktop that gives the user complete read/write access to their data even when the network goes down. When they get a connection again, everything synchronizes automatically.
This is an important requirement for us, and once we implemented it we realized that is has very useful side benefits as well: the entire application feels dramatically faster, because you're very rarely waiting for the server. Changes take effect instantly.
It also makes our backend infrastructure simpler. First, because we can take it down for a bit and nobody will even notice. Second, because once you have a true distributed synchronization algorithm running, adding another redundant server is no more complicated than adding another client. They're actually quite symmetric in many respects, running the same codebase.
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!
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!
What we're really talking about here is an advanced form of caching. "Long lived objects" doesn't mean you do no validation, or that you don't hit the server to save something permanently.
The point is that due to the difference in architecture between an SPA and a more traditional all-server-side app, there's no reason to hit the server every single time. Isn't this the advantage of writing so much JavaScript? If you're going to make a bunch of requests on every page, why not just ditch the JavaScript and write it all server side?
The point is that due to the difference in architecture between an SPA and a more traditional all-server-side app, there's no reason to hit the server every single time. Isn't this the advantage of writing so much JavaScript? If you're going to make a bunch of requests on every page, why not just ditch the JavaScript and write it all server side?
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.
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.
> 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.
Have you written about them? I haven't come across anyone who has enough experience with more than one of them to comment broadly.
I'm definitely not qualified to provide an opinion. My short summary:
Backbone was tiring for me and my partner with all the files and code to set up each view. I also never liked putting templates in script tags -- it just felt dirty. We see Ember and Angular as similar (how do you pick which language you like?), and we only picked one for atheistic reasons (data-binding in HTML) in our current project. Since I haven't written the same app in each framework, it would be unfair to comment further.
Backbone was tiring for me and my partner with all the files and code to set up each view. I also never liked putting templates in script tags -- it just felt dirty. We see Ember and Angular as similar (how do you pick which language you like?), and we only picked one for atheistic reasons (data-binding in HTML) in our current project. Since I haven't written the same app in each framework, it would be unfair to comment further.
I'm confused about what sense Ember doesn't have data binding in HTML. How is this not data binding in HTML:
<div {{bindAttr class="highlighted:paid"}}>{{name}}</div>
I also find data-binding in HTML to be aesthetically pleasing. We use knockout, which has served us well but feels like we'd rather be an Angular.
What are you working on? I did a quick trawl of your history but didn't see any mention.
What are you working on? I did a quick trawl of your history but didn't see any mention.
(this post is crazy to watch -- so many strong opinions!)
If you're like me, then you'd want to see some examples of craftsmanship to weigh the value of different opinions. Unfortunately, I can't provide links to these example works due to a very strict NDA (we did the work on behalf of a couple brand names, and ironically they wanted privacy). The projects definitely fell into the category of 'shit crud app' :)
If you're like me, then you'd want to see some examples of craftsmanship to weigh the value of different opinions. Unfortunately, I can't provide links to these example works due to a very strict NDA (we did the work on behalf of a couple brand names, and ironically they wanted privacy). The projects definitely fell into the category of 'shit crud app' :)
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 forgot to write LOC after 10k; my point was that each app took longer than a weekend to write and I had to deal with at least one wart in each framework.
Ah, that makes much more sense! Thanks for the informed insights.
(To the people downvoting my previous comment: wtf?! Politely questioning someone's stated experience when it borders on absurdity is perfectly valid. And the GP provided a perfectly reasonable explanation: s/10k+ apps/10k+ loc apps/.)
(To the people downvoting my previous comment: wtf?! Politely questioning someone's stated experience when it borders on absurdity is perfectly valid. And the GP provided a perfectly reasonable explanation: s/10k+ apps/10k+ loc apps/.)
I read it as 10KLOC.
thanks for the mention of restangular, i didn't know about it until now.
https://github.com/mgonto/restangular
https://github.com/mgonto/restangular
This is something else.
I'd like to call it, "the appeal to the bold new future fallacy, with sensationalist titles"
<template>
Is X trying to change the paradigm ? No. Use Y.
Is Y trying to change the paradigm ? Yes. Use Y
</template>
Some dumb geeks just can't handle "worse is better" !
I'd like to call it, "the appeal to the bold new future fallacy, with sensationalist titles"
<template>
Is X trying to change the paradigm ? No. Use Y.
Is Y trying to change the paradigm ? Yes. Use Y
</template>
Some dumb geeks just can't handle "worse is better" !
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 think is that deep down people are afraid that others will think they weren't smart enough to figure out the more complex and difficult to use thing.
What I am sure of is that a system that is less complex and easier to use is better engineering.
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 think is that deep down people are afraid that others will think they weren't smart enough to figure out the more complex and difficult to use thing.
What I am sure of is that a system that is less complex and easier to use is better engineering.
Please turn down the dial a little bit. Calling a stranger a pussy may be the norm on the internet at large, but it's not appropriate here.
>> 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.
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.
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.
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.
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.
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.
Dude, you don't know anything about me and I don't know anything about you. One of the reasons for my original post was to prevent this thread from turning into an unnecessary flame war.
I would ask that you consider, for a moment, that it is possible for someone to hold simultaneous opposing views. I also would ask for you to go back and re-read Brooks' essay about accidental and essential complexity. I believe that the choice of framework and the difficulties associated with a specific framework fall into the accidental complexity category. If after reading the essay you believe the same, then you would conclude that both choices in this thread have similar inherent merits. Such an opinion wouldn't be wishy-washy or a cop-out, but, perhaps, closer to a deeper understanding of our craft.
Every MVC framework I've used in production (Catalyst, ASP MVC, Cake, Spring, Rails, Rails with Spine, this batch of JavaScript frameworks) has had warts and frustrating moments just as all of the web languages have frustrations (Perl with maintainability, PHP with amateur hour inconsistencies, Python with tab/spaces that different IDEs will autocorrect, Rails with too much 'magic' that leads to serious bugs, Java with too much verbosity, Spring with too much XML, C# with too expensive support, Django with too many required add-on libraries, Rust with too few libraries, Go with too new, etc, etc).
Ember was not any harder than Angular to get going (ever try to untangle the service/factory/module/controller mess?). And I have no shame in admitting that I took at least three full workdays to learn each. At the end of the day the two frameworks were just different, in the same way that writing an app using JavaScript MVC is just different than how I used to write ASP MVC apps. The reason I use the newer stuff is because the newer stuff is more fun, I can be more responsive, and (in some cases) I can host an entire webapp on s3 (managing servers can be a headache). Despite some clear advantages, none of these different frameworks is inherently better. They all have tradeoffs. If Microsoft were to come to me and (with a large check) demand that I use ASP MVC, I would do so.
My first response reading your comment is that you have less experience than I do with software engineering. That may be untrue and unfair, but rash responses are correlated with inexperience from my career. I would ask you to consider your strong, aggressive reaction as unhealthy for merit-based engineering decisions. Learning and respecting that most decisions in software are about tradeoffs and not black-and-write-strictly-better-or-worse I believe will help you in your career. Furthermore, I hope you eventually come to point where you realize many of these different languages and frameworks all look the same after a while :) It's not until we can tell a computer what we what and it figures out how that our productivity will massively improve.
I would ask that you consider, for a moment, that it is possible for someone to hold simultaneous opposing views. I also would ask for you to go back and re-read Brooks' essay about accidental and essential complexity. I believe that the choice of framework and the difficulties associated with a specific framework fall into the accidental complexity category. If after reading the essay you believe the same, then you would conclude that both choices in this thread have similar inherent merits. Such an opinion wouldn't be wishy-washy or a cop-out, but, perhaps, closer to a deeper understanding of our craft.
Every MVC framework I've used in production (Catalyst, ASP MVC, Cake, Spring, Rails, Rails with Spine, this batch of JavaScript frameworks) has had warts and frustrating moments just as all of the web languages have frustrations (Perl with maintainability, PHP with amateur hour inconsistencies, Python with tab/spaces that different IDEs will autocorrect, Rails with too much 'magic' that leads to serious bugs, Java with too much verbosity, Spring with too much XML, C# with too expensive support, Django with too many required add-on libraries, Rust with too few libraries, Go with too new, etc, etc).
Ember was not any harder than Angular to get going (ever try to untangle the service/factory/module/controller mess?). And I have no shame in admitting that I took at least three full workdays to learn each. At the end of the day the two frameworks were just different, in the same way that writing an app using JavaScript MVC is just different than how I used to write ASP MVC apps. The reason I use the newer stuff is because the newer stuff is more fun, I can be more responsive, and (in some cases) I can host an entire webapp on s3 (managing servers can be a headache). Despite some clear advantages, none of these different frameworks is inherently better. They all have tradeoffs. If Microsoft were to come to me and (with a large check) demand that I use ASP MVC, I would do so.
My first response reading your comment is that you have less experience than I do with software engineering. That may be untrue and unfair, but rash responses are correlated with inexperience from my career. I would ask you to consider your strong, aggressive reaction as unhealthy for merit-based engineering decisions. Learning and respecting that most decisions in software are about tradeoffs and not black-and-write-strictly-better-or-worse I believe will help you in your career. Furthermore, I hope you eventually come to point where you realize many of these different languages and frameworks all look the same after a while :) It's not until we can tell a computer what we what and it figures out how that our productivity will massively improve.
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 faster at it. Soon it's no big deal to jump into the guts of Rails or Ember and bend them to your will.
This is also the best way to truly be able to judge the quality and usefulness of competing projects. Instead of following the internet popularity contest, you can go to the source and see pretty quick how good the ideas really are.
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 faster at it. Soon it's no big deal to jump into the guts of Rails or Ember and bend them to your will.
This is also the best way to truly be able to judge the quality and usefulness of competing projects. Instead of following the internet popularity contest, you can go to the source and see pretty quick how good the ideas really are.
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.
As someone with commit to Rails, it also makes you have a totally different perspective on 'magic.' You end up seeing how things work, and it no longer feels magical. It's just code.
Rejecting 'magic' and just reading the code definitely helped me to get to another level of coding.
Rejecting 'magic' and just reading the code definitely helped me to get to another level of coding.
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 it took you forever to get there.
I personally think Ember will win, and it will win hard, for the professional developer market. I think it will come down to Rails : PHP :: Ember : Angular, but in the mean time angular will get a huge head start.
Once people get used to those common single bugs that keep them stuck for hours, they will be far more productive for non-trivial applications than angular devs will be.
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 it took you forever to get there.
I personally think Ember will win, and it will win hard, for the professional developer market. I think it will come down to Rails : PHP :: Ember : Angular, but in the mean time angular will get a huge head start.
Once people get used to those common single bugs that keep them stuck for hours, they will be far more productive for non-trivial applications than angular devs will be.
> 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
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.
I wish I could upvote this a million times. And yet, I repeatedly inflict this problem on myself.. I'll look at some high-level framework for X, and I'll think "oh cool, look how easy it makes everything, let me just use that for my next project". So I set up everything in 2 hours, then spend the next two days tripping over some ridiculous issue with authentication, or ORM, or some other bug.
The best success I've had for my modest web projects has been when I've used Flask and accompanying tools for server-side (I'm guessing Sinatra would work just as well), and Backbone for client-side apps. It takes a while to set up, but I understand everything that is going on, so I can easily fix problems as they occur.
The best success I've had for my modest web projects has been when I've used Flask and accompanying tools for server-side (I'm guessing Sinatra would work just as well), and Backbone for client-side apps. It takes a while to set up, but I understand everything that is going on, so I can easily fix problems as they occur.
well said ! i agree 100% !
very true
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 know if it's really better or if it's to-mah-toh vs tom-ae-toe.
I mean, how hard could it be to have an AngularJS port where the dirty-checking part is removed and Ember-style getters & setters are introduced (thus removing the only efficiency-related issue that I ever came across).
On the other hand, what's the equivalent for "directives" in EmberJS? It's singularly, the most powerful concept that I've come across in AngularJS.
Btw, AngularJS has an accepted way to define models -- inside "factories" (I know they just sound like Java-esque hell, but they're really simple, once you get to understand them).
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 know if it's really better or if it's to-mah-toh vs tom-ae-toe.
I mean, how hard could it be to have an AngularJS port where the dirty-checking part is removed and Ember-style getters & setters are introduced (thus removing the only efficiency-related issue that I ever came across).
On the other hand, what's the equivalent for "directives" in EmberJS? It's singularly, the most powerful concept that I've come across in AngularJS.
Btw, AngularJS has an accepted way to define models -- inside "factories" (I know they just sound like Java-esque hell, but they're really simple, once you get to understand them).
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).
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).
> 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.
Not true. All Discourse content has been indexed by Google since day one. Even though it's a Javascript app it's search engine friendly.
Secondly, Stack Overflow is the official place for Ember questions. The forums are for general discussion about features and other Ember related topics. Go to SO if you have a question and tag it as ember!
Not true. All Discourse content has been indexed by Google since day one. Even though it's a Javascript app it's search engine friendly.
Secondly, Stack Overflow is the official place for Ember questions. The forums are for general discussion about features and other Ember related topics. Go to SO if you have a question and tag it as ember!
How do you ensure that Google is able to index it? Do you sniff the user-agent and serve it a pre-rendered view of the discussion thread?
See https://news.ycombinator.com/item?id=5198934
> Our site is indexable by Google and it doesn't do much fancy. On certain URLs, we generate a small HTML view of the content in the <noscript> tag. You can see this by viewing source or disabling JS in your browser. It's just a simple ERB template in Rails, and uses the same object graph that we serialize via Active Model Serializers.
> Google can see it and index it, we've confirmed by searching post launch.
> As time goes on we'll probably work more on it to make the SEO even better. As you can imagine it was tough to do when we were in stealth mode ;)
Maybe we could get an update from eviltrout on that.
> Our site is indexable by Google and it doesn't do much fancy. On certain URLs, we generate a small HTML view of the content in the <noscript> tag. You can see this by viewing source or disabling JS in your browser. It's just a simple ERB template in Rails, and uses the same object graph that we serialize via Active Model Serializers.
> Google can see it and index it, we've confirmed by searching post launch.
> As time goes on we'll probably work more on it to make the SEO even better. As you can imagine it was tough to do when we were in stealth mode ;)
Maybe we could get an update from eviltrout on that.
Honestly the reason I haven't written about it is because I didn't write it! Sam did a great job, and he did it in a super short period of time.
I was leaving it to him to explain how it works :)
I was leaving it to him to explain how it works :)
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).
we've built a rock solid architecture for complex AngularJS apps here: brandid.github.io/parse-angular-demo/
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.
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.
Thank you for this explanation. I didn't quite 100% grok how it worked, and had heard there was some kind of limitation around it, but didn't know the details. This was very clear.
there is no directives in EmberJS , you could use any DOM templating engine ( =/= string template engine like Mustach ) with it I guess to get something similar to directives.
Oh please, "template-engines-thingies" don't even come close to the concept of directives
No, I wouldn't say that's something similar to directives.
You don't understand the power of directive till you actually use them.
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 true, just use nested controllers and prototypical inheritance to access the already resolved object
"AngularJS doesn’t follow this philosophy; it encourages you to throw away what you already had and find it again (probably from the server!)."
- not true, thats why $rootScope exists
"None of the examples or blogs I read through demonstrated how to reuse object instances, for example. Is that just not done in AngularJS?"
- not true, all scopes inherit from each other, javascript prototypical inheritance applies
"The problem is that the $watch function belongs to the $scope and NOT the Room."
- not true, you can put a $watch on the model if use Backbone for your models
"If you had an array of Room instances for example, you can’t watch them all without looping through them all constantly."
- not true, you can watch a collection of models, and you can do things like watch the length of the array for less processor intensive use of $watch
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 true, just use nested controllers and prototypical inheritance to access the already resolved object
"AngularJS doesn’t follow this philosophy; it encourages you to throw away what you already had and find it again (probably from the server!)."
- not true, thats why $rootScope exists
"None of the examples or blogs I read through demonstrated how to reuse object instances, for example. Is that just not done in AngularJS?"
- not true, all scopes inherit from each other, javascript prototypical inheritance applies
"The problem is that the $watch function belongs to the $scope and NOT the Room."
- not true, you can put a $watch on the model if use Backbone for your models
"If you had an array of Room instances for example, you can’t watch them all without looping through them all constantly."
- not true, you can watch a collection of models, and you can do things like watch the length of the array for less processor intensive use of $watch
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.
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?
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.
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.
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.
> 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 writing a big Ember app and see it loosing out in the Javascript framework wars.
The one thing I will say is that his point might be true about performance now, but once Object.Observe lands we won't need dirty checking anymore. It will be easy for Angular to take advantage of it but as far as I understand, Ember will require some major changes to take advantage of it.
The way I see it Angular is a forward facing framework showing you how new technologies coming like Object.Observe and Web Components could work together in a framework today.
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 writing a big Ember app and see it loosing out in the Javascript framework wars.
The one thing I will say is that his point might be true about performance now, but once Object.Observe lands we won't need dirty checking anymore. It will be easy for Angular to take advantage of it but as far as I understand, Ember will require some major changes to take advantage of it.
The way I see it Angular is a forward facing framework showing you how new technologies coming like Object.Observe and Web Components could work together in a framework today.
> 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.
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.
Wait, are you saying you choose Angular for non super simple stuff? Because I couldn't even consider it due to it's lack of nested layout and routing for anything beyond something super simple.
I was saying yes to his last question "...do you want to add powerful features and maintain it well over time?"
I find the concept of directives one of the most powerful and maintainable features of any framework I have ever used. It's probably the "killer feature" of Angular.
I find the concept of directives one of the most powerful and maintainable features of any framework I have ever used. It's probably the "killer feature" of Angular.
Is that sarcasm ?
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.
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.observable is a big win for me. When O.o lands Angular will be just as fast (if not faster) as Ember but without the need to instantiate new Ember objects, and always use get() and set() on them.
Of course Ember could change its API in the future, but Angular won't need an API change because its already using plain old javascript objects.
1: http://emberjs.com/api/classes/Ember.Observable.html
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.observable is a big win for me. When O.o lands Angular will be just as fast (if not faster) as Ember but without the need to instantiate new Ember objects, and always use get() and set() on them.
Of course Ember could change its API in the future, but Angular won't need an API change because its already using plain old javascript objects.
1: http://emberjs.com/api/classes/Ember.Observable.html
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.
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.
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.
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.
My personal experience is the opposite.
I tried Ember first. Got excited replicating the sample blog app, but got stuck trying a simple task: show the most recent post by default (see this bug: https://github.com/emberjs/ember.js/issues/1642). Later I started to trip into namespace clashes - you have to jump a few hoops if your model has a field named "content", "is_new" or "is_deleted" (http://stackoverflow.com/questions/16515900/reserved-atribut...). My general impression is: there is nice ideas here but Ember is too opinionated and has to many magic going on (hard to debug).
In contrast, Angular shows better design everywhere. No name clashes, framework methods and attributes use special prefix $ (like python uses double underscores). Everything I got stuck with ember, I was able to achieve elegantly with Angular.
I love the eviltrout but this post is lacking a bit of diligence. Angular learning curve is a little steeper but IMHO it is way more finished and well designed than Ember (Ember data has good ideas, they have a cute mascot, and it ends here).
I tried Ember first. Got excited replicating the sample blog app, but got stuck trying a simple task: show the most recent post by default (see this bug: https://github.com/emberjs/ember.js/issues/1642). Later I started to trip into namespace clashes - you have to jump a few hoops if your model has a field named "content", "is_new" or "is_deleted" (http://stackoverflow.com/questions/16515900/reserved-atribut...). My general impression is: there is nice ideas here but Ember is too opinionated and has to many magic going on (hard to debug).
In contrast, Angular shows better design everywhere. No name clashes, framework methods and attributes use special prefix $ (like python uses double underscores). Everything I got stuck with ember, I was able to achieve elegantly with Angular.
I love the eviltrout but this post is lacking a bit of diligence. Angular learning curve is a little steeper but IMHO it is way more finished and well designed than Ember (Ember data has good ideas, they have a cute mascot, and it ends here).
...At that point, what was the advantage of Sinatra? You were basically running a Rails application.
Framework simplicity is good if your application is meant to be simple. But you should be cautious when choosing simplicity if your application is ambitious and you care about supporting it for a long time.
This is what I like about Clojure. It is so composable, that simplicity doesn't come at the expense of features. The language makes composing disparate libraries so easy, that it's quite trivial to mix and match different libraries and have them all work in tandem. You don't only use what you need, but for every aspect of your application you can choose the best tool for your particular needs.
Framework simplicity is good if your application is meant to be simple. But you should be cautious when choosing simplicity if your application is ambitious and you care about supporting it for a long time.
This is what I like about Clojure. It is so composable, that simplicity doesn't come at the expense of features. The language makes composing disparate libraries so easy, that it's quite trivial to mix and match different libraries and have them all work in tandem. You don't only use what you need, but for every aspect of your application you can choose the best tool for your particular needs.
Clojure's namespace declaration:
Composition is tedious to reason about in Ruby when your only clue is a menagerie of `require`s at the top of the file. Or, more commonly, when your only clue is a Gemfile because all the gems are auto-required and omnipresent.
(ns my-app.my-namespace
(:require [some-library.some-namespace :as foo])
Composition is tedious to reason about in Ruby when your only clue is a menagerie of `require`s at the top of the file. Or, more commonly, when your only clue is a Gemfile because all the gems are auto-required and omnipresent.
An offtopic clojure question.
Today I was seeing this -- https://en.wikipedia.org/wiki/Knuth-Morris-Pratt_algorithm
How can I begin to implement it in clojure ?
Specifically, how do I _ingeneral_ deal with assignments and while loops.
In common-lisp, for example I would use the `loop` macro and defvar-sefq combo, (beginning lisper).
In ruby, = and while itself.
Today I was seeing this -- https://en.wikipedia.org/wiki/Knuth-Morris-Pratt_algorithm
How can I begin to implement it in clojure ?
Specifically, how do I _ingeneral_ deal with assignments and while loops.
In common-lisp, for example I would use the `loop` macro and defvar-sefq combo, (beginning lisper).
In ruby, = and while itself.
Clojure has most of the semantics you're used to in other languages.
http://clojuredocs.org/clojure_core/clojure.core/let
http://clojuredocs.org/clojure_core/clojure.core/let
(let [username "prollyignored"
karma 7]
(println username "has" karma "karma points."))
; prollyignored has 7 karma points.
(loop [n 0]
(when (< n 10)
(print n)
(recur (inc n))))
;=> 0123456789
(for [x [0 1 2 3 4 5]
:let [y (* x 3)]
:when (even? y)]
y)
;=> (0 6 12)
(filter even? (map #(* % 3) [0 1 2 3 4 5]))
;=> (0 6 12)
Aha !
Now in,
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
....
There is no explicit return value because the functions aren't functions: they are values, thus the result of the algorithm is bound to the value that is bound to the function.
When you write:
(defn square [x]
(def square
When you write:
(defn square [x]
(* x x))
(def square
(fn [x]
(* x x)))
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++
;=> 10I haven't used either of these frameworks but I have used Batman.js[1] which has a very similar feel as Ember.js albeit it's written using CoffeeScript.
The two issues that this author are singling out aren't exactly addressed fairly so I sort of feel inclined to defend Angular here.
Author states that one downside of AngularJS is that it doesn't conform to the Uniform Access Principle. JavaScript the language itself doesn't conform to this either. From what I can tell from my brief review of AngularJS, it tries to be as close to the implementation of JavaScript as possible. I don't see this as a bad thing but rather as a good thing. Using methods like #get and #set drove me crazy when I was using Batman.js. I understand why they exist, but why are #get and #set acceptable ways of accessing object properties but #area isn't? I think they both have the same performance implications, don't quote me on that as I'll never claim to be a JavaScript method cache expert.
His first point is that in AngularJS you don't have a true base object that your models inherit from and instead you use plain JavaScript objects. This sounds like another bonus to AngularJS in my eyes! And if it doesn't seem like a bonus to you, you can quickly create a light abstraction to serve as a Model.
All in all, having not used either of these frameworks this blog post actually makes me want to use AngularJS more than it makes me want to use Ember.
1 - http://www.batmanjs.org
The two issues that this author are singling out aren't exactly addressed fairly so I sort of feel inclined to defend Angular here.
Author states that one downside of AngularJS is that it doesn't conform to the Uniform Access Principle. JavaScript the language itself doesn't conform to this either. From what I can tell from my brief review of AngularJS, it tries to be as close to the implementation of JavaScript as possible. I don't see this as a bad thing but rather as a good thing. Using methods like #get and #set drove me crazy when I was using Batman.js. I understand why they exist, but why are #get and #set acceptable ways of accessing object properties but #area isn't? I think they both have the same performance implications, don't quote me on that as I'll never claim to be a JavaScript method cache expert.
His first point is that in AngularJS you don't have a true base object that your models inherit from and instead you use plain JavaScript objects. This sounds like another bonus to AngularJS in my eyes! And if it doesn't seem like a bonus to you, you can quickly create a light abstraction to serve as a Model.
All in all, having not used either of these frameworks this blog post actually makes me want to use AngularJS more than it makes me want to use Ember.
1 - http://www.batmanjs.org
> why are #get and #set acceptable ways of accessing object properties but #area isn't?
Because Ember only has to recalculate the area after set is called on length or width. If area is just a function, it gets recalculated every time it's called/get'ed.
Because Ember only has to recalculate the area after set is called on length or width. If area is just a function, it gets recalculated every time it's called/get'ed.
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.
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.
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'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.
I agree, Angular has the right implementation. It's just not clear that it needs quite so much stuff to solve one problem. And if it isn't solving one problem, why not?
Angular team is going to split the Core into several small modules, hopefully a data-binding module will be available to replace knockout and do nothing more ;)
So what you're saying is they're trying to knockout knockout?
If you don't have much experience, how do you know they're too complicated?
You're right, I'm shooting my mouth off here, but this is the whole problem with these huge frameworks: they're so huge that, by the time you've spent the time to evaluate them properly, your objectivity is likely to be compromised. You'll never see an even handed comparison between the two.
This isn't unique to js frameworks. There's plenty of systems like this e.g. Hibernate. At least backbone was small enough that I could seriously evaluate it in a month long project. (For the record, I didn't like it, but at least I actually can have a considered opinion on it without being well past the point of no return.)
This isn't unique to js frameworks. There's plenty of systems like this e.g. Hibernate. At least backbone was small enough that I could seriously evaluate it in a month long project. (For the record, I didn't like it, but at least I actually can have a considered opinion on it without being well past the point of no return.)
To read another side of the coin, someone who made the move from Ember to Angular : http://beust.com/weblog/2012/12/29/migrating-from-ember-js-t...
What I REALLY want is a relatively clean implementation of MV* that I can re-use all parts client and server.. NodeJS is the natural platform, but I haven't really seen much that makes reusing rendering, models and business logic client and server to a natural point. I know that there are people working on this, but I think that getting closer to a solution that can easily converge on such re-use for really dynamic apps, maybe mobile being more server-side, and desktop/tablet being more client will do very well in the end.
Agreed - server side rendering for the first time you hit a website, pushstate and client side rendering for subsequent navigation makes for some very smooth UX.
- Derby.JS is one such a full-stack framework.
- There's also Meteor but this has a little less community support.
- Eyebrow.JS is coming (there's a number of blog posts and talk videos) but I'm not sure if it's released yet.
- Derby.JS is one such a full-stack framework.
- There's also Meteor but this has a little less community support.
- Eyebrow.JS is coming (there's a number of blog posts and talk videos) but I'm not sure if it's released yet.
Choosing a heavier framework may put you in risk of 'typical', framework-related bugs that often appear. The bugs are not part of the framework, but they are part of the patterns around it.
Discourse 'private topics' leaks (1) are good examples of typical security Rails apps bugs (the result of overusing ActiveRecord). I'm not blaming Discourse, the same kind of bugs appear in other popular Rails codebases (Diaspora, Spree, Redmine).
Ember.js is very Rails-like. I didn't use Ember much, but the patterns look so similar, that it may lead to similar kind of problems as in Rails apps.
I'm not saying that we shouldn't use Rails or Ember. In fact, I'm a big fan of Rails. It's just worth being careful of not falling into the trap of overusing the framework patterns.
The frameworks are best for the infrastructure parts of the app - http, persistence. At the end, it's better that you can control your models. That's the part of Angular that I prefer over Ember - you own your Model part.
(1) http://meta.discourse.org/t/digest-mail-ignores-secure-group... http://meta.discourse.org/t/non-authenticated-users-see-priv...
Discourse 'private topics' leaks (1) are good examples of typical security Rails apps bugs (the result of overusing ActiveRecord). I'm not blaming Discourse, the same kind of bugs appear in other popular Rails codebases (Diaspora, Spree, Redmine).
Ember.js is very Rails-like. I didn't use Ember much, but the patterns look so similar, that it may lead to similar kind of problems as in Rails apps.
I'm not saying that we shouldn't use Rails or Ember. In fact, I'm a big fan of Rails. It's just worth being careful of not falling into the trap of overusing the framework patterns.
The frameworks are best for the infrastructure parts of the app - http, persistence. At the end, it's better that you can control your models. That's the part of Angular that I prefer over Ember - you own your Model part.
(1) http://meta.discourse.org/t/digest-mail-ignores-secure-group... http://meta.discourse.org/t/non-authenticated-users-see-priv...
Those private topic bugs are not the result of ActiveRecord. We added a group layer on top of existing code and missed some places where queries did not respect it.
Had we used raw SQL instead of an ORM we would have had the same issues. All projects are open to this style of bug. The correct thing to do is report, close them quickly and add tests to prevent them from happening again (which we do.)
Had we used raw SQL instead of an ORM we would have had the same issues. All projects are open to this style of bug. The correct thing to do is report, close them quickly and add tests to prevent them from happening again (which we do.)
"Those private topic bugs are not the result of ActiveRecord. We added a group layer on top of existing code and missed some places where queries did not respect it."
I've seen so many of such bugs in other apps, that I treat them as part of "ActiveRecord price".
ActiveRecord over-usage makes it very easy to miss the places, where queries need to respect new rules.
You're doing an awesome job with Discourse and the team approach to such bugs is very good - no doubts here. Thanks for your work!
I've seen so many of such bugs in other apps, that I treat them as part of "ActiveRecord price".
ActiveRecord over-usage makes it very easy to miss the places, where queries need to respect new rules.
You're doing an awesome job with Discourse and the team approach to such bugs is very good - no doubts here. Thanks for your work!
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.
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.
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.
I agree. The article is a reasonable discussion of the differences between the two frameworks from the perspective of an experienced Ember user, and does a decent job illustrating why Robin prefers Ember.
The title is argumentative and inflammatory. I think lots of people will read the title on Twitter and roll their eyes at the Ember attack-marketing machine when the article itself contains some valuable points.
The title is argumentative and inflammatory. I think lots of people will read the title on Twitter and roll their eyes at the Ember attack-marketing machine when the article itself contains some valuable points.
You are absolutely correct. I realize I'm in the minority, but I take all blog titles with a bushel of rock salt. Probably because I like to have my own little jokes when I write titles, so I try to ignore what they appear to say and use them only to decide whether to read the post, not to decide whether the post is any good.
The title doesn't actually indicate which one wins, so at least those Twitter users would have to read the first couple sentences before clicking away...
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.
I went back and forth on the title. I don't usually write sensational titles but for some reason decided to give it a try.
I think it's a very good point and I doubt I'll do it again.
I think it's a very good point and I doubt I'll do it again.
It could be worse. One fellow I know wanted to write about the benefits of significant whitespace, and thought it would be funny to call his essay "White Power." I doubt he'll try that again.
;-)
;-)
"Ember vs AngularJS: I Prefer Ember and Feel that I Have Compelling Reasons for That Preference" is a bit longer, though.
Does this boil down to:
1) The DOM is the model. JS reads elements and data attributes and builds a model from them. Then updates the model when the DOM changes. (Angular)
2) The model is loaded from JSON. Then the App builds the DOM based on the model. (Ember)
So is the question: Does it start with the DOM, or start with javascript objects?
Am I understanding this debate correctly?
1) The DOM is the model. JS reads elements and data attributes and builds a model from them. Then updates the model when the DOM changes. (Angular)
2) The model is loaded from JSON. Then the App builds the DOM based on the model. (Ember)
So is the question: Does it start with the DOM, or start with javascript objects?
Am I understanding this debate correctly?
I don't think that's the major distinction. Both store models in javascript. Some of the big things being debated are the use of getters/setters and the data lifecycle that happens when you change routes.
Can you explain what functionality Angular is missing that makes it a less complete framework than Ember? This premise keeps getting repeated here in the form of Angular being "simpler" -- if it's more simple, but offers the same functionality, I'd take that any day.
Nested views aren't in Angular. Also Angular doesn't really have models. It has data and dirty checking, but nothing a Rails dev would recognize as a model.
can agree with the fact that angular models are really left up to you, but stating that angular can't do "nested views" just shows your ignorance
You can make a much more powerful argument by showing how nested views work in angular, rather than by making strong statements with nothing to back them up.
If nested views are in the basic Angular docs, it's even more strong. Don't just say someone is ignorant, show them how to not be ignorant any longer. It helps them, and makes you seem like less of a jerk.
If nested views are in the basic Angular docs, it's even more strong. Don't just say someone is ignorant, show them how to not be ignorant any longer. It helps them, and makes you seem like less of a jerk.
I know it's really not the point on the article, but I wanted to share a quick and dirty solution for a common problem, especially this:
>> If you were using jQuery to do this, you’d likely bind a function to the click event on each row. When fired, your function would change the CSS class of the row to highlight it.
>> You can’t stop there, though. Your function also has to remove the CSS class from any other rows that were previously selected. That’s a little crazy if you think about it! Changing which item is selected means we have to know everywhere that it’s been represented in our UI.
>> If you were using jQuery to do this, you’d likely bind a function to the click event on each row. When fired, your function would change the CSS class of the row to highlight it.
>> You can’t stop there, though. Your function also has to remove the CSS class from any other rows that were previously selected. That’s a little crazy if you think about it! Changing which item is selected means we have to know everywhere that it’s been represented in our UI.
An easy way is just to do:
$('<all-row-selector..>').each(<unselect>)
.find('<selected-row>').each(<select>)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.
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.
> I believe it's unlikely that "not even close" is at all accurate.
Especially since the opening argument of the author is that AngularJS is gaining momentum because "it is simpler".
My personal experience is that when I ported my application from Ember to Angular, my code base (~5,000 lines) get simplified considerably. Based on what I've been reading, I'm not the only one making these observations.
My main beef with Ember was not about complexity or simplicity, just that it's not as powerful as AngularJS and it also covers only a small part of what AngularJS gives me out of the box (especially server side includes).
Especially since the opening argument of the author is that AngularJS is gaining momentum because "it is simpler".
My personal experience is that when I ported my application from Ember to Angular, my code base (~5,000 lines) get simplified considerably. Based on what I've been reading, I'm not the only one making these observations.
My main beef with Ember was not about complexity or simplicity, just that it's not as powerful as AngularJS and it also covers only a small part of what AngularJS gives me out of the box (especially server side includes).
I just have the "feeling" that with Discourse being written in EmberJS, people are mindlessly going to flock to it without really looking at anything else.
And even if AngularJS really is better, it will be left behind. Just because...
And even if AngularJS really is better, it will be left behind. Just because...
It won't be left behind, it's from Google.
It's maintained by Google, but it's from Angular company (an online JSON storage service). The 'by Google' in it's name doesn't mean it's designedto be 'Google's JavaScript MVC' and I know Google employees who think expressly otherwise.
http://en.wikipedia.org/wiki/AngularJS#Development_history
http://en.wikipedia.org/wiki/AngularJS#Development_history
So true! Google never abandons technologies. At least that's what an article on my Google Reader said. :P
Angular and Backbone are currently the frontrunners, by a _lot_.
Yes, but I'm afraid it might go the RoR way. Rails started off by disrupting the web-dev space and positioning itself as an alternative to Java. It really pushed the overall web-dev space forward.
However, today, I feel, Python is more popular than Ruby (at least in my part of the world) because of various other reasons. Even though a lot of web frameworks are doing things the Rails way.
However, today, I feel, Python is more popular than Ruby (at least in my part of the world) because of various other reasons. Even though a lot of web frameworks are doing things the Rails way.
we're currently working on an angularjs application that has to deal with massive amounts of editable data on screen (think of purchase orders, ship notices, invoices that need to be sent out to walmart, kroger, target scale). although i have had minor issues here and there all you really need to know is what angular is currently monitoring (usually you expose the mutable parts of your models) and exposing that to the angular runtime while hiding what it doesn't need to know to get a performance boost. as for reusability angular services has been both easily and wonderful to use because of angularjs DI approach to everything.
this application also has to have a pluggable(200+ different company business/validation rules) rule engine, and being able to configure angularjs services through its providers interface has been very helpful with that problem.
we're not done yet so i can't give a final verdict but we've been overall pleased with the framework so far. i also agree with some of the sentiments in here where angularjs does not currently seem to have a culture of what is "idiomatic" angular which can be very detrimental in the short and long run.
one of the reasons we didn't go with ember is that the decision was made at the time where in they were making huge changes to ember.
this application also has to have a pluggable(200+ different company business/validation rules) rule engine, and being able to configure angularjs services through its providers interface has been very helpful with that problem.
we're not done yet so i can't give a final verdict but we've been overall pleased with the framework so far. i also agree with some of the sentiments in here where angularjs does not currently seem to have a culture of what is "idiomatic" angular which can be very detrimental in the short and long run.
one of the reasons we didn't go with ember is that the decision was made at the time where in they were making huge changes to ember.
It's not even close for what purpose?
For example, there's a wide common case of simple apps hacked together by 1 or 2 developers, traditionally composed of jQuery spaghetti. Maybe Angular is a perfect tool to better organize these typical, not-particularly-ambitious apps, where Ember would be a pre-mature optimization.
And perhaps Ember is the perfect tool for sophisticated apps written by teams of developers.
For example, there's a wide common case of simple apps hacked together by 1 or 2 developers, traditionally composed of jQuery spaghetti. Maybe Angular is a perfect tool to better organize these typical, not-particularly-ambitious apps, where Ember would be a pre-mature optimization.
And perhaps Ember is the perfect tool for sophisticated apps written by teams of developers.
> It's not even close for what purpose?
As the article says at the end:
> 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?
As the article says at the end:
> 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?
Read on
> If you’re serious about front end development, I advise you to take the time to learn Ember properly.
The article isn't fair to Angular. It's like saying, If you're a professional web designer, you should always use semantic markup and a CSS pre-processor, and never Twitter Bootstrap. In fact, Twitter Bootstrap and Angular both have their places alongside Sass and Ember.
> If you’re serious about front end development, I advise you to take the time to learn Ember properly.
The article isn't fair to Angular. It's like saying, If you're a professional web designer, you should always use semantic markup and a CSS pre-processor, and never Twitter Bootstrap. In fact, Twitter Bootstrap and Angular both have their places alongside Sass and Ember.
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?
Doubleclick for Advertisers is AngularJS now and that's a pretty big project in terms of surface area.
DFA drove a lot of early refinements in how AngularJS works. Since then, it's largely community driven.
DFA drove a lot of early refinements in how AngularJS works. Since then, it's largely community driven.
> 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.
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.
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.
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?
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?
But if you'd want to use an ORM , why not directly use Rails?
An ORM (the only example listed by you or the author) does not a Rails app make. There are dozens of ORMs of all types across every language; DHH did not invent the Active Record pattern and Rails' implementation of it is not the only viable option, even in Ruby (consider Sequel's ORM for example).
An ORM (the only example listed by you or the author) does not a Rails app make. There are dozens of ORMs of all types across every language; DHH did not invent the Active Record pattern and Rails' implementation of it is not the only viable option, even in Ruby (consider Sequel's ORM for example).
Coming from Backbone and not really spending any time with either Ember or AngularJS; It seems to me that Ember adopts a more Backbone-like approach to managing Model changes. If only Javascript had a missing method dispatcher, these types of accessor syntax differences would be moot.
From what I read, the Ember model looks way closer to what KnockoutJS is providing.
Just wanted to point out it's also possible to build a highly responsive single page web app with 10,000+ lines of javascript without either Angular or Ember, or any other framework. For example: http://plugg.io
I appreciate the reminder. Pluggio seems pretty clean from the video tutorial!
It seems like you must've had to implement a fairly big subset of something like Angular in the process, no?
It seems like you must've had to implement a fairly big subset of something like Angular in the process, no?
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?
Did you encounter similar issues or do you rely mostly on unit tests for debugging?
I'm mostly a backend web developer but I'm really curious to see where Google is going with Dart + AngularJS. I think there may be something interesting there, for those like me who don't like javascript!
One is 272kb and the other is 78kb. This should be noted at the beginning of any article making such a comparison.
It's not really a fair comparison for several reasons. Namely that to match Ember's functionality, you have to add several libraries to your AngularJS app. Eventually you'll reach the point where you've effectively got the same size in several libraries, as opposed to one. This is the same argument the Backbone guys use to make and it's stupid.
If you don't need that level of functionality, then fine, don't pick up the framework with a few extra KBs. But keep in mind that with any luck, your app will start to grow. When it does you'll need to scale and perhaps you'll discover there was value in using a more functional framework.
If you don't need that level of functionality, then fine, don't pick up the framework with a few extra KBs. But keep in mind that with any luck, your app will start to grow. When it does you'll need to scale and perhaps you'll discover there was value in using a more functional framework.
"In the above snippet, there are three models!"
I'm not sure why this is a problem. A model is just a representation. Could be one, could be many objects.
I'm not sure why this is a problem. A model is just a representation. Could be one, could be many objects.
this just in: Ember.js Fanboi tries AngularJs-- says it sucks because it's not like Ember.js
> but ask yourself this: are all developers on your team going to follow the same conventions?
That's the point of using a framework. You need to stick to conventions since frameworks have an opinon on how things should be(Ember does i guess).
I never tried Ember ( I will ), but AngularJS comes with a lot of battery included , that's why it is really awesome.
That's the point of using a framework. You need to stick to conventions since frameworks have an opinon on how things should be(Ember does i guess).
I never tried Ember ( I will ), but AngularJS comes with a lot of battery included , that's why it is really awesome.
OK. While religious tech war, I'll be offering whatever my clients want and solves their particular needs.
One nit from the essay: the author comments on the missing 'model' from Angular and provides an example of a computed property to illustrate this. 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. Angular (err Restangular to be specific) has a way to do this with less code and an aesthetic (data binding in HTML) that I personally like. If, however, you were writing code that needed the client to have a lot more business logic (i.e. computed properties, browser local storage, etc) then something like Ember would be a better choice because of its 'Model.' A lot of shit crud apps, however, don't need that much business logic in the client (at least for an MVP), and that would be my narrative for why Angular appears more popular. That said, I use computed properties in a couple places with Angular, and watches have performed perfectly fine for my use (gallery of 1000s thumbnails). He should disclaim that YMMV.
Neither is inherently better, and both teams working on them are full of smart, quality engineers that understand these problems in ways I never will.