4 ms·

Another option is to make a website that works without JavaScript. Only dynamically fetch pages when JavaScript is enabled. Progressive enhancement rocks. Visi

Another option is to make a website that works without JavaScript. Only dynamically fetch pages when JavaScript is enabled. Progressive enhancement rocks. Visiting http://monocle.io/posts/how-yield-will-transform-node http://monocle.io/posts/how-yield-will-transform-node without JavaScript support yields a blank page. All page titles are <title>Monocle</title> which isn't very descriptive and the meta description is the same for every page. Only with escaped_fragment can a user see descriptive page titles. For JavaScript users all pages are titled "Monocle". There are no unique content articles to rank nr. 1 for. The articles are all found on other sites. I don't really see Monocle rank 2 a lot (a quick glance). Those are reserved for other aggregating sites. The Google guidelines say: Make pages primarily for users, not for search engines. "Does this help my users? Would I do this if search engines didn't exist?" I'd extend that to JavaScript apps. Why make escaped_fragment especially for search engines, and then forget to offer this functionality for human users too?

maccman 13y ago
Hey, thanks for taking the time to comment. I certainly could make the titles more useful, in fact due to you suggestion I've just committed a fix to that. I'm interested though, why do you think it's useful for users to read meta descriptions? Or the raw text used by spiders? How does making this a pure JavaScript web app degrade the end-user's experience? I think I can effectively argue the opposite - that JS and client-side rendering makes for a much better experience.
- nkuttler 13y ago
  Having the same meta description on every page could lead to incorrect SERP snippets. See also https://support.google.com/webmasters/answer/35624?hl=en https://support.google.com/webmasters/answer/35624?hl=en Though such an obvious error is hopefully always ignored.
- rcsorensen 13y ago
  It's slower to first load and usable application on the client side. If we were to take two web apps, one using a rendr-style-render-on-server approach ( https://github.com/airbnb/rendr https://github.com/airbnb/rendr ), and one using a blank-html-bootstrap-through-js approach, the rendr-style app will win out for time-to-first interaction. To take a specific example, loading the monocle home page gives a base html time of 355ms for me. setup.js takes another 570ms. All told, it's an initial load of 355ms vs 970ms. Or "close to instant" vs "is something wrong? oh no, it's good".
- blauwbilgorgel 13y ago
  >why do you think it's useful for users to read meta descriptions? It isn't, really. I made a mistake and thought that every page (served to users and search engines) had the same title and description. A user is unlikely to read a meta description, unless he/she is on a search results page. >How does making this a pure JavaScript web app degrade the end-user's experience? NoScript users and special need users are unable to access your website's content. > JS and client-side rendering makes for a much better experience. Agreed. Progressive enhancement makes this possible and get the best of both worlds: Accessible content for NoScript users, spiffy JS rendering one page app for JavaScript users. RMS can even download your pages through Lynx. If you go pure JavaScript, you can at least add a <noscript> where you explain why you need JavaScript to enjoy this site.
  - 10dpd 13y ago
    > "special needs users are unable to access your sites content" Sorry I have to call you out on this, ignoring the use of the term "special needs", how could this possibly affect someone's use of JavaScript?
    - blauwbilgorgel 13y ago
      I don't understand your question. Is "special needs" a term I shouldn't use? I got it from Wikipedia/accessibility. [Accessibility] often focuses on people with disabilities or special needs.
JohnTHaller 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. 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.

maccman 13y ago

Hey, thanks for taking the time to comment. I certainly could make the titles more useful, in fact due to you suggestion I've just committed a fix to that. I'm interested though, why do you think it's useful for users to read meta descriptions? Or the raw text used by spiders? How does making this a pure JavaScript web app degrade the end-user's experience? I think I can effectively argue the opposite - that JS and client-side rendering makes for a much better experience.

nkuttler 13y ago
Having the same meta description on every page could lead to incorrect SERP snippets. See also https://support.google.com/webmasters/answer/35624?hl=en https://support.google.com/webmasters/answer/35624?hl=en Though such an obvious error is hopefully always ignored.
rcsorensen 13y ago
It's slower to first load and usable application on the client side. If we were to take two web apps, one using a rendr-style-render-on-server approach ( https://github.com/airbnb/rendr https://github.com/airbnb/rendr ), and one using a blank-html-bootstrap-through-js approach, the rendr-style app will win out for time-to-first interaction. To take a specific example, loading the monocle home page gives a base html time of 355ms for me. setup.js takes another 570ms. All told, it's an initial load of 355ms vs 970ms. Or "close to instant" vs "is something wrong? oh no, it's good".
blauwbilgorgel 13y ago
>why do you think it's useful for users to read meta descriptions? It isn't, really. I made a mistake and thought that every page (served to users and search engines) had the same title and description. A user is unlikely to read a meta description, unless he/she is on a search results page. >How does making this a pure JavaScript web app degrade the end-user's experience? NoScript users and special need users are unable to access your website's content. > JS and client-side rendering makes for a much better experience. Agreed. Progressive enhancement makes this possible and get the best of both worlds: Accessible content for NoScript users, spiffy JS rendering one page app for JavaScript users. RMS can even download your pages through Lynx. If you go pure JavaScript, you can at least add a <noscript> where you explain why you need JavaScript to enjoy this site.
- 10dpd 13y ago
  > "special needs users are unable to access your sites content" Sorry I have to call you out on this, ignoring the use of the term "special needs", how could this possibly affect someone's use of JavaScript?
  - blauwbilgorgel 13y ago
    I don't understand your question. Is "special needs" a term I shouldn't use? I got it from Wikipedia/accessibility. [Accessibility] often focuses on people with disabilities or special needs.

JohnTHaller 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. 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.