Live data from Hacker News

Why we left AngularJS

sourcegraph.com

21–30 of 168 posts

Re: Why we left AngularJS

#21
I have to disagree with most of this article. 1. Bad search ranking and Twitter/Facebook previews Don't force your public side to strictly angular. Serve normal pages and use angular for your interactive components. Let Google index a well formed dom. Use a full angular stack for your non public facing application(a SaaS application). You don't want to index this anyways.

2. Flaky stats and monitoring Use event driven metrics from your api and or client side. Track everything in the sense of user, controller, action, params. Blacklist sensitive data. Derive metrics with funnels, user did x actions, returned and subscribed. Conversion! It's all there just understand your events.

3. Slow, complex build tools. Your not limited to grunt, or node. For example we use rails and use our own buildscripts and generators to build fullstack angular apps. Easy Breezy.

4. Slow, flaky tests There is room for improvement. But jasmine and phantom can get the job done. But let's not forget were also testing our api. Use your goto testing framework and let jasmine phantomn do the client frontend testing.

5. Slowness is swept under the rug, not addressed Precompile your angular templates, only wait for api responses. Don't fragment your page load into seperate request. Resolve all the requires data beforehand in the route provider.

Re: Why we left AngularJS

#22
We've transitioned from Angular to ReactJS with great success. Much smaller learning curve. Using Backbone to handle the models and React for the view is a great combination.

Re: Why we left AngularJS

#23
post #12

I’m as big an Angular evangelist as anyone, but that bit about search rankings is an absolute killer. You talk about these server-side webkit parsers as tricks that “slow things down,” which indicates that you at least ultimately got them working. I never got that far.

As someone who is familiar with AngularJS but hasn't used it much, the idea that the best answer running WebKit on the server, indexing your client-side generated pages and dumping them out into a Google-indexable static resource just blows my mind .

What's really interesting is that "google" didn't see this coming - they made angular, they should in theory be huge advocates of SPA, but in reality their primary product doesn't support it well at all.

Re: Why we left AngularJS

#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 somewhere that ngmin couldn't handle. We fixed the issues and added better linting, but it's still one more thing to think about (and the theme of this article is that it was death by a thousand cuts, not one big show-stopper).

Re: Why we left AngularJS

#25
This mayaswell be titled: "Why we're paying for re-discovering client-heavy apps are hard or bad." Angular, or doesn't particularly matter.

Twitter learned it[1].

Lots of us learned it when we were experimenting as Web 2.0 was being born. Things were far more obvious, far more quickly then, as bandwidth and resources weren't anywhere near what they are today. Back then, we quickly realized that just a couple of delayed asynchronous calls could cause your app to slow to a halt and feel sluggish.

That's not to say it can't be done[2], it's just to say that, thus far for the most part, folks end up discovering reasons why they didn't "do it right" too late over and over. I could be wrong, but I feel like there's been a few posts to Hacker News within the past couple months with similar sentiment.

When people start suggesting client-side rendering, I usually ask something along these lines:

Why on earth would you leave something as simple as textual document model creation up to the client's 5 year old machine that is busy playing a movie, a song, downloading a torrent, doing a Skype call, and running 15 other tabs, when your server is sitting around twiddling it's thumbs with it's 8 cores, scalable, SSD and memory-heavy architecture?

[1] - https://blog.twitter.com/2012/improving-performance-on-twitt...

[2] - http://www.quora.com/Web-Development/What-are-the-tradeoffs-...

Re: Why we left AngularJS

#26

For sake of correctness — recent versions of Phantom.js are not dependent on Xvfb or any other variant of X, and there are grandmotherly prepared binary builds on the official website (kinda statically linked, so no dependency on WebKit as well). Not that it changes the author's arguments that much, but just worth pointing out.

[deleted]

Re: Why we left AngularJS

#27
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…

This clarifies things. I'm not familiar with Angular so thanks for sharing the perspective.

Re: Why we left AngularJS

#28
post #21

I have to disagree with most of this article. 1. Bad search ranking and Twitter/Facebook previews Don't force your public side to strictly angular. Serve normal pages and use angular for your interactive components. Let Google index a well formed dom. Use a full angular stack for your non public facing application(a SaaS application). You don't want to index this anyways. 2. Flaky stats and monitoring Use event drive…

Would also note angular isn't for everyone or every project. But when you do its priceless.

Re: Why we left AngularJS

#29
post #10

A lot of people seem to think that Single Page App frameworks like Angular/Ember are suitable for use on the public facing client side. I've always believed that SPAs are meant to be behind a login, where you don't have to also deal with spiders and other sub-optimal browsing devices, and you have a little bit more wriggle room when it comes to routing and web history. Just look at Blogger...their client-side renderi…

i agree 100%.

Most websites shouldnt be SPAs. One can still use Angular to code widgets in a regular page based site,without using a js router.

It's just that devs are getting lazy ,they throw a restfull server app quickly then dont want to deal with any view layer on the server and do everything in client-side js. For some projects it make little sense.

Re: Why we left AngularJS

#30
post #10

A lot of people seem to think that Single Page App frameworks like Angular/Ember are suitable for use on the public facing client side. I've always believed that SPAs are meant to be behind a login, where you don't have to also deal with spiders and other sub-optimal browsing devices, and you have a little bit more wriggle room when it comes to routing and web history. Just look at Blogger...their client-side renderi…

Exactly, tried to hit that in my post
Post reply on HN