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.
No idea what you mean when you say dirty checking is O(n^2) - each watcher is checked once per loop. With 100 watchers you get 100 checks, not 100 * 100...
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.
It is not, in the technical sense, O(n^2). Since it is being performed on a persistent basis, asymptotic analysis is not even quite the right tool to use - there is no single "input" and "output".
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)".
Oh ok, we're agreed. You'll not be having digest loops per second though, that'd be quite a weird situation :)
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.
I knew someone who consulted a large bank not to use Angular for financial apps. They were insistent to use Angular until he finally showed them a fairly typical requirement of an app like that in angular: 5 tables with 100 rows and columns. It literally crawled when running on a Dell Workstation laptop.
My team is using Angular for an app that contains large tabular data all over the place. We ended up having to rewrite the table generation in jQuery and now we've got a POC in development using React. Most other places we've had to use shims like angular-once to make menus performant. At this point we're building work-arounds for most of the things that makes Angular special.
Yeah, that's the final irony of all this. They get you hooked on the cool, easy two-way binding and then later you find out that whoops, it's actually a fundamental architectural problem and you get to go back and rip it all out. Good thing we picked this framework that saved us sooo much time!!
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.
apart from the overhead of finding out if the normal DOM method will work - and the overhead of parsing the selector to make sure it's not using jQuery extensions.
I don't understand this. Were they using angular grid? Because I work on an app that has tables with ng-repeat attributes and it is insanely fast. It loads hundreds or thousands of rows into about 200 columns that are separated by tabs. The client side filter searches are instant.
> Angular's scope system is exactly analogous to the scope system of a programming language.
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.
"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."
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.
My thought pattern on lexical scopes in javascript is that they're essentially a new object off of the prototype of the parent lexical scope. At least they have very similar properties.
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.
The advantage of lexical scope over dynamic scope is predictability. You can reliably* read a javascript program and map each variable access to the scope of that variable (so can a compiler, which accounts for no small portion of the speed of modern javascript implementations).
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
And it's all so you can type `model.key = value` instead of `model.set(key, value)`. When I began using Angular I thought the latter was clunky and verbose. A few months in I would have loved to have that control back. And yes, the scoping was a nightmare.
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.
1) Google was behind angular, Google has a huge marketing team, and there is a surreal amount of Google love in the developer community.
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.
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.
Interesting. I recently heard in a Podcast that Misko Hevery (a Googler) created Angular as his 20% project with the scope to make it easier for web designers to create dynamic prototypes.
Angular's scope system is only weird because they picked the name 'scope'; more modern angular applications / usage drop that one and use the 'controller as x' syntax, where instead of assigning values to a $scope object, it's assigned to the controller itself via 'this'. It's still effectively the same, but you won't be confused with scope anymore.
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.
There are many ways to check if a object has changed in JavaScript, Angular's version of it is probably however the worst approach. The fact that it loops its a fundamental flaw that can't be taken seriously. Its a hack and should have never passed code review.
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.
I'm not very familiar with React or Angular's history, but wasn't the idea of diffing a virtual DOM something that React kind of came up with, after Angular had been around? Isn't your comment kind of unfair, because you have the advantage of hindsight?
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.
By this reasoning, functional programming is only the "method" in OOP. Surely that means OOP is a necessarily fuller abstraction?
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.
It doesn't seem true to me that the "V" React gives you is so good that you don't need anything else. It does seem common (though not universal) to eschew MVC for React apps, but in most cases it is replaced with something like the Flux architecture, which is no more or less complexity than MVC, it's just different.
Even inside Facebook Flux isn't used everywhere; Yes, for heavier modelling, sure. But for most common cases you're very fine with using only js objects.
Judging from your username, I feel like I've been seeing you on various web forums for ages. At any rate, yes, yes and yes. It doesn't take a CS wizard to see such basic faults from the get go. Still I had to try angular for a day to really see how terrible it was in practice.
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.
This seems to be the summary of every tech flame war ever, and applies rather well here:
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.
I never understand an article that is only negative and never presents a viable alternative.
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.
Amen. Look back 10 years ago and we were having the exact same discussions about mod_perl, php, and java servlets. Nothing has really changed except perhaps for an increase in the number of regurgitated comparisons.
Except that php won. As weird as that seems. CGI.pm was removed from the core Perl distro this year. React learned a lot from php/xhp and is easier to use because of it.
I've worked on Angular projects of varying sizes -some as large as 30KLOC (products where every page has enough interaction to justify an Angular controller)- and I can never find myself agreeing with these articles.
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.
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.
YES! Thank you! I think I'll die if I have to read another developer arrogantly defining what should and should not be, and how he, in all his glory, hereafter defines this framework to "NOT BE WORTHY".
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.
I am always conflicted about writing about Angular on a negative light because the team has put some great work into it while raising the bar in how rich apps could be built on the web. Being a back-end developer for a long time, it let me build some great interfaces on the front-end really quickly, and I'm very thankful for that.
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.
Finally, a respectful and well founded analysis. Thank you for improving the quality of the debate.
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.
The Angular 2 presentation given recently at ng-europe made it clear that many of the fundamental parts of 1.x are not built on solid architectural principles, which is why they are killing most of them off.
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.
My team has mixed people but most of them are reasonably experienced. What we find most useful about Angular is that it offers a "right way" to go about things, which removes the necessity for endless discussions about "which architecture is best". When you have a large amount of apps that need to be built and maintained concurrently, having a similiar structure across all projects is very helpful.
Exactly. It seems to me that you can very well code the way react tells you to ( flux) in angular. Now it means you may not use two way data binding but the result will be probably much more undertstandable,
This post reminds me of these other two [0, 1] that ultimately lead Leo Horie to create Mithril [2], a tiny (5 KB down the line) but complete MVC framework that also eschews most of the criticism raised by the OP.
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].
That framework has its own problems, like you have to wrap all your data structures into the mithril collections/models so that they can communicate with the views.
> you have to wrap all your data structures into the mithril collections/models so that they can communicate with the views.
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.
I work at Google, and have been using AngularJS in different projects for about three years. The OP raises a couple of good points (in particular his "The Bad Parts" are mostly valid), but I cannot understand some others, nor do I share his take away.
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.
This is in an established corp (best practices, standards, workflows etc) - you could build things out of mud and they would still hold. Doesn't say much for/against this particular framework..
I'm late to the party, but I want to share an insight I've had regarding game development and UI applications. It baffled me for a long time why building UIs were such a pain, and doubly so in a web app. Why could I, and others, create such seemingly advanced graphics and interactions in a video game, but try to make a UI and you're stuck with thousands of difficult to discover bugs. After I started using react, I realised games are "easy" for the same reason react is a huge productivity multiplier: you re-render the game every single frame. You have the data that represents your game state, there's a game loop, and you render every single little damn thing, every damn frame. It's a one-way flow of information from your explicit state to the presentation layer. React works the same way, only it re-renders only if the state changed. That's it. Super simple, but it's a mind shift.
I've been using Angular on-and-off in professional settings since 2012. Angular is a framework obsessed with testability that treats usability as an afterthought. That said I've found Angular to be more than flexible enough to meet the needs of your typical CRUD apps, and generally enjoy working with it.
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!
The author and I don't agree, except that Angular is not suitable for high-performance frontends (like games). The author suggests that Angular is only suitable for prototyping and that simply using the framework is technical debt. I particularly disagree with this statement: "Accept the fact that you will suffer in the future. The lowered expectations will help you stay happy sometimes."
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.
> The author and I don't agree, except that Angular is not suitable for high-performance frontends (like games).
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.
Actually that is the point :) The virtual DOM is equivalent to how you do write games. Declarative to imperative. React took its cues from how games are written. The renderer in react targets the DOM. React is a renderer.
The OP said he thought it would probably be great for a typical CRUD app.
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?
It's also one thing you shouldn't do in general. IMHO, adding too many abstractions on top of already abstracted concepts is just asking for a maintenance nightmare once the original team leaves.
(some abstraction is fine, but a metaframework on top of a framework is just going too far.)
I'm a big angularjs fan butI agree with all the points made by the OP.
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.
While most of the arguments presented in this article are somewhat valid but I hope with the release of Angular 2.0 majority of the issues will be addressed (though does it make sense to make such drastic changes in the upcoming is another debate and already taken care of at: https://news.ycombinator.com/item?id=8507632)
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 you were given a chance to choose your stack again, what would you pick now? (Considering all the learning you have gained after going with Angular for your large web-app)
Actually it depends more on the time of development and project specs. For now I'll probably choose ReactJS.
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.
But ReactJS isn't a full replacement for AngularJS (and I don't see why people apparently fail to make that distinction); React is just the V in MVC, Angular is / can be the rest.
I've seen many people repeating it; but I don't know what it even means.
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?
I think the point is a bit moot. Since it’s just JavaScript, you can put pretty much any logic in a React component just like you could also put any kind of logic in an PHP template or inside a view in iOS.
Haven't used ReactJS much but it looks promising in solving the problems created by AngularJS for instance its push-and-pull mechanism for data binding is efficient than angular's 2-way binding using watches...
> 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
There are a lot of routers, http abstractions etc. out there. What people mean is "use React, along with some of the readily available modular ecosystem that exists already"
True. And like any other framework one can work around the bad parts by developing custom solutions, but Angular's one of the main features are its two-way binding which also happens to create one of the biggest performance bottlenecks as the application scales up. This can be fixed easily (bindonce is just one example) though it leaves Angular with little value.
> It rather makes me worry it is going to be the Python 3000 release all over again in terms of how much is changing.
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.
couldn't agree more on the Python example, I think one of the main agendas for the 2.0 release will be to make it more popular on mobile side of things (https://www.airport-parking-shop.co.uk/blog/built-app-2-week... is one such example though not from the core AngularJS team) for which they may have compromised backward compatibility infavour of performance.
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..
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.
A lot of constructs become simpler with the addition of web components, O.o, and ES6. Coding it up shouldn't be too bad, the Angular team seems to be trying to make sure the design is as fleshed out as possible.
Why look forward to angular 2.0? I mean, it's a completely different framework, so why are you anticipating it, and not any of the millions of other new frameworks coming out?
You can find the detailed discussion in the HN link above, but to summarize my viewpoint on this:
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)
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:
But instead of throwing a familiar native js error on line 2, you get an asynchronous ReferenceUnboxingException on line 3475 of jquery.js and your code is nowhere in the stack trace. That's what a lot of Angular errors look like (when they do show up, because null refs from templates don't).
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 ?
Maybe I'm old fashioned but Angular just does too much for me. In fact many frontend frameworks simply do too much for me. I like to structure my web applications in a very minimal way.
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
Question: I also like a minimally structured app. I've experimented with Backbone.js. Have you tried it? Did you decide to go with msngr.js after using Backbone?
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.
Backbone looks interesting and I've worked on projects that used it but honestly I've never really taken a hard look at it nor had to make huge changes with it to really have a good opinion one way or another on it. I mostly started writing and using msngr.js because I love messaging and I didn't see anything that did exactly what I wanted to do (and even if I had found something I still may have written it anyway as I've learned quite a bit in doing so).
Angular is a result of the over-engineering that is endemic to web development right now. Programmers are taking strategies designed by Google and Facebook and places that actually need the high level of conventions prescribed by software like Angular and applying it to their personal blog, their half-done only on github "startup," etc.
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).
I can't speak of Angular since I haven't used it but one problem that is recurring with use frameworks, in general, is that thinking or getting used to "their" way takes a significant amount of time and seeing the continuous change of technology, I am not sure that time is justifiable in the longer run.
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 recently wrote about my experience with Angular in a different forum. Sharing it here:
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.
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...
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.
To my knowledge, all browser developer console's are built with html/js. Most of them can be opened remotely as a consequence (where the browser acts as a web server).
I ran into a similar issue with data bindings on table cells. My solution was to keep a track of the cells in a service (later refactored into a directive), and then have the directive update the cells directly when they needed to be updated, rather than each cell listening for if it should be updated. Indeed this is more like jquery and less like angular, but with so many databindings it was necessary.
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.
- Everything you need to know about Angular is explained in ng-book or the like. Trying to learn the framework by reading blog posts isn't going to work. There's just too much to know, and it's impossible to understand what's really going on unless it's presented in a logical and comprehensive way.
- 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:
Where is the disclaimer about data binding limitations? Tabular views with hundreds or even thousands of rows aren't inherently uncommon or non-performant. It's easy to sit here and say "wrong tool", but this is a pretty significant weakness IMO.
There probably should be a disclaimer in the official docs somewhere, but if you Google for ngRepeat performance there are tons of discussions on this. It's also a perennial favorite topic for angular tech talks. There is also a lot of information on how to improve the performance if for some reason you really want to do this. That said, even if the performance were great right out of the box without using one-time bindings or tweaking the trackby parameter, it still wouldn't make sense to do large tables in angular because you don't have any of the other datatables functionality.
Anyway, it's extremely easy to get around this, provided you are willing to update the table yourself. You just skip the two-way bindings for each table cell and update the cells for yourself. No big deal. If you try to glue angular and d3js I'd say that this is the common course of action - nobody's going to two-way bind every single property
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).
You can use React without JSX. It is especially easy if you are using CoffeeScript which makes the syntax quite terse.
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.
- 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.
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.
Sure, but if you can read HTML and you've read the above list of caveats: congratulations, you can now read JSX. The attributes are simply passed to children as props. There's really not much to it.
I don't think its a big deal. I use ClojureScirpt and Om, but often read React sample code (sepecially the React-bootstrap snippets). JSX doesn't map to what my ClojureScript code looks like at all, and neither does the pure JS React code, but I don't find it hard to read or understand at all and its fairly easy to learn what I need from it.
"I personally dont like React because of JSX,I dont want to have to learn a JS superset..."
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.
The performance problem is well-known and will probably be some of the first blogs / words of caution you'll encounter when starting out with AngularJS, and there have been numerous solutions for it - 3rd-party bindOnce directives, and in Angular 1.3 native support for bindOnce has been added (prefix the value with a double colon (ng-repeat="item in ::myList").
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.
I'm currently enjoying angular after having spent a year and a bit working with it exclusively. I am keen to try out Flux and Mithril, but I've not had the time nor the opportunity. But as it stands, we're deploying several large projects into very demanding organisations that are stable, performant and easy to manage. We as a team owe lot to Angular in terms of our productivity. We're also a great team and that counts for a lot too.
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.
I'm really disappointed that not only is this article on Hacker News, but it's currently at #1. The article contains almost no substance at all.
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.
I was hoping to read some examples and alternatives as well.. Presenting a problem without examples to back it up or a solution is just ranting. That's fine, but its just less productive.
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.
I disagree greatly. I've used Angular in a team project that spanned several months and went into production at a startup. After reading this article, I realize how much of my experience is reflected in it. I personally experienced each of the problems on his "bad parts" list, except for the name clashes issue (#3). For the last few months I've been telling people that Angular is powerful, but it has an extremely steep learning curve. I've been reluctant to tell people to try it because, why you can do a lot with it, you must baptize yourself in the framework before you can write anything half-decent. It's a little depressing to see someone with deeper experience come out and say it does not get better. But I know that as much as I want to like it, Angular imposes too much for me to actually recommend it.
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.
Same opinion here. I think angular hit an inflection point on the js frameworks, proof is the rapid growth that angular had. Granted, there's some bad parts but I would say it's mostly leaky abstractions; I'm wondering how angular2 will be, but I surely don't understand why all the hate around angular.
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).
None of the stuff that angular actually does is hard, and it is done by a lot of other frameworks. 90% of the effort spent learning angular is spent on its bizarre api.
that says it all: the most framework specific part of the article are the links in the end to other articles.
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".
> that says it all: the most framework specific part of the article are the links in the end to other articles.
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.
NOTE: Haven't used AngularJS and only scraped the article. But Rails for example, doesn't have a namespace problem, because ruby modules provide a namespace and prevent name clashes easily.
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.
Rails and Angular are apples and oranges. Angular isn't a full-stack framework, it's a client-side framework that handles data source interfacing and view updating.
Rails doesn't have a namespace because Ruby has namespaces and Javascript doesn't - it'll be added in ES 6. Rather late, I think, but there you go. You can actually fake namespaces with Angular if you use a module framework like Require.js, but that involves adding more boilerplate to every module (like Angular 2.0 will actually require as well).
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.
I've actually never used any javascript framework. It is stuff like this that drives me away. If you pick any one framework, you get half of a crowd telling you that it sucks, and then a year later your version is now deprecated/replaced and you get to re-do everything again. I've attempted to avoid the whole web-app scene, but with the current job market, looks like one has to know one of these frameworks...
Angular got a lot of its popularity, I think, from people with a similar mentality as you. Since it had the Google stamp of approval, it was seen as being more stable. Unfortunately, this was not actually the case.
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.
If Angular is not The Thing (a premise which I have no trouble believing), then what is a Good Thing to perform the task of, for example, consuming Django Rest Framework endpoints and making a frontend of them?
Perhaps also consider whether front-end frameworks are a Good Thing given your requirements?
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 think in a lot of cases they actually aren't a good thing at all.
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.
It depends if you actually need one. Do you need a full javascript frontend or can you sprinkle JS on top.
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.
IMHO Good Thing is to have set of libraries and not a framework at all. Start with handcrafting all HTML,CSS with interactions you need. You HTML skeleton will depend greatly on what you want to achieve - like when one page changes to other and theres a ajax call between - where you put the wait screen: as separate, on old page, then wait, transit to new at once, then wait and so on. If that is done you know broadly what you need. Example configuration may be React for rendering, cherry picked Model (or State) from Ampersand, Backbone Events Standalone for event bus. Something for History/routes too, can't recommend anything specific because my projects did not had one (yes, you can build web-app without back button support). This way if something better comes up, you can switch, if something is abandoned, gets your way, you can switch. Or you can rewrite it in-house fairly easily. I imagine that when you discover that React is too much, too heavy, too bloaty (for example, i'm not saying, that it is, we are happy React users now), then preserving all API calls and replacing it with few lines of Mustache templates is doable. Not trivial, but doable.
I was fairly sold on react/flux after trying it because it is very simple and you can build very quickly. I've been trying Mercury.js over the last week as I thought the 'cycle' of flux/react was a bit more than necessary. Your front-end guy might be sold on Mercury next.
I did initially think the cycle of flux was a bit too much, but since having to have actions be created from various sources, etc, I've come to realise that it's actually a really good balance.
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.
If you're using Backbone, Marionette is pretty much a must-have. It provides some great classes for common Backbone use cases like rendering a template and showing views for models in a collection. It also provides some additional application-level abstractions. Fills in a lot of common boilerplate and functionality.
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.
I've got to build an SPA and I'm trying to choose between Angular and React, can you guide me a little,
the app will :
- 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 ?
Angular will force you to convert all your rendering logic into its declarative API: ng-if, ng-repeat, ng-include etc. With React, you can simply write your program logic in Javascript and compose, reuse and pass around parameterized components with ease.
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
We built a pretty complex app with Angular (https://slimwiki.com) and have had nothing but great experiences. The main issues are no guidelines about the right/wrong way to do things, it needs to be more opinionated.
I think people are failing to see that not all apps are huge monolithic applications; for most of those apps Angular works just fine.
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.
Cordova has nothing to do with angular. Why do you bring it up? In fact, angular is probably one of the worst possible frameworks to wrap into a mobile app, because of its abysmal performance.[1]
Sorry, did I miss the part where the author explained the "right (tm)" way to do things these days?
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.
The problem is not Angular specific, every Framework is designed to solve a certain problem in a certain way.
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 .... ;)
I also have been using Angular for my entire professional developer career, which in a few days will hit 2 years.
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.
I wouldn't recommend either Polymer or the current development version of Angular 2.0 for a production application just yet; Polymer leans heavily on the unfinished web components standard and other experimental and unimplemented browser features, and Angular 2.0 is still under heavy development. I also gather they're either going to use ES6-but-with-extras-because-we-can, or with AtScript, ES6-with-types-because-why-not. I can't say I agree with those motivations (and I'm sure I've got it wrong), and I quite like the more vanilla JS feel of Angular 1.x.
Anyway, my point is, both of those aren't production-ready.
Oh, I agree about not moving to either for a major project currently, although I'm probably going to use Polymer for a small static site project I'll be starting in the next month or two - web components are supported in Chrome currently (shadow DOM and custom elements at least - not sure about the data binding part yet), and Polymer's platform.js makes it very easy to polyfill the missing functionality.
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.
As someone who has thus far only used with Angular for smaller projects, seeing performance raised as a concern is a bit of a concern for ever using it in a serious project. Would still like to see some numbers to back up the anecdotal evidence.
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.
The thing I really like about Angular is it makes composition of complex ideas relatively easy. The encapsulation and dependency injection is perfect way to allow you to be as structured or unstructured as you want / need to be.
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."
I am greatly interested in learning what is the alternative that would be a 'yes-yes' in these bulletpoints.
I don't really see how any of these are a problem with Angular specifically and not just a general problem with any development.
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.
This kind of distorts the issue here. The problem is not lack of highly skilled devs but rather the fact that you need highly skills devs to digest and maintain the level of complexity that Angular produces.
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.
You don't need highly skilled devs, you need a disciplined team - which should review each other's members' code, stick to a style guide, research best practices, etc.
"2 years" and "10 projects" - 2 months for each project? And he talks about "big enterprise apps"? lol.
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
All of the frameworks suffer from performance issues. Performance will get better, but we will always have to profile our applications. A slow web component used in a ng-repeat scenario will always bring the application down to its knees. We can't just design a spaceship and expect an engineer to build a performant application. Designs need boundaries and guides as performance is one if not the most important factor of the UX. We also cannot reason with the jQuery spaghetti demon. Practice some Feng Shui, write better code. Understand whats going on in your framework. Work through the limitations with your designers. We are at the mercy of limited computation until our browsers give us more, and there is no magic bullet.
It's fair to highlight the less-ideal parts of AngularJS, but IMO the ecosystem and testing integration is as important as the framework code itself. Most of the issues the author mentions can be mitigated (eg. use ui-router).
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?
I feel somewhat conflicted about this blog post. I can agree with what others are saying in the comments that all frameworks have there pitfalls. A lot of development is dealing with trade offs and your teams varying experience.
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.
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.
My opinion of Angular is now that it's basically the equivalent of PHP (if we're comparing it to other languages.) PHP is super easy to get started with and is magical and with enough forethought and planning, proves to be a serviceable language suitable for small projects.
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.
Comparing Angular with PHP doesn't strike me as entirely fair; Angular, whatever else one might say about it, has a high degree of conceptual consistency in its internals, whereas PHP, for all that it's improved over the past few years, remains an utter farrago and likely always will. Comparing Angular with Laravel might be more reasonable, but my lack of knowledge of the latter framework forbids me from commenting further on the comparison.
The comparison between Angular and Rails I base on broader characteristics than those embodied in language or framework features. One of those characteristics, a primary one in fact, is that of convention over configuration; Angular, like Rails, defines specific conventions, which only an expert can safely bypass, and to which non-experts must adhere on pain of having a very bad time.
> there are at least 20 books on angularjs that are easy to read to understand the framework properly
A prototypical example of the sort of wizard comment about which I spoke earlier.
> The big issue[, ]in my opinion[, ]is that one needs to know how [J]avascript works in order to understand how directives work.
True of any framework, though; if you don't understand the language in which it is built, you are certainly going to be at sea in trying to use it. Angular isn't special in this regard.
(Also, some notes on English orthographic conventions, for the benefit of someone who may not yet be familiar with them: First, medial and terminal punctuation, such as commas and periods, is invariably followed by a space, as exemplified in this comment. Second, abbreviations such as "isn't" and "doesn't" take an apostrophe before the final 't'. Hope this helps!)
I really think that the bigger the app gets the smaller the framework should be. If it lacks functionality, it should be possible to easily add it using the frameworks core functionality.
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.
I am not a lover of angular, but the reason angular is so popular is because it gets the prototype out there.
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.
I've been using Angular now for a year and half, and a year professionally. The only issues I've run into are pages with large data bindings. I would love if the Angular team could recommend a solution other than "don't do that." That answer is simply unacceptable in my opinion -- their silence on this topic has been very frustrating.
AngularJS owes it success to an easy onboard that allows a user to easily create a gimmicky two-way binding demo. And then the pain begins.
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.
> It matters little whether some find it productive, what matters is that the engineering principles it is based upon are fundamentally unsound.
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.
True, but Angular reinvents the wheel unnecessarily and at a cost of performance and being difficult to reason about.
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.
Bizarrely enough, I've built about 4 web apps ( using Angular over the past 2 years also. However, I've found that scalability (mainly due to it's reusability) is one of the strongest points. I've worked with enormous applications built entirely with jQuery.
I love angular, but perhaps thats because I'd only worked with jQuery before.
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.