When the author doesn't understand the difference between a module system and a dependency injection system, it's hard to take the rest of what he says seriously.
They kind of solve the same problem, but in different ways. I, for one, think it's debatable if the 800 lb gorilla that is dependency injection has any merit in javascript.
I disagree. They were a solution to the inflexibility of rigid languages like Java, but seems entirely alien in the context of Javascript. A DI framework adds a load of indirection.
DI is a design principle, not a class for frameworks. DI just means to "inject" the dependancies of an object through constructor arguments, setters or by simply setting instance (aka member) variables. In other words, DI means that you don't use global variables (aka singletons). DI does not provide any more flexibility itself, but most DI frameworks encourage the usage of interfaces instead of concrete classes (which is a good thing) when it comes to defining dependancies. Sadly however, the fancy pants therm for using interfaces is "dependency inversion", because when using interfaces, the compile time and runtime dependancies of a class point in opposite directions. As you can imagine, this lead to a lot of confusion.
It has nothing to do with the "rigidity" of Java, and everything to do with the complexity of the problems solved in Java land.
The value comes as you scale the number of developers, the lifetime of the software and the complexity of the product. This holds just as much for Java as it does for Ruby or Javascript.
Fair enough. It's probably a matter of taste to some extend.
I generally don't like too much structure unless there are clear benefits and DI doesn't seem to hold up on that scale. The problem it's solving has traditionally been solved with a dozen global variables. And while the purists may scuff at this, I find that in practise it's never an issue in otherwise well structured code.
The difference is that modules systems specify statically resolved dependencies between code files. DI and IoC specify dynamically resolved dependencies between instances of objects. They are both useful, but they both solve different problems.
The author's point was that with Angular, the Angular module system you must use (you can't opt out), and you are most likely nowadays going to be using commonJS or AMD anyway, so you end up with two module systems. At the time (in 2009) it probably made sense to come up with an Angular module system, but now that most people use require/webpack/browserify, it has become a hinderance. The reason being you can't just require() a module in a unit test, you have to bootstrap the entire Angular system and all angular modules, which is a huge pain for unit testing and causes all sorts of side effects.
The other thing the author didn't mention is you can't debug your HTML templates. With Mithril, you can set a regular javascript breakpoint in your views. Directives and code-in-HTML essentially reimplement a half-assed version of JavaScript. (The same criticism applies to JSTL which throws out a perfectly good language, Java, and forces you to use XML and tag libraries.)
HTML logic creates complexity because it invents a new programming language in the HTML.
The code-as-HTML is the root problem that causes all the scope issues, all the explosion and complexity of directives, filters, and the inability to set breakpoints in views. With Mithril you don't have this whole directive/filters nonsense, you just write functions.
Because React solves only the directive part of Angular? I'm not saying it's great BTW, but comparing React to Angular is silly. That's like saying you chose lodash.js over Angular.
This was probably a valid observation two years ago, when the React story on state management was "bring your own solution." But these days, although it's technically a separate project, Flux is the de-facto state management solution that a React-first webapp will use. There are lots of competing implementations (I use redux) but my point is that you'd be hard-pressed to find an app written in Angular that couldn't also be written using React+Flux. Of course the architecture is going to look different, but you can certainly get to the same place.
Sure you can. And as I said, I'm not a big angular lover. In fact we used Backbone for REST in it, because of shortcomings of the $resource at the time.
And flux is great and React-first, but it's not technically a part of React. And it is also great, having a choice is usually a good thing.
Still I'm skeptical when people are happy just because they moved from angular to react. Or from any X to Y really. Usually the gain comes more just from rewriting things with better understanding of the project and from more established team. No one does A/B studies on it, right?
> Because React solves only the directive part of Angular?
I can't say I miss anything from angular in React. If anything it's good that React does not try to go too far down the rabbit hole. Which particular functionality is absent in React that you need?
React encourages a certain style of development/architecture to a degree. Sure, it doesn't compete with Angular feature for feature, but it does encourage a style that IMHO is different enough to be interesting as a conversation topic when discussing alternatives to Angular.
React usually comes with the connotation of using Flux as your data, state and control mechanism (we use ALT as our implementation) and then usually the NPM and Browserfy ecosystem to fill in the gaps as needed with libraries. It is a valid replacement for Angular but takes more of the perl or ruby approach to grab what you need and not the Angular, Java or .NET approach of most of it is already in the bag.
Personally I like the event/component oriented development style of Flux/React over procedural controllers that tend to become monolithic. The browser model was always event based, but with the flood of server side development talent the JSP / ASP controller model trickled over. It takes time for people to realize there is a better way.
We use reagent with success. We still have some legacy code in Angular. Each time we need to change something in that old code, it reminds us how Angular has done a lot of things wrong.
We often qualify Angular as the J2EE of the front.
While the author makes some fair point about angular's weirdness. He fails to understand that many design choices where made because javascript and js libraries were not as advanced as today.
For example the module system is made so because at the time, amd, browserify and ES6 modules were not ready.
And the main point of angular 2 is not to remake angular because it was weird, it is to adapt it to new technologies.
This was the deal breaker for me when first looking at Angular - loose coupling, progressive enhancement, accessibility and keeping code in its appropriate layers seemed to get thrown out for an attitude that everyone has JS running... it felt like a return to the days of Flash.
I could ramble for a long time about it, anecdotally; I have peers who use (and seem to enjoy using) Angular (all .net devs), and others who point out its flaws (front-end architects). I find it a very interesting discussion point.
While I'm sure this gets abused, I think many of the people who use and enjoy Angular limit it to developing web apps. When I use Angular for something, it's a true web app, and I need to be able to execute client side code. When I have static content, I would just use HTML + CSS.
If you're using Angular, the use case might justify the attitude that everyone has JS running. The same people who hold this attitude when making an Angular app might build perfectly serviceable sites to deliver static content without JS.
The fact that I can declare a scope variable in a directive and it is magically available in a controller is also another one, only once one starts to dig do they find out about the less than obvious scope controls to not allow what amounts to global variables. Further down that path, variables can be declared in the template, in the controller or in a directive. There is no traceability of where state starts. Honestly I am the type that blames myself first and think I must be missing something, but there are just such junior mistakes in how Angular was implemented, that it does encourage voodoo.
"I’m not joking: we were perfectly able to get by in one of the Angular projects developed internally — consisting of around 200 Javascript files and a total of around 10,000 lines of code — using only factories."
Funny, I could agree this is true for providers or services. Factories however can't be used for singletons, so I'd rather not know how they implemented shared state and utils.
Factory is just a function. It can easily instantiate and return singleton. You just call it instead of using `new` on it at the place of use. It's probably not very nice from philosophical standpoint but it can have its merits.
I work as a JS contractor on large custom e-commerce configurators. In the last few months I've learned that Angular is not built for large custom e-commerce configurators. Just my 2c /
They announced recently that there will be an easy Angular 1 to Angular 2 migration path.[1]
I think Google is getting blowback from the "worse is better" crowd that have supported the meteroic rise of c, php and mongodb. Specifically, the "worse is better" belief that:
"There is a point where less functionality ('worse') is a preferable option ('better') in terms of practicality and usability." [2]
reminds me of his criticism of "excessive" features in Angular, even though those features are there for a reason.
Usually, what happens with "worse is better" is that when people start missing key features, a bunch of bolt on pre and post processor tools show up to add features (e.g linters, "strict mode",Mongo migration tools) that weren't needed in the more complete solution.
I haven't tried Angular yet but have built applications in React. In my opinion, frameworks like Angular suffer from a fundamental problem, that, it is almost impossible to gauge the problems of a new design unless you have a built a medium - large scale application with it which is very hard when you are just experimenting. There might be few heuristics, few rule of thumbs one can follow but still it will be hard to see if the ease - effort ratio will make the framework worthwhile. You can make things too "magical" and also too "worthless".
I guess that's why everyone complains that it is easier to build a Todo application in Angular but the troubles grow as you grow bigger. The reason why React is successful might be they did get a chance to experiment the architecture on their own things before releasing it to the public.
I've never understood any comparison between React and Angular. To me it seems like trying to compare a slick car to a fancy car garage. They try to solve quite different problems, right?
I've used both and I could completely replace Angular with React and some scaffolding code.
I used Angular on medium to large web apps in the past and while its easy to get started you always get tons of problems at scale. Staying at scale without problems requires so much discipline its not even worth mentioning.
The two-way bindings are just the wrong way to go in order to keep things simple as you scale. It becomes nearly impossible to reason about the performance of your app or what is going to trigger if you change a model.
This is way, way too complex to build an application. With React most of this complexity goes away. I'm also using React from ClojureScript through the Om library so these might be contributing to said simplicity!
> They try to solve quite different problems, right?
Sort of. The problem React is solving is a subset of the problem Angular is solving. It's a bit more like comparing an older model sports car to a modern engine.
> I haven't tried Angular yet but have built applications in React. In my opinion, frameworks like Angular suffer from a fundamental problem, that, it is almost impossible to gauge the problems of a new design unless you have a built a medium - large scale application with it which is very hard when you are just experimenting.
I don't see how this is any different with React. Building a medium - large scale application in React involves just as much complexity as doing it with an Angular app, because you end up adding a Flux implementation (and all of its boilerplate code and ceremony), some sort of routing engine, a testing framework of your own choosing, a myriad of helpers, mixins, and components that a framework like Angular or Ember provide out of the box, and we haven't even started about the increased complexity in terms of tooling; babel, webpack, jsx trasnpiling. Add to that radical new concepts like css defined in your javascript files, the rapid rate at which breaking changes are introduced to React, and the moving target around data handling (Flux is out, Relay is in?) and you find yourself in a very similar situation.
You're comparing a view layer to an entire framework. It would be more apt to compare React to Angular directives but then your overarching point about complexity would be lost. I've worked on large Angular apps and large React apps and I can assure you the complexity was about the same.
"BazarJS" is a series of articles about JS frameworks, pre-processors, etc... they already published the same in italian language some months ago. now they're re-publishing (with eventual updates) the same in english.
So, they trot out the same tired arguments against Angular that people have been making since the beginning, and this makes the front page where people engage in serious discussion about it?
Did I miss some subtle novelty about this post, or is Angular ennui just that popular on HN?
Not to mention his example is just straight wrong about $scope and ng-if.
His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope inside an ng-if.
I agree that angular 1.1.5 had it's warts, if that's what this is supposed to be about. The current release version of angular is 1.4, about to be 1.5.
Edit: After fully reading through this blog post; it's almost all wrong.
Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model.
Dependency Injection: Are you kidding me? He's not even using the array notation for proper DI with minification.
Pointless Complexity: This is an actual valid argument, and the only one on the blog. Google has some pretty bad documents for angular, especially when describing directives that isolate scope.
Server Side Rendering: Uh, the whole idea behind stuff like angular is decoupled frontends from your server. Build a REST API and point angular at it; no need to ship layout code with services.
Angular 2: There's an upgrade path that should allow the two to exist in tandem. There's no reason to not keep writing angular 1.x code right now. It's not like Angular 2 being released means all your previous code is worthless.
There are tradeoffs to both. Server-side will always have a seat at the table. Ex - populating a simple key-value select statement will always perform better using server-side.
There are functional reasons, yes. But the best business case for internet dev is a frontend hits a backend, and that's it. The relationship is purely request/response payloads. It's transactional, massively simplifies development and qa, and better encourages the notion that every endpoint should be able to provide, as well as consume services.
Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model.
As someone who's going to need to make a recommendation soon about whether or not to use Angular on a new project, this part worries me. The apps my company builds are full of data grids (Enterprise CRUD-based stuff) and it's entirely reasonable for us to have a 100-row grid with 20 columns as just one of the components on our page. So that's 2000 data bindings right there just for the data values. We'd also have metadata on every cell bound to classes and validation state. If we allow in-place editing, a single one of those fields can be updated. We can't have the entire grid re-checked after every update if that's going to hit the limit on acceptable performance. We'd need to limit it to the row (eg: cross-field validation rules) and elements outside the grid (eg: change toolbar button states.)
Does Angular 2 have similar limitations? Should we wait for Angular 3 and Object.Observe?
Might be a nasty pill to swallow, but in most cases, populating a grid with 2000+ bindings is in the area I'd call bad UI.
Totally agree, but my business is auto-generating fully-featured applications based on database schema inspection and a code-generation wizard, for clients with large enterprise databases. So the app has to work reasonably well with out-of-the-box generation before we start tweaking it to customize and improve the UI for the most important tables and most common workflows.
Thanks for the jsperf test. It's good to know the range of results for different browsers. Our app needs to run on everything, including Mobile browsers, and that test proves that we can't get away with using the typical Bootstrap responsive "hide some columns for xs" approach. We need to not generate markup for most of the columns at all. That means we're going to have to enhance our generation wizard to let us specify, per-table, device-size-specific column lists instead of just a single column list.
If the individual cells in your grid aren't changing dynamically, you can use a one-time-binding[1] which will improve performance by removing the watchers after the expression is populated.
You can also always use a directive to do the DOM management yourself, and still use Angular-y templating in the rest of your app.
knockout.js doesn't do everything Angular does, but it does two-way binding incredibly well. Very efficient with binding and rendering, so you don't need to be concerned with total data binding count.
I'd argue that KO's rendering isn't actually all that efficient - I use it daily on our core product and have been won over by React's crazy pseudo-DOM diffing voodoo.
keep in mind that even if you go with angular you don't need to use it in 100% of your site.
Need to display a grid of data fast? Use any grid. There are lots of fast grids out there.
Angular 2 eliminates dirty checking (last I've read) so it could be good enough, or maybe there will be something faster on the market that works best in your situation. There is no reason to assume that once you go with Angular you are now limited by 2000 watchers. you don't have to choose between Angular vs React vs Ember for that a single specific case (unless maybe one big mega grid is the bulk of your app). It is far more important to decide which architecture works best for your needs/team and how it will fit with all the other decisions you've made in your application stack.
>Server Side Rendering: Uh, the whole idea behind stuff like angular is decoupled frontends from your server. Build a REST API and point angular at it; no need to ship layout code with services.
This is not a solution because the lack of content from the perspective of UAs that don't process JS (such as some web crawlers) decreases search ranking.
The alternative solution for the architecture you propose (0 rendering on the server) is to add a prerendering server between the Internet and your system.
With JS frameworks that do not depend on the DOM, one can have isomorphic JS that runs in both the browser and node. This means the same code can run on the server, for the first request, and after the rendered code is sent down the pipe further requests use the API.
Sending acontent-less HTML with proceeds to fetch something from some API is a non-answer for websites whose search ranking is relevant.
If I had to chose between isomorphic JavaScript + server-side prerendering OR having an extra layer between my frontend server and the Internet, I rather the former – assuming there are no other language/technology requirements.
So code your public facing pages with static html and reserve angular for the app?
The public pages I build for my apps are all static html with some JS for flashy crap that people ask for. Search engines don't need to care about the app itself, just the front page, about page, contact, etc, of the biz.
Unless you're talking about a CMS built in Angular, which can get sketchy. Google's web crawler parses JS now anyway, so it shouldn't be a huge problem.
> Dependency Injection: Are you kidding me? He's not even using the array notation for proper DI with minification.
Can I just say that this is the single thing that really irritates me about Angular?
This has been the "gotcha" forever... why are all the guides not using this syntax by default? Why is this just not "the way you do things" if everyone knows this is a problem?
The array notation can be automatically added to your build tool (gulp, grunt) using ngAnnotate: https://github.com/olov/ng-annotate. This reduces the amount of duplication and Angular boilerplate around dependency injection. Most Angular projects I've worked on use this, making the Angular guides relevant.
Funny that the last complaint is that Angular2 will break a lot of stuff, when it will actually fix most of the issues he's mentioning above. One can never win.
Valid criticisms of Angular include that it gives you enough rope to hang yourself, that the documentation/tutorials teach you to code Angular in a bad way (abuse the $scope object, etc.) in the interest of making it "easy" and that the terminology and symbols used can be simplified.
However, once you learn to avoid Angular's pitfalls, it's a very powerful tool for creating large apps that do not collapse under their own weight.
To illustrate, how often do experienced Angular devs make $scope inheritance errors? If you are, you're not using controllerAs syntax and are coding sloppily. No framework can save you from sloppy coding.
Yours is the third post I see that amounts to "you're doing it wrong."
But if the docs are bad, and there are pitfalls that experienced Angular devs know to avoid, how can we distill that down into common knowledge that beginners can avoid?
Can you recommend a book or resource that does that?
* ng-newsletter
* bennadal.com (fairly advanced, and sometimes unorthodox)
* I found the egghead.io videos very helpful when I was starting
* John Papa's angular style guide
If I recall correctly, most of the other resources I've relied on were strewn about the web, and not at any one particular website.
One of the trends I've seen in my own hiring is that many Angular devs lack a solid understanding of fundamental JavaScript (closures, prototypes, functional programming, DOM API, async patterns, et al). This may be a function of how much the framework is able to abstract away from the user.
This dearth can lead to lots of code smells, bugs, antipatterns, and other grenades that can present significant problems at scale no matter what framework you choose to go with.
So if it's true that many Angular apps have problems at scale — one hypothesis would be that it may be a reflection of the selection bias of those who choose to use the framework. Which is not to say that advanced JS people aren't using the framework (they clearly are) but anecdotally, upwards of 90% of the Angular-based devs I've interviewed or interacted with personally lack an understanding of many of the aforementioned JS fundamentals.
Perhaps the scaling problems are also because JS only became a "real" language in the past few years. Beforehand, there wasn't much need for coherent app structure because large apps were impractical.
Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync. I like using nearly straight up HTML as my template. I do this in Django, so why not in Angular? I like that I don't need to render things server-side because then the server is just running a REST-ful API. That way I can write different clients for the API and don't have to change the server (mobile app, desktop UI, etc.) I like the clean separation between presentation (HTML templates), UI logic (controllers), and communication (services).
I feel like Angular's biggest problem is the documentation. It starts out talking about things like dependency injection and why that's good, instead of simply displaying how to use the framework. It's got a steep learning curve and it just seems that people get scared of the documentation and run away before they really give it a try.
I think Angular is so widely used because so many people do like it. It has quirks and shortcomings (per the article), but those are only relevant because it is generally liked and used by so many.
> it just seems that people get scared of the documentation and run away before they really give it a try
Anedoctally, as the author of another JS framework (http://mithril.js.org), I see a lot of people migrating away from Angular due to complexity, bloat and performance issues. I, myself, spent a good two years wrestling w/ Angular problems full time before jumping ship. Our apps were quite complex and we were fully invested in trying to make Angular work, and definitely not just making a half-assed effort to like it. So it's definitely not just newbies.
I like Mitiril, but the way you manage your view layer doesn't work for me. I've tried several "build a Dom in code" approaches before, and they haven't proven to be very maintainable in the long run, especially for larger and more complex solutions. Additionally, the cost of migrating an app is much much higher.
So while this post is mostly FUD, your points are valid, I feel all frameworks come with a tradeoff.
I love Mithril's (and other's) "build a DOM in code" approach. Traditional templating systems are always limited domain-specific languages that add lots of complexity for things that should be simple, template "partials" and iteration come to mind instantly.
Making the virtual DOM tree a first-class value that can be treated as a persistent data structure is a huge win. Templates are functions that return a virtual DOM node. Rendering a list is a map from Thing -> virtual DOM node. Redundant rendering is avoided with memoization. "Partials" are just functions. The system handles escaping and prevents XSS vulnerabilities by distinguishing plain strings from DOM nodes, which string-based templating systems do not do. All of the complexity and difficulty of working with templating systems goes away when we can just use the usual functional combinators we all know and love to compose views.
On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. Angular just doesn't compose well with other things like Mithril and other primarily functional libraries do. I should really write a blog post on this.
> On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional.
How are you using an FRP library with Mithril? I thought with vdom libraries you never touch the real DOM.
Mithril allows you to declare callbacks for the various DOM events on the virtual DOM nodes. This is where you glue in the FRP library. A callback will set the current value for one of the roots of the signal graph.
Would you care to elaborate on the maintainability aspect? I've worked with various "build DOM in code" approaches too, ranging from anywhere between Ext.js to HTML string interpolation/concatenation in jQuery and I think a lot of approaches do suck (some more so than others).
One major problem with older "build-DOM-in-code" approaches was ability to integrate to third party libraries, but I feel that this problem has been solved by newer frameworks (e.g. via lifecycle methods/mixins in React, `config` in Mithril, etc).
Personally, I find that mapping the DOM structure onto Javascript a la Mithril, React, et al works out better than mapping scopes and closures and logic onto HTML (a la Angular), simply because it's easier to refactor code that is, well, code, rather than something that tries to emulate having programming-language-like properties in HTML by shipping its own quirky implementation of scopes, expression parsers, compiler, etc.
I disagree on cost of migration. It's not exactly trivial to migrate from Angular to any framework that I know of, for example, especially once you start using things like form validation flags or filters. The only migrations that sound somewhat straightforward to me are Meteor/Ember (since both use Handlebars flavors) and - perhaps ironically - React/Mithril (assuming JSX/MSX), but for mostly anything, you're pretty much stuck with manually porting framework-specific syntax. With that being said, it's not necessarily impossible. I know of success stories of people porting non-trivial codebases from Ember to Mithril and even from jQuery spaghetti to Mithril (via its template converter too). At the end of the day, I think it comes down to tooling. With React's renderToString or mithril-node-render, it's quite feasible to automate a large portion of the work of porting templates away from these newer frameworks, should you need to do so down the road.
I haven't been able to write this without sounding critical of mithiril, and I don't want to do that. I suspect it all comes down to use case, and the line of work I'm in, it's not a wise choice.
I like that I don't need to render things server-side because then the server is just running a REST-ful API. That way I can write different clients for the API and don't have to change the server (mobile app, desktop UI, etc.)
I've been working pretty much exclusively with Angular for the past 18 months on some high volume financial processing systems. Shipped 3 codebases that would probably be considered 'large'. It's been one of the best development experiences I've ever had.
The learning curve is steep, but when you get into the groove, when it finally clicks, then you can really take off with it.
I love the tooling (node, Yeoman, Grunt, jshint, karma, protractor etc.). While not perfect, it's definitely helped me write better, more readable code.
We have been dealing with a large angular front end and our big problem is really more along the lines of using watchers to take the place of what should be handled by a domain model. I don't think this is a problem with Angular but an issue with JSON. I have yet to find something that can take serialized JSON and hydrate a domain object in javascript.
I really like Angular and have been able to pick it up faster than other frameworks. Mainly because its a complete framework as opposed to having to mix it with other frameworks like Backbone or React has to do with Express or Ampersand
My only gripe is having so much code in the HTML that it makes it nearly unreadable. Maybe this is just the people I've worked with who do this. I think most of this could/should be put in separate controllers?
IMO there is no problem with Angular, except when people use it as a square peg with a round hole. It's ideal for your use case - lots of data entry, forms, etc. etc. But then someone tries to write a blog platform with it, or something.
I think part of the problem is that everyone wants there to be The Next Thing that will solve all problems, when that doesn't exist.
This is the problem with angular. Why are people using it as a square peg with a round hole? Is it because people are stupid or is it because angular is stupid?
Looks to me angular is a round peg disguised as a square one.
>Sometimes I feel like I'm the only one who actually likes Angular. Two way data bindings are very convenient for writing UI. I don't want to write an event listener for every onclick, onchange, and onkeypress. I want the values in my models and the values in the DOM to be in sync.
React solves all of those in a cleaner way.
>I like using nearly straight up HTML as my template.
And yet you don't. You use Angular-ized HTML as your template.
I work with React daily and love it but will freely admit that using it for simple data-binding for input heavy forms is a gigantic ass-pain.
If you're using Flux, you end up with an immense amount of boilerplate action and store code around every input field. The other option is to violate the model, make all your inputs uncontrolled and have boilerplate onChange listeners for each one.
Choose the right tool for the job. Angular's no-questions-asked data-binding is perfect for this scenario.
It is incredibly easy to write a function that creates an input field and keeps track of the state wherever you want, so I don't think that is a valid criticism at all.
I've got a React app which is basically just one giant form. My inputs are not uncontrolled, I use boilerplate onChange listeners, and I'm not violating the "model".
I agree with this, I've been using Angular for a while now and like it. Every time I read these criticisms of Angular, I always think...compared to what?
For example, I don't find fixing occasional performance issues when using two way binding a big deal. Two way binding makes my UI code much more concise and free from bugs concerning keeping models and the DOM in sync. I've worked with Backbone before for instance and found that dealing with listeners and syncing manually was a huge source of bugs.
Most of the time all you need is a computed property. It simplifies the code base and allows the framework to make optimizations where it needs to. If you really need a two way binding you can always do it with a computed alias.
ember's computed properties are irrelevant if you're targeting any kind of modern browser. Object.defineProperty is the standardized way to do this and perfectly possible within Angular-land (and more performant than literring your code with $watches)
How are Ember's computed properties analogous to defineproperty? The latter doesn't give me dependencies for my properties, so may as well just be functions. Ember's properties will only need to be recalculated when their dependent properties change.
I enjoyed Angular 1.x. But I feel burned really badly by 2.0. I learned 1.3 shortly before 2.0 was announced and it was a really frustrating experience to have just felt like I learned this tool and then have everything thrown out the window. So, I'm not excited about learning 2.0 and haven't yet. I believe the claims that it's faster/better, but the way they threw everything out the window with 2.0 makes me concerned that I'll get burned again.
> "I like that I don't need to render things server-side because then the server is just running a REST-ful API."
Thank you! I never understood the big push towards server-side rendering. I did server side rendering for 10+ years in JSP land. I love having a clean separation between client and server, freeing me to experiment with different languages and frameworks on the server side. Likewise, if I want to experiment with a React component consuming my REST API I can. Not to mention my AWS expenses are kept minimal as most of the processing is offloaded to the client side.
> "I like using nearly straight up HTML as my template."
Agreed again. Am I the only one who works with people who know HTML, CSS, and a little bit of Javascript who can contribute to the front end design? I feel like if I threw a "DOM in code" type of approach at them they would feel lost.
I like those things (data bindings, values in models) too but Angular isn't the only solution. I don't like Angular's heavy handedness, and I really really don't like mixing JS and HTML (which rules out Ember or React).
I personally find Knockout to be almost the sweet spot. Very lightweight, plays well with others, doesn't "take over" or try to impose a top-down ordering on the page.
I know the rest of the developer world has moved on but I'm hoping I can hold on to using Knockout long enough until another MVVM system which separates view and model but binds them together comes along.
I'm also a major fan of two way binding, but I agree with the problem the article raises re dirty checking. I much prefer Knockout because for the price of writing observable(value) rather than field = value I don't have to worry about dirty checking or the knock on effects of updating a value. Combine it with Typescript and you quickly get over the learning curve of calling to set a value rather than assigning.
On the server side rendering front I'd be curious to know if you do LOB apps. In my in house dev world where people are almost always within 100m of the server and used to Oracle Forms the experience you are describing is easy, fast and blows user's minds.
I have no issue liking angularjs. It's everywhere in the industry so let's not think that everybody hates it. It has problems , but I've yet to see a framework that allows developers to write complex front-end apps faster. There is none in my opinion. Anything that involves settings up events in some ways (and React usage involves writing event handlers) is a no deal for me.
> Sometimes I feel like I'm the only one who actually likes Angular.
Why? You're obviously not the only one, considering Angular's immense (and deserved) popularity. The simple fact is that popularity does not immunize it to having some problems. Angular is great, but it's hardly perfect. The issues with scope (gone in 2.0), the complexity of directives (also gone in 2.0, I think) are well known and being addressed.
Say what you will I like Angular 1. And there is a ton of resources and books all over the web to help.There is a solution to everything and it's pretty RAD
However, I'm very skeptical about Angular 2. For several reasons. First (I tested it) right now, it is way too complex and unnecessary verbose.
They wanted to support future techs like web components, observables (reactive functional programming) which are great, but it's not that easy to use.
Some people will not like the Rx approach which forces one to rethink the way one codes. There is serious mental gymnastic involved here when one has to think in terms of cold and hot streams, especially when one is used to ng1.
Of course, people who love Typescript will enjoy it,and it's true it's easier to figure out what is what with explicit types, but people who are sticking with ES5 for various reasons will hate all the boilerplate needed to get started.
And they went crazy with dependency injection,this time, this is a divisive issue among programmers and while ng1 DI was light weight, ng2 DI is going full Java which Java/C# folks will like, but i'm not so sure about the rest.
The biggest question is, how is ng2 relevant compared to React + Flux/Relay? since it tries to do the same thing but with more complexity? with that weird template syntax ([attr-read-from]="variable" , (event)="handler" ,[(read-write)]="variable", *template-directive="expression" ... )? React has JSX which is a serious advantage.
ng2 will be ready in a year at best but businesses can be tempted to just move to React in the meantime and then stick with that.
I think if a business needs to, I would recommend they move to React now - Angular 2 is shaping up to be quite impressive, and taking pretty much all of the lessons that Facebook has brought with React (& possibilities brought about by the generally clean architecture such as server-side rendering, native mobile app support, etc.), and refining it ruthlessly, but you can only use what is available if you are consuming a third party library. Once Angular 2 is ready though, I would only consider using it in a new project unless the company is already deeply invested in React (or other tech) & doesn't have the time to migrate.
Angular 2 is still rough today, and that is why it is still in alpha - the Angular team is still trying to figure out what do they need to expose in the framework for consumers to build flexible components. In addition, the testing situation still needs to be refined some. The UI Bootstrap team is in the beginning of migration to Angular 2, and we already came across some pain points that Google is working with us to try to ease as much as possible.
As far as ng2 vs. React - ng2 uses pure HTML templates still. ng2 manages to use this and still optimize dramatically over React due to how change detection works in Angular. The template syntax is not complicated once you get used to it - it is much easier than remembering all of the edge cases that JSX has had to write around (i.e. className) due to issues of conflict with JS itself, and certainly much easier than remembering all of the little caveats and edge aspects of ng1.
Web component support for Shadow DOM is opt-in, and it does use the template tag for custom components. Observables have some overhead, but the great thing is that it is optional for many things, and easy to use when something is exposed as an observable.
The Angular 2 DI is much better than the Angular 1 version - it is much more powerful and doesn't require a hacky implementation due to its use of decorators.
> ng2 manages to use this and still optimize dramatically over React due to how change detection works in Angular.
That's what the angular team claims yet, there is absolutely no proof that ng2 templates are faster than React, and I did my own benchmarks. You can say "it's still alpha" , but if speed is a business requirement for ng2, alpha doesn't fulfill that promise.
> The Angular 2 DI is much better than the Angular 1 version
Better or more verbose and complicated ? I just don't want to do that kind of DI in the front-end. It will lead to people over engineering their code bases. It will lead to bad and verbose code, everything what front-end development should not be.
Actual benchmarks would disagree with your claim - the Meteor team did a benchmark and found Angular 2 significantly faster than Angular 1 (I hope so), React, and their own Blaze. The perf gap increases dramatically with the more DOM elements worked with - the best part is that the Angular and Meteor team's benchmarks are both open source! (The Angular team does not compare with React, just Angular 1 and a baseline of no JS generated DOM)
The problem I have found with most codebases written with angular is by far the underengineering put into it, sometimes to an appalling degree. The new DI is pretty simple - specify an array of services, or just define the array elsewhere and import it in and set it to a config onject. There is not much complexity on the user's side.
There is no such things as underengineering, given specific business requirements. On the other hand, writting useless code is something I often see with people abusing IoC containers like Spring. If a minimal codebase passes the acceptance tests it is not "underengineering" ,it's actually doing one's job as a developer.
Anyway i'm really against the lack of pragmatism in the new DI. But don't worry , by the time ng2 is realised you'll see an avalanche of blog posts about how horrible it is. Mark my words.
There is such a thing called underengineering - it happens quite often at dev shops where developers do not plan their code out with flexibility, clarity, and modularity, where you run into poor abstractions that are inflexible because not enough thought went into what approach would work best for potential business needs...and unsurprisingly, that sort of code often is difficult, if not impossible, to properly test.
Re: ng2 DI, I disagree, I have used the ng2 DI system for almost a year now, in production code as well for a large part of it.
The new DI is decoupled from any framework, allows multiple injectors, avoids verbose hackiness, and is more natural to use - all significant improvements to ng1. There is literally nothing lost, only additions in terms of features and flexibility.
You have the calvinist way of coding: learning, coding, and working harder to improve. Believing that experience will help you build a greater skill. You put your faith in yourself and hard work. You aim for simple elegant code that talks less and does better. You believe more in efficient design than in code: you are a programmer, not a coder.
You have the catholic way of coding: believing in a framework like a church and venerating a bloated edifice with multiple weaknesses to support your most complex code.
Most of the angular coder I have met are just lazy coders believing in magic and tradition not wishing to see coding has a hard earned skilled acquired by craftsmanship.
Coding is not a "tradition", it is a "Beruf".
I am a protestant programmer, and I believe I will achieve better code with more hard work and learning than by venerating any bloated layers in between that will come in my profound gained understanding of programming.
[The one relying on his hard work] is like a man building a house, who dug down deep and laid the foundation on rock. When a flood came, the torrent struck that house but could not shake it, because it was well built. (Luke 6:48)
PS: I do angular. I fix my colleagues' works and it always make me want to puke to dig in this insanity everytime.
This is a rehash of the same problems that have been circulating for years [0]. There is literately not a single original thing here.
Most of these issues are gotchas that can easily be avoided once the developer is aware of them (such as scope inheritance / dynamic scope which is due to Javascript Prototypal Inheritance [1]).
What's ironic is that angular 2 is fully rewritten in part to fix all of these issues, but none of that is mentioned, and the only focus is on how much Angular 2 sucks because it's not compatible with 1. There is also no mention of clear migration path and ability to run angular 1 and 2 side by side [2]
I've put 4 Angular sites in production and never faced issues due to any of these problems. I've had issues with caching, end to end testing of ajax calls, sharing functionality with non angular parts of the site. The very fact that the OP listed these issues tells me that he's not actually used Angular in production.
Angular 1.x has limitations for sure but it works quite well in most scenarios.
This is the comment I was looking for. There was definitely a lot of hand-wringing around the migration path from Angular 1 to 2, but I think the resolved the issue quite nicely.
I've used it in production in a few scenarios and it's worked just fine. They're fairly complex applications and performance hasn't been an issue. Granted, with the author trashing Angular and then talking about how awesome their React article is going to be I think we can all see where this is heading.
Where is this focus about Angular 2 sucking?
The author is in fact happy about Angular 2 being a re-write. Read the section under Problem 6, where he calls the proposed complete re-write of Angular courageous and laudable.
Now he says this is a problem for Angular 1.x because there's no carry-over of knowledge into 2.x, but that's in no-one saying Angular 2 sucks like you are suggesting.
you're right, that was not the best way to put it. I just saw this which seemed like focusing on negative w/out noting that all his complaints will be addressed.
Not convinced yet? Well, what if we were to tell you that the next major version of Angular will take a scorched earth approach to the existing structure that means it will have zero retro-compatibility with what exists today?
Angular may not be perfect, and there are lots of other tools out there, but Angular definitely remains an option to get the job done. And when articles like this pop up, I wonder if we all unconsciously fall into the trap of the "Fallacy of the Perfect Framework" described by Shawn Wildermuth in a recent post. As if moving from one framework to a different one, we will all of the sudden have no more problems and everything will be "perfect".
I love Angular but I often find when I look on StackOverflow for a better way to do something that the most upvoted "solution" is often the WRONG way(Abusing watchers, Abusing $scope, etc) to do something and often contradicts what's in the Angular docs. I can't help but think to myself, "No wonder people hate angular. There's so much bad documentation(Official and Unofficial) and hacky solutions out there. No wonder people are having a bad time."
The #6 complaint on "server-side rendering" calls the rest of the article into question. This illustrates a fundamental "missing the point" of either Angular or React. Client-side templating is one of the essential ideas.
Angular's dependency injection system is much much better than dealing with CommonJS/AMD in my opinion. I would be okay with ES6 modules too but apparently those aren't getting much love yet.
The scoping in AngularJS can be a bit of a pain but I mean, if you know it's dynamically scoped and you know that the directive (ng-if) is introducing a new scope then it isn't the end of the world. Emacs has dynamic binding and it's been working on pretty well so far and contributes to extensibility.
I wonder how the author would convert Angular to use lexical scoping instead of dynamic scoping; would it even be possible without forcing all directives to have a lot of boiler plate?
In terms of Single Page Application frameworks, Angular is very popular. Comparing it to jQuery doesn't really make sense as jQuery is a utility library and doesn't support all of the features that Angular has.
That's hardly a fair comparison. jQuery is a library and Angular is a framework. IIRC, Angular depends on (at least a subset) of jQuery, so it could only approach usage and never exceed.
> Problem #1: Scope inheritance and dynamic scoping
Easily solved by using the controllerAs syntax
> Problem #2: Dirty checking
One time binding to the rescue here. Been available for a good while now. Dirty checking does suck though but is usually not a deal breaker.
> Problem #3: Dependency injection
The authors main problem here seems to be with problems minifying the code. All one needs to do is to pass in an annotations array which is an established best practice. So instead of controller('ControllerName', function($scope, $someService){}) one should use controller('ControllerName', ['$scope', '$someService', function($scope, $someService){}]) there are other more readable ways to do this such as $inject but I digress.
> Problem #4: Pointless complexity
This is debatable and more a matter of opinion. I disagree and think the glut of the authors woes come from not taking the time to understand the framework properly. The learning curve is steep yes but I've used a TON of javascript frameworks and Angular consistently comes out the winner long term in maintainability and stability.
> Problem #5: Server-side rendering
Isomorphic javascript to the rescue here. React does it better in this case but its available if you need it. Angular is a single page web app. If you knew that going in and have a problem with it now... well lets just say that its important to understand the trade offs that come with any technology one chooses to include in their stack.
> Problem #6: Angular 2
Yes this was a concern, and then the angular team listened to the outcry from the community and now have been developing a migration path for users of the 1x code. They have also dedicated an entire team to continue development on the 1x codebase for as long as it remains popular thats why there are two angular websites.
While I admit that angular isn't perfect (literally nothing is) nearly all of the authors criticisms are due to lack of following best practices. You can find a pretty good summation here: https://github.com/johnpapa/angular-styleguide
149 comments
[ 2.8 ms ] story [ 181 ms ] threadThe value comes as you scale the number of developers, the lifetime of the software and the complexity of the product. This holds just as much for Java as it does for Ruby or Javascript.
I generally don't like too much structure unless there are clear benefits and DI doesn't seem to hold up on that scale. The problem it's solving has traditionally been solved with a dozen global variables. And while the purists may scuff at this, I find that in practise it's never an issue in otherwise well structured code.
no they don't. That's a fundamental mistake to say that. DI is about inversion of control , modules don't do that.
Now, on the matter of IOC containers, you can easily roll your own or use a sane one (eg, Guava in Java).
The other thing the author didn't mention is you can't debug your HTML templates. With Mithril, you can set a regular javascript breakpoint in your views. Directives and code-in-HTML essentially reimplement a half-assed version of JavaScript. (The same criticism applies to JSTL which throws out a perfectly good language, Java, and forces you to use XML and tag libraries.)
HTML logic creates complexity because it invents a new programming language in the HTML.
The code-as-HTML is the root problem that causes all the scope issues, all the explosion and complexity of directives, filters, and the inability to set breakpoints in views. With Mithril you don't have this whole directive/filters nonsense, you just write functions.
I've written more about this subject at: https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d6...
How can you take the article seriously with that kind of conclusion.
And flux is great and React-first, but it's not technically a part of React. And it is also great, having a choice is usually a good thing.
Still I'm skeptical when people are happy just because they moved from angular to react. Or from any X to Y really. Usually the gain comes more just from rewriting things with better understanding of the project and from more established team. No one does A/B studies on it, right?
I can't say I miss anything from angular in React. If anything it's good that React does not try to go too far down the rabbit hole. Which particular functionality is absent in React that you need?
It's a valid comparison, if you feel Angular tries to solve problems you don't have, and in doing so, causes other headaches.
Personally I like the event/component oriented development style of Flux/React over procedural controllers that tend to become monolithic. The browser model was always event based, but with the flood of server side development talent the JSP / ASP controller model trickled over. It takes time for people to realize there is a better way.
Lots of people keep repeating that.
It's obvious he means React + React Router + some Fluxy helper lib.
Just substitute "React-based solution" when you read React, and the whole "apples to oranges" or "Angular has so much more" fades away.
(Not to mention that some of us find Angular bloated in the first place, so that it handles "so much more" is not really an asset for us).
We often qualify Angular as the J2EE of the front.
For example the module system is made so because at the time, amd, browserify and ES6 modules were not ready.
And the main point of angular 2 is not to remake angular because it was weird, it is to adapt it to new technologies.
I could ramble for a long time about it, anecdotally; I have peers who use (and seem to enjoy using) Angular (all .net devs), and others who point out its flaws (front-end architects). I find it a very interesting discussion point.
If you're using Angular, the use case might justify the attitude that everyone has JS running. The same people who hold this attitude when making an Angular app might build perfectly serviceable sites to deliver static content without JS.
Funny, I could agree this is true for providers or services. Factories however can't be used for singletons, so I'd rather not know how they implemented shared state and utils.
I think Google is getting blowback from the "worse is better" crowd that have supported the meteroic rise of c, php and mongodb. Specifically, the "worse is better" belief that:
"There is a point where less functionality ('worse') is a preferable option ('better') in terms of practicality and usability." [2]
reminds me of his criticism of "excessive" features in Angular, even though those features are there for a reason.
Usually, what happens with "worse is better" is that when people start missing key features, a bunch of bolt on pre and post processor tools show up to add features (e.g linters, "strict mode",Mongo migration tools) that weren't needed in the more complete solution.
1.http://news.softpedia.com/news/google-releases-guide-on-how-...
2.https://en.m.wikipedia.org/wiki/Worse_is_better [fixed]
I guess that's why everyone complains that it is easier to build a Todo application in Angular but the troubles grow as you grow bigger. The reason why React is successful might be they did get a chance to experiment the architecture on their own things before releasing it to the public.
I used Angular on medium to large web apps in the past and while its easy to get started you always get tons of problems at scale. Staying at scale without problems requires so much discipline its not even worth mentioning.
The two-way bindings are just the wrong way to go in order to keep things simple as you scale. It becomes nearly impossible to reason about the performance of your app or what is going to trigger if you change a model.
This is way, way too complex to build an application. With React most of this complexity goes away. I'm also using React from ClojureScript through the Om library so these might be contributing to said simplicity!
Sort of. The problem React is solving is a subset of the problem Angular is solving. It's a bit more like comparing an older model sports car to a modern engine.
So, both are garages in this sense.
I don't see how this is any different with React. Building a medium - large scale application in React involves just as much complexity as doing it with an Angular app, because you end up adding a Flux implementation (and all of its boilerplate code and ceremony), some sort of routing engine, a testing framework of your own choosing, a myriad of helpers, mixins, and components that a framework like Angular or Ember provide out of the box, and we haven't even started about the increased complexity in terms of tooling; babel, webpack, jsx trasnpiling. Add to that radical new concepts like css defined in your javascript files, the rapid rate at which breaking changes are introduced to React, and the moving target around data handling (Flux is out, Relay is in?) and you find yourself in a very similar situation.
You're comparing a view layer to an entire framework. It would be more apt to compare React to Angular directives but then your overarching point about complexity would be lost. I've worked on large Angular apps and large React apps and I can assure you the complexity was about the same.
Did I miss some subtle novelty about this post, or is Angular ennui just that popular on HN?
His JSFiddle examples are all using angular 1.1.5. Angular 1.2 properly binds scope inside an ng-if.
I agree that angular 1.1.5 had it's warts, if that's what this is supposed to be about. The current release version of angular is 1.4, about to be 1.5.
Edit: After fully reading through this blog post; it's almost all wrong.
Dirty Checking: Yes, we have have to sacrifice ease of use for performance sometimes. So keep it in mind and don't make so many simultaneous data bindings. Why you would need 2000+ in any given state(ui-router)/route is just mystifying. Don't abuse ng-model.
Dependency Injection: Are you kidding me? He's not even using the array notation for proper DI with minification.
Pointless Complexity: This is an actual valid argument, and the only one on the blog. Google has some pretty bad documents for angular, especially when describing directives that isolate scope.
Server Side Rendering: Uh, the whole idea behind stuff like angular is decoupled frontends from your server. Build a REST API and point angular at it; no need to ship layout code with services.
Angular 2: There's an upgrade path that should allow the two to exist in tandem. There's no reason to not keep writing angular 1.x code right now. It's not like Angular 2 being released means all your previous code is worthless.
As someone who's going to need to make a recommendation soon about whether or not to use Angular on a new project, this part worries me. The apps my company builds are full of data grids (Enterprise CRUD-based stuff) and it's entirely reasonable for us to have a 100-row grid with 20 columns as just one of the components on our page. So that's 2000 data bindings right there just for the data values. We'd also have metadata on every cell bound to classes and validation state. If we allow in-place editing, a single one of those fields can be updated. We can't have the entire grid re-checked after every update if that's going to hit the limit on acceptable performance. We'd need to limit it to the row (eg: cross-field validation rules) and elements outside the grid (eg: change toolbar button states.)
Does Angular 2 have similar limitations? Should we wait for Angular 3 and Object.Observe?
However, I don't think that the performance hit you would take would be that noticeable depending on the implementation.
Here's a jsperf test that can demonstrate angular performance with 10k watchers:
http://jsperf.com/angularjs-digest/72
Chrome 45 gave me about 3.2k ops/sec
Totally agree, but my business is auto-generating fully-featured applications based on database schema inspection and a code-generation wizard, for clients with large enterprise databases. So the app has to work reasonably well with out-of-the-box generation before we start tweaking it to customize and improve the UI for the most important tables and most common workflows.
Thanks for the jsperf test. It's good to know the range of results for different browsers. Our app needs to run on everything, including Mobile browsers, and that test proves that we can't get away with using the typical Bootstrap responsive "hide some columns for xs" approach. We need to not generate markup for most of the columns at all. That means we're going to have to enhance our generation wizard to let us specify, per-table, device-size-specific column lists instead of just a single column list.
"Performs well with large data sets; even 10,000+ rows"
http://ui-grid.info/
If the individual cells in your grid aren't changing dynamically, you can use a one-time-binding[1] which will improve performance by removing the watchers after the expression is populated.
You can also always use a directive to do the DOM management yourself, and still use Angular-y templating in the rest of your app.
[1] https://code.angularjs.org/1.4.6/docs/guide/expression#one-t...
You will not regret it.
This is not a solution because the lack of content from the perspective of UAs that don't process JS (such as some web crawlers) decreases search ranking.
The alternative solution for the architecture you propose (0 rendering on the server) is to add a prerendering server between the Internet and your system.
With JS frameworks that do not depend on the DOM, one can have isomorphic JS that runs in both the browser and node. This means the same code can run on the server, for the first request, and after the rendered code is sent down the pipe further requests use the API.
Sending acontent-less HTML with proceeds to fetch something from some API is a non-answer for websites whose search ranking is relevant.
If I had to chose between isomorphic JavaScript + server-side prerendering OR having an extra layer between my frontend server and the Internet, I rather the former – assuming there are no other language/technology requirements.
The public pages I build for my apps are all static html with some JS for flashy crap that people ask for. Search engines don't need to care about the app itself, just the front page, about page, contact, etc, of the biz.
Unless you're talking about a CMS built in Angular, which can get sketchy. Google's web crawler parses JS now anyway, so it shouldn't be a huge problem.
Can I just say that this is the single thing that really irritates me about Angular?
This has been the "gotcha" forever... why are all the guides not using this syntax by default? Why is this just not "the way you do things" if everyone knows this is a problem?
1) Define $scope.obj in the controller, instead of letting ng-model create it for you. [0]
2) Bind to $parent.obj in the inner scope (not necessary in later versions of angular) [0]
3) Upgrade to a modern version of Angular.
[0] https://jsfiddle.net/e924n237/
However, once you learn to avoid Angular's pitfalls, it's a very powerful tool for creating large apps that do not collapse under their own weight.
To illustrate, how often do experienced Angular devs make $scope inheritance errors? If you are, you're not using controllerAs syntax and are coding sloppily. No framework can save you from sloppy coding.
But if the docs are bad, and there are pitfalls that experienced Angular devs know to avoid, how can we distill that down into common knowledge that beginners can avoid?
Can you recommend a book or resource that does that?
* ng-newsletter * bennadal.com (fairly advanced, and sometimes unorthodox) * I found the egghead.io videos very helpful when I was starting * John Papa's angular style guide
If I recall correctly, most of the other resources I've relied on were strewn about the web, and not at any one particular website.
This dearth can lead to lots of code smells, bugs, antipatterns, and other grenades that can present significant problems at scale no matter what framework you choose to go with.
So if it's true that many Angular apps have problems at scale — one hypothesis would be that it may be a reflection of the selection bias of those who choose to use the framework. Which is not to say that advanced JS people aren't using the framework (they clearly are) but anecdotally, upwards of 90% of the Angular-based devs I've interviewed or interacted with personally lack an understanding of many of the aforementioned JS fundamentals.
I feel like Angular's biggest problem is the documentation. It starts out talking about things like dependency injection and why that's good, instead of simply displaying how to use the framework. It's got a steep learning curve and it just seems that people get scared of the documentation and run away before they really give it a try.
I agree on the documentation being unusual. I found the Angular Style Guide to be a huge help: https://github.com/johnpapa/angular-styleguide
Anedoctally, as the author of another JS framework (http://mithril.js.org), I see a lot of people migrating away from Angular due to complexity, bloat and performance issues. I, myself, spent a good two years wrestling w/ Angular problems full time before jumping ship. Our apps were quite complex and we were fully invested in trying to make Angular work, and definitely not just making a half-assed effort to like it. So it's definitely not just newbies.
So while this post is mostly FUD, your points are valid, I feel all frameworks come with a tradeoff.
Making the virtual DOM tree a first-class value that can be treated as a persistent data structure is a huge win. Templates are functions that return a virtual DOM node. Rendering a list is a map from Thing -> virtual DOM node. Redundant rendering is avoided with memoization. "Partials" are just functions. The system handles escaping and prevents XSS vulnerabilities by distinguishing plain strings from DOM nodes, which string-based templating systems do not do. All of the complexity and difficulty of working with templating systems goes away when we can just use the usual functional combinators we all know and love to compose views.
On top of Mithril, I recommend working in a functional reactive library (Kefir, Bacon, Rx, whatever else) to make the whole application declarative and functional. Angular just doesn't compose well with other things like Mithril and other primarily functional libraries do. I should really write a blog post on this.
How are you using an FRP library with Mithril? I thought with vdom libraries you never touch the real DOM.
VDom lets you express UI as a function of the state
Observables let you express state as a function of user interactions
One major problem with older "build-DOM-in-code" approaches was ability to integrate to third party libraries, but I feel that this problem has been solved by newer frameworks (e.g. via lifecycle methods/mixins in React, `config` in Mithril, etc).
Personally, I find that mapping the DOM structure onto Javascript a la Mithril, React, et al works out better than mapping scopes and closures and logic onto HTML (a la Angular), simply because it's easier to refactor code that is, well, code, rather than something that tries to emulate having programming-language-like properties in HTML by shipping its own quirky implementation of scopes, expression parsers, compiler, etc.
I disagree on cost of migration. It's not exactly trivial to migrate from Angular to any framework that I know of, for example, especially once you start using things like form validation flags or filters. The only migrations that sound somewhat straightforward to me are Meteor/Ember (since both use Handlebars flavors) and - perhaps ironically - React/Mithril (assuming JSX/MSX), but for mostly anything, you're pretty much stuck with manually porting framework-specific syntax. With that being said, it's not necessarily impossible. I know of success stories of people porting non-trivial codebases from Ember to Mithril and even from jQuery spaghetti to Mithril (via its template converter too). At the end of the day, I think it comes down to tooling. With React's renderToString or mithril-node-render, it's quite feasible to automate a large portion of the work of porting templates away from these newer frameworks, should you need to do so down the road.
How is that specific to Angular?
The learning curve is steep, but when you get into the groove, when it finally clicks, then you can really take off with it.
I love the tooling (node, Yeoman, Grunt, jshint, karma, protractor etc.). While not perfect, it's definitely helped me write better, more readable code.
The one article that helped me get to my 'gotcha' stage was this one by Todd Motto: http://toddmotto.com/rethinking-angular-js-controllers/
I think part of the problem is that everyone wants there to be The Next Thing that will solve all problems, when that doesn't exist.
Looks to me angular is a round peg disguised as a square one.
React solves all of those in a cleaner way.
>I like using nearly straight up HTML as my template.
And yet you don't. You use Angular-ized HTML as your template.
If you're using Flux, you end up with an immense amount of boilerplate action and store code around every input field. The other option is to violate the model, make all your inputs uncontrolled and have boilerplate onChange listeners for each one.
Choose the right tool for the job. Angular's no-questions-asked data-binding is perfect for this scenario.
For example, I don't find fixing occasional performance issues when using two way binding a big deal. Two way binding makes my UI code much more concise and free from bugs concerning keeping models and the DOM in sync. I've worked with Backbone before for instance and found that dealing with listeners and syncing manually was a huge source of bugs.
Most of the time all you need is a computed property. It simplifies the code base and allows the framework to make optimizations where it needs to. If you really need a two way binding you can always do it with a computed alias.
Thank you! I never understood the big push towards server-side rendering. I did server side rendering for 10+ years in JSP land. I love having a clean separation between client and server, freeing me to experiment with different languages and frameworks on the server side. Likewise, if I want to experiment with a React component consuming my REST API I can. Not to mention my AWS expenses are kept minimal as most of the processing is offloaded to the client side.
> "I like using nearly straight up HTML as my template." Agreed again. Am I the only one who works with people who know HTML, CSS, and a little bit of Javascript who can contribute to the front end design? I feel like if I threw a "DOM in code" type of approach at them they would feel lost.
I personally find Knockout to be almost the sweet spot. Very lightweight, plays well with others, doesn't "take over" or try to impose a top-down ordering on the page.
I know the rest of the developer world has moved on but I'm hoping I can hold on to using Knockout long enough until another MVVM system which separates view and model but binds them together comes along.
On the server side rendering front I'd be curious to know if you do LOB apps. In my in house dev world where people are almost always within 100m of the server and used to Oracle Forms the experience you are describing is easy, fast and blows user's minds.
Why? You're obviously not the only one, considering Angular's immense (and deserved) popularity. The simple fact is that popularity does not immunize it to having some problems. Angular is great, but it's hardly perfect. The issues with scope (gone in 2.0), the complexity of directives (also gone in 2.0, I think) are well known and being addressed.
However, I'm very skeptical about Angular 2. For several reasons. First (I tested it) right now, it is way too complex and unnecessary verbose.
They wanted to support future techs like web components, observables (reactive functional programming) which are great, but it's not that easy to use.
Some people will not like the Rx approach which forces one to rethink the way one codes. There is serious mental gymnastic involved here when one has to think in terms of cold and hot streams, especially when one is used to ng1.
Of course, people who love Typescript will enjoy it,and it's true it's easier to figure out what is what with explicit types, but people who are sticking with ES5 for various reasons will hate all the boilerplate needed to get started.
And they went crazy with dependency injection,this time, this is a divisive issue among programmers and while ng1 DI was light weight, ng2 DI is going full Java which Java/C# folks will like, but i'm not so sure about the rest.
The biggest question is, how is ng2 relevant compared to React + Flux/Relay? since it tries to do the same thing but with more complexity? with that weird template syntax ([attr-read-from]="variable" , (event)="handler" ,[(read-write)]="variable", *template-directive="expression" ... )? React has JSX which is a serious advantage.
ng2 will be ready in a year at best but businesses can be tempted to just move to React in the meantime and then stick with that.
.
Angular 2 is still rough today, and that is why it is still in alpha - the Angular team is still trying to figure out what do they need to expose in the framework for consumers to build flexible components. In addition, the testing situation still needs to be refined some. The UI Bootstrap team is in the beginning of migration to Angular 2, and we already came across some pain points that Google is working with us to try to ease as much as possible.
As far as ng2 vs. React - ng2 uses pure HTML templates still. ng2 manages to use this and still optimize dramatically over React due to how change detection works in Angular. The template syntax is not complicated once you get used to it - it is much easier than remembering all of the edge cases that JSX has had to write around (i.e. className) due to issues of conflict with JS itself, and certainly much easier than remembering all of the little caveats and edge aspects of ng1.
Web component support for Shadow DOM is opt-in, and it does use the template tag for custom components. Observables have some overhead, but the great thing is that it is optional for many things, and easy to use when something is exposed as an observable.
The Angular 2 DI is much better than the Angular 1 version - it is much more powerful and doesn't require a hacky implementation due to its use of decorators.
That's what the angular team claims yet, there is absolutely no proof that ng2 templates are faster than React, and I did my own benchmarks. You can say "it's still alpha" , but if speed is a business requirement for ng2, alpha doesn't fulfill that promise.
> The Angular 2 DI is much better than the Angular 1 version
Better or more verbose and complicated ? I just don't want to do that kind of DI in the front-end. It will lead to people over engineering their code bases. It will lead to bad and verbose code, everything what front-end development should not be.
The problem I have found with most codebases written with angular is by far the underengineering put into it, sometimes to an appalling degree. The new DI is pretty simple - specify an array of services, or just define the array elsewhere and import it in and set it to a config onject. There is not much complexity on the user's side.
There is no such things as underengineering, given specific business requirements. On the other hand, writting useless code is something I often see with people abusing IoC containers like Spring. If a minimal codebase passes the acceptance tests it is not "underengineering" ,it's actually doing one's job as a developer.
Anyway i'm really against the lack of pragmatism in the new DI. But don't worry , by the time ng2 is realised you'll see an avalanche of blog posts about how horrible it is. Mark my words.
Re: ng2 DI, I disagree, I have used the ng2 DI system for almost a year now, in production code as well for a large part of it.
The new DI is decoupled from any framework, allows multiple injectors, avoids verbose hackiness, and is more natural to use - all significant improvements to ng1. There is literally nothing lost, only additions in terms of features and flexibility.
You have the catholic way of coding: believing in a framework like a church and venerating a bloated edifice with multiple weaknesses to support your most complex code.
Most of the angular coder I have met are just lazy coders believing in magic and tradition not wishing to see coding has a hard earned skilled acquired by craftsmanship.
Coding is not a "tradition", it is a "Beruf".
I am a protestant programmer, and I believe I will achieve better code with more hard work and learning than by venerating any bloated layers in between that will come in my profound gained understanding of programming.
[The one relying on his hard work] is like a man building a house, who dug down deep and laid the foundation on rock. When a flood came, the torrent struck that house but could not shake it, because it was well built. (Luke 6:48)
PS: I do angular. I fix my colleagues' works and it always make me want to puke to dig in this insanity everytime.
It's weird, but it's weird in the exact way that JS prototypical inheritance is weird. So it's important to learn.
Anyways the fix is simple, always initialize your variables before you use them. Either in the controller or using an ng-init.
What's ironic is that angular 2 is fully rewritten in part to fix all of these issues, but none of that is mentioned, and the only focus is on how much Angular 2 sucks because it's not compatible with 1. There is also no mention of clear migration path and ability to run angular 1 and 2 side by side [2]
I've put 4 Angular sites in production and never faced issues due to any of these problems. I've had issues with caching, end to end testing of ajax calls, sharing functionality with non angular parts of the site. The very fact that the OP listed these issues tells me that he's not actually used Angular in production. Angular 1.x has limitations for sure but it works quite well in most scenarios.
[0] http://larseidnes.com/2014/11/05/angularjs-the-bad-parts/
[1] http://jimhoskins.com/2012/12/14/nested-scopes-in-angularjs....
[2] http://angularjs.blogspot.com/2015/08/angular-1-and-angular-...
EDIT: shortened. EDIT2: added conclusion
I've used it in production in a few scenarios and it's worked just fine. They're fairly complex applications and performance hasn't been an issue. Granted, with the author trashing Angular and then talking about how awesome their React article is going to be I think we can all see where this is heading.
Now he says this is a problem for Angular 1.x because there's no carry-over of knowledge into 2.x, but that's in no-one saying Angular 2 sucks like you are suggesting.
Not convinced yet? Well, what if we were to tell you that the next major version of Angular will take a scorched earth approach to the existing structure that means it will have zero retro-compatibility with what exists today?
http://wildermuth.com/2015/09/01/Angular_v_React_v_Aurelia_v...
The scoping in AngularJS can be a bit of a pain but I mean, if you know it's dynamically scoped and you know that the directive (ng-if) is introducing a new scope then it isn't the end of the world. Emacs has dynamic binding and it's been working on pretty well so far and contributes to extensibility.
I wonder how the author would convert Angular to use lexical scoping instead of dynamic scoping; would it even be possible without forcing all directives to have a lot of boiler plate?
https://www.google.com/trends/explore#q=jquery%2C%20angularj...
Easily solved by using the controllerAs syntax
> Problem #2: Dirty checking
One time binding to the rescue here. Been available for a good while now. Dirty checking does suck though but is usually not a deal breaker.
> Problem #3: Dependency injection
The authors main problem here seems to be with problems minifying the code. All one needs to do is to pass in an annotations array which is an established best practice. So instead of controller('ControllerName', function($scope, $someService){}) one should use controller('ControllerName', ['$scope', '$someService', function($scope, $someService){}]) there are other more readable ways to do this such as $inject but I digress.
> Problem #4: Pointless complexity
This is debatable and more a matter of opinion. I disagree and think the glut of the authors woes come from not taking the time to understand the framework properly. The learning curve is steep yes but I've used a TON of javascript frameworks and Angular consistently comes out the winner long term in maintainability and stability.
> Problem #5: Server-side rendering
Isomorphic javascript to the rescue here. React does it better in this case but its available if you need it. Angular is a single page web app. If you knew that going in and have a problem with it now... well lets just say that its important to understand the trade offs that come with any technology one chooses to include in their stack.
> Problem #6: Angular 2
Yes this was a concern, and then the angular team listened to the outcry from the community and now have been developing a migration path for users of the 1x code. They have also dedicated an entire team to continue development on the 1x codebase for as long as it remains popular thats why there are two angular websites.
While I admit that angular isn't perfect (literally nothing is) nearly all of the authors criticisms are due to lack of following best practices. You can find a pretty good summation here: https://github.com/johnpapa/angular-styleguide