Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Criticisms of Angular

leanpanda.com

Post reply on HN
Print view View original

141–150 of 150 posts

Re: Criticisms of Angular

#141

Post by bluepnume »

grumblestumble wrote: post #137
3pt14159 wrote: post #92

Earlier quoted context omitted.

Compared to Ember. 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.

Re: Criticisms of Angular

#142

Post by [deleted] »

grumblestumble wrote: post #137
3pt14159 wrote: post #92

Earlier quoted context omitted.

Compared to Ember. 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)

[deleted]

Re: Criticisms of Angular

#143

Post by joshschreuder »

snorrah wrote: post #127
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…

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.

So then why is it under a heading that says Problem 6?

Re: Criticisms of Angular

#144

Post by juristr »

Nowadays: want lots of traffic on your blog -> rant about Angular.

The problem is just that you're nearly a year too late.

- yep angular has flaws (which framework doesn't?)

- ya, it does dirty checking and yes, that might have perf implications if used the wrong way. But hey, 6 years ago when Angular was created it was a revolutionizing idea, and still holds today. Also, at that time no Objecte.observe existed, nor did SPAs really (well..GWT was kinda the solution at that time). But, did u check what they're doing in Angular 2? Heard about RxJS and stuff?

- DI: strange syntax techniques to work around minifiers? You don't really use those, do u? heard about ngAnnotate?

- Oh...AMD, UMD etc...do not dependency injection. And yes, agree, DI together in combination with AMD/UMD/... creates confusion with newbie frontend developers

- Then: Angular 2 is already live on GitHub, for a while; has even it's own webpage online

- and for god's sake..Angular 2 is compatible with Angular 1...read their blog posts, their Tweets, weekly meetup notes and design docs (all openely available on GDocs)

- oh..and there are even some rumors server-side rendering will be possible in ng 2

I like ur blog, but if you go and rant, please check the latest status, inform yourself, then rant. Nothing against critics, they foster discussion, but only if made properly.

Re: Criticisms of Angular

#145

Post by code_sterling »

lhorie wrote: post #97
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.

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

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.

Re: Criticisms of Angular

#146

Post by juristr »

choward wrote: post #132

This article is about 2 years late. These are solved problems in angular 2 by default and have solutions in angular 1. = Problem #1: Scope inheritance and dynamic scoping Use directive controllers = Problem #2: Dirty checking Use immutability = Problem #3: Dependency injection I'm not really sure what the author is saying here. It sounds like he's confused and thinks DI and modules solve the same problem. The one sta…

ah...finally, someone that gets it and says it aloud...if I would have found this comment before, I wouldn't have put mine further below. Thx!

Re: Criticisms of Angular

#147

Post by elros »

fein wrote: post #81
elros wrote: post #70

Earlier quoted context omitted.

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

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

Well, you're assuming the content does not live inside the app. In my situation, and in many others, it does.

Re: Criticisms of Angular

#148

Post by mcv »

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…

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

Re: Criticisms of Angular

#149

Post by ry_ry »

ohitsdom wrote: post #129
DougWebb wrote: post #59

Earlier quoted context omitted.

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

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.

Re: Criticisms of Angular

#150

Post by trophygeek »

SonicSoul wrote: post #126
pwfisher wrote: post #124

Our company had two Angular codebases, the public site and our internal site. Experience in one taught you nothing about the other because there was no "Angular way" to structure your code. Having "enough rope to hang yourself" while our devs were just learning Angular led to an unholy mess. Development slowed to a painful crawl. We hate Angular. We're an Ember shop now. We love Ember! Angular gives you enough rope t…

Interestingly I've heard similar sentiments from Ember developers, mainly that it is much more 'opinionated' than Angular. In my experience with Angular there is a pretty clear logic on how to structure code. I suppose that logic is not enforced so there is nothing to stop developers from just cramming all code into index.thml. Being a dev manager I've adopted feature structure [0] and it has worked quite well across…

I'm a bit behind on this thread and I am an Angular guy myself, but I think Ember is moving this direction.

http://www.programwitherik.com/ember-pods/

Post reply on HN