3 ms·

This is the greatest html5 feature I've never heard of, and it's really going to change how everybody make web apps. Here's my wild prediction: 10 years from n

by korch 16y ago

This is the greatest html5 feature I've never heard of, and it's really going to change how everybody make web apps. Here's my wild prediction: 10 years from now, with the benefit of hindsight, we will trace the moment where Google's Page Rank empire started to crumble to the introduction of this html5 feature. However, discovering this makes me wonder what other incredibly useful but as yet unknown html5 features are out there in the wild?

gojomo 16y ago
How does this feature make much difference to Page Rank (or the many other ranking factors now as important or moreso for Google)?
- korch 16y ago
  By decoupling urls in the browser from urls in the web app, it's only going to increase the amount of content in the Deep Web that Google can't index. I imagine it'll be difficult to make GoogleBot crawl and index "pages" after large swaths of the web are using this. And once this Javascript feature is in jQuery, then we can expect a huge number of web developers to start using it by default. I don't know how much Javascript the GoogleBot currently parses and/or executes, but I imagine it would be enormously complex to embed v8 into the crawler, and then execute all Javascript on every page and determine what to index on a "page." If we ever get to the point where you can't screen scrape a web app without also executing its Javascript, then PageRank-like methods become less effective, and we'll need more semantic approaches to search. It's a great thing such semantic approaches don't yet exist!
  - gojomo 16y ago
    Some Google crawls already execute Javascript; they could easily do so more extensively if that were the only way to reach valuable content. Also, Google is already promoting a convention for making the various parts of an AJAX application reachable via different URL-#fragments more easily crawlable. See: http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=174992 http://www.google.com/support/webmasters/bin/answer.py?hl=en... A number of sites including Facebook have adopted this convention; app developers usually want to be found by search engines.
    - korch 16y ago
      Microsoft for one would love to have a big chunk of Internet real estate that couldn't be found and indexed by Google. It's funny you mention Facebook. I would say Facebook's chief motive right now is to stop Google from encroaching upon their territory, so Facebook wants to put up as many speed-bumps as possible around Google. Basically that means keeping Google sandboxed—it's okay to let Google index anything they want and throw that up on an ordered SERP, but no way can we let them grow elaborate ivy APIs and web-based UIs around our walled-garden of user generated content. (i.e. Buzz.) Given Microsoft's ownership and early partnering with Facebook, Microsoft and Facebook have aligned interests in keeping Google in the sandbox.
    - deleted 16y ago
      [deleted]
gorog 16y ago
It's exactly the feature I desperately wanted a few months ago, but then I modified the UI so that it loads a page for each piece of information that's important enough to have it's own URL and the result was considerably simpler to use. This feature will make it very easy to write overly complicated interfaces. Designers will have to be careful.

by korch 16y ago

gojomo 16y ago

How does this feature make much difference to Page Rank (or the many other ranking factors now as important or moreso for Google)?

korch 16y ago
By decoupling urls in the browser from urls in the web app, it's only going to increase the amount of content in the Deep Web that Google can't index. I imagine it'll be difficult to make GoogleBot crawl and index "pages" after large swaths of the web are using this. And once this Javascript feature is in jQuery, then we can expect a huge number of web developers to start using it by default. I don't know how much Javascript the GoogleBot currently parses and/or executes, but I imagine it would be enormously complex to embed v8 into the crawler, and then execute all Javascript on every page and determine what to index on a "page." If we ever get to the point where you can't screen scrape a web app without also executing its Javascript, then PageRank-like methods become less effective, and we'll need more semantic approaches to search. It's a great thing such semantic approaches don't yet exist!
- gojomo 16y ago
  Some Google crawls already execute Javascript; they could easily do so more extensively if that were the only way to reach valuable content. Also, Google is already promoting a convention for making the various parts of an AJAX application reachable via different URL-#fragments more easily crawlable. See: http://www.google.com/support/webmasters/bin/answer.py?hl=en&answer=174992 http://www.google.com/support/webmasters/bin/answer.py?hl=en... A number of sites including Facebook have adopted this convention; app developers usually want to be found by search engines.
  - korch 16y ago
    Microsoft for one would love to have a big chunk of Internet real estate that couldn't be found and indexed by Google. It's funny you mention Facebook. I would say Facebook's chief motive right now is to stop Google from encroaching upon their territory, so Facebook wants to put up as many speed-bumps as possible around Google. Basically that means keeping Google sandboxed—it's okay to let Google index anything they want and throw that up on an ordered SERP, but no way can we let them grow elaborate ivy APIs and web-based UIs around our walled-garden of user generated content. (i.e. Buzz.) Given Microsoft's ownership and early partnering with Facebook, Microsoft and Facebook have aligned interests in keeping Google in the sandbox.
  - deleted 16y ago
    [deleted]

gorog 16y ago

It's exactly the feature I desperately wanted a few months ago, but then I modified the UI so that it loads a page for each piece of information that's important enough to have it's own URL and the result was considerably simpler to use. This feature will make it very easy to write overly complicated interfaces. Designers will have to be careful.