41–50 of 263 posts
Earlier quoted context omitted.
Javascript-dependent content _can_ present problems for search engine accessibility
There have been techniques for dealing with this for a very long time: https://developers.google.com/webmasters/ajax-crawling/docs/... And this is only an issue for pages where you actually want to expose your content to search engines.
Earlier quoted context omitted.
Every Ember.js app, by definition, connects to an API that does all of the things you are asking for. Seriously, open up any Ember.js app and look at the network traffic. You'll see a series of requests, usually using very RESTful URLs, that requests the document. The only difference is that, instead of HTML, where you are conflating the markup and the content, you get a nice, easily-consumable version of the documen…
That could work -- if the JSON is intended for public consumption, and if it is documented as so. The problem, I'd argue, with JSON is that it does not intentionally facilitate semantic annotations, unlike HTML(5). I'd argue that a properly marked-up HTML5 representation of a piece of data is more useful than a bespoke JSON structure with crude naming liable to change without notice. The benefit I get with an HTML re…
Is the HTML of any popular website publicly documented? Is there any guarantee that an XPath to a particular value won't change? Is there any guarantee the data I need is marked up with semantically accurate class names? No.
HTML is intended for public consumption—by a human, at a particular time. It is not a data interchange format.
Contrast that with things like Twitter or GitHub, which provide a versioned JSON API that is guaranteed not to change. Your web site becomes just another consumer of that API.
JSON contains all of the data you need, but in a way designed to be consumed by computers, and you don't have to do all of that awful HTML scraping.
And as for Bustle not having a public JSON API, well, here you go:
curl -H "Accept: application/json" http://www.bustle.com/api/v1/sections/home.json
A versioned JSON API that is guaranteed not to change. Can any public site on the internet guarantee that about its HTML?
"And most importantly: Don’t be ashamed to build 100% JavaScript applications. You may get some incensed priests vituperating you in their blogs. But there will be an army of users (like me) who will fall in love with using your app." This statement needs a huge, HUGE caveat that you should only be building 100% JavaScript apps in situations where doing so makes sense . For example, I find the new Blogger "web app" i…
i m still opening a dozen tabs and reading them whenever i want, unfortunately most newer js only web blogs such as inc mobile, end up having a lot of errors and white pages.. i understand your newly found js excitement with your full ember.js app, but do'nt forget the lessons from java the browser plugin and flash. 1. ok you re real time, but don't assume i m watching your site like a tv 2. dont consume my precious…
However I don't think citing the problems with Flash and Java Applets is applicable. JavaScript maturity is explicitly the long-awaited remedy to the problems of those bolted-on runtimes. It's true that bloated over-the-top CPU-hogging monstrosities will be done with JS as with prior technologies, but there's no technology that is immune to that.
FWIW, Ember is pretty performance-oriented and lets you get a lot done with a very low code / performance / byte overhead.
Earlier quoted context omitted.
Javascript-dependent content _can_ present problems for search engine accessibility
There have been techniques for dealing with this for a very long time: https://developers.google.com/webmasters/ajax-crawling/docs/... 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.
How about: If it's profitable for your site to offer a non-JS fallback, do it. If it isn't, don't.
"And most importantly: Don’t be ashamed to build 100% JavaScript applications. You may get some incensed priests vituperating you in their blogs. But there will be an army of users (like me) who will fall in love with using your app." This statement needs a huge, HUGE caveat that you should only be building 100% JavaScript apps in situations where doing so makes sense . For example, I find the new Blogger "web app" i…
"Friendly reminder that "people with JS disabled" includes those on high-latency networks, bad firewalls, and browsers you don't support." - @jcoglan https://twitter.com/jcoglan/status/370173041193406464
And people using NoScript.
This post does nothing to address the biggest reason people might have Javascript disabled: security. If I'm browsing through Tor (or whatever), I'm not going to turn on Javascript to use your site. If your site doesn't work without it, you've lost a customer. Granted, people who disable javascript are obviously vastly outnumbered, but just saying "fuck you" to security conscious (and most likely tech-savvy) users se…
According to developer.yahoo.com[1],
> After crunching the numbers, we found a consistent rate of JavaScript-disabled requests hovering around 1% of the actual visitor traffic[...].
I work for a medium sized company that version tests almost every change we make, and in the end the version that wins is the feature with the higher conversion rate.
[1] http://developer.yahoo.com/blogs/ydn/many-users-javascript-d...