Live data from Hacker News

Why we left AngularJS

sourcegraph.com

121–130 of 168 posts

Re: Why we left AngularJS

#121
post #24

We're using Backbone+React so this may not be applicable. However... “You can separate your dev and production build pipelines to improve dev speed, but that’s going to bite you later on.” In my experience, you must separate dev and prod pipelines. It has never bitten me because I make hundreds dev (local) and dozens kinda-prod (staging server) builds a day. For dev builds, Grunt just compiles LESS but doesn't touch…

Yes, we did use separate dev and prod pipelines when we used AngularJS. (We used https://github.com/ngbp/ng-boilerplate. ) It took 2-3sec for the dev build (most of which was taken up by recess) and 30-45sec for the prod build (primarily JS uglification). However, probably 5-10 times we deployed a broken site because either 1) the LESS compiler changed the order of our CSS rules or 2) we used AngularJS DI syntax some…

I understand how this could be really frustrating. We solved this problem (well, we never really had it, but we solved the ability of this problem to come up) by having a suite of unit and functional webui tests. Combined that with a CI environment that runs these tests and creates builds only when the tests pass. Ngmin can be a little flakey if you get into fringe situations but deploying broken code is a testing problem, not a toolset problem.

Re: Why we left AngularJS

#122
post #110

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

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.

Re: Why we left AngularJS

#123
post #110

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

tl,dr: Just because you really like your hammer, doesn't mean everything is a nail.

Re: Why we left AngularJS

#124
post #110

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

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.

Re: Why we left AngularJS

#125
post #61
post #32

Earlier quoted context omitted.

What would you use for a public facing application?

I recommend PJAX. It degrades gracefully for search engine indexing.

I've started using PJAX where the rendered page does not have to change when its source data does, and where you don't have large tables/calendars that would have to be re-rendered when one data value changes.

Development is significantly faster, less error-prone, easier to maintain. Development can also be given to people with lower skill levels.

Re: Why we left AngularJS

#126
post #59

Earlier quoted context omitted.

Discourse is essentially a SPA (see http://try.discourse.org/ ) and designed to be public-facing. It does a good job at providing a very bare, lightweight interface for people with JavaScript disabled and, I'm assuming, for web crawlers.

FWIW.. it looks overkill for me

...because?

Re: Why we left AngularJS

#127
post #110

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

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

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

Re: Why we left AngularJS

#128
post #110

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

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 =)

Re: Why we left AngularJS

#130
post #110

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

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 =)
Post reply on HN