2 years with Angular
fse.guru
fse.guru
Angular's scope system is exactly analogous to the scope system of a programming language. This is a solved problem! When you make a scope system, make it lexical, and require explicit declaration before use. If you're not making those choices, then at least acknowledge that these are the standard answers, with very clear advantages over other scoping systems, and explain why you are not using these answers. But with angular, we have a dynamic, implicit declaration scoping system. New scopes are introduced somewhat unpredictably, at the discretion of each directive. I thought that introducing dynamic, implicit-declaration, non-block-scoped variables in 2014 was like introducing a new car with a coal-burning engine, but no one even seems to remark on it.
Then there's the dirty-checking loop. After every event there is a digest; every digest runs every watch. To me, just reading this description makes a voice speak up in my head: "Uh-oh! That sounds like O(n^2)!" Now that angular is being widely used, people are noticing that it's slow as shit. But why did the framework get to this level without anyone remarking, "this dirty-checking algorithm is fundamentally, irremediably not scalable"? Do people not have a sense even for the most coarse performance characteristics of algorithms like this? Or do people simply think that nowadays "performance does not matter"?
Angular's "module" system is the strangest of all. It doesn't do namespacing or dependency tracking. What is even the point of it? What thought process led to this useless module system?
It's just strange. Hundreds of years of people's work are spent on something, which the most cursory, CS 101 analysis shows to be seriously flawed. Is analysis simply a lost art in this industry?
Oh well, people are finally realizing Angular has its faults, because they've seen them with their own eyes and now they believe them. It would be nice if we could learn from this, and maybe skip the next boondoggle (web components for instance), but I have no hope for it.
I agree with a lot of what you say, but wonder if you're being rhetorical when you say Angular's popularity is baffling. Do you actually think that people pick tools by reviewing the CS literature and picking the one that best reflects the state of the art? :)
Angular is productive, people want to get things done; thus Angular is popular.
What is more precisely true is that the time taken by dirty checking per second scales with d×w×l, where d is the number of digest loops triggered per second, w is the number of watches, and l is the length of the digest cycle (the number of times that the watches are rerun before values stop changing).
Specific applications may find these variables to increase in different ways - all three will generally increase with application size, but for example, adding a digest on mousemove will immediately send d to a very high value.
What I really meant when I said O(N^2) was nothing precise though - just that, when I first read "every time you trigger a digest, we traverse every watch," it sounded like N^2 - it fit the pattern of "for every one of (growing number of things), do each one of (growing number of things)".
Digest on mousemove wouldn't be a good idea - look at _.throttle etc. You shouldn't realistically need digest loops more than once per 100ms, as people can't perceive changes happening faster.
2) Angular was the first framework where you could take developers who didn't know JavaScript (or hated it for its worst parts / memories from the bad old days), but were used to learning frameworks (think Java people) and dealing with framework workarounds, and say, use this, you'll feel right at home.
Not really.
It is the remnants of a failed web startup. They offered a freemium backend as a service, but it didn't take off.
http://web.archive.org/web/20091230110525/http://getangular....
http://web.archive.org/web/20100215054417/http://www.angular...
Then I believe that one of the founders/authors was hired by google, and...
> They then attached "from Google" to the logo and it took off like a rocket.
Yeah.
It's not the first time I hear that he doesn't mention BRAT Tech LLC when he tells the story behind Angular.
In an interview last year one of the founders mentioned that angular was made for creating form based apps. That is its strong suit, which is fine, but it has been stretched so far now.
The dirty-checking loop is IMO a compromise they made because the ES6 standardisation body and consequently browser support for object observable is very, very slow - although it's been added in Chrome 35. I'm sure they'll rely on that full-time in Angular 2.0, maybe even as an option in a future 1.x Angualr release.
I agree on the module system, it's weird, causes naming clashes and I don't think it adds much since it's also not linked to a script loader of any kind.
As for the rest of your statement, I'm still going to say that application frameworks in Javascript are in its infancy; the single-page application paradigm is only ten years old (with Gmail being the first major one), and there have only been frameworks dedicated to SPA's in the past five years, with AngularJS only becoming popular in the past two (and solving a number of issues from its predecessors, like two-way binding, testability, etc).
Angular has its faults, but the alternatives aren't flawless either. Angular 2.0 will be the defining front-end framework for the next five years to come. It takes the lessons learned from Angular 1.x, Angular Dart, Durandal, and applies the bleeding edge in client-side scripting (ES 6). It's still got its weirdness (like square and round braces around HTML attributes, I have no clue what that's about), but I'm sure that none of the weirdness in that framework has been without thorough research and design discussions - I'd argue that it will be the most well-designed and well-thought-out front-end application framework in history, instead of a lot of current-day frameworks that sorta evolved into what they are today over the years.
Diff the virtual DOM to determine the minimal amount of imperative real DOM operations needed. Why is this so hard to understand as the optimal solution?
Heck, you can even re-render the entire DOM on every requestanimationframe. This is still better than AngularJS approach! Google Bloop for an example which is very easy to follow and can either support occlusion.
AngularJS is pure hype and ignorance.
React gives you a powerful V that expresses things so intuitively that for most cases it eschews the help of a C or an M. That's a good thing when it's achievable.
To the best of my knowledge, React is indeed the first "mainstream" UI framework for JavaScript to be so fundamentally built around a virtual DOM. I think as a minimum the React team deserve credit for popularising the idea and for raising awareness of the underlying performance characteristics of browsers that make the idea relevant in practice.
That said, many of the "big ideas" that have been popularised among front-end web developers in recent years by big name frameworks are not even remotely new to the programming world as a whole.
For example, it's hardly news to anyone who's worked on browser-based UIs that DOM updates are often the bottleneck. However, back in the days of IE6/7 and the early versions of Mozilla or even Firefox and Chrome, JS generally and DOM updates in particular were far slower than they are in modern browsers. People have been writing UI code specifically to minimise DOM updates since long before the likes of Angular and React came along, because what is done today as a performance boost for relatively large and complicated pages used to be a necessity to get acceptable performance out of any JS-based UI at all (the major alternatives being either plugins like Flash or Java, which ran routine UI code much faster in those days, or doing pretty much all of the work server-side using old school web forms).
It's also hardly news to anyone who worked with client-server apps a few years ago, when again things were much slower and more specifically bandwidth was a fraction of what we enjoy today, that sending patches instead of complete data can be an easy performance win. (People have been using the rsync technique for a couple of decades or so.) In the early days of what we might now call web apps, before JSON won and everyone had numerous JSON-friendly persistence and data binding libraries to choose from, a comedian developed a format called XML that accidentally caught on when too many people didn't realise it was a joke. (See also: XMLHttpRequest, the standard tool for retrieving JSON data from servers everywhere.) In order to avoid half the development team retiring before the first test XML data had finished downloading on a typical project, we got pretty good at designing diff/patch formats for these kinds of nested data structures.
Put those two ideas together, and as you can imagine, a lot of web developers wrote a lot of ad-hoc tools whose basic purpose was to take some sort of change set for the underlying data model as input and figure out some sort of reasonably small set of DOM updates to match. The canonical example would be something like updating a container in your underlying data model, where you couldn't afford to rewrite a whole list or table element in your DOM for each inserted/changed/deleted element in the container, so you had to bundle up the changes transaction-style and then flag the DOM for a single update at the end.
Obviously we've learned a lot since the early versions of this, and today we enjoy templating and data binding libraries that can be dropped into projects with negligible effort but do the same jobs we used to spend many days automating on each new project, with all the usual benefits of consolidation and peer review that come from having generic libraries with many users and many contributors. No doubt some of the techniques used in modern frameworks like React are far more widely applicable and systematic than a lot of the old code we used to use. So in this sense, again, perhaps the React team deserve some credit for advancing the state of the art.
Like others here, the app I was working on hit a hard performance limit with the digest cycle. When the main table of our app got to a certain number of rows it started to crawl on a desktop browser and was just unusable on a mobile device. And we tried so many things but there was just no real way out of it. It's crazy to me that people even offer up such things as infinite scrolling as a way out.
The weird thing was, I was by far the most experienced web developer working in that part of the organization, but all the backend/.NET dev and project managers were insisting on Angular as "the future of web development". I recall being spooked by how insistent they were, even though I had nothing against Angular at the time and wanted to learn it. Bringing up some performance caveat about data-binding wouldn't have gone anywhere, even had I the foresight to raise the issue.
I don't work there anymore but as far as I know they just... left it that way. So the most intensive users of the app got the worst experience. I know this is snarky but I suspect that's the kind of shop that should use Angular.
It is kind of nuts that angular is big.
> writes a solution using jQuery
Angular tries to be clever and solve loads of problems, sure tables and table rendering sucks anyways, but a simple querySelector with jQuery is 98% slower than just using normal DOM methods.
If you're gonna write your own bits of code to improve the caveats of any framework, especially in the financial industry, you go full hog and you write it properly.
Fixing an angular problem with a jQuery solution will get you marginal gains. Fixing an angular problem with a DOM solution will get you the best results and it isn't even that hard.
A simple querySelector with jQuery maps directly to a normal DOM method in browsers that support it.
There is the adage that "good enough" is good enough, but there should be another one that starting really bad stays bad no matter how many fixes get applied year after year (then the magical 2.0 happens)
Look at good enough languages like Perl and Python, they have their faults, Python 3 solves a lot of them, but 2.7 stays in production because it really is good enough. People don't go bailing on it for some other option because their codebases got unmaintainable, performance problems got O(n^2) or worse, they just go bail because maybe they want to try the compiled ease of Go or maybe touch Julia over numpy here or there.
Bad is bad, and people need to use just a bit of their algorithms class to figure it out. Shame that a ton of people asking similar questions about "how do I _______" results in a higher PageRank, while time tested easy to use options just hide in the shadows of good documentation and infrequent code updates.
Yup. Because it's literally using javascript scoping/inheritance directly. A new $scope object from a parent $scope can be treated the same as the new scope inside of a function block because it's how prototypical inheritance works. Not surprising that they used the scoping system of the language they're building in.
> Now that angular is being widely used, people are noticing that it's slow...
With wide use comes wide misuse. This is not new either. A hammer makes a crappy screwdriver, but it works. If you don't know your tool, you're gonna have a bad time.
> people are finally realizing Angular has its faults
I hope you're right. Because the more that people think something is perfect, the more it disappoints them when they realize that nothing's perfect. Use the right tool for the job and know its strengths and weaknesses and you're less likely to get caught with your pants down.
This seems rather confused. There's lexical scoping with function blocks, and there's prototypical inheritance on objects, and yes in the abstract both are used for dereferencing identifiers. The parent post's point is that Angular's $scope rules are as though every function's scope behaves like prototypical inheritance on the call site rather than lexical name resolution. This is analogous to every function call being wrapped in a 'with' statement.
In a new lexical scope, a new variable of the same name as one accessed via closure means I lose reference enclosed variable. In the same way, a new property of the same name as a property in the prototype chain means I lose reference to that property somewhere up the chain.
I have a suspicion that it's all linked lists of hashmaps under the hood, though I haven't checked the source. At the very least, prototypical inheritance and lexical scoping can definitely both be implemented that way.
With dynamic scoping there are no guarantees about where you'll find any nonlocal variable. In practice this caused enough difficulty that the programming language community has moved steadily away from dynamic scoping.
You make an interesting parallel with prototype lookup, but it's worth noting that the prevailing pattern of prototype use mimics the traditional class and instance rubric. In that situation it is also fairly easy and deterministic to pin down where in the prototype chain every identifier is defined.
* with the exception of code which uses `with` statements and certain forms of eval, which is a big part of why those constructs are strongly discouraged by the community
A: I've used tech X in a lot of Y contexts, and I find it's not great. I will generalise slightly imply that tech X is not the panacea that it has been presented as.
B: Yeah? Well, I've used tech X in a lot of Z contexts, and I find it works fine! You're wrong! You're using it wrong! Maybe you're not wrong in context Y, but for most other contexts X is still the best tech!
C: I haven't used tech X at all, but here's my opinion on it anyway.
"This technology contains trade offs and is complex at times."
Oh, you don't say?
Furthermore, I've found that it either let me shoot myself in the foot, or would not let me shoot wherever I wanted.
Some of these very high level statements could be made on any technology.
OK - So you think Angular is not good for "professional" work. Then what is? Present an alternative and compare and contrast them. Then we will tear it up and come to our own conclusions like the ruthless masses that we are.
Have I just drunk too much kool-aid? Or is it possible that with the right team, the right architecture, Angular can actually be a really great framework to use? The common theme for every large Angular project I've worked on is that the teams have leaned towards a more functional design where state is rarely used. This has always seemed to encourage smaller, decoupled modules which don't suffer from many of the problems that the author mentions.
But hey, it's probably the kool-aid.
I can't stand how some articles simply s&*t on years of software architecture principles and the work of very talented engineers and simply dismisses them like it's nothing.
If you disagree with a framework's perspective, AT LEAST be respectful.
BTW, I also have used Angular for 2 years and, given the pros and cons and existing alternatives, I will choose it again for my next big project. The structure is simply too solid. This is invaluable when you have a large team that must work together.
But we should also learn from where Angular succeeded and where it failed. Making XML declarative is fraught with difficulties. Things like ng-repeat are but a thin declarative veneer over the fundamentally imperative nature of constructing views. The biggest difference between most existing templating frameworks and React is in this world view: is the view constructed imperatively, or is it declared?
The other question of contention is how much implicit magic should the framework supply vs how much explicitness the user should bring into the code. Angular's design decision is to make bindings work magically, while React identifies explicitness as a virtue.
Having used both, I'm liking the imperative+explict camp.
My 2 cents: I actually prefer the declarative approach. My attempts at imperative view generation resulted in far more shooting-on-the-foot. Naturally, this is the very specific conclusions of me and my team, not the entire human race. I always think you should try both!
Also, I'm a huge fan of Polymer, which is also very much declarative. Going to use Angular instead of Polymer simply because of better project structure and browser support.
I'd be interested to know how many of your large team were not experienced web developers before starting with Angular given that is one of the big criticisms in the article.
I chose to use AngularJS in our team a year ago for quite a large web-app. It isn't perfect, but it is leagues ahead of whatever other choices I was and still aware of.
Regarding the brought up problems, they indeed exist. I think the true fault of Angular is that it gives the impression easy and friendly, while it is really, nothing of the sort:
"Come" it says, "Use my nice bindings. You don't need to worry, just bind all your data and will magically appear, no need to read the docs". Gladly you comply and all your data appears there. Magic.
"I see you have a lot of objects", says Angular, "go ahead and use ng-repeat to show them all... They will all manifest by themselves, no need to write anything." So you do that too, and it works.
Then a week later, when faced with real data in production, you have huge delays and the browser freezes for customers. "What have you done, Angular?" you shout angrily. "Now, now", it replies, "I thought you understood what you're doing, perhaps you should, after all, read all the docs, and maybe some blogs and videos about AngularJS performance tips, and of course, it is always suggested to read the source."
P.S I haven't played too much with React yet and I should definitely do so.
Maybe you drunk too much good practice-aid ;)
The Mithril blog is also worth a look, it addresses a lot of concrete scenarios with recipies to solve common front end problems with the framework. For example, here's a post on asymetrical data binding [3].
————
0. http://lhorie.blogspot.fr/2013/09/things-that-suck-in-angula...
1. http://lhorie.blogspot.fr/2013/10/things-that-suck-in-angula...
2. http://lhorie.github.io/mithril/
3. http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi...
Only when you need bidirectional bindings, and you're not forced to use the builtin `m.prop()` helpers, you can easily whip your own if they don't work for your use case.
See my last link for an example.
AngularJS is not a silver bullet or panacea. It has bad parts such as the directives API (making it hard to create reusable components), the global namespacing in the injector, and indeed, the number of watch expressions is an issue.
That being said, internally at Google:
- we do have well working, shared, reusable UI components based on directives. So it's quite possible to write usable AngularJS modules.
- There are multiple old (>3 years), large AngularJS apps that do not seem to have major maintenance issues. Maintenance of large code bases (>100k SLOC JS) is always an issue, but if you follow the style guide [0] at least it doesn't seem worse than with other JS frameworks
- Code is minified and compiled, using Closure Compiler's @ngInject and @export annotations as required.
OP's comments mostly sound like they were burned by not following software development best practices (e.g. throw the prototype away, make sure to properly design your domain model, have a qualified tech lead, have qualified engineers).
His "Lessons for framework (and metaframework) developers" seem generally useful, but unrelated to particular AngularJS shortcomings.
[0] http://google-styleguide.googlecode.com/svn/trunk/angularjs-...
In the modern closed web you unfortunately have to deal with legacy tech like HTML, JS, CSS which will never ever go away "because compatibility".
One thing I agree with the author about is the importance of expertise for a successful Angular project. Some specialized knowledge is needed to get a decent fit and finish, and the results can be horrible without that.
Strongly discouraging globals goes a long way towards improving code written by inexperienced engineers, but Angular's provider system is still not clearly documented with practical examples, which makes those engineers more likely to shove everything into the unavoidable Angular constructs (controllers, directives, $scope).
The middling quality and small availability of third-party Angular libraries is a problem. I believe that greater awareness/better tooling for ngDoc would be a tremendous help there. Best practices are not well-presented anywhere in the Angular world, particularly for designing reusable Angular libraries.
The other big problem is the project source code which I find poorly organized and documented. If you want to get into the guts of Angular for debugging purposes, good luck!
> That said I've found Angular to be more than flexible enough to meet the needs of your typical CRUD apps
The OP says:
> Are there any use cases where Angular shines?
> * Building form-based "CRUD apps".
So I guess you and the OP pretty much agree.
It seems like the author is simply unhappy to be working in a framework not of his own design: "Create a metaframework based on angular, tailored SPECIFICALLY for your project needs and your team experience!" That's the one thing you shouldn't do if you want to reuse code between projects.
(some abstraction is fine, but a metaframework on top of a framework is just going too far.)
Would you really use DOM/virtual DOM templates to make a game? it makes little sense. I dont believe any "MV*" framework is suitable for games,even if the game is DOM based.
In a game,what you want is to make sure that at time T,the screen reflects the state of the game.Since you are manually pooling all states with a timer in order to render the game on screen,there is no need for databinding.
From you wrote, you implied that maybe you mostly make only typical CRUD apps, when you write that's where you've found Angular to be more than flexible enough?
So that could explain your different experiences/analyses? You both actually agree it's good for typical CRUD apps?
I will however stick with angularjs because frankly there is no better alternative.
the selling points for me are:
- Testing:Karma,Protractor,dependency injection are fundamental when working with a team.Everything is so easy to test,so easy to mock.
- Speed:Sorry but there is no other framework that makes front-end dev faster.I can come up with very complex apps within hours,fully tested.
- Resources:20+ books,hundreds of blogs,1000+ directives on the web.
- Easy to integrate with legacy jquery mess:since jQlite is compatible with jQuery,I can just drop a jQuery plugin in a directive observe something with no effort and have it rendered properly.
The main drawbacks:
- Dont expect to understand angular without a serious understanding of javascript.
- Performances: yes there are performance issues,but when they show up,one needs to work on these issues.
- Probably too much hype.
I'm currently working on a comparatively large webapp built in Angular and it was after about 7 months into the project that we started realising it's pitfalls, and it was very difficult to abandon it then.
So we worked it around by: 1) using one-way binding (or bindonce to be exact) to reduce watches 2) avoiding un-necessary $apply() and using $digest() carefully if required 3) using ng-boilerplate for scaffolding 4) defining our own style guides/coding conventions/design patterns to overcome Angular's bad parts 5) frequent code-reviews that made sure new team members are upto speed with the above techniques
luckily we haven't ran into much issues after that :)
If by the time Angular 2.0 is launched then I'll definitely give it a shot, it seems promising and is based on ECMA6 utilizing the new features provided by it will be a plus.
IMO AngularJS can be scaled _IF_ used with caution, though I won't recommend it unless one has a good experience with its core.
> React is just the V in MVC, Angular is / can be the rest.
that's why its more of a micro-framework, its pluggability with other frameworks makes it customisable according to the proj requirements
It definitely is the V - since it renders the view.
But it is also the C - a component encapsulates the view and view logic together. From within the component, you have lifecycle events: when the component is mounted for the first time, whenever it receives new properties, when it is unmounted etc. In any of these events, you can receive data from the external world through AJAX calls. Or you can set up AJAX calls from outside the component, and in its callback, ask React to re-render the component. There are as many ways to update the data model inside the component as we can possibly do with Javascript and callbacks. This is exactly what a Controller in a traditional MVC does: orchestrate data flow between the external world and the view. React does it beautifully.
React can also be the M, or it can compose it into the component. You can have your own validation methods and business logic that mutates the state in the component (a component is simply a Javascript object with state); or you can compose your custom Javascript object or something like Backbone.model, and keep all your logic in there.
And you can use react-router for routing. What else do we need to compare React with Angular?
You've done the easy things after 7 months, and the hard things are always going to be hard.
It rather makes me worry it is going to be the Python 3000 release all over again in terms of how much is changing.
It looks like `master' is all Angular 2 and coming along well.
138 JS files v > 1000
Fingers crossed that isn't the level of Hello World required either in the world of 2.0 and AtScript.
The underlying technology is changing so fast (ES6, web components, mobile web, etc.) that it's going to make upgrading an obvious choice even if it involves relearning a lot of stuff.
and also do you think they'll continue with the 1.x releases? since so many developers have already invested time and effort on their webapps and shifting it to an entirely new framework (read release) is a major cost to pay..
https://www.youtube.com/watch?v=LG9VkCDbte0&feature=youtu.be
They say the exact plans for how long they are going to support 1.x won't be finalized until after 2.0 gets released, so that they have some idea of how difficult it's going to be to migrate.
1. It already has a much bigger and growing community than any of the new frameworks
2. It has backing/support of Google, when such a big company puts steam behind something than you can be sure it's not going to die out just like that, and will continue to grow and improve, no other framework other than ReactJS has such a portfolio
3. Third-party plugins/components, AngularJS already has some amazing libraries/plugins/directives built that one can easily plug into the project (this is by far greater than any other new frameworks coming out)
and one can go on...
I've also used Angular for around 2 years for a large application. This article resonates pretty accurately with the problems we were running into before I decided to write Mithril.
It can certainly work well (heck, the mobile part of our app was doing just fine because it was specifically designed to be a trimmed down version of the much more powerful desktop app), but performance problems aren't necessarily because people don't know how to use Angular. In our case, performance problems usually became obvious when we had UIs for editing large volumes of information, and large volumes of information did appear on the page. Two of the examples that we were running into problems with were a work breakdown structure UI, and a scheduling UI, which are far from being things-you-should-not-be-doing.
The team scalability issue is real, but I think it's not entirely Angular's fault per se. My general experience w/ co-workers dabbling w/ Angular was that they were accustomed to jQuery in terms of discoverability (i.e. if you don't know jQuery, you can fake it w/ Google-fu until make it). Getting into Angular is not like that at all. There are lots of places where you can shoot your foot if you don't do it the right way (tm), and deadlines will trump doing it the right way if the right way is sufficiently non-intuitive. You can blame that on teams not having good processes or good developer or what have you, but hey, that's the real world for ya.
My main problem with Angular is the error messages. Imagine writing this:
$(".foo").each(function() {
this.addClass("bar")
})
Mithril.js seems like something I would study in my maths class (its a good thing). I have spent a good amount of my last year trying to get better at angular and wasting a large amount of my time. Angular.js has seriously colored my image about google's engineering poweress.Looking back I put my intuition and education at the back seat - due to my own insecurity of my intelligence - google must be better than me right ?
I like having one layer that covers the UI display and UI events. This layer does nothing beyond styling, setting up the UI and using messages to pass back events in a generic way.
My business logic handles generic events. So say I have a button for saving, in my UI layer it registers the click event but then sends a generic message with a payload that is simply "Save". The business logic then saves it. This let's me drastically change any of the UI with zero affect on my business logic.
I wouldn't recommend it yet for production (very early) but I'm working on a small library that does much of this messaging and binding of messages directly to DOM objects. https://github.com/KrisSiegel/msngr.js
I feel like I spend a lot of time trying frameworks, only to find very little benefit. Happy to learn more, but would love to have some basis of comparison to some tech I've worked with to date.
JavaScript isn't really a good place to adopt convention - you're dealing in a mixed-code environment almost from the start, speed is constantly an issue if you're doing something complex, and there's no such thing as "one size fits all."
I've looked at almost every JavaScript framework out there, and they really don't offer much more than what you would get out of a very lightweight jQuery (or your library of choice) abstraction. I want very much to find something that is as useful as the programming friction it introduces, but I haven't really found anything that meets that criteria yet. React seems to be very good at face value, but in general it isn't saving you nearly the amount of code that you might hope it does. Ember is probably the best at this, but it has its own tradeoffs (namely speed).
Take example of rails. I was trying to learn it sometime ago and was really amazed how it has a process for nearly everything. Migrations, asset pipelines, generators, and very extensive command line. Sure it does make it seem like "Once I learn it, it will be so much easy to make the next app" but it is easy to realize after sometime that you have to cross usual hurdles of Googling everything, learning these processes, facing issues, digging out new ways of debugging to finally be good at it.
My idea is that frameworks should be minimal which only ensure a basic working architecture and everything else should be extensible (via packages).
Ultimately, you should control the architecture of your application. When this is the case, you can develop abstractions around libraries that shield the rest of your code from their bugs, 'conventions', and error handling strategies.
I worked on Angular last year building an app with a few complex views. The initial days were full of glory. Data-binding was new to me, which produced much goodwill towards the framework.
Things started falling apart as I had to inevitably understand the framework in a little more depth. They practically wrote a programming language in the bid to create declarative templates which knows about the Javascript objects they bind to. There is a hand-rolled expression parser (https://github.com/angular/angular.js/blob/v1.2.x/src/ng/par...), new scoping rules to learn, and words like transclusion and isolate scope, and stuff like $compile vs $link.
There is a small cottage industry of blogs explaining how Angular directives work (https://docs.angularjs.org/guide/directive). The unfortunate thing is that all of Angular is built on directives (ng-repeat, ng-model etc.); so till one understands it in depth, we remain ignorant consumers of the API with only a fuzzy idea of the magic beneath, which there is a lot of.
The worst however was when we started running into performance problems trying to render large tables. Angular runs a $digest cycle whenever anything interesting happens (mouse move, window scroll, ..). $digest runs a dirty check over all the data bound to $scope and updates views as necessary. Which means after about 8k-10k bindings, everything starts to crawl to a halt.
There is a definite cap on the number of bindings that you can use with Angular. The ways around it are to do one-time binding (the data won't be updated if it changes after the initial render), infinite scrolling and simply not rendering too much data. The problem is compounded by the fact that bindings are everywhere - even string interpolation like `{{startDate}} - {{endDate}}` produce two bindings.
Bindings are Angular's fundamental abstraction, and having to worry about its use due to performance issues seems quite limiting.
Amidst all this, React feels like a breath of fresh air. I've written a post about what makes it attractive to me here: http://www.jasimabasheer.com/posts/on-react.html.
Compared to Ember, neither Angular nor React dictate as rigorous an organization of files and namespaces (routes, controllers, views), and have little mandatory conventions to follow. But React is as much a framework as Angular is. The event loop is controlled by the framework in the case of both, and they dictate a certain way of writing templates and building view objects. They can however be constrained to parts of the app, and so can play well with both SPA and non-SPA apps. The data models are plain Javascript objects in both (it is not in Ember), which is really nice.
Google recently released a new version of their developer console (https://console.developers.google.com) which is built on Angular. So the company is definitely putting their weight behind the framework. However, Angular 2 is not at all backwards compatible. That was quite unexpected. If I had known this going in, I would have never used it for the project. But it felt like such a good idea at the time...
Large grids were rendered using jQuery's DOM methods. The data-flow was made explicit, and the view was updated whenever any change was needed.
React embraces the explicitness of data flow instead of watching the objects in the background. This is done using `setState`, which queues up a re-render of the virtual dom.
> Google recently released a new version of their developer console (https://console.developers.google.com) which is built on Angular.
Which actually works worse than the previous version. The layout is non-responsive and creates massive amounts of scrollbars on "portrait"-monitors, while 90% of the screen is effectively white-space.
Completely wasted. Completely pointless.
So whatever Angular-templates Google is using, they are clearly not (any more?) adhering to responsive design nor using pixel-independent CSS, and in 2014 that's pretty sad.
- Angular isn't designed to render large tables. Go with DataTables for jQuery instead, or if you don't need all the features there then maybe you can get away with ui-grid.
In general though if you're running into performance issues because you have too many bindings, then you're probably using it for things it wasn't designed for.
Also, don't forget 'track by' for improving ngRepeat performance:
http://www.codelord.net/2014/04/15/improving-ng-repeat-perfo...
"...but if you Google for ngRepeat performance there are tons of discussions on this."
Sure,the difference is React doesnt tell you how to organize your application.AngularJS does,you have to use dependency injection.I like it,some people dont.
AngularJS is in no way perfect.But compared to other frameworks,Ember,Backbone,... In my opinion it's better.
I personally dont like React because of JSX,I dont want to have to learn a JS superset,and i'll probably wont like AngularJS 2.X because of atscript either,wether it's mandatory or not(understanding exemples on the web will make it mandatory).
I personally like JSX. It is more of a variant of Javascript that lets us mix HTML into JS seamlessly. It was inspired from XHP (https://www.facebook.com/notes/facebook-engineering/xhp-a-ne...), a PHP extension developed and used by Facebook that lets PHP understand XML. I think that the cross-pollination of this idea into React might be one of the best things to have happened to front-end development in the recent past.
JSX is different from HTML in a few simple ways (http://facebook.github.io/react/docs/jsx-in-depth.html):
- All HTML attributes are written in lowerCamelCase, like so: contentEditable, maxLength etc. React has a wonderful "is this what you meant?"-style warning system for when we slip-up on these details. More on HTML attributes in JSX is here: http://facebook.github.io/react/docs/tags-and-attributes.htm...
- You can't use `class` to denote CSS class names. It is always `className`. You are going to forget this as you copy-paste a FontAwesome icon definition or Bootstrap snippet into the project and wonder what went wrong. But practice makes perfect.
- If you want to write inline styles, the style attribute should be written as a Javascript hash (it is actually a blessing in disguise). React documents it here: http://facebook.github.io/react/tips/inline-styles.html.
I haven't found any other incidental quirks in JSX, and it integrates nicely with Javascript in practice. It is however different from the way things have always been done, which can be a good reason for resistance.
That's a subtle thing but important enough when you're working on big projects.
What do you gain from that? You don't like it because you haven't really given it a go because you'd have to learn something new? JSX is very low resistance to learn. Not that you have to use it; it's worth learning it because it makes you more productive.
I use Angular for my main product, but chose to go with React for a new small sub-product to see how it worked. I learnt JSX, I learnt how you should do things. I followed something similar to the Flux patterns in the time I had available. Now, I feel in a much better position to make an informed choice in the future. Using React helped me to appreciate the things Angular does well, it also showed me areas where things could be done better.
There isn't a 'better' framework in either case. You need to understand the tradeoffs to know where one or other is going to be a good fit. This is always the case in software.
- JavaScript - React.render - React.DOM.tagName(props, children)
I agree about JSX, because it introduces 1) general complexity, 2) steeper learning curve, 3) incompatibility with other tools.
But React works fine without JSX! Just structure your app properly with small components and DOM.div(...) isn't that noisy.
React handles rendering completely different though, and it's not a drop-in replacement for all of Angular. I probably would look at React if actual view rendering becomes an issue though. For the app I'm working on it's not, it's usually a single rendering pass without too much interaction.
The thing I would like to add to the debate is this: We've all learned that Angular is hard. It's a complex beast with it's own nuances and idiosyncrasies. It also offers plenty of ways to do things you probably shouldn't do (i'm looking at you expressions). But more than that, with Angular in the tool box, people push themselves to deliver products vastly more complex than would be feasible without it. And these two issues collide all the time. Learning a framework + the desire to deliver more; One should follow the other, but people tend to attempt both at the same time.
I personally don't think there's anything "wrong" with Angular, but people have to acknowledge that despite the marketing hyperbole, learning Angular means setting out on a long and difficult journey that will require the developer to rethink a lot of what they know about building web stuff. But that's web development in a nutshell. It's a different gig every year, and within an alarmingly short amount of time, Angular will probably be replaced with something better suited to the tasks that try to accomplish the thing we want to accomplish with mere HTML, CSS and Javascript.
There's also a lot to be said for how you organise your projects and what tools you use (eg Require or Browserify etc etc), but that's a very different kind of conversation.
Angular's a controversial topic. So if you're going to write a long blog post picking a side, you really need to back it up with examples and offer alternatives. The six part "detail" posts aren't much better.
But this article is not Angular specific at all, it stays on a very high-level. Replace the word Angular with any other web framework and the article would still make perfect sense.
Not that the article does not have some value, just that it has very little to do with its title.
Its good to have feedback from the community, but I wish some of these posts would get down to the specifics, we would all benefit much more. Something like: "I tried to this (details) in Angular and it was difficult, tried to do it again with this other framework and it was much easier".
http://www.fse.guru/angular-bad-parts-part-1
http://www.fse.guru/angular-bad-parts-part-2
http://www.fse.guru/angular-bad-parts-part-3
http://www.fse.guru/angular-bad-parts-part-4
>'Dependency injection lacks some functionality you will need sometime.'
But fails to reveal which functionality he has in mind.
He later claims that 'inheritance is an antipattern' and posts a link to google search results as 'proof'.
Not worth reading, in my opinion.
Having to click a link to reach the information you need, isn't a big deal IMHO. It's the content that should be discussed. Personally, I don't see anything wrong with posting links to prior (or other) blog posts.
That said, I'm not sure Rails and AngularJS are direct competitors as many apps use a combination of both frameworks or more generally Rails + JS-framework.
It seems that the poster got bitten by some problems and blames it on angular. I recommend an exercise to current and future angular users: really try to understand HOW you would implement angular features such as two-way binding or modules or directives. If you do this you will understand that problems such as described by the poster in http://www.fse.guru/angular-bad-parts-part-3 are really due to his own misconception about what the framework should do and what it really does. I've been working with angular for two years and never had the problems that the poster reflects. I've had other problems but I would argue that for the most of it, I like the way angular is designed and like the compromises they took (mostly dirty checking to make two way binding work automagically).
So, this article is definitely not generic. Maybe, if you're reading at the bottom of the article, you can call it generic, because the advice for future projects is good. But otherwise, it's spot on. I can only hope that the Angular dev team sees this blog post and incorporates the recommendations into version 2.
I've spent the last year working on a complex and widely-used site that is built with Angular. It is maintainable, performant, has a smooth UX, and is mobile-friendly.
I'm usually extremely cautious about relying on frameworks for long projects, because easy setup doesn't matter after you've been working on something for a year. In our case, using Angular was the best choice we could have made. I would absolutely not replace Angular with my own in-house MVC, even if you gave me a year to develop it.
-The testing tools are some of the best I've used, and hugely contribute to making the app easier to maintain
-It's not as much of a framework as a set of tools. Angular mostly stays out of the way and mostly allows us to structure code to match our needs
-You absolutely need to have top-notch developers, and ideally someone experienced enough to mentor people on the team who are new to Angular. There are a lot of JS developers who are former Flash designers who learned how to use a few jQuery plugins. If they don't know the fundamentals of programming really well, they will make a huge mess of the project.
-We've definitely run into performance problems, but they're manageable. We've had to write code that bypasses Angular's digest cycle, but it feels similar to writing a bit of inline assembler in a C++ program. I wouldn't stop using C++ because of that.
It is not just a CRUD app. It has:
~170 views ~70 custom directive ~100 controllers
Many directives can execute on the same page.
A single page can have multiple tabs, forms, modals, charts.
I hit some situations where performance dropped a lot but if you take the time to benchmark and test you can fix it.
The key to keep it stable is to load the UI (directive) when you need it and destroy it when you are done.
Personally, I've not found any serious issue so far.
I say, be thankful for the flux currently underway, and realize that it will result in some really good tech when it's all sorted out. Until then, either get used to learning new things, or leave front end dev to the professionals.
He came to that decision just after we committed to angular... :(
Having a glance at Mercury. Looks interesting, but react is working so well for my projects I'd need a damn good reason to give it up.
To save the next guy some googling:
Now I'm trying to figure out if the bad parts in Angular are worst than the bad parts in React. I don't have an answer yet.
The only thing I'm sure is that the virtual-DOM thing is a good idea and most frameworks are likely to converge here.
Which are...?
My current app is actually still back on Marionette 1.0.4 for various reasons, so I'm not as familiar with the changes in the latest versions of Marionette. Looks like they've added a considerable amount since then.
Many of the largest sites on the internet don't use them in any significant way, and you could just as easily use Django to server HTML/CSS to browsers, as well as a Rest endpoint for mobile apps or other users of your data.
I have used a fair number of websites recently which used front end frameworks badly and ended up causing all sorts of havoc (not being able to save the page, random {{ things like this }} appearing all {{ over }} the place at inconvenient times, pages just not loading, janky controls, etc.)
In short, bugs that don't happen when you have static web pages and forms and a smatter of javascript.
In almost all of these cases I think users would likely not have noticed a substantive difference between an angular-style web app and simple HTML forms.
I'm a huge fan of Backbone. Its small enough to learn the in's and outs of it and also allows you to control the structure / design of the application.
This definitely has pro's and con's but for us it means we can swap developers and theres a design pattern thats easy to understand and implement.
We're actually building a pretty large Ember project at the moment (a project management tool called Matterhorn). Its been a great experience and we're planning on using it for all of our client projects going forward.
The learning curve is a little high and the 'plugin' eco-system is lacking to say the least. I actually think this is a good thing though as most people write terrible plugins. Roll your own and own it.
- create a big form based on an XML schemas, the form will be used to generate valid XML with the schemas
- some schemas can be really big with more than 3000 elements, the whole thing won't be shown in full to the user directly but probably folded
- because it is based on XML Schema, it must have interactivity to make some elements repeatable, and groups of nested elements repeatable, some elements with bounds, some maybe draggable to reorder them, everything an XSD can do...
- it will also some kind of polymorphism where you can choose the children element type and have the corresponding schema showed
- it will also show a leaflet map, with some interaction between the form and the map
- there is also a rich text editor where you can arrange xml objects between formated text
I fear that angular won't be fast enough for that, but his support for forms seems better, I've tested JsonSchema forms generator like https://github.com/Textalk/angular-schema-form and https://github.com/formly-js/angular-formly the first one is slow when editing 3000 items the second seems fast when editing, and slow when it generates the json. I've done some angular tutorials and their concepts don't stick in my head. I've tested React and their concept stick easily in my head but there is less native support for forms.
I had just decided to go with angular partly because of all the hype around it, but I see the article and others as a bad omen and I want to go with react now. Any advise ?
Try building a simple nested tree in both Angular and React to see how both feels.
Khan Academy has open-sourced their QA builder that supports creating questions and answers with graphs, radiobuttons, multi-selects, images etc. It is built in React. Take a look here: https://github.com/Khan/perseus
In fact we should be striving to get away from all of those monolithic code bases as much as we can. In the cases where we can't get away from that then we should be going with tried and trusted methods of building those apps and probably relying on the server a hell of a lot more for those kinds of really large/enterprise/corporate apps.
Most use cases for angular are to make a web app that pulls and pushes data from some Restful service. Angular lets us take that web app, through cordova/phonegap/etc, and wrap it into a mobile ready application that you can push to an app store.
Whats wrong with that?
Seriously though, I've used Angular just as long as the author and for the most part I wholeheartedly agree with the complaints (and I have complained myself for some time). However, what is the "better" way? People keep throwing out things like React, but React solves much less for app developers. Also, that answer doesn't help the countless people who began app development more than a year or so before React was released.
The Javascript ecosystem is evolving constantly and yet in some ways not much at all. Throughout that time, I've found that just about everyone can find excellent reasons not to use the various frameworks and libraries but few offer concrete recommendations in exchange for these criticisms. It's disappointing.
At this point in our own project, like many others I assume, we are reconsidering Angular. Not simple because we don't like it, but because clearly the Angular team doesn't either. Angular 2.0, like Sproutcore 2.0 before it, appears to be a complete rewrite. (Rightfully so.) As a result, we plan to examine our other options in detail while our work is still mostly in the prototype territory.
Right now however, I don't think I've seen anything yet, that makes sense for most people who've started out with Angular to do that re-write. I'm hoping as I spend more time examining this I'll find I'm wrong.
I've had many people ask me what framework they should use for new projects and every time I've said, it probably doesn't matter use right now, but be prepared to fully rewrite things in a year or so. The JS ecosystem is in so much flux right now that you can't count on any of these choices being the right one in couple of years. I've accepted that reality for now.
People hate this answer. They tell me that no PM/Exec is going to want to hear that. Fine, don't tell them. The silver lining is that whatever does comes to save us will hopefully be so much more productive than what you were doing before you won't care about rewriting it, you'll do it because it actually makes sense.
Let's all hope that's true.
But most developers think, that when they learn once a Framework, they can use it for any kind of project.
When i read "xxx is really cool and fun" iam really careful. Most people create a "Hello World" and then THEIR favorite framework is the greatest thing in the universe and they communicate it to others.
Take a framework, live with the mistakes, until the next "better" framework appear... and it will appear, and the next, and .... ;)
This article is pretty accurate for the most part, although some of the minor complaints are not quite so accurate.
Performance is something to be careful about, but the Angular team has worked hard at improving it and it has improved immensely with 1.3 - optimizations such as bind once & $watchGroup and optimizations around the $digest cycle and $watch make it a huge improvement over 1.2. I want to say there is a chart floating around showing over 30% improvement.
As far as frameworks go, I believe Angular is the best we have currently. It does a lot for you without getting too opinionated in general, and some of its tooling is just flat out better than much of what you can find in the wild.
I have been experimenting with Polymer lately though with an eye towards web components - there is a lot of change coming in how we will have to structure our code. I suspect that those using React will also not be shielded from the pain of integration with ES6 and web components as well, and so I have been hesitant to recommend it in a core product. Ember claims they will make the breaking changes slower, but I also suspect that it will limit its growth as well.
Frontend seems to be rolling on as fast as ever - I don't see much of a way around everyone having to scrap their code regardless of the major library chosen for their projects. I'm hoping the pain dies down once ES6 and web components becomes the norm though.
Anyway, my point is, both of those aren't production-ready.
I suspect Angular 2 will be the best we have once it comes out, but I also question some of the decisions made from certain perspectives. At least they're listening to the community, evaluating the feedback and suggestions, and incorporating it into their decision making though, such as the change with the HTML templates.
It's also hard to motivate starting a potentially large project in Angular right now, knowing that v2 is on the way that is basically a new framework.
I can understand how someone coming from more traditional frameworks, and working in an environment where you are rarely or never required to think outside the box, will have difficulty making the transition.
Where I personally think Angular could be better (yet was state-of-the-art when it originally came out) is with directives. Now, I'm not talking about run-of-the-mill directives that are easy, that implement relatively straightforward concepts. I'm talking about highly complex functionality that you want to encapsulate into a single "thing" in your code. I think Polymer is going to fill that gap. That being said, Angular team has already (if it hasn't changed) decided they're going to be moving forward with Polymer.
Personally I think Angular + Polymer is going to be hard combination to beat.
Teams with varying experience.
Projects, which are intended to grow.
Lack of highly experienced frontend lead developer, who will look through the code all the time."
With any team that has varying experience, the beginner developers are more likely to write bad code regardless of the framework. You need to be careful with any project that is likely to grow.. it's called technical debt. You always want someone experienced with the domain to look through the code.
The solutions include, coding standards, code reviews, pair programming, refactoring, automated tests.. all the usual agile suspects.
I'm big believer on light frameworks that does least amount of abstractions and can get out of way if you need. You definitely want to avoid frameworks that claims to abstract everything away and especially those that requires to learn entirely new way of doing pretty much everything and its own world of lingua franca. My preference therefore gravitates towards lighweight stuff like KnockoutJS and likes. Any average dev can understand KnockoutJS in just hour or two. More importantly, most devs can immediately have intuitive understanding of how things work under the hood and therefore can anticipate performance issues or easily extend it.
Like with every software development, actually.
Please links to examples of your code, author.
I wonder how people can't understand all the power of the 'directives' approach it's the MOST powerful thing in web development now and only advice I can give to future inventors of new frameworks: implement 'directives' concept, and then do everything you want else. It's advice after my 3 years with Angular, and counting ;)
Reusable code and TDD is the key for growing apps and directives - most successful following of this way.
---/ please news.ycombinator, treat new line symbols as new line symbols and use ANY modern framework to make this site less slow and more mobile friendly
The momentum behind AngularJS is huge, and with the 1.3 release I feel like 90% of webapps can be written well in Angular. Ionic is a great example of pushing AngularJS to the edge with mobile applications.
It really is up to the team to enforce good practices, pair or review code and refactor and unit test components. There is no framework which can make this happen, you need to be disciplined and always look to leanr more and improve the code you have written.
The author certainly does not recommend anything else, so where to now?
On the other hand, I agree with the author that there is a tipping point where a framework/tool becomes too much of a burden. Sure, we can all do it the "right way" but teams don't always have people with the experience to even know what the right way is.
We should think about the frameworks we use as tools. Make sure the tool is right for the problem and the team. Also, don't try to apply all your older experience to the new tool. Take time to learn about the thing you use.
Angular is the Rails of Javascript.
That probably sounds like a derogation. But behold: I offer nuance!
They're both big and powerful, and capable of rewarding dedicated study with enormous power. Thus they develop a devoted following whose members often do things lesser mortals find little short of wizardry.
They're also both built to be friendly and welcoming to the newcomer, and offer a relatively short and comfortable path from zero to basic productivity. Thus they trigger the "I made a thing!" reward mechanism which excites newbies and leaves them thirsting for more.
They also, in order to go from newbie to wizard, involve a learning curve like the north face of K2.
In both cases, it's a necessary consequence of the design decisions on which the platform is based, and those decisions, by and large, have sensible reasons behind them -- not, I hasten to note, decisions with which everyone will (or should) agree, but decisions which can be reasonably defended.
But that doesn't make it a good thing. When people start off with "I made a thing!" and then run smack into a sheer wall of ice and granite, initial excitement very often turns into frustration and even rage, as on display in some comments here in this very thread.
(I hasten again to add that I'm not judging anyone for being frustrated and angry over hitting that wall -- indeed, to do so would make me a hypocrite, given my reaction to hitting that wall with Rails a year or so ago.)
Further compounding the issue is that, often enough, wizards who've forgotten the travails of their ascent will condescend to say things like "Well, what's so hard? Just read {this book,that blog post,&c.} and it's all right there." Well, sure, for wizards, who are well accustomed to interpreting one another's cryptic aides-memoire. For those of us still toiling our way up the hill, not so much.
I will note, though, that while I hit that wall (hard!) with Rails, and in the end couldn't make it up, I haven't had the same problem with Angular. The sole significant difference I can identify, between the two attempts, is this:
When I took on Rails, there was no one else in the organization who knew (or should've known) the first thing about the platform. When I had a problem with Rails, I faced it all alone, with only my Google-fu, my source-diving skills, and my perseverance on which to rely. For a while I did well, but in the long run, for all but the most exceptional engineers, such expenditure of personal resource without resupply becomes unsustainable.
When I take on Angular, I do so with the support of a large team, composed of the most brilliant and capable engineers among whom I have ever had the privilege of working. When I have a problem with Angular, I have a dozen people at my back, at least one of whom is all but guaranteed to have encountered the exact same situation previously -- or, if not this precise permutation, then something very like it, from which experience more often than not comes precisely the advice I need to hear, to guide me in the direction of a solution.
Of course, whether this is really useful to anyone is an open question; I think it's a little facile, at least, to say "Oh, if you're having Angular problems, all you have to do is find a team of amazing people who mostly all have years of Angular experience, and work with them!" But, at the very least, if you're going to be fighting through the whole thing all by your onesome, maybe think about picking up a less comprehensive but more comprehensible framework, instead.
However, if you don't draw lines in the sand for yourself and watch performance very carefully as you scale, your app will suck. For reasons of maintenance or user experience, it will suck.
It's awesome for tiny projects or things that won't need to be changed or internal use stuff. I personally am using it to build a prototype of a product. But I'm planning to convert this prototype very soon to React or Meteor.
IMHO in general the core functionality of a clientside framework is to provide a way of structuring the app and allow for communication between logical units that are nestable and modularized.
If a basic framework does that, and only that, it should be bulletproof. I admit, it took me 10 years to rethink and recode this over and over - and there is no end in sight.
I love this discussion, it reflects much of my thoughts about the issue.
And not only for AngularJS but as design principle.
So many things and places are just doing things "lean" and "iterating" so angular makes that easy.
I'm not sure anyone could tell me Angular isn't very productive and that it wouldn't be tempting to use it so you can get some fairly magical experiences for users and in demos.
It matters little whether some find it productive, what matters is that the engineering principles it is based upon are fundamentally unsound.
Control and conditionals in attributes are absurd. Especially when they require learning an expression language unique to that framework. Especially when they create side effects. Why should something as simple as a loop or if create a new controller and scope? This is absurd. The expression language is not statically analyzable to boot.
There is no reason for a framework to do anything beyond handling the last mile tranform between view model and DOM. Everything else can be done through JavaScript and modules.
JavaScript is a wonderfully expressive language, reinventing that through some hacked up expression language makes no sense and buys no advantage.
Bindings can be handled through a multitude of great npm modules.
Watch the video of the Google Analytics team explaining the cortitions needed to make AngularJS performant. Watch the videos where the AngularJS 2 team discards nearly everything from 1.3 (and then adds their own comical nonsense).
Declarative DOM manipulation through a virtual DOM is the future - every more than web components will be. Why? Because instead of being another "web framework", is it sound computer science.
I disagree. What matters is whether you can produce a working application - and iterate on that, but after actually releasing. Angular is modular enough to allow for gradual optimization (like integrating React et al), instead of doing premature optimization.
Using vanilla JS like you recommend will lead to a lot of reinventing the wheel, and for new developers to have no clue what's going on (they have to learn the framework you thought up). At least you can make predictions about applications when it says 'AngularJS' on the job advert.
JavaScript code can be easily written for reuse and composition. When a framework attempts to co-opt that there should be a very good reason. For Angular no such reason exists.
I love angular, but perhaps thats because I'd only worked with jQuery before.