31–40 of 104 posts
Neither. Small modularized CommonJS files that serve the need of what you are doing is always faster to write and easier to load in your head than large frameworks that you never fully understand. Learn to use npm and use it well.
I have limited experience with javascript and MVMM's and cannot answer all the questions, but here is what I do know: Which is best overall? Not enough experience with ember.js to comment. Common gotchas for angular: It's a very different approach when compared to using jquery for everything. The documentation can seem a bit daunting at first, as described in the popular post about why discourse chose ember.js. "The…
Actually that's the only bit confusing part of the documentation (which now everyone is quoting to troll Angular).
AngularJS :
+ MVVM : databinding
+ Dependency Injection, so no global state, and loose coupling
+ Well organised into services , view models ,directives , filters , ...
- forget any projects that are animation/transition between views heavy, you'll fail
- doesnt play well with some other frameworks ( requireJS, jQuery mobile , even phonegap ...)
- is slow when dealing with a lot of data.
- no control over dom objects lifecycle
- the doc sucks
- if you dont understand Dependency injection , dont use it.
- will not scale if javascript dont get some new structures , dirtychecking is insane given javascript performances.
Ember: + fully event driven
+ plays well with other libraries
+ less magic than angular
+ full control over DOM lifecycle
- the doc sucks but less than angularJS one
- more verbose than AngularJS
- unstable API
I built apps in both langages. like that one :
I prefer Ember but have no problem using Angular when I have to.
ok here is my take : AngularJS : + MVVM : databinding + Dependency Injection, so no global state, and loose coupling + Well organised into services , view models ,directives , filters , ... - forget any projects that are animation/transition between views heavy, you'll fail - doesnt play well with some other frameworks ( requireJS, jQuery mobile , even phonegap ...) - is slow when dealing with a lot of data. - no con…
Animation is coming to the next version. It's already possible but you have to do it yourself.
> doesnt play well with some other frameworks ( requireJS, jQuery mobile , even phonegap ...)
* https://github.com/tigbro/jquery-mobile-angular-adapter * http://briantford.com/blog/angular-phonegap.html
> is slow when dealing with a lot of data.
It's fast enough not to be noticeable by humans unless you're batman as explained by Angular creator: http://stackoverflow.com/questions/9682092/databinding-in-an... . Object.observe will make it fast even if you're batman.
> no control over dom objects lifecycle
There is control actually (see digest, apply etc).
> the doc sucks
The guides are actually pretty good and http://egghead.io/ free screencasts are awesome.
Edit: Google is going to sponsor the author of egghead.io videos! https://twitter.com/eggheadio/status/302494160982781953
> if you dont understand Dependency injection , dont use it.
You don't have to understand DI to use it. I know I didn't.
> will not scale if javascript dont get some new structures , dirtychecking is insane given javascript performances.
Again, read this http://stackoverflow.com/questions/9682092/databinding-in-an...
I have enormous confidence in the capabilities of the team working on Ember. jQuery, Sproutcore, Rails core team members. If you're a Rails developer, the existence of active_model_serializers as a quasi-standard for how JSON is shuttled between tiers suggests that Ember has taken a position of strong thought leadership on a lot of things that other frameworks just don't have the reach to do. Also, the recent Peepcod…
There is a free alternative for angular: http://egghead.io/
I tried both in similar circumstances (coming from a long backbone background), all I can say is I personally found with Ember.js (around august 2012): - more boilerplate - learning curve was much steeper. - the documentation confused me, it turned out there were many slight diferences between 0.9.xxx and 1.xxx. This "gotcha" is probably rectified by now I tried Angular.js next (this month) and "got it" immediately:…
> This "gotcha" is probably rectified by now It's not. The guides published on emberjs.com apparently track the master branch on github, so are regularly out of sync with the version offered for download on the front page, and at the moment there's a third version bundled with the starter kit. This completely tripped me up when I tried to get off the ground a couple of weeks ago, because things that were described as…
ok here is my take : AngularJS : + MVVM : databinding + Dependency Injection, so no global state, and loose coupling + Well organised into services , view models ,directives , filters , ... - forget any projects that are animation/transition between views heavy, you'll fail - doesnt play well with some other frameworks ( requireJS, jQuery mobile , even phonegap ...) - is slow when dealing with a lot of data. - no con…
Why? How is it different from using jQuery without Angular?
Also that there is no templating system - I always disliked having to learn and use and debug another abstraction layer (Mustache/Handlebars or Razor with MVC etc.).
The biggest "gotchas" with these frameworks will typically be the problem of having to wrap your head around a few new and unfamiliar concepts and syntax that take a while to "grok". (On the other hand, it's NOT difficult in a objective sense, like some advanced mathematics that not everyone is capable of doing, so, to anyone reading these JS framework-threads on HN, please end up encouraged to try them out yourself.)
Learning one framework will greatly help your understanding of the other, so I'd say just pick one and decide later which one is "best".
Neither. Small modularized CommonJS files that serve the need of what you are doing is always faster to write and easier to load in your head than large frameworks that you never fully understand. Learn to use npm and use it well.
you obviously never wrote a "fat" client and had to maintain it : at some point you need some kind of framework to make sense out of the "small modules" mess. And CommonJS doesnt solve dependency injection issues.