Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Googlebot's recent improvements might revolutionize web development

blog.workhere.io

Post reply on HN
Print view View original

31–40 of 97 posts

Re: Googlebot's recent improvements might revolutionize web development

#31

Post by rcsorensen »

marknutter wrote: post #26
rcsorensen wrote: post #23

Sending the framework of a page to your users and expecting them to do all the heavy lifting and slow loading of constructing the page and fetching the data is still rather unfriendly if you can afford a server to construct it. If you love your users, give them HTML and let the Javascript enhance it. Projects like Facebook's React ( http://facebook.github.io/react/docs/top-level-api.html#reac... ) and Rendr ( https:/…

The lifting ain't that heavy. And besides, wouldn't you want your server spending its precious cycles on things the clients absolutely cannot handle?

Like `ssorallen says, slow CPUs and limited battery life is an issue. In addition, latency on mobile networks is rough and should be avoided for your users whenever possible.

You have two choices when taking an SPA approach:

1) Give your users a webpage that is usable, readable, and navigable as soon as they get it.

2) Give your users the skeleton of a webpage that they then have to accept the latency of javascript parsing and execution, and then the latency of data fetches.

we have the ability to do #1.

Re: Googlebot's recent improvements might revolutionize web development

#32

Post by workhere-io »

andrenotgiant wrote: post #8

Taking a step back: The "Page" paradigm is still very much alive, despite these recent javascript parsing advances. 1. Google still needs a URL-addressable "PAGE" to which it can send Users. 2. This "PAGE" needs to be find-able via LINKS (javascript or HTML) and it needs to exist within a sensible hierarchy of a SITE. 3. This "PAGE" needs to have unique and significant content visible immediately to the user, and on…

As I mentioned in the post, all these problems can be solved by using real paths/URLs and changing them dynamically using pushState.

Re: Googlebot's recent improvements might revolutionize web development

#33

Post by qyv »

jacquesm wrote: post #7

One potential problem here is that google will use this to widen the gap between it and the 'one page apps' web and other search engines (such as duckduckgo) that can't match it in resources. How strong of an advantage that will be in the long run is uncertain, I would rather see a web that ships pages with actual content in them than empty containers for a variety of reasons (most of which have to do with accessibil…

I don't see this as a problem at all, here is why:

Google doesn't really have competitors in search, they just don't. I mean look at how we even define 'searching the internet' in our spoken language: 'google it'. Google has become the identity of search on the web in most people's minds. And to top it off, they are really, really good at it. Google getting better is going to widen the gap between them and everyone else, but the gap is already pretty damn wide. Was there really any chance of someone catching them in any foreseeable future?

But, the wider that gap gets the more motivation there becomes to not attack the gap, but to go in a different direction altogether. Nobody talks about duckduckgo because they're search results are better than google's, they talk about them because duckduckgo is all about your privacy. They found a different way to make a search that people want to use. The wider that gap gets the more motivated some will be to try something truly novel to compete with google.

Re: Googlebot's recent improvements might revolutionize web development

#34

Post by MichaelGG »

BorisMelnik wrote: post #29
iLoch wrote: post #19

Earlier quoted context omitted.

It's not difficult to set up middleware that'll render the page for any clients that require it. (For instance, we can assume any client that identifies as "bot" that's not Google probably wants a pre-rendered page, which we can do quite effortlessly. Here's one implementation for Nodejs: https://prerender.io , or you can always roll your own with something like Phantom.js.

wow this is amazing. would love to see an offshoot of this where it could render a sitemap, or even keep a live sitemap up to date via cron.d or something (just hoping out loud)

We're using Brombone. You give them your sitemap, they do the prerendering and save it all. Then you proxy to them for Googlebot and others.

Re: Googlebot's recent improvements might revolutionize web development

#35

Post by acqq »

So you want to have the URL for every content but you don't want to provide the content as HTML, instead expecting that once the page is by client, the client only then separately loads the content? Only because it's easier to you to program, you want to deliver me the content much slower than you can?

There is some strange logic there.

Re: Googlebot's recent improvements might revolutionize web development

#36

Post by workhere-io »

rcsorensen wrote: post #23

Sending the framework of a page to your users and expecting them to do all the heavy lifting and slow loading of constructing the page and fetching the data is still rather unfriendly if you can afford a server to construct it. If you love your users, give them HTML and let the Javascript enhance it. Projects like Facebook's React ( http://facebook.github.io/react/docs/top-level-api.html#reac... ) and Rendr ( https:/…

Clientside rendering doesn't need to be heavy at all. In fact, you could do it with just $.getJSON('/api/users', function(data) { $('#users').text(data.content) }.

Sure, that requires jQuery, but most "normal" sites require jQuery, too.

Re: Googlebot's recent improvements might revolutionize web development

#37

Post by MichaelGG »

jacquesm wrote: post #7

One potential problem here is that google will use this to widen the gap between it and the 'one page apps' web and other search engines (such as duckduckgo) that can't match it in resources. How strong of an advantage that will be in the long run is uncertain, I would rather see a web that ships pages with actual content in them than empty containers for a variety of reasons (most of which have to do with accessibil…

>I'm fairly sure this is not the web that Tim Berners-Lee envisioned.

So? None of these are convincing arguments for application developers. Having to rewrite an application to perform all its UI logic on the server side in addition to client side is a lot of work, for almost no benefit to the people paying to make the application.

As a user, so long URLs work so I can send locations to other people, then most of my accessibility scenarios are solved.

The rest is simply a lack of technology in other clients.

Re: Googlebot's recent improvements might revolutionize web development

#38

Post by marknutter »

ssorallen wrote: post #27
marknutter wrote: post #26

Earlier quoted context omitted.

The lifting ain't that heavy. And besides, wouldn't you want your server spending its precious cycles on things the clients absolutely cannot handle?

The lifting can be heavy for mobile devices with slow CPUs and limited battery life unlike the servers running your site. Also if your server renders the site and some of the pages are public, the server can cache the HTML and let the web server serve cached HTML rather than render the page in the web framework for each request.

It doesn't have to be heavy, even for mobile devices. Decrease your dependency on large libraries, minify and cache everything, and only load what they need. Once they load it the first time and cache it then all they ever need is a bit of JSON here and there.

Re: Googlebot's recent improvements might revolutionize web development

#39

Post by workhere-io »

acqq wrote: post #35

So you want to have the URL for every content but you don't want to provide the content as HTML, instead expecting that once the page is by client, the client only then separately loads the content? Only because it's easier to you to program, you want to deliver me the content much slower than you can? There is some strange logic there.

The whole point is to make the experience better for the user: When going to each new page on the site only involves fetching a bit of JSON and not an entire HTML page including header, footer, JS, CSS, etc., that makes the user experience faster. Add to that the fact that since the front page HTML now no longer contains any dynamic elements (you would get those dynamic elements via JS), you can put your front page HTML (the one HTML page there is) on a CDN and get faster load times.

As for speed: Sure there are exceptions when developers go crazy with tons of heavy JS, but that doesn't need to be the case at all.

Re: Googlebot's recent improvements might revolutionize web development

#40

Post by acdha »

ssorallen wrote: post #27
marknutter wrote: post #26

Earlier quoted context omitted.

The lifting ain't that heavy. And besides, wouldn't you want your server spending its precious cycles on things the clients absolutely cannot handle?

The lifting can be heavy for mobile devices with slow CPUs and limited battery life unlike the servers running your site. Also if your server renders the site and some of the pages are public, the server can cache the HTML and let the web server serve cached HTML rather than render the page in the web framework for each request.

> The lifting can be heavy for mobile devices with slow CPUs and limited battery life unlike the servers running your site.

The reverse is also frequently true: if client rendering can improve cacheability or reduce the data going over the wire the radio savings will pay for a LOT of text updates. Similarly, if you can transfer a large listing without creating thousands of DOM nodes the results can be a wash depending on exactly how much data, the browser, etc.

There isn't a single right answer here - it really depends on the application and good analysis.

Post reply on HN