Hacker News new | ask | show | jobs
by neya 4499 days ago
I had the opportunity to work for a million dollar budget client project, about a year ago. (Obviously I'm bound by an NDA, so I won't go into specifics). You can think of this site like an oDesk/Freelancer competitor, but with some social features.

We also had another team from California working on this project, who consistently insisted that we go with Angular for a project of such complexity. Back then, on HN, everybody was writing about how awesome Angular is, and how you must use it for your next project and so on. It reminded me of the early MongoDB days here.

I was under constant pressure from my client too, since he was also reading a lot about Angular everywhere and the Californian company had him almost brainwashed in favor of angular. After already falling trap for the MongoDB buzz (I used MongoDB for the wrong use-case and suffered the consequences), I decided to carefully evaluate the decision to go with Angular for the project.

After about 6 months of using Angular for a different medium-scale project, I decided against it for my client. I realized that Angular is the all powerful Battle Tank. It can do everything you want it to. But it's very tempting to choose a battle tank when all you need is a sedan to get you from home to office.

Angular has it's own use-cases, but for the most part what I observed was that you could get a lot of mileage without using Angular, with just plain Jquery+Knockout (or any other similar framework of your choice) for most of the front-end.

In a simple calculation that I made (to pitch to my client), I estimated about easily 25% of time (and thus money) savings by not going with Angular for our project. (YMMV)

Usually I tend not to open my mouth about/against angular here because most HNers seem to like Angular a lot and they downvote without a reason just for having a different opinion. But, I am really glad someone wrote a blog post about this.

8 comments

Don't be afraid of a downvote from me. Personal opinion, with content, like yours is the main reason why I read Hacker News.
Thank you for your kind words =)
Although angular is aimed at Wide/SinglePage Apps I find it perfectly suited for small scale stuff. It's like a sedan if you wish but with all the safety airbags and comfort of an mvc and the possibility to mount a canon if you move out in the jungle. It gives you a level of confidence I'd find difficult to abandon.

Also I don't see how jquery + knockout is so different from taking the angular/ember road ? (edit: I see why from a legacy point of vue)

Finally the comparison with mongodb is misleading : angular & cie brings your code from procedural mess to a well known structured area, whereas moving away from sql didn't improve any of your architecture it just proposed another one

One of the things that appeals to me about angular is that you can compose your application of smaller angular apps. I think what you're talking about (and the original article) mostly are about single page javascript apps rather than angular specifically. One perk of angular is that you can use it almost exactly like knockout, as a way to get nice two way data binding, without having to go full on SPA. Unlike knockout, it also gives you a nicer enforced structure for your mini apps.

That said, I still go knockout for this sort of thing most of the time because their support for legacy browsers wins out, and in the industries I do work for old versions of IE are sadly common.

tl,dr: Just because you really like your hammer, doesn't mean everything is a nail.
The counter-point is always valuable!

I find Angular really helps when you have a fairly complex single-page app that has non-trivial interactions. The complexity tradeoff you make using it is not worth it when you don't have those needs, especially when you have a team of people that need to be up to speed working on it.

Knockout's simplicity is hard to beat.

Thank you for sharing your opinion. Where technology is concerned, I find the simplest route is usually the best.

Sometimes certain libraries 'make sense' to me. Sometimes other people on a project choose a library because it makes sense to them.

I like that you tried to make it clear to your client by putting it in the time/money perspective.

Thank you for your kind words, it's the right thing to do, after all =)
I've had a primarily positive experience criticising it and the whole javascript-mandatory mentality in general. Perhaps comparing it to early-2000s Flash sites helps.
Wait, Wait, WAIT. No to angular, but you then casually throw in that instead you went "plain Jquery+Knockout", as if Knockout is commonplace? How is that plain?

Knockout is not commonplace.

They're just alternatives. One is Microsoft's, one Google's. They're both client-side frameworks.

Your post makes no sense at all. All it sounds like is that you're familiar with knockout but not angular and managed to convince the client to use something that everyone else wasn't familiar with, only you.

In fact this post is all about not using client side frameworks like angular. The arguments against it are the same as the one's you'd use against knockout.js. So your post makes even less sense.

>How is that plain? Knockout is not commonplace.

Knockout is a common data binding library in the JS world. It does one thing and only one thing very well - databinding. Sure it might have (little) features here and there that allow you to do other things, but it's core feature is data binding.

>They're just alternatives. One is Microsoft's, one Google's. They're both client-side frameworks.

No, they're not. Knockout a is a data binding library. One of several Angular's offerings is data binding.

>..and managed to convince the client to use something that everyone else wasn't familiar with, only you.

That's an assumption. I never said that nobody knew it except me. Sorry if it wasn't clear from my original post, but everyone in my company knows all the major frameworks - Angular, Knockout, Ember, etc. etc. We never get religious over this stuff and always use what's best for the project in hand.

>The arguments against it are the same as the one's you'd use against knockoutjs.

You completely missed my point - Angular is X+Y+Z, my suggestion is to use a framework for X, if you need mostly just X for your project. Replace X with any framework you want, including Knockout. It does not make sense to use a framework that offers X+Y+Z when you need just X or Y. That's my point. I'm sorry you feel offended.

Just to be clear - I'm not advocating any framework by name, including knockout in particular, I just mentioned it because I was documenting my use-case in my original post. Use what suits the best for your project and not because you read about it on HN/Slashdot/etc.

Please calm down your tone and don't get religious about this stuff.

Cheers.

Yeah, Angular and Ember both have their own 'runtimes' essentially which is in stark contrast to knockout, which really is just a library, and there really is a fundamental difference.