Hacker News Reader

Comment by thekingshorses | Hacker News Reader

> it would be interesting to learn what lead to over 400,000 lines of CSS in over 2000 files for an actually not that complex site in the first place

This is so common. Lot of time, they use CSS to change the design of the module, which is how it should be. But when they revert the look of the module, instead of deleting CSS, they add new rules to overwrite existing CSS. Which leads to specificity fight and !important.

At my previous job, site was rendering on server. It was old, and we wanted to redesign it. I wanted to keep rendering on the server. CTO and VP wanted to build Angular site because everyone is moving to Angular and its easy to find Angular developers. Company's 30+% of new visitors comes through SEO.

View on HN

> At my previous job, site was rendering on server. It was old, and we wanted to redesign it. I wanted to keep rendering on the server. CTO and VP wanted to build Angular site because everyone is moving to Angular and its easy to find Angular developers. Company's 30+% of new visitors comes through SEO.

I think I missed the point of your second paragraph, I'd be interested to know what you meant to say. (currently working with Angular on a small hybrid app and thought about experimenting with it on the web but SEO concerns were the first thing that came to mind, so it feels like a relevant piece to me!)

I think he's pointing out the extreme ridiculousness of doing things just because they're what everyone is up to- if you're doing ng-includes and using ngRoute client-side for the public bits of your app, you're going to want to consider either a phantomjs-based snapshot service or refactoring to render the HTML on the server (you can still work Angular in w/ this latter approach, it's just trickier). Most of the Sails apps I've done have been server-rendered pages for the public sections with >=1 SPAs for the logged-in experience. In my experience, this is the most practical approach and lets you get some of the best of both worlds.

The implication is that without server-side rendering, SEO would drop. This isn't actually true for Google (edit: sometimes!), since it executes JavaScript, in part to prevent SEO gaming of its platform. But it would likely harm other web crawlers unless care was taken to incrementally add Angular to the existing HTML pre-rendered, or to execute the Angular.js server-side for bots and a nice page load speedup.

@lstamour Careful! We tested this theory last Fall with sailsjs.org and it turned out to be patently false-- we went from the second result when you google "Node.js framework" to not even being present. When I turned our headless browser snapshot stuff on again about a month later (we use brombone), it worked itself out. Needless to say, sucks :/ But everyone should be aware of the reality.

Sorry, that's true. I should have been a bit less forceful on that one. I know personally that there's a lot which goes into Google's rankings -- for instance: mobile optimization, SSL, and (where JS can slow things down the most) page speed. Google wants the web to be fast, and if two websites have identical rankings, it will rank the faster one higher. Waiting on JavaScript delays the "time to visible content" by a significant amount.

I know google is experimenting but I have never seen any JS rendered page in the google search result.

My mobile hacker news client http://hn.premii.com/ ranks top on Google but not because of the content. Content is not indexed by Google.

From my experience, the state of javascript for what's ostensibly the best web crawler in the world is still "it might work".

If your site is going to rely on search engines like google, and bing, you should think twice before committing to angular or client only app.

- JS only site won't rank higher on search engines.

- Facebook share/Open graph won't work

Or any site that relies on getting HTML from you to index wont work.

>At my previous job, site was rendering on server. It was old, >and we wanted to redesign it. I wanted to keep rendering on >the server. CTO and VP wanted to build Angular site because >everyone is moving to Angular and its easy to find Angular >developers. Company's 30+% of new visitors comes through SEO.

IMV most people don't understand the tradeoff's they're making when they adopt Angular - I'm seeing plenty of sites that have huge start up times due to them using Angular when they could equally achieve a better experience without it.

And what's even better is that Angular is throwing everything out an starting over with 2.0.

Well, they don't know that!

All our servers (API/DB) are slow, and they think that Angular will free up resource (Because not rendering on servers), and using "free" client resource to render, it will be fast.

Reply on news.ycombinator.com