Criticisms of Angular • Hacker News Board

Re: Criticisms of Angular

#111

Post by Touche » Wed, Sep 23, 2015, 3:47 PM UTC

davexunit wrote: post #94

code_sterling wrote: post #64

Earlier quoted context omitted.

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 D…

> 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.

Re: Criticisms of Angular

#112

Post by rbalicki » Wed, Sep 23, 2015, 3:50 PM UTC

spmurrayzzz wrote: post #96

rbalicki wrote: post #43

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…

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 sc…

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.

Re: Criticisms of Angular

#113

Post by aikah » Wed, Sep 23, 2015, 3:53 PM UTC

Bahamut wrote: post #66

aikah wrote: post #48

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,…

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 consumin…

> 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.

Re: Criticisms of Angular

#114

Post by SonicSoul » Wed, Sep 23, 2015, 3:54 PM UTC

CitizenKane wrote: post #104

SonicSoul wrote: post #57

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…

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 artic…

yeah I wonder how he managed to make front page of HN with these outdated ng-criticisms

Re: Criticisms of Angular

#115

Post by rbalicki » Wed, Sep 23, 2015, 3:54 PM UTC

bphogan wrote: post #73

rbalicki wrote: post #43

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…

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?

Off the top of my head, I can recommend:

* 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.

Re: Criticisms of Angular

#116

Post by l1ambda » Wed, Sep 23, 2015, 3:54 PM UTC

stupidcar wrote: post #2

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.

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.

I've written more about this subject at: https://medium.com/@l1ambda/mithril-vs-angular-vs-react-d0d6...

Re: Criticisms of Angular

#117

Post by thoman23 » Wed, Sep 23, 2015, 3:56 PM UTC

IgorPartola wrote: post #45

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…

> "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.

Re: Criticisms of Angular

#118

Post by davexunit » Wed, Sep 23, 2015, 4:01 PM UTC

Touche wrote: post #111

davexunit wrote: post #94

Earlier quoted context omitted.

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 D…

> 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.

Re: Criticisms of Angular

#119

Post by steven777400 » Wed, Sep 23, 2015, 4:03 PM UTC

IgorPartola wrote: post #45

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…

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.

Re: Criticisms of Angular

#120

Post by cmdkeen » Wed, Sep 23, 2015, 4:05 PM UTC

IgorPartola wrote: post #45

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…

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.