Gawker, like Twitter before it, built their new site to be totally dependent on JavaScript, even down to the page URLs. The JavaScript failed to load, so no content appeared, and every URL on the page was broken."
I've noticed this same thing with the NY times app on the chrome web
store. In my experience about 25-30% of the time it fails to load and
you get no content. I also notice this with the NY times app on the
apple app store which appears to just be a native app with a webkit
view hosting the same content as whats on the chrome web store.
Its a difficult problem. While the idea of "progressive enhancement"
sounds nice, I can see it being particularly hard to achieve with
HTML5 web apps. Lifehacker is kind of a borderline case where they
really are not full blown web apps but include a lot of essential
functionality that needs JS.
On Feb 8, 6:48 pm, cancel bubble <cancelbub...@gmail.com> wrote:
> Gawker, like Twitter before it, built their new site to be totally dependent
> on JavaScript, even down to the page URLs. The JavaScript failed to load, so
> no content appeared, and every URL on the page was broken."
> I've noticed this same thing with the NY times app on the chrome web
> store. In my experience about 25-30% of the time it fails to load and
> you get no content. I also notice this with the NY times app on the
> apple app store which appears to just be a native app with a webkit
> view hosting the same content as whats on the chrome web store.
> Its a difficult problem. While the idea of "progressive enhancement"
> sounds nice, I can see it being particularly hard to achieve with
> HTML5 web apps. Lifehacker is kind of a borderline case where they
> really are not full blown web apps but include a lot of essential
> functionality that needs JS.
> On Feb 8, 6:48 pm, cancel bubble <cancelbub...@gmail.com> wrote:
> > Gawker, like Twitter before it, built their new site to be totally dependent
> > on JavaScript, even down to the page URLs. The JavaScript failed to load, so
> > no content appeared, and every URL on the page was broken."
On Feb 10, 1:10 am, Jason Mulligan <jason.mulli...@avoidwork.com>
wrote:
> TDD would've caught that.
A Telecommunication Device for the Deaf? Oh, you mean test driven
development.
An architecture based on links and perfectly functioning javascript to
follow them is brittle and subject to additional a single points of
failure. An architecture isn't a development methodology, they are
completely separate animals.
> On Feb 10, 1:10 am, Jason Mulligan <jason.mulli...@avoidwork.com> > wrote: > > TDD would've caught that.
> A Telecommunication Device for the Deaf? Oh, you mean test driven > development.
> An architecture based on links and perfectly functioning javascript to > follow them is brittle and subject to additional a single points of > failure. An architecture isn't a development methodology, they are > completely separate animals.
> -- > Rob
> -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/jsment...@jsmentors.com/
I'm pretty sure IE9 won't be supporting it. Anything that's not in the beta won't be in the final version is what I heard from an MS evangelist back in October.
On Wed, Feb 9, 2011 at 8:45 PM, cancel bubble <cancelbub...@gmail.com>wrote:
On Wed, Feb 9, 2011 at 05:09, mcot <atm1...@gmail.com> wrote: > Its a difficult problem. While the idea of "progressive enhancement" > sounds nice, I can see it being particularly hard to achieve with > HTML5 web apps.
There is a bigger problem: no search engine optimization.
Who cares about the content that can't be found on Google. For me it doesn't exist.
Solution is simple: write a bare-bone no-css no-flash (who uses that anyway?) no-nothing pure default html web page that gets displayed by everything, even text browsers, and can be spidered by Google (googlebot = text browser). Do not forget the static links that work, so bots can scan the site.
Then add css. Then add javascript which replaces blocks of the default html (in divs or html5 sections) with advanced functionality after the page has loaded. Advanced = ajax inline content replace with no reloading, animations, etc...
> On Wed, Feb 9, 2011 at 05:09, mcot <atm1...@gmail.com > <mailto:atm1...@gmail.com>> wrote:
> Its a difficult problem. While the idea of "progressive enhancement" > sounds nice, I can see it being particularly hard to achieve with > HTML5 web apps.
> There is a bigger problem: no search engine optimization.
> Who cares about the content that can't be found on Google. For me it > doesn't exist.
> Solution is simple: write a bare-bone no-css no-flash (who uses that > anyway?) no-nothing pure default html web page that gets displayed by > everything, even text browsers, and can be spidered by Google > (googlebot = text browser). Do not forget the static links that work, > so bots can scan the site.
> Then add css. Then add javascript which replaces blocks of the default > html (in divs or html5 sections) with advanced functionality after the > page has loaded. Advanced = ajax inline content replace with no > reloading, animations, etc...
This is the concept I have been advocating for years, too. The argument against it I hear though is that if you build an HTML5 Application then you by default don't want it indexed by Google. Gmail should not show up in search results as these are your private emails.
On Thu, Feb 10, 2011 at 5:03 AM, Chris Heilmann <code...@gmail.com> wrote: > On 10/02/2011 07:11, Andraž Kos wrote:
> On Wed, Feb 9, 2011 at 05:09, mcot <atm1...@gmail.com> wrote:
> Its a difficult problem. While the idea of "progressive enhancement" > sounds nice, I can see it being particularly hard to achieve with > HTML5 web apps.
> There is a bigger problem: no search engine optimization.
> Who cares about the content that can't be found on Google. For me it > doesn't exist.
> Solution is simple: write a bare-bone no-css no-flash (who uses that > anyway?) no-nothing pure default html web page that gets displayed by > everything, even text browsers, and can be spidered by Google (googlebot = > text browser). Do not forget the static links that work, so bots can scan > the site.
> Then add css. Then add javascript which replaces blocks of the default > html (in divs or html5 sections) with advanced functionality after the page > has loaded. Advanced = ajax inline content replace with no reloading, > animations, etc...
> This is the concept I have been advocating for years, too. The argument > against it I hear though is that if you build an HTML5 Application then you > by default don't want it indexed by Google. Gmail should not show up in > search results as these are your private emails.
But that's silly. If you don't want web crawlers reading your emails don't expose that capability. You probably don't want random people reading your emails anyway :)
Authorization and indexability are orthagonal issues.
On Thursday, February 10, 2011 at 10:11 AM, Andraž Kos wrote: > On Wed, Feb 9, 2011 at 05:09, mcot <atm1...@gmail.com> wrote: > > Its a difficult problem. While the idea of "progressive enhancement" > > sounds nice, I can see it being particularly hard to achieve with > > HTML5 web apps. > There is a bigger problem: no search engine optimization.
> Who cares about the content that can't be found on Google. For me it doesn't exist.
> Solution is simple: write a bare-bone no-css no-flash (who uses that anyway?) no-nothing pure default html web page that gets displayed by everything, even text browsers, and can be spidered by Google (googlebot = text browser). Do not forget the static links that work, so bots can scan the site.
> Then add css. Then add javascript which replaces blocks of the default html (in divs or html5 sections) with advanced functionality after the page has loaded. Advanced = ajax inline content replace with no reloading, animations, etc...
> -- > To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsment...@jsmentors.com/
On Thu, Feb 10, 2011 at 7:11 AM, Andraž Kos <andraz....@gmail.com> wrote: > On Wed, Feb 9, 2011 at 05:09, mcot <atm1...@gmail.com> wrote:
>> Its a difficult problem. While the idea of "progressive enhancement" >> sounds nice, I can see it being particularly hard to achieve with >> HTML5 web apps.
> There is a bigger problem: no search engine optimization.
> Who cares about the content that can't be found on Google. For me it > doesn't exist.
> Solution is simple: write a bare-bone no-css no-flash (who uses that > anyway?) no-nothing pure default html web page that gets displayed by > everything, even text browsers, and can be spidered by Google (googlebot = > text browser). Do not forget the static links that work, so bots can scan > the site.
> Then add css. Then add javascript which replaces blocks of the default html > (in divs or html5 sections) with advanced functionality after the page has > loaded. Advanced = ajax inline content replace with no reloading, > animations, etc...
I don't think progressive enhancement solves all that much in terms of SEO.
The problem lies in the fact that humans will *always* use the human version of URLs, and Google still won't know how to deal with those. For example, I will add a link on my blog to my Twitter account like this: twitter.com/#!/danburzo, because that's what it says in my browser's location bar. Search engines still need to make sense of this in order to boost the rank for twitter.com/danburzo.
On Thu, Feb 10, 2011 at 12:03, Chris Heilmann <code...@gmail.com> wrote: > On 10/02/2011 07:11, Andraž Kos wrote:
> On Wed, Feb 9, 2011 at 05:09, mcot <atm1...@gmail.com> wrote:
> Its a difficult problem. While the idea of "progressive enhancement" > sounds nice, I can see it being particularly hard to achieve with > HTML5 web apps.
> There is a bigger problem: no search engine optimization.
> Who cares about the content that can't be found on Google. For me it > doesn't exist.
> Solution is simple: write a bare-bone no-css no-flash (who uses that > anyway?) no-nothing pure default html web page that gets displayed by > everything, even text browsers, and can be spidered by Google (googlebot = > text browser). Do not forget the static links that work, so bots can scan > the site.
> Then add css. Then add javascript which replaces blocks of the default > html (in divs or html5 sections) with advanced functionality after the page > has loaded. Advanced = ajax inline content replace with no reloading, > animations, etc...
> This is the concept I have been advocating for years, too. The argument > against it I hear though is that if you build an HTML5 Application then you > by default don't want it indexed by Google. Gmail should not show up in > search results as these are your private emails.
> -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/jsment...@jsmentors.com/
> I don't think progressive enhancement solves all that much in terms of > SEO.
> The problem lies in the fact that humans will *always* use the human > version of URLs, and Google still won't know how to deal with those. > For example, I will add a link on my blog to my Twitter account like > this: twitter.com/#!/danburzo <http://twitter.com/#%21/danburzo>, > because that's what it says in my browser's location bar. Search > engines still need to make sense of this in order to boost the rank > for twitter.com/danburzo <http://twitter.com/danburzo>.
Totally. The other thing to consider is though that for a lot of these apps SEO is not really an issue. So if you tell people they shouldn't use hash-bangs because of Google you will get a lot of "well, we have an app that has people's private info in it - it shouldn't be indexed anyways".
Actually, Google seems to have a way to translate the hashbang into something more meaningful.
"As soon as you use the hashbang in a URL, Google will spot that you're following their protocol, and interpret your URLs in a special way - they'll take everything after the hashbang, and pass it to the site as a URL parameter instead. The name they use for the parameter is: _escaped_fragment_"
> I don't think progressive enhancement solves all that much in terms of SEO.
> The problem lies in the fact that humans will *always* use the human version > of URLs, and Google still won't know how to deal with those. For example, I > will add a link on my blog to my Twitter account like this: > twitter.com/#!/danburzo, because that's what it says in my browser's > location bar. Search engines still need to make sense of this in order to > boost the rank for twitter.com/danburzo.
> On Thu, Feb 10, 2011 at 12:03, Chris Heilmann <code...@gmail.com> wrote:
>> On 10/02/2011 07:11, Andraž Kos wrote:
>> On Wed, Feb 9, 2011 at 05:09, mcot <atm1...@gmail.com> wrote:
>> Its a difficult problem. While the idea of "progressive enhancement" >> sounds nice, I can see it being particularly hard to achieve with >> HTML5 web apps.
>> There is a bigger problem: no search engine optimization. >> Who cares about the content that can't be found on Google. For me it >> doesn't exist.
>> Solution is simple: write a bare-bone no-css no-flash (who uses that >> anyway?) no-nothing pure default html web page that gets displayed by >> everything, even text browsers, and can be spidered by Google (googlebot = >> text browser). Do not forget the static links that work, so bots can scan >> the site. >> Then add css. Then add javascript which replaces blocks of the default >> html (in divs or html5 sections) with advanced functionality after the page >> has loaded. Advanced = ajax inline content replace with no reloading, >> animations, etc...
>> This is the concept I have been advocating for years, too. The argument >> against it I hear though is that if you build an HTML5 Application then you >> by default don't want it indexed by Google. Gmail should not show up in >> search results as these are your private emails.
>> -- >> To view archived discussions from the original JSMentors Mailman list: >> http://www.mail-archive.com/jsment...@jsmentors.com/
> Actually, Google seems to have a way to translate the hashbang into > something more meaningful.
> "As soon as you use the hashbang in a URL, Google will spot that > you're following their protocol, and interpret your URLs in a special > way - they'll take everything after the hashbang, and pass it to the > site as a URL parameter instead. The name they use for the parameter > is: _escaped_fragment_"
There are still several problems with this, though.
It requires the implementer to forego more human-friendly progressive enhancement techniques in favor of a non-standard _escaped_fragment_ query parameter, which currently only benefits the GoogleBot. It breaks referrer URLs. It adds significant latency to the initial request to a bookmarked # URL, since JavaScript (and probably more requests) must execute before content can be displayed. It doesn't work at all if JavaScript is disabled, or if the script fails to load.
Hash-based history is perfectly acceptable (and advisable) for minor functionality like keeping track of the active tab in a JavaScript-enhanced tab widget, or which label is currently being viewed in Gmail, or similar things. It's not a good solution as the primary navigation handler of an entire content-focused website.
HTML5 pushState is a much better alternative that allows JavaScript apps to change the URL in a way that's backwards compatible (if implemented correctly), so the generated URLs can be used regardless of whether the client supports JavaScript. They don't have the same latency penalty as hash URLs, since content can be generated on the server for the initial request. They will also be indexable by all search crawlers instead of just the GoogleBot. They're correctly passed as referrer URLs. And they look and behave like perfectly normal URLs that users are used to, because that's exactly what they are.
The major drawback of pushState, of course, is a lack of broad browser support. No version of IE supports pushState (not even IE9). Some browsers (like Mobile Safari) have buggy support. Since pushState inherently encourages progressive enhancement, it's possible to gracefully degrade to non-JS handling of URLs for those browsers, but it requires careful planning and application design.
Hash-based history is better than no history support at all, but it's the laziest solution there is.
> HTML5 pushState is a much better alternative that allows JavaScript > apps to change the URL in a way that's backwards compatible (if > implemented correctly), so the generated URLs can be used regardless > of whether the client supports JavaScript.
IMO, Github's use of pushState for browsing repos seems quite well done and a good example of progressive enhancement. For example, compare browsing through folders and files at this URL in FF 3.6 vs. Chrome:
