Things that suck in AngularJS • Hacker News Board

Re: Things that suck in AngularJS

#141

Post by gtrak » Tue, Oct 29, 2013, 9:10 PM UTC

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…

Maybe I'm a bit of a masochist, but it's not that hard to read the compiled output, especially when you have a decent mental model of what it should be. It doesn't look like idiomatic javascript, but the structure is pretty regular.

Here's an example for the kids at home.

compiled: https://github.com/gtrak/node-cljs-template/blob/master/src/...

from: https://github.com/gtrak/node-cljs-template/blob/master/src-...

Re: Things that suck in AngularJS

#142

Post by Oculus » Tue, Oct 29, 2013, 9:20 PM UTC

pygy_ wrote: post #67

Oculus wrote: post #65

Earlier quoted context omitted.

Where'd you get the wrong idea that it was a Startup? AngualrJS was a side project of Misko, who was working at Google on the DoubleClick team, until he bet he could rewrite DoubleClick in 1 or 2 (can't remember) weeks using his framework and cut down on the LOC/code complexity. He eventually did and they decided to go full time on the framework. They discussed this at the start of their Google IO presetation.

[0] which leads to [1] Notice the "Copyright 2009 - Angular / BRAT Tech. LLC" at the bottom of the page. IIRC, They had a plan to provide a paid or freemium server-side counterpart. edit: freemium, see the first revision of getangular.com[2], there's a pricing tab which disappeared later on. update 2 : they were not acquired, they abandoned the startup because it did not get enough traction. The framework lived on, t…

I stand corrected, my apologies. I simply assumed that it was Misko's side project (by assuming, I mean made an ass of myself). I'm going to pay more attention next time they talk about its history to see if they actively attempt to not bring that part of its history up. Agree with novaleaf, it's super weird they never mentioned it.

Re: Things that suck in AngularJS

#143

Post by anoncowherd » Tue, Oct 29, 2013, 9:35 PM UTC

lhorie wrote: post #133

Nitramp wrote: post #12

I agree with most of the things mentioned in the article, but here are a couple of nits, just in case you have that exact problem and look for the fix: $timeout having no $cancelTimeout: that's just called $timeout.cancel(), taking the promise you got out of the initial $timeout call. $.when is called $q in AngularJS, support for promises actually runs deep in the framework. Regarding the difficulty of instantiating…

Hi author here. Thanks for the feedback :) re: instantiating controllers - services definitely help, but you still have to design and expose APIs to manage the lifecycle of variables from the controllers, and often times (at least for me), there are a lot of cross-concerns and it becomes impractical to have services to deal with each permutation of concern groups (this is especially a problem in more exploratory proj…

So why does Backbone.JS suck then? :)

Re: Things that suck in AngularJS

#144

Post by erikpukinskis » Tue, Oct 29, 2013, 11:10 PM UTC

Zelphyr wrote: post #80

psychometry wrote: post #5

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…

I think it depends on how good you are. If you're a great developer, with deep knowledge of patterns, a strong commitment to refactoring, with lots of experience such that you're aware of the pitfalls you are likely to befall, then you're probably right: frameworks will buy you little.

I'm pretty good, but I'm apparently not good enough, because I find myself consistently learning things from frameworks. I certainly am familiar with the Last Ten Percent you're talking of. But I also know that for every 10% that I have to pull teeth to get, there are many many things that work well because the platform team did a great job and drew on a depth of experience and expertise that I just don't have yet.

DHH built a lot of Ruby apps before he built Rails, and by using Rails I can draw on his experience. As a solo founder that's worth a lot to me. And even now, when I've largely moved on from Rails I still draw on things I learned from studying that framework. And the frameworks I use now are equal distillations of very deep experience.

You're perhaps a more experienced developer than I am, or just better suited to the job.

Re: Things that suck in AngularJS

#145

Post by erikpukinskis » Tue, Oct 29, 2013, 11:13 PM UTC

josteink wrote: post #119

gkoberger wrote: post #20

Earlier quoted context omitted.

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.

whereas Angular pretty much re-envisioned everything. Angular is the first time I've written a web-app and been completely lost from second one without a fully stateful JavaScript debugger willing to break at any point and letting me inspect the call-stack, parameters and locals. Everything which was simple about the web up until now, Angular transformed into horrible, black voodoo magic which either just worked or d…

> Everything which was simple transformed into horrible, black voodoo magic

That's what radical re-envisionings always look like. Anything that fits easily into your toolbelt is an incremental improvement. That's what the word "radical" means.

The promise is that after doing some hard work to learn new data structures you will be more powerful, but it's certainly your right to be skeptical of that.

Re: Things that suck in AngularJS

#146

Post by erikpukinskis » Tue, Oct 29, 2013, 11:16 PM UTC

pavlov wrote: post #121

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 feel like I spend 90% of my time banging my head against a brick wall. Why do people want to work with a technology like that? Personally I feel that the worst part of programming is when you're stuck trying to decipher the inner workings of an intermediate layer. It's so frustrating and futile, and I'm not learning anything generally useful because mastering arcane workarounds for technology layer X doesn't transl…

Why do people want to work with a technology like that?

I do because studying advanced frameworks and working within them is the main way that I learn new patterns.

Re: Things that suck in AngularJS

#147

Post by atjoslin » Wed, Oct 30, 2013, 4:23 AM UTC

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

An effort is being made right now to rewrite the concepts docs in better language - and moving out from there.

Re: Things that suck in AngularJS

#148

Post by d0m » Wed, Oct 30, 2013, 6:58 AM UTC

joevandyk wrote: post #72

d0m wrote: post #56

Earlier quoted context omitted.

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.

Sure, if you read all the doc and stumble on this page.. but for a newcomer it's damn surprising to see existing code not working. It's like adding jquery and having random links disappearing.

Re: Things that suck in AngularJS

#149

Post by kosinus » Wed, Oct 30, 2013, 1:10 PM UTC

yeukhon wrote: post #137

kosinus wrote: post #95

Earlier quoted context omitted.

So you're learning a lot more than just AngularJS, then, and attributing the problems you run into along the way to AngularJS. Maybe AngularJS is hard to grasp if you're not already familiar with the DOM, compared to other frameworks. I wouldn't know, to be honest. Your video driver example is not a good comparison, in my opinion. You're comparing developers to users. If a developer triggers a bug in a video driver t…

You understand a lot of people using Linux are developers. That comparison is not so bad. Yesterday I was playing counter strike and an error popped. I did a quick search and I could have fix the file in place but instead I just use built-in feature to fix the error. As a developer, I rather have someone to deal with that problem if I had the choice. Learning Angular.js internal is not interesting to most of us. Sorr…

You misunderstand. I don't expect a Linux user to understand video driver internals. But I do expect a developer using OpenGL to have some grasp of the situation once he runs into a problem.

I strongly urge you to learn and understand the tools you are using. It's what makes all the difference between a good developer and a great developer.

There's nothing wrong with the issue you reported. Nobody is asking you to send patches. (Though that would be nice.) But you've already added a small test case, so that's excellent.

There are always things you can do to get a better understanding. For example, take AngularJS out of the equation. Turns out, you can add options to a select element and everything's fine. Only once you set the select value, does Firefox flip the highlighted item.

Re: Things that suck in AngularJS

#150

Post by Zelphyr » Thu, Oct 31, 2013, 2:45 AM UTC

erikpukinskis wrote: post #144

Zelphyr wrote: post #80

Earlier quoted context omitted.

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

I think it depends on how good you are. If you're a great developer, with deep knowledge of patterns, a strong commitment to refactoring, with lots of experience such that you're aware of the pitfalls you are likely to befall, then you're probably right: frameworks will buy you little. I'm pretty good, but I'm apparently not good enough, because I find myself consistently learning things from frameworks. I certainly…

You touch on one of the other benefits of a framework; they're a fairly decent way to learn. But, unfortunately, much of that is because you're learning what NOT to do.

A much better way to learn is to go write your own framework. Then you're forced to encounter the pitfalls and overcome them through research, trial-and-error, and interacting with the community.

But continuing to use a framework is just a crutch in my opinion. At some point not only are you not learning anything but, as I mentioned before, all you're really doing is gluing framework code/modules together. You're actively doing yourself a disservice and letting your skills atrophy by relying on such a crutch.

One thing about frameworks that I find interesting is; how many were used to develop Unix? None. Because there weren't any back then. And now its in billions of devices worldwide.

I did this myself. It was crap. Fun to write, and I learned a lot from it. But still, monolithic, poorly documented, tightly-coupled crap and even I don't use it anymore.