3 ms·

Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support

Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. The couple million people with NoScript installed who enable it only on specific sites know to enable it if a site doesn't work.

nkuttler 13y ago
You have to support non-JS browsers if you want to support search engines crawling your sites. The hash fragment is a non-JS method that only works with search engines. Why not use something that works with noscript browsers as well, and incidentally with search engines that don't support the hash fragment?
Isofarro 13y ago
It's not a question of having JavaScript enabled/disabled. It's a question of whether the JavaScript gets delivered from your server to the client's browser properly and fully in a state that it can be executed successfully. Progressive enhancement is about robustness, being adaptable when the network fails to be perfect. Look at it this way, this __escaped_fragment__ is only supported by Google. No other search engine supports it. And considering that building it with progressive enhancement first, and then enhancing it with JavaScript, you get content that's indexable by any search engine, not just Google. The workload is the same, the complexity is the same, the only difference is the focus on progressive enhancement first rather than try to bolt a clearly less optimal solution later.
- nkuttler 13y ago
  At least Bing supports the hash fragment as well, but it looks like you have to enable it manually http://www.bing.com/blogs/webmaster/f/12248/p/671232/9669509.aspx http://www.bing.com/blogs/webmaster/f/12248/p/671232/9669509...
blauwbilgorgel 13y ago
It does make sense to me, because: - Not all search engines can handle JavaScript, Google is leading the way, but not perfect. - Those NoScript users could be potential clients or users of your site. I love it when my conversation rate goes up 1%, and that becomes harder when you ignore 1-5% of users. - Screenreaders generally do not support JavaScript [not true, see comment]. If only one blind user gets to access the content/design I created, then that is worth it to me. I am thinking as front-end engineer here, not as a business owner, where time is money. (Also depending on jurisdiction it may be against the law to be inaccessible). - Noscript users will likely bounce in large numbers when seeing just a blank page. Simply adding a <noscript> tag, explaining why you need JavaScript goes a long way. As a front-end engineer I go for maximum content accessibility. I don't meddle into the politics of things ("If we don't drop IE6 support, the web won't move forward!"). I totally understand the new landscape, where a lot of people have JavaScript on. Some web apps can not use progressive enhancement, because the JavaScript is core to the app. But for "static" content websites like these, it is certainly possible to make a website that is usable by most users, human and robot.
- Isofarro 13y ago
  "Screenreaders in generally do not support JavaScript." Please stop saying that. It hasn't been true for a good 5 years or so. * http://www.brucelawson.co.uk/2011/javascript-and-screenreaders/ http://www.brucelawson.co.uk/2011/javascript-and-screenreade... * http://webaim.org/projects/screenreadersurvey4/#javascript http://webaim.org/projects/screenreadersurvey4/#javascript * http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html
  - blauwbilgorgel 13y ago
    Thank you! I've been behind the times. I'll start viewing it as a general accessibility issue, not specific to screen readers. But like Steve Klabnik commented, and from http://www.w3.org/WAI/intro/aria.php http://www.w3.org/WAI/intro/aria.php , there are a few more steps to take to make JavaScript enabled screen readers play nice: "WAI-ARIA addresses these accessibility challenges by defining how information about this functionality can be provided to assistive technology. With WAI-ARIA, an advanced Web application can be made accessible and usable to people with disabilities."
asdasf 13y ago
>it doesn't make much sense to support browsers with it disabled But that is exactly what you are doing anyways, you are just limiting it to googlebot for no reason.
Amadou 13y ago
Don't forget that javascript performance on mobile is abysmal. If your use of javascript is much more than light fluff, its going to seriously annoy mobile users. http://sealedabstract.com/rants/mobile-web-apps-are-slow/ http://sealedabstract.com/rants/mobile-web-apps-are-slow/
e12e 13y ago
> Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. Well, javascript support in w3m and lynx is still pretty poor. It makes it harder to easily get some content from offline reading using wget/curl. It does depend on what kind of site/app you're making. I'd say that if your main content is text, then requiring js makes no sense (especially if you're publishing some blog posts on configuring server software -- I might want do download that article to a headless server). I think most apps also benefit from an old school REST architecture, so that it is possible to eg: script your todo-app with curl to create a new todo-item without having to go through 3 pages of api-specs.

nkuttler 13y ago

You have to support non-JS browsers if you want to support search engines crawling your sites. The hash fragment is a non-JS method that only works with search engines. Why not use something that works with noscript browsers as well, and incidentally with search engines that don't support the hash fragment?

Isofarro 13y ago

It's not a question of having JavaScript enabled/disabled. It's a question of whether the JavaScript gets delivered from your server to the client's browser properly and fully in a state that it can be executed successfully. Progressive enhancement is about robustness, being adaptable when the network fails to be perfect. Look at it this way, this __escaped_fragment__ is only supported by Google. No other search engine supports it. And considering that building it with progressive enhancement first, and then enhancing it with JavaScript, you get content that's indexable by any search engine, not just Google. The workload is the same, the complexity is the same, the only difference is the focus on progressive enhancement first rather than try to bolt a clearly less optimal solution later.

nkuttler 13y ago
At least Bing supports the hash fragment as well, but it looks like you have to enable it manually http://www.bing.com/blogs/webmaster/f/12248/p/671232/9669509.aspx http://www.bing.com/blogs/webmaster/f/12248/p/671232/9669509...

blauwbilgorgel 13y ago

It does make sense to me, because: - Not all search engines can handle JavaScript, Google is leading the way, but not perfect. - Those NoScript users could be potential clients or users of your site. I love it when my conversation rate goes up 1%, and that becomes harder when you ignore 1-5% of users. - Screenreaders generally do not support JavaScript [not true, see comment]. If only one blind user gets to access the content/design I created, then that is worth it to me. I am thinking as front-end engineer here, not as a business owner, where time is money. (Also depending on jurisdiction it may be against the law to be inaccessible). - Noscript users will likely bounce in large numbers when seeing just a blank page. Simply adding a <noscript> tag, explaining why you need JavaScript goes a long way. As a front-end engineer I go for maximum content accessibility. I don't meddle into the politics of things ("If we don't drop IE6 support, the web won't move forward!"). I totally understand the new landscape, where a lot of people have JavaScript on. Some web apps can not use progressive enhancement, because the JavaScript is core to the app. But for "static" content websites like these, it is certainly possible to make a website that is usable by most users, human and robot.

Isofarro 13y ago
"Screenreaders in generally do not support JavaScript." Please stop saying that. It hasn't been true for a good 5 years or so. * http://www.brucelawson.co.uk/2011/javascript-and-screenreaders/ http://www.brucelawson.co.uk/2011/javascript-and-screenreade... * http://webaim.org/projects/screenreadersurvey4/#javascript http://webaim.org/projects/screenreadersurvey4/#javascript * http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html http://www.w3.org/TR/WCAG20-TECHS/client-side-script.html
- blauwbilgorgel 13y ago
  Thank you! I've been behind the times. I'll start viewing it as a general accessibility issue, not specific to screen readers. But like Steve Klabnik commented, and from http://www.w3.org/WAI/intro/aria.php http://www.w3.org/WAI/intro/aria.php , there are a few more steps to take to make JavaScript enabled screen readers play nice: "WAI-ARIA addresses these accessibility challenges by defining how information about this functionality can be provided to assistive technology. With WAI-ARIA, an advanced Web application can be made accessible and usable to people with disabilities."

asdasf 13y ago

>it doesn't make much sense to support browsers with it disabled But that is exactly what you are doing anyways, you are just limiting it to googlebot for no reason.

Amadou 13y ago

Don't forget that javascript performance on mobile is abysmal. If your use of javascript is much more than light fluff, its going to seriously annoy mobile users. http://sealedabstract.com/rants/mobile-web-apps-are-slow/ http://sealedabstract.com/rants/mobile-web-apps-are-slow/

e12e 13y ago

> Honestly, with every worthwhile browser (both desktop and mobile) supporting JavaScript and having it enabled by default, it doesn't make much sense to support browsers with it disabled. Well, javascript support in w3m and lynx is still pretty poor. It makes it harder to easily get some content from offline reading using wget/curl. It does depend on what kind of site/app you're making. I'd say that if your main content is text, then requiring js makes no sense (especially if you're publishing some blog posts on configuring server software -- I might want do download that article to a headless server). I think most apps also benefit from an old school REST architecture, so that it is possible to eg: script your todo-app with curl to create a new todo-item without having to go through 3 pages of api-specs.