Hacker News Reader

Comment by andrzejkrzywda | Hacker News Reader

It's both simple and revolutionary.

It starts with saying "well, let's just render html on the client-side instead of on the backend". Suddenly you're in a new world of programming.

View on HN

Shipping JS to a browser and then rendering the page with javascript DOM manipulation was the Hot New Thing in about about 1998, as I recall.

It didn't last because, unsurprisingly, plain HTML loads renders a lot faster.

That said: XHR is a genuine change in the model. So too the leaps and bounds in bandwidth and computing power.

"So too the leaps and bounds in bandwidth and computing power."

And JavaScript engines performances too.

What is your point? You write in italics that "plain HTML renders a lot faster" and then you contradict yourself.

Plain HTML still renders faster.

First page load, definitely. Subsequent updates - depends.

Sure.

Part of the confusion is that HTML is living a strange life as part document, part app platform. I mean if you compare HTML and JS to the fit-and-finish of a mid 90s platform it's a mess.

But, it's what we have.

One problem I see is that a lot of that page generation being moved to the client increases the first time page loads (which matter) and on a mobile device can prove very taxing on 3 - 4 year old hardware.

I think it is more about do you want to figure out the html in JS or something else, and do you want to pay the bill to make the pages at home or lose some customers who don't have the power to do it themselves.

It's not all or nothing.

You can do what Twitter did. Allow some duplication and render html server-side on the first request.

Airbnb mentions that in a recent post: http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-t.... I think, ultimately, it depends on how your app is structured and how heavy is your feature set. We usually try and keep things as simple as possible, but we've experienced the issue a couple more complex apps and spent a good deal of time optimizing things and dynamically loading dependencies.

They ain't no silver bullet: you have to decide where you want to invest your time.

How about Google SEO? If content is pulled via AJAX and rendered in the client; what does Google see?

Google uses a crawler (allegedly) build on Chrome's internals, and renders a lot of Javascript/AJAX content just fine.

I'm not sure they'll index content based on this though (yet). It's probably used to check other algorithm drivers like page performance and spam tricks.

They do index at least some AJAX content - https://twitter.com/mattcutts/status/131425949597179904.

They have been doing for a while, at least for non-user-initiated ajaxy data :

http://www.tomshardware.com/news/google-googlebot-ajax-javas...

One approach is to use PhantomJS as your app server (much like you would use Django, Rails or something else) to render HTML for the crawlers.

See http://github.com/steeve/angular-seo

that's just crazy enough that it might work. have you run this in production ?

it renders each fragment to a file and serves that to the bots, right ?

it does, I'm doing a version for html5modes angular apps (slightly more complicated!)

careful to only serve these pages to bots tho

SEO is really the last bastion, the one major benefit, of "the old way". Decent server-side JavaScript means there are becoming ways to deal with it. See the post from yesterday on AirBNB's dual-side JS approach. http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-t...

The best way seems to be returning different results to the Google bots. It's recommended by Google.

It's not as much pain as you would think, it's enough to just return some html. No css/js is needed.

Still, that's some additional work.

No. Returning different content to Googlebot is a technique called cloaking. http://en.wikipedia.org/wiki/Cloaking

Probably worth reading this: http://productforums.google.com/forum/#!category-topic/webma...

They'll accept geo-targeted or mobile vs desktop optimised content, but everything else is a grey area.

The official documentation is here:

https://developers.google.com/webmasters/ajax-crawling

That talks about using progressive enhancement as the primary approach to building websites.

Google is actually starting to crawl that too. But more importantly, in many case it's not that much of a concern (private apps and/or content for example). And if you need so, you can follow Google's guidelines on the subject: https://developers.google.com/webmasters/ajax-crawling/

It fails in practice though. Gawker tried this, and reverted it a few months later when it became clear that their traffic from search engines took a nose-dive.

Interesting. You're sure it's not because most of the advertising business right now is organized around the "more pageviews == more prints == more $$" logic? It sure doesn't help to sell to advertisers. But we're mostly building products that need to sell to users, we care a lot more about UX and relevancy.

Very sure. http://news.ycombinator.com/item?id=2596263 -- that's what I wrote two years ago:

Once of the reasons Gawker moved away from hashbangs is that they weren't well supported by Google, despite this being a "Google specification". Nick Denton, the founder of Gawker, has some interesting tweets about the use of hashbangs over the past few months:

Nick Denton: "Dip in uniques largely because of drop in Google refers. Pageviews (which are driven more by core audience) less affected." -- http://twitter.com/nicknotned/status/61152134929981440

Nick Denton: "Google does not fully support "hashbang" URLs. So we're eliminating them rather than waiting for Mountain View." -- http://twitter.com/nicknotned/status/61465859079671808

Nick Denton: "Yeah, I'd advise against hashbang urls. Will kill search traffic -- even if you abide by Google protocol." -- http://twitter.com/nicknotned/status/62595141927583745

So here's a high-profile failure of hashbangs when it comes to being indexed by Google. Which means if it's search indexability you want, hashbangs isn't it. The Google spec just isn't mature enough, or well supported by Google search itself.

It's document-generation versus API writing, as I see it.

Reply on news.ycombinator.com