I feel Angular is better than almost everything out there but still not quite right. It seems way too complex for what it does, and the syntax looks like somebody vomited all over your code. Does two-way databinding have to be so awkward? Angular does help you in writing maintainable code (which is vital for JavaScript - dealing with large JS codebases is hard), but it also ties you to a technology which is probably transitional. I have high hopes for 2.0, and I hope they work out these issues.
Have you seen React.js (http://facebook.github.io/react/) and Mithril (http://lhorie.github.io/mithril/)? They're supposedly smaller, faster, and easier than Angular, and does roughly the same things, as far as I've read. And they support server side rendering. At least React does.
Still early days for Flux, but the principles are sound and I hope it offers a viable alternative to all these framework that rely mainly on variants of the MVC pattern.
The overcomplication (relative to what could be) is due to boilerplate and poorly defined convention for anything but the canonical todo app. It's early days.
There are some frameworks using some form of the Flux spec like Fluxxor and Reflux, but they're not opinionated or complete enough to hit the ground running.
The author of Fluxxor, for example, is himself working out where to put very basic functionality like network service calls.
In the react-router project, there's not an obvious way to either render from server or refetch data on route changes.
This is all very basic functionality for a medium to large project. It will feel like you're in the weeds after a couple of days of development.
We need a Flux++ framework with some stronger opinions, closer to Ember or Angular in scope.
I agree with andwaal that reflux is the simplest way so far that I've seen. I think what is really lacking is a demonstration application which isn't just "hello world" or the standard todo app rewritten in React. I just don't find that helpful.
Thanks for mentioning Mithril, I didn't know about it. It looks very interesting. I've been meaning to try React.js for a while now, just haven't found the time.
About Mithril, HTML generation with JavaScript is an odd design choice. Obviously it's much better from a technical point of view, but nested or complex HTML must get ugly fast, and I really don't want to deal with template code written by non-developers. Having said that, for a certain class of apps with high performance requirements and comprehensive browser support, Mithril is a very appealing option.
That's the problem JSX solves - nesting tags and attributes is less syntactically onerous than managing a tree of function calls or nested object structures, with their attendant braces and commas.
Here's the Mithril getting started example [1] done using JSX [2], for comparison (some of the other code has changed since I did this, but the rendering part looks the same)
The verbose parts have nothing to do with the data-binding. The dependency injection is there for testability (https://docs.angularjs.org/guide/unit-testing), you have to use array notation because JS changes variable names upon minification. The rest is just objects being used to set up options.
Array notation is only required if you're not actually up to date on modern build tooling - ng-annotate [0] will automatically generate array notation DI statements in most of your application code.
JS doesn't change variable names upon minification - minifiers do. For the dubious benefit of saving probably less than 5-10% of a transfer we've decided it's worth repeating ourselves pointlessly.
How are you finding it awkward? It's the simplest way of getting data into a template that I know of - assign a value to a scope and done, no hassle. And vice-versa, too.
(disclaimer: I come from Backbone, where we did all data and event binding by hand)
Sorry for not clarifying. What I find awkward about it is the Angular-specific baggage and the syntax, which just got more complex.
Stuff like ng-model-options="{ updateOn: 'blur' }" is far from straightforward. I guess you could do ng-model-options="model.modelOptions" and define the behavior in the controller, but then your controller would be handling far more than it should. By the way, wouldn't a separate directive be more appropriate for this? ng-update-on="blur" is more palatable.
And in my experience with Angular, it's never just "assign a value to a scope and done", except for the most trivial situations. When you leave these behind, you have to think about scope hierarchies. You have to watch your watchers. When you use something like angular-translate, you have to carefully consider synchronicity issues and the performance drawbacks of each way to bind your models. And so on. I love the power and flexibility that Angular gives you, but I wish there was a simpler way for it to do its magic.
>When you leave these behind, you have to think about scope hierarchies.
Yes, a prerequisite to using a JavaScript framework is understanding prototypical inheritance
>You have to watch your watchers
What?
>I wish there was a simpler way for it to do its magic.
To date I haven't seen a coherent argument against Angular; complaints seem focused around having to learn framework specific syntax (present in any large MVC framework) or the perceived "heaviness" of the framework (suggesting the apps you're building aren't complex enough to justify something like Angular)
> Yes, a prerequisite to using a JavaScript framework is understanding prototypical inheritance
Obviously, but you shouldn't have to care about prototypical inheritance for simple databinding. The way view-models work in Angular leads to some complicated scenarios which, in my opinion, shouldn't exist in the first place (http://toddmotto.com/all-about-angulars-emit-broadcast-on-pu...).
> To date I haven't seen a coherent argument against Angular; complaints seem focused around having to learn framework specific syntax (present in any large MVC framework) or the perceived "heaviness" of the framework (suggesting the apps you're building aren't complex enough to justify something like Angular)
I have no problem with learning framework specific syntax and Angular is actually lightweight, both from an architecture and from a code weight point of view. What I do find problematic in Angular are some design decisions which often lead to complicated, and non-beautiful, code. Angular is no doubt incredibly useful, even for smaller apps, and I'm grateful for its existence. It is a step in the right direction. But I do think it has room for improvement.
Angular is described by its creator as a better browser. That's why it gets so much heat. Because you actually have to hook into a app lifecycle you dont control.
And you know what ? that's great,because it means there is only one way to skin a cat and when you have to work with a huge team,it's time saving as there is no architectural debate. That's frankly why I like big and opinionated frameworks such as Angular.
It's basically the framework's way or the highway,code becomes predictable and you only need to know how the frameworks works to understand other's people code.
You know there will be no DOM manipulation in controllers. You know that the view layer will communicate with other layers through services.You know that developpers will have to use promises. And you know you'll be forced to write testable code that makes heavy use of dependency injection.
I'd agree with you but then I realize I just got done pruning pure dom-manipulating jQuery code out of a colleague's angular directive today. Honestly I wish angular were more opinionated.
>That's frankly why I like big and opinionated frameworks such as Angular.
That's weird that you say that Angular is opinionated, or maybe it's not.
When I first started hearing about Angular, the story was that Angular was very opinionated compared to Backbone which made you figure everything out on your own.
Then as Ember gelled Angular became the un-opinionated framework that left the developers to their own devices compared to the very opinionated "Ember way".
I guess every framework is what you want it to be, or what you don't.
Ember Data is opinionated about the backend, Ember itself isn't. You can use Ember without Ember Data, as is the case with Discourse, one of the largest Ember apps out there.
It probably depends on how far you try to get from angular in angular-based project. As soon as you try to do something differently - it might bite you and bite you badly.
As for promises - try to define custom parser or formatter on ngModelController using anything asynchronous :)
And yes, you are right - it might be easy to understand other's angular code for you, but when javascript developer come into angular project, try to explain why utility library called 'Service' and why DI does not take care of loading these dependencies :)
After working for some time on angular project, I got a conspiracy theory: Google bought this company and threw angularjs to masses so they get all excited and spin wheels reimplementing stuff already done elsewhere, while Google will keep building products :)
I am joking of course, but each joke always have part of truth in it..
Minus the fact that AngularJS was developed as a Google internal project / by a Googler / for a Google service (their support / help pages iirc), after they struggled for months building it.
The´re a bit different. Actaully the AngularDart has features that 1.3 don't have, like the new router, and I'm sure there is something in 1.3 that don't exist in AngularDart. But AngularDart seems to be the more "advanced" one.
Does using AngularDart means you can code with types and get decent auto-completion ?
I know it can compile to regular JS, but does it really works well with non-chrome browser ?
Shameless plug for my open-source project Angular Classy. Recently pre-released a beta for 1.0, of course it's fully tested and compatible AngularJS 1.3.
Small sidenote. Whilst I understand that the Angular team feel obliged to use Blogger, can people please not use the Blogger dynamic views. No content without JavaScript. Why doesn't Google come up with their own standard Google Blogger template for their project teams anyway?
> And as we announced back in December, AngularJS 1.3.0 no longer supports IE8. This allowed us to make improvements and performance enhancements that otherwise would not be possible.
It is possible, see how rivetsjs did that years ago. But it is still a very nice thing to drop IE8.
Msft still supports IE8 on windows 7 and various server os's. As much as I would like to see it die it remains in a bunch of corporate environments with ms support.
You're preaching to the choir, but try convincing my boss and the company that owns our agency; it's too large a user-base to ignore, and we do some stuff for the government so we don't have much of a choice.
Having to run through 1000s of watchers in a digest cycle is not unusual with a typical Angular site and oftentimes most of those watchers are redundant.
Are there any benchmark results available? They mention it increased speed, by a lot, but don't give any numbers -- instead point to a code repo where you can run your own. This is great, but I want an "at a glance" numbers on a variety of platforms so I can verify their claim and then take it to my boss to push through an upgrade. An "executive summary" if you will.
You can use it anywhere but it'll be especially helpful for long lists. Angular binds anything in double curlies, creating watchers that dirty check and evaluate with every digest cycle. It's tempting (and IMO Angular incorrectly encourages users) to use double curlies for templating everwhere, so in typical list views you can end up with thousands of watchers on data that never needs to change once the page is rendered. This is slow, especially for searching and sorting. Further reading[1]
Before this release it's been necessary to write custom directives or use a tool like Bindonce[2] to turn off data binding where it's not needed.
I don't like Angular. Everybody likes it but I don't.
It feels like 2004 all over again. SOAP! SOAP! XML! GWT! ColdFusion!!!!1onene!!!1
I also don't like working with Google toolchain, because for a company full of smartest dudes on the planet it certainly seems like these dudes don't care about their customers.
2. By using Angular you are throwing away the toolchain we have been honing and making better for the last fifteen years.
3. Debugging - If I have learned anything from the XML dark ages it is that you do not want to program in a language that is not debuggable. And yet, here comes Google and does it again!
4. Overloading semantics. I hate Angular for just going and reinventing so many of the words and context we use in this trade.
5. Angular is not free! I would not use Angular for the same reason I would not use Java. I would hate to tie my future to this uber monstrous corporation's whims.
Thinking about Angular I realized (yet again!) that Google has jumped the shark. It is no longer pragmatic and cheeky startup of fifteen years ago. Nowadays it is more akin IBM and Microsoft of old.
Edit: Basically to me Angular is another stab at the softcoding - where Angular is the app and your code is softcoded definitions of behaviors. And as such it will eventually fail for the same reasons all the similar projects have done so before. Some of which are listed above.
I may be biased, since I've been using (and enjoying) Angular for quite some time now. But I don't agree with any of your points.
1. I can't think of a single case where the Angular documentation has failed me. Yes, it's sketchy in places, but what open source documentation isn't?
2. I'm not sure which toolchain you're referring to, but Angular is just a framework - you can use whichever toolchain you like. You can even use no toolchain if you wish.
3. Debugging has improved significantly since 1.0, especially since Angular started adding HTML comments to denote where markup is generated from. Browser extensions like AngularJS Batarang and ng-inspector help out as well.
4. Again, I don't know exactly what you're referring to here, but I feel like Angular's concepts and semantics fit in just fine with other systems. Scopes, services, controllers, modules... These all mean what you think they mean.
5. I'm genuinely interested how you think using an open-source JS framework will tie you to a corporation? Hell, I'm interested how using Java will tie you to (I assume) Oracle when things like OpenJDK exist?
1. GAE and GoLang is neither here nor there; Angular's documentation was in need of a lot of improvement when I started using it a year ago, but since then they've been working hard on it. (I found myself in the list of contributors actually, all I did was make a small edit to the documentation). If the documentation sucks - and you seem to know what's wrong with it - edit it. There's a big shiny "IMPROVE THIS DOC" button on every documentation page.
2. As others mentioned, what toolchain? At my current project we've got the ol' Grunt toolchain set up, generated by Yeoman, and customized to our needs - no Google involvement there, and it's a massive improvement over the old toolchain, which was an assortiment of tools run from Maven (often in the old Java JS runtime, which was slow)
3. I've yet to encounter any issue in our Angular projects that need debugging; writing proper unit tests (and Angular allows that) and not doing crazy stuff helps a lot in that respect.
4. Such as? Every framework introduces its own semantics; before, I used Backbone, which has routers (which were actually controllers), models and collections (where collections were a subset of models containing models, what?), and views (which often served as controllers as well, creating the ViewController thing). I don't see your point.
5. Yes it is. MIT license, open source, hosted on Github - the comparison with Java probably couldn't be more skewed.
The comparison with other frameworks is somewhat relevant, in that it's a full-scale application framework - not jQuery with a structure layer on top like for example Backbone is. The upsides of that is that it's much easier to achieve the same thing (trust me, I'm rebuilding a 60K Backbone project in Angular with a factor 10 less code required), it's much easier to develop, test and maintain (and with a 12-man development team of varying skill levels you need that), etc. Not to mention, like I said, unlike ColdFusion or Java or Silverlight or whatever, it's an open source project from the start - not something ditched to the community after the company itself lost interest.
1. I admit Angular documentation sucks, but that's not atypical in any open source. It's getting way better btw, and there are tons of resources from 3rd party.
2. Which toolchain are you referring to? If we're talking Web/JavaScript (where Angular is for), I can say the toolchain e.g. Grunt is quite recent.
3. I somewhat agree with this. We can use e.g. Chrome Dev tools and Batarang (Angular Chrome plugin), but definitely there's room for improvements.
5. Care to elaborate your definition of free? Even for Java, I can say a significant ecosystem for Java is open source. Sure, some Enterprise prefer Java Enterprise Edition, but many are satisfied with Spring and other open source Java-based solutions.
2. Templates and existing JavaScript code - i.e. Bootstrap, jQuery, templating languages and other existing app components. With Backbone you can easily use any JavaScript library - because it itself is just JavaScript. I really don't like how angular forces everything to have a ng-something derivative.
5. Angular is not free because it is this monolyth that only the sage men within the temple of G can comprehend. The sages give you an incantation for a ritual and you, the believer use it. If it is not yet, then its core is going to become an indecipherable mess - built to serve the temple of G. Google is building it for itself and as usual doesn't really care about anything but its own objectives. Whatever they may be - a user might find itself in the same situation that i.e. Silverlight users found themselves after MS decided that Silverlight was not a good idea at all.
2. Nothing's stopping anyone from using 3rd party libraries within an AngularJS application - using React for the view layer, for example. Angular encourages the use to separate concerns (mainly DOM manipulation) via directives, instead of mixing that logic into other parts of your application (like vanilla JS, jQuery and Backbone tend to do).
5. You're wrong, and your argument is invalid. It's open source, legible, modular and fully comprehensible if anyone bothers to dive into it.
I'm honestly curious here – not being an FE developer, but I've wired up Angular in a few projects in the recent past.
I've felt like it's easy to use and to get the job done, not any harder to debug than JS in general, that it wasn't that hard to fiddle with it to a point where I could use my old plain-JS knowledge fairly well, that the documentation wasn't excellent but not bad, and that the online error generation (whatever it's name is) was quite handy.
What haven't I seen yet? I mean, it seems to have its quirks and difficulties that make me go halfway insane, but that's a characteristic of JS development in general.
Reasons 1 and 3 are enough for me to stop someone who is relatively new to web app development to use something other than Angular. egghead.io saved me when trying to learn it, but before that I was stuck trying to follow their tutorials and docs (which understand are a little better today) and spending hours each day trying to figure out problems - this wasn't the case with Ember and Backbone just for a persona comparison there.
