“If it’s not curlable, it’s not on the web.” 📷 @jkphl js;dr in print! Thanks to Joschi for the photograph of page 88 of @heydonworks’s new book “Inclusive Design Patterns”. From: https://twitter.com/jkphl/status/792452368562618369 This book will last longer than all your fashionable JS frameworks no matter what your coding schools are teaching you. Except maybe jQuery. You can still use jQuery to build reliable web sites. #IndieWeb #JavaScript #content #curlable #jsdr #book #hardcopy #printmedialives When I showed this photo yesterday to @adactio, he noted that the quote from my js;dr post: tantek.com/2015/069/t1/js-dr-javascript-required-dead “If it’s not curlable, it’s not on the web.” sounded like something @benward had said in one of his blog posts from long ago. So we both researched it last night and found this post of Ben’s from 2011-02-11 “Hash, Bang, Wallop” https://benward.uk/blog/tumblr-3231388630 In which he notes: “(It turns out that it was me who wrote “if site content doesn’t load through curl it’s broken”, and I'll stand by that.)” Where the phrase “who wrote” links to: developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/#comment-17071 Unfortunately that link now 404s. I assumed it was due to Yahoo shutting down all of YDN and so found this archive.org version instead (as noted tantek.com/2016/311/t1/site-content-load-through-curl) https://web.archive.org/web/20101016010319/http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/#comment-17071 While writing this post, and about to claim that YDN shut down (it did not), I double checked and remnants remained (top level blog URL etc). There was no archive navigation (I’m not one to talk, I still need to build that on my site, maybe today at IndieWebCamp LA), so I paged through the "Previous" pages of the blog (eventually hacking the URL directly) and found: “How many users have JavaScript disabled?” https://developer.yahoo.com/blogs/ydn/many-users-javascript-disabled-14121.html Looks like YDN changed their CMS and broke all their permalinks. This is pretty clear even from their own blog, e.g. the follow-up post to that post: “Followup: How many users have JavaScript disabled?” https://developer.yahoo.com/blogs/ydn/followup-many-users-javascript-disabled-16191.html Which itself still links to the old permalink of the post it is following-up to. In addition to breaking all their permalinks, they also removed all their comments, including Ben Ward’s comment, so we still have to go back to the archive.org link: https://web.archive.org/web/20101016010319/http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/#comment-17071 With Ben’s comment, which I’m going to quote in full because it provides a lot of the thinking behind js;dr before I wrote it up, and I figure providing yet another copy will help it stick around: @BenWard on 2011-10-13: “One additional piece of information I’d be interested in here is whether the ‘JavaScript disabled’ measure is just that—the user’s browser having a featured turned off—or whether it factors in some scenarios of ‘JavaScript unavailable’. For example, where variable or poor network performance causes external JavaScript to load slowly and execute late, or not at all. And then, how much of an increase that can give to the numbers if it’s possible to factor it in. “Increasingly, I find that the ‘some users turn off JavaScript’ argument is difficult to make—not because they don’t, your graph illustrates that—but because even presented with percentages, developers are sceptical and evasive of those users (I think there’s a suspicion that the kind of use who might make such a decision to turn off a cool browser feature is not the kind of user that would want their cool product… or something like that, less grossly over-slimplified.) The argument that instead JavaScript-less versions of the pages can be served to anyone if their network degrades is more universal: Not just second or third world scenarios without robust communications infrastructure, but anyone tethering through AT&T in San Francisco. Poor network performance seems to be something that developers relate to more easily than an alien configuration decision. “Of course, all of this is elaborate: The truth is that if site content doesn’t load through curl it’s broken.” In particular, Ben’s point about: “[…] variable or poor network performance causes external JavaScript to load slowly and execute late, or not at all.” This is really the key behind js;dr. We still have this problem, six years later. You CANNOT depend on external JavaScript loading quickly, or at all. I *just* experienced this, this morning due to bad hotel wifi while trying to write this up! (as noted tantek.com/2016/311/t2/js-dr-pages-not-rendering-bad-hotel-wifi) Networks are still slow or unreliable, no matter what device you may be using (like a laptop), no matter what country you may be in (here in the US, or in Europe, or elsewhere). Lessons: make sure your sites and pages: 1. Show content immediately without waiting for ANY external JS. 2. Have meaningful readable text alternatives for all non-decorative images and other embedded content. Previously, previously, previously: * tantek.com/2016/229/t3/content-viewable-links-buttons-inputs-work * tantek.com/2016/229/t2/ad-driven-js-dr-web-breaking * tantek.com/2016/229/t1/fail-slow-internet-ad-driven-js-react-angular * tantek.com/2016/228/t2/slow-flakey-internet-use-cases * tantek.com/2016/226/t1/rare-slow-flakey-internet-simple-ok-js-useless * tantek.com/2015/069/t1/js-dr-javascript-required-dead See Also: * https://indieweb.org/js;dr

“If it’s not curlable, it’s not on the web.” 📷 @jkphl
js;dr in print! Thanks to Joschi for the photograph of page 88 of @heydonworks’s new book “Inclusive Design Patterns”.

From: https://twitter.com/jkphl/status/792452368562618369

This book will last longer than all your fashionable JS frameworks no matter what your coding schools are teaching you. Except maybe jQuery. You can still use jQuery to build reliable web sites.

#IndieWeb #JavaScript #content #curlable #jsdr #book #hardcopy #printmedialives

When I showed this photo yesterday to @adactio, he noted that the quote from my js;dr post:

tantek.com/2015/069/t1/js-dr-javascript-required-dead

“If it’s not curlable, it’s not on the web.”

sounded like something @benward had said in one of his blog posts from long ago. So we both researched it last night and found this post of Ben’s from 2011-02-11 “Hash, Bang, Wallop” https://benward.uk/blog/tumblr-3231388630

In which he notes:

“(It turns out that it was me who wrote “if site content doesn’t load through curl it’s broken”, and I'll stand by that.)”

Where the phrase “who wrote” links to:

developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/#comment-17071

Unfortunately that link now 404s. I assumed it was due to Yahoo shutting down all of YDN and so found this archive.org version instead (as noted tantek.com/2016/311/t1/site-content-load-through-curl)

https://web.archive.org/web/20101016010319/http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/#comment-17071

While writing this post, and about to claim that YDN shut down (it did not), I double checked and remnants remained (top level blog URL etc).

There was no archive navigation (I’m not one to talk, I still need to build that on my site, maybe today at IndieWebCamp LA), so I paged through the "Previous" pages of the blog (eventually hacking the URL directly) and found:

“How many users have JavaScript disabled?” https://developer.yahoo.com/blogs/ydn/many-users-javascript-disabled-14121.html

Looks like YDN changed their CMS and broke all their permalinks.

This is pretty clear even from their own blog, e.g. the follow-up post to that post:

“Followup: How many users have JavaScript disabled?” https://developer.yahoo.com/blogs/ydn/followup-many-users-javascript-disabled-16191.html

Which itself still links to the old permalink of the post it is following-up to.

In addition to breaking all their permalinks, they also removed all their comments, including Ben Ward’s comment, so we still have to go back to the archive.org link:

https://web.archive.org/web/20101016010319/http://developer.yahoo.com/blogs/ydn/posts/2010/10/how-many-users-have-javascript-disabled/#comment-17071

With Ben’s comment, which I’m going to quote in full because it provides a lot of the thinking behind js;dr before I wrote it up, and I figure providing yet another copy will help it stick around:

@BenWard on 2011-10-13:

“One additional piece of information I’d be interested in here is whether the ‘JavaScript disabled’ measure is just that—the user’s browser having a featured turned off—or whether it factors in some scenarios of ‘JavaScript unavailable’. For example, where variable or poor network performance causes external JavaScript to load slowly and execute late, or not at all. And then, how much of an increase that can give to the numbers if it’s possible to factor it in.

“Increasingly, I find that the ‘some users turn off JavaScript’ argument is difficult to make—not because they don’t, your graph illustrates that—but because even presented with percentages, developers are sceptical and evasive of those users (I think there’s a suspicion that the kind of use who might make such a decision to turn off a cool browser feature is not the kind of user that would want their cool product… or something like that, less grossly over-slimplified.) The argument that instead JavaScript-less versions of the pages can be served to anyone if their network degrades is more universal: Not just second or third world scenarios without robust communications infrastructure, but anyone tethering through AT&T in San Francisco. Poor network performance seems to be something that developers relate to more easily than an alien configuration decision.

“Of course, all of this is elaborate: The truth is that if site content doesn’t load through curl it’s broken.”

In particular, Ben’s point about:

“[…] variable or poor network performance causes external JavaScript to load slowly and execute late, or not at all.”

This is really the key behind js;dr.

We still have this problem, six years later.

You CANNOT depend on external JavaScript loading quickly, or at all.

I *just* experienced this, this morning due to bad hotel wifi while trying to write this up! (as noted tantek.com/2016/311/t2/js-dr-pages-not-rendering-bad-hotel-wifi)

Networks are still slow or unreliable, no matter what device you may be using (like a laptop), no matter what country you may be in (here in the US, or in Europe, or elsewhere).

Lessons: make sure your sites and pages:
1. Show content immediately without waiting for ANY external JS.
2. Have meaningful readable text alternatives for all non-decorative images and other embedded content.

Previously, previously, previously:
* tantek.com/2016/229/t3/content-viewable-links-buttons-inputs-work
* tantek.com/2016/229/t2/ad-driven-js-dr-web-breaking
* tantek.com/2016/229/t1/fail-slow-internet-ad-driven-js-react-angular
* tantek.com/2016/228/t2/slow-flakey-internet-use-cases
* tantek.com/2016/226/t1/rare-slow-flakey-internet-simple-ok-js-useless
* tantek.com/2015/069/t1/js-dr-javascript-required-dead

See Also:
* https://indieweb.org/js;dr