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

Things that suck in AngularJS

lhorie.blogspot.ca

Post reply on HN
Print view View original

71–80 of 151 posts

Re: Things that suck in AngularJS

#71

Post by r4vik »

film42 wrote: post #64
cgag wrote: post #35

Earlier quoted context omitted.

This seems like such a huge win, I'm it's not more common with other compile to js languages.

It's not so common because: - It requires a running JVM to compile it all down (not a bad thing). - Can take upwards of a second to compile depending on code base size and compression setting (even if the JVM is warm). - Kills all ability to debug. Looks like "a.call().call()" etc. That said, ClojureScript has been fun to work with, but IMO, Google Closure as dependency thwarts a lot of people looking to try it out l…

http://cljsfiddle.net/ goes a long way towards having a tool people can just play with to try out ClojureScript without being twarted by setting up Clojure/JVM/Lein/Lein-cljsbuild/

Re: Things that suck in AngularJS

#72

Post by joevandyk »

d0m wrote: post #56
jowiar wrote: post #54

Angular, when it feels right, makes me incredibly productive, but I feel like I spend 90% of my time banging my head against a brick wall. One of the single biggest usability features of anything is giving things appropriate names. The "other half" of Karlton's law is well in effect here. Angular fails miserably at this task. And that makes reading documentation, as well as maintaining enough context in my head to be…

I agree with you that it's frustrating at time. Especially when angular does magic stuff that you're just supposed to know. Like fuck with your existing links and stop existing forms from working. And sometimes, real easy things are so complicated.. For instance, try to make a form post on the current page. (Hint: If you don't have action="", then the form doesn't post. But, by default, no action usually means submit…

http://docs.angularjs.org/api/ng.directive:form explains it pretty well.

Re: Things that suck in AngularJS

#73

Post by chii »

nostrademons wrote: post #49
hswolff wrote: post #47

Earlier quoted context omitted.

I thought Gmail was a compiled to JavaScript from Java application?

Nope, you're thinking of GWT. Relatively few Google products actually use GWT; the bulk of them are on Closure. GMail's client (and Google+, and Docs, and Search) all use Javascript-compiled-to-Javascript for the client side.

I've always wondered why GWT isn't much more popular (at least, for google properties). I know of a half dozen apps written in GWT by google. The rest is probably in closure (or something else).

Perhaps they still haven't solved the SEO problem of GWT internally, and so only things that don't need SEO-features like control panels, dashboards (but ironically, the google groups forums too) are in GWT.

Re: Things that suck in AngularJS

#74

Post by chii »

graue wrote: post #42
paultannenbaum wrote: post #21

Earlier quoted context omitted.

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…

You may be thinking of Clojure and ClojureScript — with a J. It's confusing naming, but those are different, and are not Google products. In this thread, we're talking about Google's Closure (with an S) Library. Google also makes a Closure (with an S) Compiler, but it's more of an optimizer — it "compiles" from JavaScript to optimized JavaScript.

I would prefer to clear the confusion by calling Closure templates "soy templates", and differentiate it from the Closure compiler (for compiling javascript).

Re: Things that suck in AngularJS

#75

Post by chii »

film42 wrote: post #64
cgag wrote: post #35

Earlier quoted context omitted.

This seems like such a huge win, I'm it's not more common with other compile to js languages.

It's not so common because: - It requires a running JVM to compile it all down (not a bad thing). - Can take upwards of a second to compile depending on code base size and compression setting (even if the JVM is warm). - Kills all ability to debug. Looks like "a.call().call()" etc. That said, ClojureScript has been fun to work with, but IMO, Google Closure as dependency thwarts a lot of people looking to try it out l…

i m certain you can pretty print the resulting compiled js. see http://googleclosure.blogspot.com.au/2010/10/pretty-print-ja...

Re: Things that suck in AngularJS

#76

Post by Bahamut »

erikpukinskis wrote: post #24
famo wrote: post #18

Earlier quoted context omitted.

I started with Ember about a year ago and the getting started docs were pretty terrible. It took a lot of experimentation and frustration before I was comfortable developing with it. Eventually I became familiar with the framework and the API docs are quite in-depth, not really great for a beginner though. After about four Ember projects I can now prototype a large app (using something like Bootstrap) in a day or so,…

My experience pretty much parallels yours. These frameworks are at the cutting edge. Only a handful of big apps have been made with Ember or Angular, and so the core teams are constantly bumping up against weaknesses in their designs which can only be addressed by making changes that break apps. From reading the Ember discussion lists I get the strong sense that the core team is willing to make difficult breaks, but…

I'm currently working on a big Angular app that is about to move into production (although it's not to be something that's widely used in public) - we have found that Angular causes everything to be structured in a nicely organized fashion overall. This app is not structured perfectly by any means either, due to bad design on some of our pre-existing code base.

From what I understand, big Ember projects have turned out well for Ember devs - I can confidently say that I feel the same way about big Angular apps. I have built several big ones, including an online assessment platform (frontend by myself) and an online assessment platform/management system (with a team of ~10, 3 of us on frontend).

From my experience, the Angular team has thought things out on a high level, which I greatly appreciate. They are big consumers of their own product, as Angular is used quite a bit with Google's own sites - here is an example of an Angular app, with Angular being used to implement parallax scrolling (and probably more): http://www.google.com/nexus/7/

Re: Things that suck in AngularJS

#79

Post by grumblestumble »

gkoberger wrote: post #4

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

AngularUI is indeed very much 'off on their own doing what they want', they are not a part of the core team AFAIK. Even inside the AngularUI team, quality, convention and style can be dramatically different across different modules ( cough ng-grid ).

Re: Things that suck in AngularJS

#80

Post by Zelphyr »

psychometry wrote: post #5
gkoberger wrote: post #4

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

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 you. In my experience, all of the time gains you realize from using a framework early on are lost (and then some) trying to get it to do that last 10% that you need.

Ultimately I've found that using vanilla Javascript offers everything I need to just "get things done" and complete a project successfully. Sure, I might not be able to get something out the door in a day. But at the end of the project I've delivered clean, maintainable code on time. And anyone who knows Javascript will be able to read it.

Now, lest you think I'm a complete framework hater; they have their place. They're great at prototyping, for example. But never again will I build an entire project on one. I have little interest in being a glorified glue stick, piecing framework code together. How boring.

I should add that I make heavy use of libraries like jQuery and Underscore. They're libraries, not frameworks. Take what you need with them yet still reasonably lightweight. Frameworks are bloated, tightly-coupled, poorly documented monstrosities in my opinion.

Post reply on HN