7 ms·

I was wrong to be afraid of Angular.js

50 points by pistoriusp 13y ago

lmm 13y ago
So was the project any good, or was it the kind of unmaintainable nightmare you feared? I've learnt from bitter experience to trust my programming instincts even when I can't justify them logically.
- AdrianRossouw 13y ago
  it was some of the most fun ive had programming in a while. daemon.co.za/2014/03/mirror-tumblr-picture-blogs-browsr/
pistoriusp 13y ago
I think Adriaan's description of having it "feel" almost emotional rather than strictly intellectual is a good example of his intuition and experience playing a role rather than a pure academic understanding. I think this was described in Malcom Gladwell's Blink. I have a similar methodology which I coined "dumb-ass software development." The basic premise is that you're meant to build software that isn't too clever.
mattmanser 13y ago
Post is half finished, doesn't explain the interesting bit of why it's not wrong to be afraid. I also wonder if a small 2-week project is complicated enough to hit the usual idiosyncrasies of auto-magical frameworks that suddenly cause your code to contort into spaghetti. Usually it's things like "I have to get hold of the error, how do I do that? [Googling]. Oh, I can't. Bugger." or "I need to step in before it does this render to slightly tweak the data. How do I do that? [Googling]. Oh, I can't. Bugger.".
- lerouxb 13y ago
  I would like to see a follow-up post.
- AdrianRossouw 13y ago
  actually. the post is half finished. the next part is actually what I ended up thinking about angular on an intellectual level. The tone of the article veered so wildly that it felt right to stop there for now.
- coldtea 13y ago
  >Usually it's things like "I have to get hold of the error, how do I do that? [Googling]. Oh, I can't. Bugger." or "I need to step in before it does this render to slightly tweak the data. How do I do that? [Googling]. Oh, I can't. Bugger.". Well, if tons of big apps have been written in the framework, including by Google, then you shouldn't have problems, unless you're doing it wrong or your app is "unique".
  - mildtrepidation 13y ago
    That sounds an awful lot like the scaling argument for PHP... just because a lot of people use something doesn't mean it does everything better than anything else. A project doesn't have to satisfy some snarky definition of "unique" to have different requirements and optimal paradigms than other projects. Also, the idea that if it doesn't work for you means you're doing it wrong is disingenuous at best. People have different ideas about what things a framework should or shouldn't do, and how it should or shouldn't do them. That doesn't make them wrong or you right.
  - taeric 13y ago
    Agreed with the other poster on this. This is dangerously close to saying you should just use the framework that worked from years ago. I want to note that I actually agree with this mentality for a large portion of what is getting written. Many shops should spend less time building their apps than they do a framework to build all apps. Worse, many people should get a few more apps under their belts before they build another framework. It seems that the reason it is so easy to write todo lists in every framework is that is about as far as people are able to get them before they start hitting the dirty details.
    - taeric 13y ago
      I realize I have some typos up there. Apologies if that messed up any understanding.
yukichan 13y ago
Angular.js is a JavaScript framework. It has an API that does stuff. You can look at the source code to see how it does that stuff. It helps you add events to elements and listen for state changes. Why would that be scary? You're going to have to learn one of these all the time if you want to do frontend development. They live shorter than fads these things, although maybe Angular.js won and will stick around.
- AdrianRossouw 13y ago
  because I need to be able to rely on my intuition to guide me. when i looked at angular, I saw a lot of things that I could see would cause problems in the future. It was more about understanding myself than understanding angular really. I went through this process, not because I needed to use angular for anything, but because I needed to know that my gut instincts were right or wrong.
  - yukichan 13y ago
    I don't understand what intuition and gut instincts have to do with JavaScript frameworks. When I evaluate libraries I do not check my emotional state or what my my stomach is telling me. I use a rational process, a heuristic: I check to see how actively developed the library is. If it's on GitHub I check how many people have starred and forked it and when the last commit was. I look at the issues list to see if it has any horrible errors that have been around forever with giant threads. I check the documentation to see if I like what it does. I scan the source code to see if it uses giant functions and globally scoped variables or does other horrible things. I also check for readability. I Google the thing and see if anyone is using it on Twitter. Then I build something small with it and if it helps more than it hurts then maybe it's good to go. The place where this heuristic has failed me is with long term big applications. I chose Google Closure for a startup once and it turned out to make everything take much more time than it should have. It was the write more do less library, but at the time there was no backbone.js and Sproutcore, Cappuccino, dojo and ext.js have all pretty much gone away. So I don't know how I feel about it now, but I definitely wouldn't use gut instinct when I can just apply rational thought.
onion2k 13y ago
I've learnt that it's far, far better to try a library and find that it's everything you feared than to fear it and not try using it. Occasionally it's not as bad as you thought it was going to be, and very occasionally it's actually rather good. Unless you're willing to endure the repeated feeling of failure than you get from trying something and not getting anywhere with it (which is ultimately what we're afraid of when we don't try things) you'll never be able to use the tools that are the best fit for you.
- mildtrepidation 13y ago
  Definitely true, and well put. I had a similarly, surprisingly positive experience with AngularJS (right down to the brief time frame, mentioned relevantly elsewhere in this discussion) when a client wanted it used to talk to web services, at which point I grimaced and started learning it. It's hard for me to be positive about Yet Another JS Framework, but it turned out I enjoyed what it did -- enough that, though that part of the project fell through, I really want to try it out with a Flask back end on a real project.
- jrochkind1 13y ago
  If you're just playing around in your spare time, sure, why not try it? If the library ends up in an actual product you have to maintain, and you end up regretting it... I'm not sure it's better to try and find out it's everything you feared. I'm curious how many developers do such 'own time' side project hacking to learn new stuff.
  - sanderjd 13y ago
    Yeah I think side projects are important for learning new things precisely because they hedge the risk of those new things. When you know you're making something for work that is actually going to be used for awhile, it's much less risky to use something that you know for sure will work reasonably well than something you think might work really well. There is actually a lesson for businesses here: giving engineers time to tinker with new ideas and technologies reduces the future risk of decisions made for real projects. (Of course if you just employ people who spend their free time tinkering with things, you get the best of both worlds for free!)
matt_s 13y ago
I looked at Angular a while ago in comparison to Knockout. Angular strikes me as one of those frameworks that requires you to get to a certain mental state in order for you to use it. Maybe it just requires an extensive project being built to really appreciate it. For someone doing web development on a casual basis there is too much meta and magic under the hood with Angular. When you have to quickly get up to speed on something you (or someone else) wrote but haven't touched in days or weeks then I'd prefer not have to do mental gymnastics before getting stuff done. I'd prefer KISS and obvious solutions.
- Quarrelsome 13y ago
  You're missing out. All it forces you to do is push your html fiddling into directives and use dependency injection (which is awesome anyway). It does way more than knockout.
- mcv 13y ago
  It's important to realize that Angular is not simply a library, it's a framework. It starts up your app for you based of stuff you declared somewhere, and then it calls your code when your code is needed. It's actually quite comparable to frameworks like Spring, Wicket, Grails, Rails etc. The magic under the hood is not significantly different from the magic of those frameworks. It presents you with an environment to work in, rather than only doing what you tell it to. That environment can be limiting in some ways, but it also handles a lot of boring stuff for you. You need to learn how to work in that framework, but once you do, you're up to speed much faster.
pothibo 13y ago
Because framework that big takes months to understand and discover, a 2 week project is the same as a 'hello world' when it comes to gauging a framework. You're in the enlightenment phase. You start to understand some critical part of the framework and you feel giddy about it. However good angular.js is, your feeling right now is due to you wrapping your head around angular, not angular being awesome. I strongly think it's a dumb idea to jump around framework that does the same thing (1 project rails, another nodejs, another sinatra, etc.) Choose angular, or backbone, or ember and stick with it, you'll learn a lot more.
- craigching 13y ago
  > Choose angular, or backbone, or ember and stick with it, you'll learn a lot more. I agree that there is a problem of depth of learning of a framework (or any third party library that you use), but to suggest that you only learn one is not the best way to go about it either. As always in life, balance is a good thing. Sometimes learning another library/framework/whatever is a good way to learn about your current "one" library/framework/whatever.
  - pothibo 13y ago
    It was meant as a general statement. I'm not advocating to stay with the same framework for your whole career. I'm advocating for having a deep understanding of a framework of your chosing before changing so you actually understand why you are changing. I believe we think the same thing.
- nobleach 13y ago
  I agree, I've written 4 apps with it and I really only feel like I'm scratching the surface.
- AdrianRossouw 13y ago
  I _know_ backbone. almost biblically, actually. I've been building backbone apps since early 2011 and have released more than half a dozen apps into production, including a few node knockout entries I would be able to build in a weekend. I also released my own open source framework built around backbone and marionette in a bid to standardise my team's stack and force us to use proper methodologies. i think ember is basically just backbone with a bunch of assumptions (i really hate working around other people's assumptions about my code). They are closer to each other than they are different. angular otoh is something completely different. I needed to build something achievable in it to understand how and why it differs from backbone. on a deeper level.
joelhooks 13y ago
In my experience with Angular, both in the capacity of using it and teaching it, is that there is this huge amount of rote facts that need to be absorbed. THAT is the "steep learning curve" that people talk about. Directives, for instance, require understanding of what "@", "=", and "&" mean in relation to your isolated scope... The analogy that I present that it is like multiplication tables and algebra. If you don't have the FACTS by rote, it is a way harder to do useful work. A nice set of ng-flashcards would probably be very useful :>
applecore 13y ago
o·ver·blown, ˌōvərˈblōn/ 1. excessively inflated or pretentious. "overblown dreams of glory and success" 2. (of a flower) past its prime. "an overblown rose" These JavaScript frameworks are overblown.
- swalsh 13y ago
  Just curious, have you tried Angular? I had a similar thought until I started using it... than I realized, it kind of changed things in a very big way. In some ways, that was bad, but in even more ways it was a really big relief.
  - applecore 13y ago
    Yeah. Backbone.js is better.
- jf22 13y ago
  The frameworks help make creating large SPAs easier but I think most people are using these frameworks to make creating small SPAs harder.
adyus 13y ago
This post is interesting because I can't remember the last time I read a programmer's blog dealing with emotions and how it feels to program. We're not cold, calculating automatons. We get scared, frustrated, angry, but also elated, excited and encouraged. Yet these kinds of words don't find their way into blog posts very often. Kudos for stopping the post there and splitting the intellectual half for later.
nikon 13y ago
Having used AngularJS since July 2013, I can't really say a bad word about it. It's a truly brilliant framework. Tips: - UI-Router will make your life easier when your app gets larger - Don't ignore directives - Try and use TDD early with Jasmine If you want good code examples, the AngularUI projects look very well written. The UI Router code is pretty good. One word of warning: public sites = headache for SEO.
- PhilipA 13y ago
  You can try to use something like prerender.io.
AdrianRossouw 13y ago
So it seems the right time to announce Werewolves.io - https://news.ycombinator.com/item?id=7385206 https://news.ycombinator.com/item?id=7385206 It's a WebRTC based version of the famous party game Werewolves/Mafia. Supports 7-16 players.
iopq 13y ago
I was right to be afraid of Angular.js I had some kind of a header caching bug where changing the headers on log-in didn't work properly... but only once out of ten times. Really annoying thing to track down and ultimately something I never fixed because I didn't know where to start. This is why people use Angular once you logged in, not for their entire site.
tcopeland 13y ago
Along the same lines, I just posted a list of things I deferred in order to get my first Angular / Rails app out the door - http://thomasleecopeland.com/2014/03/12/doing-a-rails-angular-mvp.html http://thomasleecopeland.com/2014/03/12/doing-a-rails-angula...
platinumdragon 13y ago
Post doesn't even touch on the subject of the title, and you have a typo where you ask for new challenges.
insertnickname 13y ago
Loading content via JavaScript is a terrible idea.
shidhincr 13y ago
Well thought and said. I guess the post is incomplete; waiting for the second part
calgaryeng 13y ago
What exactly does "full-stack javascript developer" mean? You can write NodeJS on the backend and jQuery on the frontend?
- gaoshan 13y ago
  I expect it means that the developer can handle both backend and frontend related javascript (like, they are comfortable working with nodejs, expressjs, Angularjs, Emberjs, etc.)

50 points by pistoriusp 13y ago

lmm 13y ago

So was the project any good, or was it the kind of unmaintainable nightmare you feared? I've learnt from bitter experience to trust my programming instincts even when I can't justify them logically.

AdrianRossouw 13y ago
it was some of the most fun ive had programming in a while. daemon.co.za/2014/03/mirror-tumblr-picture-blogs-browsr/

pistoriusp 13y ago

I think Adriaan's description of having it "feel" almost emotional rather than strictly intellectual is a good example of his intuition and experience playing a role rather than a pure academic understanding. I think this was described in Malcom Gladwell's Blink. I have a similar methodology which I coined "dumb-ass software development." The basic premise is that you're meant to build software that isn't too clever.

mattmanser 13y ago

Post is half finished, doesn't explain the interesting bit of why it's not wrong to be afraid. I also wonder if a small 2-week project is complicated enough to hit the usual idiosyncrasies of auto-magical frameworks that suddenly cause your code to contort into spaghetti. Usually it's things like "I have to get hold of the error, how do I do that? [Googling]. Oh, I can't. Bugger." or "I need to step in before it does this render to slightly tweak the data. How do I do that? [Googling]. Oh, I can't. Bugger.".

lerouxb 13y ago
I would like to see a follow-up post.
AdrianRossouw 13y ago
actually. the post is half finished. the next part is actually what I ended up thinking about angular on an intellectual level. The tone of the article veered so wildly that it felt right to stop there for now.
coldtea 13y ago
>Usually it's things like "I have to get hold of the error, how do I do that? [Googling]. Oh, I can't. Bugger." or "I need to step in before it does this render to slightly tweak the data. How do I do that? [Googling]. Oh, I can't. Bugger.". Well, if tons of big apps have been written in the framework, including by Google, then you shouldn't have problems, unless you're doing it wrong or your app is "unique".
- mildtrepidation 13y ago
  That sounds an awful lot like the scaling argument for PHP... just because a lot of people use something doesn't mean it does everything better than anything else. A project doesn't have to satisfy some snarky definition of "unique" to have different requirements and optimal paradigms than other projects. Also, the idea that if it doesn't work for you means you're doing it wrong is disingenuous at best. People have different ideas about what things a framework should or shouldn't do, and how it should or shouldn't do them. That doesn't make them wrong or you right.
- taeric 13y ago
  Agreed with the other poster on this. This is dangerously close to saying you should just use the framework that worked from years ago. I want to note that I actually agree with this mentality for a large portion of what is getting written. Many shops should spend less time building their apps than they do a framework to build all apps. Worse, many people should get a few more apps under their belts before they build another framework. It seems that the reason it is so easy to write todo lists in every framework is that is about as far as people are able to get them before they start hitting the dirty details.
  - taeric 13y ago
    I realize I have some typos up there. Apologies if that messed up any understanding.

yukichan 13y ago

Angular.js is a JavaScript framework. It has an API that does stuff. You can look at the source code to see how it does that stuff. It helps you add events to elements and listen for state changes. Why would that be scary? You're going to have to learn one of these all the time if you want to do frontend development. They live shorter than fads these things, although maybe Angular.js won and will stick around.

AdrianRossouw 13y ago
because I need to be able to rely on my intuition to guide me. when i looked at angular, I saw a lot of things that I could see would cause problems in the future. It was more about understanding myself than understanding angular really. I went through this process, not because I needed to use angular for anything, but because I needed to know that my gut instincts were right or wrong.
- yukichan 13y ago
  I don't understand what intuition and gut instincts have to do with JavaScript frameworks. When I evaluate libraries I do not check my emotional state or what my my stomach is telling me. I use a rational process, a heuristic: I check to see how actively developed the library is. If it's on GitHub I check how many people have starred and forked it and when the last commit was. I look at the issues list to see if it has any horrible errors that have been around forever with giant threads. I check the documentation to see if I like what it does. I scan the source code to see if it uses giant functions and globally scoped variables or does other horrible things. I also check for readability. I Google the thing and see if anyone is using it on Twitter. Then I build something small with it and if it helps more than it hurts then maybe it's good to go. The place where this heuristic has failed me is with long term big applications. I chose Google Closure for a startup once and it turned out to make everything take much more time than it should have. It was the write more do less library, but at the time there was no backbone.js and Sproutcore, Cappuccino, dojo and ext.js have all pretty much gone away. So I don't know how I feel about it now, but I definitely wouldn't use gut instinct when I can just apply rational thought.

onion2k 13y ago

I've learnt that it's far, far better to try a library and find that it's everything you feared than to fear it and not try using it. Occasionally it's not as bad as you thought it was going to be, and very occasionally it's actually rather good. Unless you're willing to endure the repeated feeling of failure than you get from trying something and not getting anywhere with it (which is ultimately what we're afraid of when we don't try things) you'll never be able to use the tools that are the best fit for you.

mildtrepidation 13y ago
Definitely true, and well put. I had a similarly, surprisingly positive experience with AngularJS (right down to the brief time frame, mentioned relevantly elsewhere in this discussion) when a client wanted it used to talk to web services, at which point I grimaced and started learning it. It's hard for me to be positive about Yet Another JS Framework, but it turned out I enjoyed what it did -- enough that, though that part of the project fell through, I really want to try it out with a Flask back end on a real project.
jrochkind1 13y ago
If you're just playing around in your spare time, sure, why not try it? If the library ends up in an actual product you have to maintain, and you end up regretting it... I'm not sure it's better to try and find out it's everything you feared. I'm curious how many developers do such 'own time' side project hacking to learn new stuff.
- sanderjd 13y ago
  Yeah I think side projects are important for learning new things precisely because they hedge the risk of those new things. When you know you're making something for work that is actually going to be used for awhile, it's much less risky to use something that you know for sure will work reasonably well than something you think might work really well. There is actually a lesson for businesses here: giving engineers time to tinker with new ideas and technologies reduces the future risk of decisions made for real projects. (Of course if you just employ people who spend their free time tinkering with things, you get the best of both worlds for free!)

matt_s 13y ago

I looked at Angular a while ago in comparison to Knockout. Angular strikes me as one of those frameworks that requires you to get to a certain mental state in order for you to use it. Maybe it just requires an extensive project being built to really appreciate it. For someone doing web development on a casual basis there is too much meta and magic under the hood with Angular. When you have to quickly get up to speed on something you (or someone else) wrote but haven't touched in days or weeks then I'd prefer not have to do mental gymnastics before getting stuff done. I'd prefer KISS and obvious solutions.

Quarrelsome 13y ago
You're missing out. All it forces you to do is push your html fiddling into directives and use dependency injection (which is awesome anyway). It does way more than knockout.
mcv 13y ago
It's important to realize that Angular is not simply a library, it's a framework. It starts up your app for you based of stuff you declared somewhere, and then it calls your code when your code is needed. It's actually quite comparable to frameworks like Spring, Wicket, Grails, Rails etc. The magic under the hood is not significantly different from the magic of those frameworks. It presents you with an environment to work in, rather than only doing what you tell it to. That environment can be limiting in some ways, but it also handles a lot of boring stuff for you. You need to learn how to work in that framework, but once you do, you're up to speed much faster.

pothibo 13y ago

Because framework that big takes months to understand and discover, a 2 week project is the same as a 'hello world' when it comes to gauging a framework. You're in the enlightenment phase. You start to understand some critical part of the framework and you feel giddy about it. However good angular.js is, your feeling right now is due to you wrapping your head around angular, not angular being awesome. I strongly think it's a dumb idea to jump around framework that does the same thing (1 project rails, another nodejs, another sinatra, etc.) Choose angular, or backbone, or ember and stick with it, you'll learn a lot more.

craigching 13y ago
> Choose angular, or backbone, or ember and stick with it, you'll learn a lot more. I agree that there is a problem of depth of learning of a framework (or any third party library that you use), but to suggest that you only learn one is not the best way to go about it either. As always in life, balance is a good thing. Sometimes learning another library/framework/whatever is a good way to learn about your current "one" library/framework/whatever.
- pothibo 13y ago
  It was meant as a general statement. I'm not advocating to stay with the same framework for your whole career. I'm advocating for having a deep understanding of a framework of your chosing before changing so you actually understand why you are changing. I believe we think the same thing.
nobleach 13y ago
I agree, I've written 4 apps with it and I really only feel like I'm scratching the surface.
AdrianRossouw 13y ago
I _know_ backbone. almost biblically, actually. I've been building backbone apps since early 2011 and have released more than half a dozen apps into production, including a few node knockout entries I would be able to build in a weekend. I also released my own open source framework built around backbone and marionette in a bid to standardise my team's stack and force us to use proper methodologies. i think ember is basically just backbone with a bunch of assumptions (i really hate working around other people's assumptions about my code). They are closer to each other than they are different. angular otoh is something completely different. I needed to build something achievable in it to understand how and why it differs from backbone. on a deeper level.

joelhooks 13y ago

In my experience with Angular, both in the capacity of using it and teaching it, is that there is this huge amount of rote facts that need to be absorbed. THAT is the "steep learning curve" that people talk about. Directives, for instance, require understanding of what "@", "=", and "&" mean in relation to your isolated scope... The analogy that I present that it is like multiplication tables and algebra. If you don't have the FACTS by rote, it is a way harder to do useful work. A nice set of ng-flashcards would probably be very useful :>

applecore 13y ago

o·ver·blown, ˌōvərˈblōn/ 1. excessively inflated or pretentious. "overblown dreams of glory and success" 2. (of a flower) past its prime. "an overblown rose" These JavaScript frameworks are overblown.

swalsh 13y ago
Just curious, have you tried Angular? I had a similar thought until I started using it... than I realized, it kind of changed things in a very big way. In some ways, that was bad, but in even more ways it was a really big relief.
- applecore 13y ago
  Yeah. Backbone.js is better.
jf22 13y ago
The frameworks help make creating large SPAs easier but I think most people are using these frameworks to make creating small SPAs harder.

adyus 13y ago

This post is interesting because I can't remember the last time I read a programmer's blog dealing with emotions and how it feels to program. We're not cold, calculating automatons. We get scared, frustrated, angry, but also elated, excited and encouraged. Yet these kinds of words don't find their way into blog posts very often. Kudos for stopping the post there and splitting the intellectual half for later.

nikon 13y ago

Having used AngularJS since July 2013, I can't really say a bad word about it. It's a truly brilliant framework. Tips: - UI-Router will make your life easier when your app gets larger - Don't ignore directives - Try and use TDD early with Jasmine If you want good code examples, the AngularUI projects look very well written. The UI Router code is pretty good. One word of warning: public sites = headache for SEO.

PhilipA 13y ago
You can try to use something like prerender.io.

AdrianRossouw 13y ago

So it seems the right time to announce Werewolves.io - https://news.ycombinator.com/item?id=7385206 https://news.ycombinator.com/item?id=7385206 It's a WebRTC based version of the famous party game Werewolves/Mafia. Supports 7-16 players.

iopq 13y ago

I was right to be afraid of Angular.js I had some kind of a header caching bug where changing the headers on log-in didn't work properly... but only once out of ten times. Really annoying thing to track down and ultimately something I never fixed because I didn't know where to start. This is why people use Angular once you logged in, not for their entire site.

tcopeland 13y ago

Along the same lines, I just posted a list of things I deferred in order to get my first Angular / Rails app out the door - http://thomasleecopeland.com/2014/03/12/doing-a-rails-angular-mvp.html http://thomasleecopeland.com/2014/03/12/doing-a-rails-angula...

platinumdragon 13y ago

Post doesn't even touch on the subject of the title, and you have a typo where you ask for new challenges.

insertnickname 13y ago

Loading content via JavaScript is a terrible idea.

shidhincr 13y ago

Well thought and said. I guess the post is incomplete; waiting for the second part

calgaryeng 13y ago

What exactly does "full-stack javascript developer" mean? You can write NodeJS on the backend and jQuery on the frontend?

gaoshan 13y ago
I expect it means that the developer can handle both backend and frontend related javascript (like, they are comfortable working with nodejs, expressjs, Angularjs, Emberjs, etc.)