81–90 of 104 posts
Earlier quoted context omitted.
- forget any projects that are animation/transition between views heavy, you'll fail Why? How is it different from using jQuery without Angular?
you have a list , each time you remove elements on the list ,you want to fade out elements that are being removed for 0.5 secs. Explain me how you would do that.
Earlier quoted context omitted.
Ha ha, nice way to scare people off angular and justify their decision ;) Transclusions are an interesting feature to cherry pick because a) they're a necessary complexity to enable reusable components (one of angular's greatest strengths), and b) they highlight the steep learning curve required to truly master angular. I agree that the docs can be a bit vague occasionally, but I think that's only due to the sheer de…
if you think Angular docs are vague, go check Ember. (what docs?)
Ember.JS Guides: http://emberjs.com/guides/
Ember.js API Docs: http://emberjs.com/api/
To be fair there have been a bunch of API changes but as of yesterday Version: v1.0.0-rc.1 is released.
This means that the API for Ember.js should now be much more stable going forward.
The next step is to get Ember-Data to where it's stable and then merge it into Ember.js proper.
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…
"To solve the issue of lack of isolation, the directive declares a new isolated scope. An isolated scope does not prototypically inherit from the child scope, and therefore we don't have to worry about accidentally clobbering any properties.
However isolated scope creates a new problem: if a transcluded DOM is a child of the widget isolated scope then it will not be able to bind to anything. For this reason the transcluded scope is a child of the original scope, before the widget created an isolated scope for its local variables. This makes the transcluded and widget isolated scope siblings."
Data-binding and re-usability should not be that hard.
Earlier quoted context omitted.
Ha ha, nice way to scare people off angular and justify their decision ;) Transclusions are an interesting feature to cherry pick because a) they're a necessary complexity to enable reusable components (one of angular's greatest strengths), and b) they highlight the steep learning curve required to truly master angular. I agree that the docs can be a bit vague occasionally, but I think that's only due to the sheer de…
I wasn't trying to scare people off of angular, as it's what I am currently trying to use. I find it to be a very good framework, but also plan on checking out ember.js to see if it provides more for me overall or not.
Earlier quoted context omitted.
Ha ha, nice way to scare people off angular and justify their decision ;) Transclusions are an interesting feature to cherry pick because a) they're a necessary complexity to enable reusable components (one of angular's greatest strengths), and b) they highlight the steep learning curve required to truly master angular. I agree that the docs can be a bit vague occasionally, but I think that's only due to the sheer de…
Can you share what converted you from knockout to to angular? What were the big reasons? What was the tipping point?
1) a good friend recommended angular to me, in pre-1.0 days, the site was horrid, and I just couldn't grok angular. The framework, site and docs have improved drastically over the last year.
2) I was initially against angular's declarative markup style, thou shalt not mix html and code, etc. But after spending a bit of time getting unobtrusive bindings to work with KO [1], and then looking at the angular equivalent functionality [2], I was sold.
3) Having to massage "business-logic" code into ko.observable* (or DS.*) is quite arduous, angular does 2-way binding on plain old JS objects.
4) Angular templates are logic-less and it strongly encourages you to put your logic into your controllers, where it can be easily tested.
In the end KO is a template-binding library, whereas angular and ember are full stack.
[1] http://gratdevel.blogspot.com.au/2012/02/exploring-todomvc-a... [2] http://angularjs.org/#add-some-control
Ember is object-oriented, angular is functional(ish).
I'm not familiar with the maintainers of Angular and their backgrounds, but with Ember you can expect solutions that mimic the methodologies you'd otherwise find in Rails. I'm particularly referring to OO in this case.
Earlier quoted context omitted.
you have a list , each time you remove elements on the list ,you want to fade out elements that are being removed for 0.5 secs. Explain me how you would do that.
Just create a custom binding (or whatever it is called, using knockout terminology here) which fades it via a jQuery fadeOut?
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…
I think the capabilities of the Angular team are quite respectable as well. Speaking of "reach" and thought leadership makes think of the fact that these guys are working at Google! This seems to have several positive aspects: a) Possibly a more solid stance on development (stable APIs, not ditching a project and rewriting (Sproutcore -> Ember). Sorry if I simplify too much here. b) Being a little "strategic" for Goo…
b) The Ember developers also have influence over those who work with web standards too. Yehuda Katz, of the Ember Core Team, is a member of TC39 and also W3C TAG. We regularly meet and converse with developers both for Chrome and Firefox. Furthermore, Chrome is not going to implement features that are only useful for Angular. Anything they implement that benefits Angular is also provided to be useful to a broader audience. In many cases, those improvements are also useful to Ember.
c) As announced at EmberCamp yesterday, there is also an Ember Chrome extension in development.
Earlier quoted context omitted.
This was only true briefly. The guides on emberjs.com reflect the currently released version, 1.0 RC. Since we've hit RC the APIs are now frozen.
I checked the dates. I tripped over the docs not matching the download version on January 7th. I found non-matching versions yesterday . It's possible that both times I decided to look at it I got unlucky, I guess. I'm glad the APIs are frozen, I was worried there'd still be creep through the RCs.
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…
We haven't found speed to be a problem yet. We used to use CanJS, and I can tell you that handling the same amount of data, Angular is faster, even with fairly complicated filters in place.
I do agree that Angular requires you to let go of the "jQuery way" of approaching DOM manipulation, which throws jQuery-coders for a loop. It's a downside not to be able to plop in a jQuery plugin. Then again, considering some of the plugins I've encountered, that might not be a complete loss. Also, the Angular-UI team is doing a heck of a job of replicating the most common plugins as Angular native directives.