99.99% of the people visiting my site have JS enabled and I'm happy to support them just fine without worrying about the really long tail.
99.99% of the people visiting my site have JS enabled and I'm happy to support them just fine without worrying about the really long tail.
The fact that the JS frequently results in lower usability is biggest on my list. I've encountered Blogger themes which are so fucking piss-poor I literally cannot read them, even with JS enabled.
If the primary goal of your site is content, stick with vanilla HTML. You're vastly better off for it.
It doesn't look like it is too difficult to add search indexing support.
http://eviltrout.com/2013/06/19/adding-support-for-search-en...
And this is only an issue for pages where you actually want to expose your content to search engines.
_escaped_fragment_ is a stupid hack that requires hardest bit of work needed for progressive enhancement, but provides none of the benefit.
Asking Timmy to "step up his game" is heartless, and it'd be unnecessary if we were better citizens.
I've never seen an example where Google crawled a page and included content that was loaded via ajax or an external javascript file. I have seen Google index content that is loaded from a script tag included in the html page.
However, from working with customers of BromBone, I know this. People have javascript powered webpages that were not getting indexed by Google. Google would crawl the page, and see no content. The pages were not in Google. After creating prerendered snapshots and serving them when the _escaped_fragment_ parameter was present, the pages showed up in Google.
And if you use html5 pushstate you could even serve the HTML captures to any bots. Eventually you also could easily add graceful degradation to your site serving snapshots for non js users. As of PoC for SEO4Ajax (http://www.seo4ajax.com), I built this application (http://www.appscharts.me) illustrating this purpose.
You are right about one thing, it is a pain to setup. Much harder than it sounds at first. After doing it a few times, I finally got sick of it and built http://www.BromBone.com. It's a service that takes generates the html snapshots for site owners and keeps them up to date. I hope it will let site owner keep all the positives and eliminate most of the new negatives.
I make this assumption because most of us don’t actually know how Google works, acting as a user’s proxy is in Google’s interest, and it is certainly within their technological capability. (Let me emphasize assume, again.)
This would require that the crawler actually renders sites, indexes the resulting DOM, and clicks what can be clicked. A headless Chrome, perhaps.
"Use a text browser such as Lynx to examine your site, because most search engine spiders see your site much as Lynx would. If fancy features such as JavaScript, cookies, session IDs, frames, DHTML, or Flash keep you from seeing all of your site in a text browser, then search engine spiders may have trouble crawling your site."
With regard to Google, however, they are explicit in their support for JavaScript rendered sites:
https://developers.google.com/webmasters/ajax-crawling/docs/...
Amongst many other links.
Do you know that for a FACT, or are you just guessing?
If you don't have javascript enabled...
You don't get to define what the baseline correct thing is for a business, profit does that. Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.
That's what I am using.
>Progressive enhancement is more work than simply presuming JavaScript is always available; that's just a simple undeniable fact.
I am denying it right now, that is the whole point. Server side templates with simple javascript enhancement has been much faster for us, and much easier to maintain.
I simply don't believe you. It's a fact that it's more work to support both AJAX interactions and work with js disabled than it is to support just AJAX alone. There is no arguing this, it's more work to support 2 modes of interaction than it is to support only 1. You may find it a comfortable workflow for you, to start with vanilla HTML and then progressively enhance it, but regardless of how much you like the style, it is more effort and does have more long term maintenance costs to forever support 2 modes of interaction. No one who isn't completely full of shit would argue that progressive enhancement is less work.
That is not a fact. It may well be your experience from the way your applications were written, but it is not a fact. You clearly do need a lecture, or you wouldn't be posting garbage.
That's certainly not how I calculate revenue...