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.
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.
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.".
>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".
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.
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.
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.
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.
I'm not the downvoter. The process you described is part of the due diligence you go through - checking for activity, longevity etc. You described a good starting point for evaluating a framework (I don't think you should have been down voted for that).
Unfortunately, that's not the end of it. As with your Closure example, it's not easy to see the issues until you're up in your neck in them. At that point you have a revelation about how truly borked you are, struggling to make progress when you've gone too far to go back.
That's why it makes sense to experiment a bit to see how it feels. That's not something easily quantifiable.
If it were quantifiable then there would be no need for these discussions at all. There would only be one framework in any space worth looking at because it would have the best number against it.
Unfortunately, in the case of application frameworks, building something small is never going to be enough.
If as a manager or lead engineer someone told me they couldn't put their finger on it but a using a library just didn't "feel right" I'm not sure how I'd respond to it, but it probably would involve asking for more specific information.
Angular.js is a JavaScript framework. It has an API that does stuff.
We fear not being able to understand it, and the consequential feeling of inadequacy that goes along with that. We all avoid putting ourselves in situations that are likely to make us feel we aren't as good at things as we thought we were.
Angular has managed to do things in a remarkably different way to most of the other JS frameworks out there. Opinionated app structure, enforced strict separation of concerns, views are live DOM, strictly no DOM manipulation in controllers, promises used liberally, testability right up front, etc. ... I agree its just a framework and your heuristics for framework evaluation are still valid, but it's at least understandable that your average jQuery/Backbone dev could feel some trepidation before diving in ... it may represent an enforced "level-up" in terms of their entire approach to building web apps.
I agree with you except the "level up" word choice. That implies that it is necessarily better, whereas I still think that's up for debate.
I think we've all been burnt by "magic" code before. A good "smell" for that sort of thing is when newbies start asking questions on stack exchange like "How do I do this in Angular?" when they should be asking "How do I do this in JavaScript?" (or rather "How do I do this at all?").
Regarding how long it will stick around: Angular has a de facto advantage over similar frameworks that might be maintained on the developers' free time given Angular is maintained by Google.
And then I have an input type=email and auto complete fills in the email for the user, but Angular doesn't detect that the browser did this, and invalidates my input even though I never told it to explicitly check for it being a proper email input...
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.
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.
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.
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!)
Although the learning curve was steep and painful but AngularJS saved me from the terrible spaghetti soup of javascript + jQuery. The UI I work on is a bit complex and AngularJS makes it a piece of cake to keep it all-together. Code reuse and stability is awesome. But on the downside I still get caught off guard by "$apply already in progress" and despite all the PhantomJS trickery I am yet to recover from the SEO mess that migrating to AngularJS created for me. Overall the benefits far outweigh the cons though. It was only due to AngularJS that I could add multi-currency support on my site in less than half a day.
I’ve always been under the impression that the use case for AngularJS is applications, and by definition it is not intended for anything where SEO is a concern (e.g. 99.9% of AngualrJS apps should be post-login). Is this not the case? What are you doing with Angular that SEO is enough of a concern to try to work around it, but not enough of a concern not to use Angular?
Full disclosure, I’ve never used Angular but it’s next on my list of things to learn.
I agree with your point regarding applications being dynamic and SEO only for the content heavy stuff. My site is a mix of both where the content is sprinkled with pieces of data that is dynamic.
Confirmation bias? (Due to the experience you had every time you finally did bite the bullet). I ask because by that argument every single person should try every single technology.
For example, by your argument you should try AccDC, Ample SDK, AngularJS, CupQ, DHTMLX, Dojo, Echo3, Enyo, Ext JS, Google Web Toolkit, jQuery, midori, MochiKit, MooTools, PhoneJS, Prototype & script. aculo.us, Pyjamas, qooxdoo, Rialto Toolkit, Rico, SmartClient and SmartGWT, Wakanda, YUI, ZK, Webix, and Web Atoms JS. Why don't you start tomorrow?
While you're at it, don't forget
AccDC, Dojo Toolkit, Glow, jQuery, midori, MooTools, Prototype JavaScript Framework, YUI Library, GUI-related (Widget libraries), Ample SDK, DHTMLX, Dojo Widgets, Ext JS
iX Framework, jQuery UI, Lively Kernel, qooxdoo, Script.aculo.us, SmartClient, Graphical/Visualization (Canvas or SVG related), , D3.js, JavaScript InfoVis Toolkit, Kinetic.js, Processing.js, Raphaël, SWFObject, Three.js, EaselJS, part of CreateJS, Web-application related (MVC, MVVM, or otherwise), , AngularJS, Backbone.js, Cappuccino, Chaplin.js, Echo, Ember.js, Enyo, Google Web Toolkit, JavaScriptMVC, Knockout, Rialto Toolkit, SproutCore, Web Atoms JS, Wakanda Framework, Pure Javascript/AJAX, , FuncJS, Google Closure Library, Joose, jsPHP, Microsoft's Ajax library, MochiKit, PDF.js, Rico, Socket.IO, Spry framework, Underscore.js, Wakanda Framework, Template Systems, , Cascade Framework, Handlebars, jQuery Mobile, Mustache, Twitter Bootstrap, ZURB Foundation, Unit Testing, , Jasmine, Unit.js, Other, and Modernizr.
So, you recommended "try nothing and re-invent everything"?
Incidentally, I don't think the author meant try everything, but rather don't be afraid to try it out, in the right context. You seem to suggest something orthogonal, but not the opposite of what he said. Obviously, in time-to-market situations or other, that is not the time to experiment.
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.
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.
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.
> 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.
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.
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 :>
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"
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.
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.
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.
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.)
57 comments
[ 4.7 ms ] story [ 119 ms ] threaddaemon.co.za/2014/03/mirror-tumblr-picture-blogs-browsr/
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.
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.".
The tone of the article veered so wildly that it felt right to stop there for now.
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".
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.
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.
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.
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.
http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisit...
Unfortunately, that's not the end of it. As with your Closure example, it's not easy to see the issues until you're up in your neck in them. At that point you have a revelation about how truly borked you are, struggling to make progress when you've gone too far to go back.
That's why it makes sense to experiment a bit to see how it feels. That's not something easily quantifiable.
If it were quantifiable then there would be no need for these discussions at all. There would only be one framework in any space worth looking at because it would have the best number against it.
Unfortunately, in the case of application frameworks, building something small is never going to be enough.
We fear not being able to understand it, and the consequential feeling of inadequacy that goes along with that. We all avoid putting ourselves in situations that are likely to make us feel we aren't as good at things as we thought we were.
I think we've all been burnt by "magic" code before. A good "smell" for that sort of thing is when newbies start asking questions on stack exchange like "How do I do this in Angular?" when they should be asking "How do I do this in JavaScript?" (or rather "How do I do this at all?").
http://stackoverflow.com/questions/15250644/angularjs-loadin...
Lets do something even more basic, like use HTML5 push state:
http://stackoverflow.com/questions/11095179/using-html5-push...
Oh, that's "easy", how could I have missed that in the API docs?
http://docs.angularjs.org/api/ng/provider/$locationProvider
Oh.
it gets complicated
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.
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.
Although the learning curve was steep and painful but AngularJS saved me from the terrible spaghetti soup of javascript + jQuery. The UI I work on is a bit complex and AngularJS makes it a piece of cake to keep it all-together. Code reuse and stability is awesome. But on the downside I still get caught off guard by "$apply already in progress" and despite all the PhantomJS trickery I am yet to recover from the SEO mess that migrating to AngularJS created for me. Overall the benefits far outweigh the cons though. It was only due to AngularJS that I could add multi-currency support on my site in less than half a day.
Full disclosure, I’ve never used Angular but it’s next on my list of things to learn.
For example, by your argument you should try AccDC, Ample SDK, AngularJS, CupQ, DHTMLX, Dojo, Echo3, Enyo, Ext JS, Google Web Toolkit, jQuery, midori, MochiKit, MooTools, PhoneJS, Prototype & script. aculo.us, Pyjamas, qooxdoo, Rialto Toolkit, Rico, SmartClient and SmartGWT, Wakanda, YUI, ZK, Webix, and Web Atoms JS. Why don't you start tomorrow?
While you're at it, don't forget
AccDC, Dojo Toolkit, Glow, jQuery, midori, MooTools, Prototype JavaScript Framework, YUI Library, GUI-related (Widget libraries), Ample SDK, DHTMLX, Dojo Widgets, Ext JS iX Framework, jQuery UI, Lively Kernel, qooxdoo, Script.aculo.us, SmartClient, Graphical/Visualization (Canvas or SVG related), , D3.js, JavaScript InfoVis Toolkit, Kinetic.js, Processing.js, Raphaël, SWFObject, Three.js, EaselJS, part of CreateJS, Web-application related (MVC, MVVM, or otherwise), , AngularJS, Backbone.js, Cappuccino, Chaplin.js, Echo, Ember.js, Enyo, Google Web Toolkit, JavaScriptMVC, Knockout, Rialto Toolkit, SproutCore, Web Atoms JS, Wakanda Framework, Pure Javascript/AJAX, , FuncJS, Google Closure Library, Joose, jsPHP, Microsoft's Ajax library, MochiKit, PDF.js, Rico, Socket.IO, Spry framework, Underscore.js, Wakanda Framework, Template Systems, , Cascade Framework, Handlebars, jQuery Mobile, Mustache, Twitter Bootstrap, ZURB Foundation, Unit Testing, , Jasmine, Unit.js, Other, and Modernizr.
Well, see you in 2015!
Incidentally, I don't think the author meant try everything, but rather don't be afraid to try it out, in the right context. You seem to suggest something orthogonal, but not the opposite of what he said. Obviously, in time-to-market situations or other, that is not the time to experiment.
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.
It does way more than knockout.
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.
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.
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.
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.
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.
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 :>
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.
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.
It's a WebRTC based version of the famous party game Werewolves/Mafia. Supports 7-16 players.
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.