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…
Why we left AngularJS
121–130 of 168 posts
Re: Why we left AngularJS
#122I 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…
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
#123I 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…
Re: Why we left AngularJS
#124I 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…
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
#125Earlier quoted context omitted.
What would you use for a public facing application?
I recommend PJAX. It degrades gracefully for search engine indexing.
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
#126Earlier 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
Re: Why we left AngularJS
#127I 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…
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
#128I 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.
Re: Why we left AngularJS
#129Our javascript tests suites are always much, much faster than our server-side test suites with similar coverage.
Re: Why we left AngularJS
#130I 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.