7 ms·

> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care ab

by baddox 11y ago

> Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website. Sure there is, if you care about interactivity, responsiveness, and general user experience. The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. You might as well say that not all potential clients have access to the Internet.

liviu- 11y ago
I think he means that it's best to offer both variants with a graceful fallback for no-js users. This doesn't require sacrificing interactivity, responsiveness or UX for users with JS enabled.
- baddox 11y ago
  It does, however, require a potentially large amount of work for a SPA. Granted, server-side rendering for JavaScript libraries like Ember and React is doable now.
- joepie91_ 11y ago
  "Graceful fallback" is what came before progressive enhancement, and is considered obsoleted for good reason. Graceful fallbacks tend to be maintained as a separate version, and neglected over time. Progressive enhancement means taking a basic page and adding snazzy functionality to it - eg. ajaxified page loads. The latter is what you want.
fred2133 11y ago
You should check your stats some time and see how many of your users fail to load your JS, rather than are capable of loading your JS. You might be surprised, especially if you have lots of mobile traffic.
- baddox 11y ago
  Just out of curiosity, what's the standard way to gather that data? I guess you could put a non-JS request (like an image) and a JS request (like XMLHttpRequest) on each page, and compare numbers.
  - liviu- 11y ago
    A `<noscript>` tag seems most intuitive to me, perhaps paired with some server-side Google Analytics.
- anantzoid 11y ago
  Also, most of the corporate people still have forced IE installed on their work laptops. SPAs do generally break in IE.
joepie91_ 11y ago
> Sure there is, if you care about interactivity, responsiveness, and general user experience. And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs. > The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. Your use of the term 'probably' suggests to me that you have not run any actual metrics. Here's a short list of some examples: - Bots and spiders - Low-powered mobile devices - Privacy-conscious users who use NoScript - Terminal-based browser users - Literally every single one of your users until the .js blob has completed downloading - ... Requiring JS for a website is not okay, end of story. We all collectively understood this 10 years ago, and I'm not really sure where along the way this understanding has gotten lost. EDIT: Forgot that HN has a neutered version of Markdown. Fixed.
- baddox 11y ago
  > Your use of the term 'probably' suggests to me that you have not run any actual metrics. What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. > Requiring JS for a website is not okay, end of story. It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story." > We all collectively understood this 10 years ago Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."
  - joepie91_ 11y ago
    > What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. I was refering specifically to websites, not webapps. > It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story." That analogy makes absolutely no sense, nor does your comparison to CSS. JS is an entirely different class of dependency than either CSS or web browsers. JS is turing-complete, has a significantly bigger attack surface (both in terms of vulnerabilities and in terms of tracking), is much, much harder to optimize for a low-powered device than HTML and CSS, and so on. Further, the web browser is a necessity to view something on the web. It is well understood, it is easy to optimize, and it is widely deployed. JS is no such 'required dependency' - and you should not make it one, when it can be done just fine without. > Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago." The support/compatibility landscape for JS has not changed in those 10 years. The types of non-JS clients are still the same, the reasons for progressive enhancement are still the same. The only thing that has changed is standardization. "Old" is not the same as "obsoleted". Unless you can come up with a concrete reason as to why this knowledge has been obsoleted throughout the past 10 years, it still applies. And I'm getting a little tired of these poorly fitting analogies, you're using them as a crutch.
jalfresi 11y ago
"if you care about interactivity, responsiveness, and general user experience" A simple web page (no-js) in a browser covers these three things to a highly acceptable standard. It's when you start to add the other junk that these three become compromised. For example: Interactivity: Hyperlinks work great from HTML 1.0 onwards Responsiveness: Without additional items like JavaScript or even CSS, web pages are incredibly responsive. General User Experience: The basic web page user experience is EXCELLENT for web pages because it is incredibly basic. Even date pickers can consist of 3 select drop downs (or even a text box; there are plenty of human-date-to-ISO-3306 convertors out there)
- jdscriven 11y ago
  What is ISO-3306?
  - shiggerino 11y ago
    He probably meant ISO 8601
  - jalfresi 11y ago
    LOL thats the mysql port! I'm an idiot

by baddox 11y ago

liviu- 11y ago

I think he means that it's best to offer both variants with a graceful fallback for no-js users. This doesn't require sacrificing interactivity, responsiveness or UX for users with JS enabled.

baddox 11y ago
It does, however, require a potentially large amount of work for a SPA. Granted, server-side rendering for JavaScript libraries like Ember and React is doable now.
joepie91_ 11y ago
"Graceful fallback" is what came before progressive enhancement, and is considered obsoleted for good reason. Graceful fallbacks tend to be maintained as a separate version, and neglected over time. Progressive enhancement means taking a basic page and adding snazzy functionality to it - eg. ajaxified page loads. The latter is what you want.

fred2133 11y ago

You should check your stats some time and see how many of your users fail to load your JS, rather than are capable of loading your JS. You might be surprised, especially if you have lots of mobile traffic.

baddox 11y ago
Just out of curiosity, what's the standard way to gather that data? I guess you could put a non-JS request (like an image) and a JS request (like XMLHttpRequest) on each page, and compare numbers.
- liviu- 11y ago
  A `<noscript>` tag seems most intuitive to me, perhaps paired with some server-side Google Analytics.
anantzoid 11y ago
Also, most of the corporate people still have forced IE installed on their work laptops. SPAs do generally break in IE.

joepie91_ 11y ago

> Sure there is, if you care about interactivity, responsiveness, and general user experience. And all of these can be provided just fine using progressive enhancement. This is _not_ an argument for SPAs. > The fact that not all potential clients support JS is probably irrelevant, since that number is probably incredibly small. Your use of the term 'probably' suggests to me that you have not run any actual metrics. Here's a short list of some examples: - Bots and spiders - Low-powered mobile devices - Privacy-conscious users who use NoScript - Terminal-based browser users - Literally every single one of your users until the .js blob has completed downloading - ... Requiring JS for a website is not okay, end of story. We all collectively understood this 10 years ago, and I'm not really sure where along the way this understanding has gotten lost. EDIT: Forgot that HN has a neutered version of Markdown. Fixed.

baddox 11y ago
> Your use of the term 'probably' suggests to me that you have not run any actual metrics. What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. > Requiring JS for a website is not okay, end of story. It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story." > We all collectively understood this 10 years ago Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago."
- joepie91_ 11y ago
  > What I really meant is that if you have a significant non-JS-supporting visitor base, you almost certainly already know it. There are a huge class of web apps that simply do not have to worry about it. If you know who your customers/visitors are then you should already know how important it is to support non-JS browsers. I was refering specifically to websites, not webapps. > It's really not the end of story, and it's not your call except for your own web apps. JavaScript is an integral part of the platform that is the web, just like HTML and CSS. You might as well make the argument that "requiring a web browser for your app is not okay, end of story." That analogy makes absolutely no sense, nor does your comparison to CSS. JS is an entirely different class of dependency than either CSS or web browsers. JS is turing-complete, has a significantly bigger attack surface (both in terms of vulnerabilities and in terms of tracking), is much, much harder to optimize for a low-powered device than HTML and CSS, and so on. Further, the web browser is a necessity to view something on the web. It is well understood, it is easy to optimize, and it is widely deployed. JS is no such 'required dependency' - and you should not make it one, when it can be done just fine without. > Things were a lot different 10 years ago, and perhaps your reluctance to update your understanding less than once per decade might explain some of your views. You may as well be saying "making a store than can only be accessed over the Internet is not okay, end of story, we all collectively understood this 25 years ago." The support/compatibility landscape for JS has not changed in those 10 years. The types of non-JS clients are still the same, the reasons for progressive enhancement are still the same. The only thing that has changed is standardization. "Old" is not the same as "obsoleted". Unless you can come up with a concrete reason as to why this knowledge has been obsoleted throughout the past 10 years, it still applies. And I'm getting a little tired of these poorly fitting analogies, you're using them as a crutch.

jalfresi 11y ago

"if you care about interactivity, responsiveness, and general user experience" A simple web page (no-js) in a browser covers these three things to a highly acceptable standard. It's when you start to add the other junk that these three become compromised. For example: Interactivity: Hyperlinks work great from HTML 1.0 onwards Responsiveness: Without additional items like JavaScript or even CSS, web pages are incredibly responsive. General User Experience: The basic web page user experience is EXCELLENT for web pages because it is incredibly basic. Even date pickers can consist of 3 select drop downs (or even a text box; there are plenty of human-date-to-ISO-3306 convertors out there)

jdscriven 11y ago
What is ISO-3306?
- shiggerino 11y ago
  He probably meant ISO 8601
- jalfresi 11y ago
  LOL thats the mysql port! I'm an idiot