Live data from Hacker News

Things that suck in AngularJS

lhorie.blogspot.ca

101–110 of 151 posts

Re: Things that suck in AngularJS

#101
post #80

Earlier quoted context omitted.

Is there a Javascript MVC framework that actually has good documentation, guides, and code samples? I've been working with Ember.js, but it's incredibly frustrating trying to learn a framework whose documentation is incomplete. The other problem I've found is that docs, tutorials, and Stack Overflow posts that are even six months old are often completely useless when troubleshooting bugs in Ember.js or even learning…

> Those of us who really need to just "get things done" might be better suited by a mature, well-documented framework, but does one actually exist? No. Frameworks are all the same in that they are great at getting you to about 80% of what you need REALLY fast. The next 10% takes some investigation but its doable. But that last 10%. Its like pulling teeth. You're working for the framework rather than it working for yo…

Finally someone said it. Even if I write more code by only using libraries and no frameworks (which is debatable), at least I'm happy while writing it.

I do consider some frameworks to be exceptions though. Express is called a framework but it looks more like a library for HTTP handling to me. Most npm packages behave like libraries - maybe that's why I like using Node.js so much. Also CSS "frameworks" like Bootstrap aren't in the same league. They've never caused me the type of frustration I've had with frameworks like RoR or Angular. Bootstrap is actually a library of UI widgets. They can call it a "framework" but I don't consider it to be one.

Re: Things that suck in AngularJS

#102
post #44
post #15

Earlier quoted context omitted.

> Google has the chance to build the new framework that will run the web in 2-3 years. Much like Rails a few years ago. Angular is an amazing framework. It seems like they just don't care. People use to say that about ExtJS a few years ago , then BackboneJS, etc ... There will never be one framework to rule them all , like Rails never ruled server-side developpment, Rails influenced other frameworks. Likewise Angular…

I think Angular is just the latest in their web dev portofolio, driven by internal needs. They have Closure, which is basically their own jQuery + package/module/dependency loader & framework. Then there's Dart, which is kind of their version of CoffeeScript/TypeScript/etc. (and even looks strikingly like Angular at times[1]). There are definitely overlapping concerns, but they've dogfooded Angular for both the YouTu…

> Then there's Dart, which is kind of their version of CoffeeScript/TypeScript/etc.

From my point of view, it's just the next logical step after GWT and Closure. The annotations are baked into the language's syntax, you get the usual JS-like development cycle (save -> F5), and Java/C#-like tooling.

TS is somewhat similar. CS, however, isn't. CS doesn't offer any tooling advantages over JS.

> looks strikingly like Angular at times

Heh. There is also a Dart version of Angular:

https://github.com/angular/angular.dart

Re: Things that suck in AngularJS

#103

Documentation is by far the worst part of Angular. I spent 90% of my time Googling and 10% writing code. (Hey, maybe that's Google's plan -- ramp up traffic to search. Synergy!) AngularUI is confusing, mostly undocumented and often behind Angular. Splitting ngRoute/ngAnimate into their own files is an odd choice, although I assume the former is so they can replace it with the superior ui-router. Which also is weird.…

Sounds like something that could be crowd-funded - pay some contributor's salary for a while to write the docs :).

Re: Things that suck in AngularJS

#104
As you dive deeper into Angular it becomes clear a lot of it is unpolished. For example $resource seems very half baked. It has lots of quirks e.g. trailing slashes and its promises support seems to be a bolt-on.

Re: Things that suck in AngularJS

#105
post #93

Earlier quoted context omitted.

GWT is seen as extremely slow (especially compilation times) and not suited to heavy client-side applications. I don't think the SEO nature of GWT is fundamentally different from Closure or Angular.

GWT on AppEngine (which it has great integration for) has a ten second startup time when not loaded, and on the free tier they unload it when not in use, so that's not the greatest. I used GWT for a while and it would be great for enterprise and large teams. The static typing which I usually love/insist on though, does seem pretty cumbersome for something as simple as a web page. I've switched to scala play for the b…

you should try out closure. it has static typing and a really well developed and tested library alongside the fantasitc compiler.

Re: Things that suck in AngularJS

#106
post #6

Earlier quoted context omitted.

I felt like Backbone.js (when I was actively using it) had really clean and complete docs. Couple that with the fact that the source is incredibly readable and debugging anything strange was never that tough.

Sure, but Backbone does a fraction of what Angular does. And, it's pretty consistent with how most people write JS anyway -- whereas Angular pretty much re-envisioned everything.

You say that like it's a pro but I'm pretty sure it's a con.

Re: Things that suck in AngularJS

#107
post #15

Earlier quoted context omitted.

> Google has the chance to build the new framework that will run the web in 2-3 years. Much like Rails a few years ago. Angular is an amazing framework. It seems like they just don't care. People use to say that about ExtJS a few years ago , then BackboneJS, etc ... There will never be one framework to rule them all , like Rails never ruled server-side developpment, Rails influenced other frameworks. Likewise Angular…

The problem with Closure is that it really sucks for small projects. It was built for large products with hundreds of developers and millions of users; many of the library features (eg. static typing; dependency management; compilation; CSS renaming; namespacing & scoping; full component libraries) are absolutely invaluable for that use case, but don't get you much when you're just prototyping a few ideas. I don't th…

We started our project from the get go in closure because this overhead can be automated. The benefits outweigh the pitfalls IMO, and a week spent on process will pay huge dividends down the line.

Re: Things that suck in AngularJS

#108
post #15

Earlier quoted context omitted.

> Google has the chance to build the new framework that will run the web in 2-3 years. Much like Rails a few years ago. Angular is an amazing framework. It seems like they just don't care. People use to say that about ExtJS a few years ago , then BackboneJS, etc ... There will never be one framework to rule them all , like Rails never ruled server-side developpment, Rails influenced other frameworks. Likewise Angular…

Maybe my understanding is wrong, but closure (and closurescript) are compiled languages. Angular is a UI framework, so comparing them is apples to oranges. And I think the Angular community would be thrilled if it had even close to the kind of documentation that Rails has. You are correct, no one framework will rule them all, but there are examples of OS projects that have good docs (like jQuery and Rails) that can b…

I am fairly sure I have seen tutorials on using the two together.

Re: Things that suck in AngularJS

#110
post #27

Documentation is by far the worst part of Angular. I spent 90% of my time Googling and 10% writing code. (Hey, maybe that's Google's plan -- ramp up traffic to search. Synergy!) AngularUI is confusing, mostly undocumented and often behind Angular. Splitting ngRoute/ngAnimate into their own files is an odd choice, although I assume the former is so they can replace it with the superior ui-router. Which also is weird.…

If you're really spending 90% on Google, and 10% writing code, then you're doing it wrong. At least a good 30% of your time should involve reading code. In any framework. That said, AngularJS' code is magic in places. The magic is contained within small modules, or at least as small as those can get for what they're supposed to do. But documentation is only enough to get you started. In any framework. (And in my expe…

Why?

I use Django on the server side, the documentation is superb (compared to Angular's). I hardly ever need to dig inside the code, unless I want to do something quite special.

I have a good idea of how the framework works, what pieces fit together where, but I never feel the need to go in and read the code for it.

And what about proprietary software? I am sure there are plenty of frameworks where you can't get to look at the code.

Post reply on HN