11 ms·
AngularJS from an Ember.js perspective
- sailfast 13y agoHaving just dug into Angular while wondering if I really wanted to be working with Ember, this was a great comparison. It's obvious to me now I have to look at both frameworks. While done by an Ember.js creator I found the presentation also provided me with a much deeper knowledge of Angular at the same time - well done. As for the Google popularity, one could snidely remark that Angular's documentation and taxonomy requires significant amounts of searching to solve the problems you are after. While the community is active, it's quite difficult to find examples of the right solution or effective documentation for newbies at times.
- machty 13y agoI just added this to the slides (ran out of time to prepare/say all the things I wanted to), related to Google popularity: - A toolset’s mindshare is predictably going to be greater than that of a framework - Angular interest (per Google) dwarfs Ember; jQuery interest dwarfs Angular, etc - Angular encourages you to build the framework; Ember is the framework
- bib971 13y agoWhat do you mean "Angular encourages you to build the framework"? What kind of framework?
- trek 13y agoThe framework appropriate to the kind application you want to build
- steveklabnik 13y agoThe answer is in the deck. https://docs.google.com/a/steveklabnik.com/presentation/d/1e0z1pT9JuEh8G5DOtib6XFDHK0GUFtrZrU3IfxJynaA/preview#slide=id.g177e4bd2b_0192 https://docs.google.com/a/steveklabnik.com/presentation/d/1e...
- veemjeem 13y agoit is also on slide 53
- thatthatis 13y agoMy usual trick for getting around this is in rails vs django is to add tutorial to the search, so "emberjs tutorial" and "angularjs tutorial." Unfortunately it looks like we're still too early to have enough data using those terms, which tells me that the google search data should be taken with an enormous grain of salt.
- dsego 13y agoThis format sucks, I can't click on jsfiddle links or even copy them.
- Banzai10 13y agoSo technically what the presentation is trying to say is that you should use Angular to build Ember like framework. hahah I personally like Angular, the Google support and the community are strong points to it. The documentation used to be hard to find, but now, specially with StackOverflow, finding what you need is easy.
- bcardarella 13y agoI don't think relying on Stack Overflow is a good solution for lack of good library documentation.
- cjcenizal 13y agoWhy not? It is a good solution for lacking good library documentation.
- Bognar 13y agoI hate that Google Docs modifies your history when you go to the next slide. This presentation clocks in at 57 slides and Firefox history defaults to truncating after 50 entries, meaning I can only go back to slide 7 and not back to HN. Is it really better that I can use my browser forward and back buttons to navigate slides? Especially when there are forward/back buttons on the presentation anyway?
- steveklabnik 13y agoI personally enjoy this aspect, as I think it fits the philosophy of the web better. Each slide has an address, because they're separate things. You can also trivially link to a particular slide this way. I open articles in new tabs, so the going back to HN part hasn't ever affected me.
- Already__Taken 13y agoEach slide should have an address yes but I don't think everything should push do your history stack. That Git cheat sheet page the was on HN a few days ago. Every time you changed the command it pushed onto your history. I want to click back to HN not back and forth between 2 commands I switched across 6 times. I was going to comment then but I don't think the site was using push state it is actually browser behaviour.
- taude 13y agoI just open all articles (and all HN comment threads) in new tabs. Sometimes I don't even get to them after scanning the front-page for awhile.
- leeoniya 13y agoi agree, i find that history modification on slide changes is a huge anti-pattern. aggravates me every single time. i think a good compromise is to use the left/right keys for onpage slide nav, but leave the browser history alone.
- rlivsey 13y ago
- atjoslin 13y agoI use angular a ton, and just learned more about Ember from this. thanks. I'll have to check it out someday. Ember looks like it has good testing now too :-)
- chidevguy 13y agoOne thing that I like about Knockout is that you can easily drop it into a legacy site, allowing you to have some pages that use it and others that don't. Forgive my naivete, but is this something that is easy to do with Ember or Angular as well?
- machty 13y agoYes. Both Angular and Ember support this pattern pretty effortlessly.
- bmelton 13y agoWithout knowing the specifics, the best answer I can come up with here is that it's Javascript -- so yeah, you can write it affect parts of the page, or all of the page. You can have it control just the navigation bar on a site, or the whole site altogether. There are caveats here -- if you have the library loaded from any page with html5 location mode enabled, it'll take over link-handling on those pages. With Angular, it's easy to circumvent by adding a 'target' attribute to the links, but on a legacy site, that might mean having to touch every page that Angular doesn't already exist on, which would be a chore. The alternative is to not enable HTML5 location mode (so links are to #/link/) or to adjust the targets on links that aren't meant to be handled by JS. All summed up though, while it may not be written anywhere, I've always gotten the feeling that Angular prefers to own the entire page, loading partials into views where appropriate, and using separate controllers for other portions of the page. That said, it can work either way, but does take some extra special care.
- machty 13y ago"allowing you to have some pages that use it and others that don't" Your response seems to dig into a different (though related) issue. If the question is whether, given a whole website, whether angular/ember can exist only on certain pages, but not all pages, then the answer is Yes.
- adambard 13y agoAngular yes, Ember perhaps not. I this wrote briefly on the subject recently: http://adambard.com/blog/angular-in-the-small/ http://adambard.com/blog/angular-in-the-small/
- hpvic03 13y agoI've been working with Ember for a while now, and I love it. Convention over configuration is a big deal, and the Ember team has done it right. I think if you like Rails then you'll like Ember.
- Bahamut 13y agoI enjoyed reading this, as a heavy Angular user & someone interested in trying out Ember sometime. Thanks!
- gregwebs 13y agoThis is the only intelligent comparison I have seen of Ember & Angular (or actually of Angular with any other modern framework). Thanks! I am wondering if the uniform access principle is mostly a dynamic language issue: you end up screwing up whether you need a parentheses invocation and you don't know until runtime. If you type everything with TypeScript then you know at compile time if you messed it up. Relatedly, Ember's get/set is more difficult to make strongly typed. In the TypeScript definitions I am looking at, property access is only typed as a string. One could define an enum for each object to be used in place of the string, but overall there is a price to pay with set/get since it isn't baked into the language (like Ruby).
- emn13 13y agoI think the uniform access principle is misguided (or at least misconstrued). It's a bad idea... in general. If you're building an API and you have need some kind of stable, unchanging interface to expose - then it makes sense. But people are using it everywhere in their programs; and it's not really valid there. First of all, data-access is fast and computed functions may be slow. Hiding this difference means that writing efficient code becomes more tiresome - you need to consider each and every access as potentially expensive, even though the majority are probably trivial. This means you need to know the code better to get anywhere. And if you make it hard to write efficient code, people won't bother (and rightly so, since that's usually premature optimization). Secondly, in most languages, simple data access is side-effect free and (usually) thread-safe or at least has predictable threading behavior. Managing side-effects - even without threading - is a major pain in any large code base, and although functional purity can be enforced otherwise in some languages, in most cases you've got nothing to go on. Making your life more difficult by discarding annotations that distinguish between method calls and member access isn't helping. Of course, in a dynamic languages you're in a tricky spot here - it's hard to refactor, so exposing member access is something that's more work to change later when you discover you need computation or a side effect. However, even so; making a system harder to reason about for the purpose of a fairly pointless architectural purity is usually a bad idea. The uniform access principle as applied to interfaces is another story; but in general use - I think it sounds nice in theory, but works poorly in practice.
- paulftw 13y agoKudos to the author - I am impressed how well Alex Matchneer understands Angular. Few thoughts of my own: - Ember is a long term relationship with one particular way of doing web FE, a way invented by someone else for you. Ember philosophy is "one size fits all". - On directives and transclusion - it's like Lisp's dotted pair. these new concepts may be hard to understand, but experiments like that often fascinate programmers, and for a good reason - one day those experiments will revolutionize the way we build software. The debate of a small set of flexible tools vs one tightly integrated system is not new. We had Linux vs Windows, Django vs Flask, etc. It's funny to see it pop up in yet another area. Thank you for this great write up and raising a bar of this long going discusiion on Ember vs Angular.
- tomphoolery 13y agoI really liked this. Although I prefer to work with Ember.js, Emblem and EmberScript (as the latter addresses some of Ember's syntactical faults), Angular seems very interesting when you view it as more of a toolset for building your own framework than a "complete" framework in and of itself. When you bring the entire Ember toolchain into the mix, outside of the already-complete framework, it begins to smooth Ember's rough edges in development. It's just the same with Rails, I'm a Ruby developer and we're used to dealing with dependencies already, so it's not really a huge leap outside the box for us to be using tools that will compile down to HTML/CSS/JavaScript to build the frontend to a Rails backend API application. I still understand Angular as a toolchain/framework/whatever for people who do not understand JS to the point where they want to begin extending it. Angular is a "safe zone", something that frankly JavaScript as a language (without Ember's additions to the object model and such) needs right now. When you write apps in Ember, I feel like a deeper understanding of how JS is working is necessary before you begin to abstract that portion away. Is this still a correct assumption to have? I'm not trying to insult anyone, frankly JS is a pretty screwed up language so I feel like it's a natural tendency to want to just get what you need out of it quickly and safely and then move on to more fun projects. In my opinion, it's simply a different way of doing things, not better and not worse.
- wereHamster 13y agoPeople really like googling angular That could also be because angular has horrible documentation!
- iamgopal 13y agoso is there angularjs framework for google app engine + endpoints ?
- virtualwhys 13y agoThat was a really informative comparison, kudos to the Ember author for injecting minimal bias. I've been on the fence about switching from jQuery + Coffeescript to Angular/Ember/etc. Still am, bit of a server-side luddite here, AJAX, client-side form validation, some jQuery effects for dropdown menus, show/hide layers, etc. is as far as I go.
- jemptymethod 13y agoDo we really need either Angular's or htmlbars' (see slide 37) way of "decorating DOM elements with behavior" when it is so trivial with just ES5 and HTML? See this jsfiddle: http://jsfiddle.net/dexygen/nU8VK/ http://jsfiddle.net/dexygen/nU8VK/ Give me a couple/three strong JS devs and I guarantee you I could take these simple building blocks (as well as spans with data- attributes, and innerHTML, instead of templates), and I could build out a framework way faster than either Angular or Ember.js and would validate as HTML5 to boot. Doubt me? I pretty much did the same thing for PHP; see http://dexygen.com/ria/#!/docs/jackrabbitmvc http://dexygen.com/ria/#!/docs/jackrabbitmvc