9 ms·

Everyone Has JavaScript, Right?

68 points by 0xedb 5y ago

habibur 5y ago
As the world has moved to HTTPS everywhere, ISPs injecting JS is a non-issue. They can't as they can't see what's in there. They can't even block JS. It's browser plugins right now -- the main snoopers.
- MereInterest 5y ago
  Depending on the browser plugin, they can be there to prevent snooping. Going to booking.com (chosen by percentile dice from list of top 100 websites), there were several snooping javascript downloads blocked by ublock origin, from google analytics, google ad services, and lms-analytics.
g_p 5y ago
An interesting blog post from the UK Government digital team on progressive enhancement, suggesting from their findings that 0.9% of visits to a national government site are from people without functioning JavaScript, who haven't intentionally turned it off. https://technology.blog.gov.uk/2016/09/19/why-we-use-progressive-enhancement-to-build-gov-uk/ https://technology.blog.gov.uk/2016/09/19/why-we-use-progres... And the original research is available at https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...
- Wowfunhappy 5y ago
  Their research was conducted in 2013, so I do wonder how applicable it is today. For example, as I recall Blackberries didn't support Javascript in most cases, and there were probably still a lot of those in active use as of 2013. Not so much in 2021.
  - rhdunn 5y ago
    I used lynx on a computer of mine a while ago when an upgrade broke the login. I could switch to a different terminal to do that, find the issue, then run the commands to fix it. I've also used the Raspberry Pi as a computer in the past and used Dillo (or similar browser) as it was lightweight.
    - Wowfunhappy 5y ago
      I don’t doubt that there are still plenty of users on browsers without Javascript (many of them here on HN), but I wonder if they would still constitute 0.9% of visits.
      - spookthesunset 5y ago
        Probably <0.1%. If you sorted your site traffic by visits per user agent, it probably would be lost in the long tail of noise.
        grayhatter 5y ago
        I mean if you consider your uncommon users noise, I kinda get why you wouldn't want to make any effort to support them.
  - jlokier 5y ago
    I encountered the "your ISP injects broken Javascript into all HTTP pages" problem around 2016. Someone thought I had done a poor job on a site I built for them. It turned out the Javascript on the page wasn't from the site I built, it was injected by the ISP, one of the UK's largest mobile data providers. We fixed the problem by switching to HTTPS.
ClearAndPresent 5y ago
When I see on an empty white page: > You need to enable JavaScript to run this app. I know I have no interest in your project as you have no interest in communicating with me, only funnelling me into your recently launched startup.
Wowfunhappy 5y ago
Hm, this makes me think about my personal website, which uses a fancy Javascript fade-in because I like fancy animations (and the site is partly my playground to do what I want). However, I also have a noscript stylesheet to ensure the website is functional without Javascript. Does anyone know what that means for e.g. flaky mobile browsers?
- lexicality 5y ago
  <noscript> is only activated if JS is actively disabled. None of these failure modes will trigger it. You can use onerror="foo" on <script> tags though EDIT: Actually the data saver thing is called "noscript" so you'd hope it'd activate the tags. Network failures though will trigger onerror and leave the rest up to you
towb 5y ago
"Have they switched off JavaScript? - People still do." Is that really a valid case 2021?
- hookem2019 5y ago
  I agree with you, this shouldn’t even be an issue in 2021.
- fragileone 5y ago
  Yes - see the popularity of uBlock Origin, NoScript, uMatrix etc.
  - krono 5y ago
    Neither uBlock or uMatrix blanket disable JavaScript.
    - smichel17 5y ago
      My uMatrix config does :P
    - grayhatter 5y ago
      but being able to disable it is the whole point of installing it and it does disable third-party by default.
      - krono 5y ago
        I know they have the capability to block scripts, but this is the first time I'm hearing that blocking all javascript on all websites is the primary purpose of both uBlock and uMatrix. Their strength is in selective and goal-oriented blocking, in a way that doesn't break nearly every website by default.
  - ceejayoz 5y ago
    HN may be giving a skewed idea of how truly popular things like NoScript are.
k__ 5y ago
I'm thinking a lot about this while planning a frontend architecture for my new project. Currently, I'm checking out Cloudflare Workers. They're compatible with service workers, so they might be a viable fallback solution for people without JS.
- BillinghamJ 5y ago
  I've been hearing that the Jamstack type approach, along with a supporting CDN like Netlify can achieve this pretty well. No experience actually putting into practice yet though
xet7 5y ago
Is it possible, without Javascript, to have: - drag drop reorder and move? - accessibility? - draw on top of webpage? - popup menus? - show/hide sidebar? Any links for examples?
- vereis 5y ago
  Popup menus, sidebars, drawing on top of a pages can all be done to a certain extent with some CSS Accessibility is possible with standard semantic HTML and aria tags (again to a certain extent) D&D is probably not workable though
- devit 5y ago
  1. Probably not in general? Maybe with a vertical <input type="range"> for each item and a lot of server-generated CSS hackery, for small lists? 2. Use ARIA 3. Use position: absolute? 4. Create it with position: absolute/relative and use CSS :hover selector to show it (or see #5 for explicit open/close) 5. Use <details> or a checkbox along with the appropriate CSS
- Zealotux 5y ago
  >accessibility? HTML is pretty accessible by itself, simply follow the standard and WAI-ARIA. >popup menus? https://www.w3schools.com/howto/howto_css_dropdown.asp https://www.w3schools.com/howto/howto_css_dropdown.asp >show/hide sidebar? You can use the checkbox way to handle that: https://codepen.io/Sfate/pen/nLBGr https://codepen.io/Sfate/pen/nLBGr The rest isn't really possible without JS as far as I know.
  - no_way 5y ago
    That popup menu is not accessible though, no keyboard navigation and if you really wanted follow all accessibility guidelines you still need javascript to toggle attributes and stuff. https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-links.html https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-b...
    - eldelshell 5y ago
throwaway284534 5y ago
These people march into every JavaScript discussion, carrying the same cross on their back since the first day Netscape supported AJAX. They lament what a travesty the internet has become thanks to this mongrel language which broke the purity of HTML. What really gets me is this kind of Good Samaritan plea to developers to just “do the right thing” as if every line of JavaScript was paid in orphan tears and puppy blood. It’s 2021 and at this point it really feels like they’re begging the question: “Sites that require JavaScript are not as good as sites that don’t because they can’t operate without JavaScript.” We already know that. It’s well understood what makes a site feel slow. Progressive enhancement is an ideal situation — it’s just not something that every organization prioritizes. And for some web apps, server side rendering adds significant overhead to problems like caching, authentication, and multi platform compatibility. If you’re honestly invested in progressive enhancement, contribute to open source tools that make it easier to ship.
- simonw 5y ago
  The author of this piece has been working to help people implement progressive enhancement for nearly two decades now.
  - throwaway284534 5y ago
    I think we can agree that the author is genuinely interested in the problem. Personally, it’s exhausting to hear what I believe are the same people ask web developers to build with competing constraints at the same time. A good website must be… - Renderable to both modern and older browsers - Designed for mobile and desktop screens - Accessible to those with disabilities - Supporting some level of offline web app use, ideally avoiding a platform specific App Store There’s all of that and more, but it’s not is impossible. In fact, requirements like accessibility are often mandated by law. But if I was building a new product, I’d honestly prefer a smaller set of JS friendly customers that I can serve a great experience to, and go from there. Progressive enhancement usually runs opposite to this issue. It’s very time consuming and adds an additional platform complexity to your existing technical product problems.
axiosgunnar 5y ago
Nice list of rare edge cases. Worrying about somebody using „Chrome data saver mode“ before your startup gets 100k hits per month means to me that your focus is completely off. Instead, perhaps improve your core product and talk to actual users today?
- grayhatter 5y ago
  You know I want to saw a video where Linus Torvalds describes good code as code that doesn't have to handle edge cases differently from non-edge cases. HTML will always render, so why isn't that always the minimum default? why is starting with HTML and adding JavaScript harder?
  - axiosgunnar 5y ago
    Feel free to try to tick all the UX best practices from Nielsen Norman with pure HTML, and be done by the end of this week since we would like to ship. See where the problem is?
    - grayhatter 5y ago
      > See where the problem is? No, I don't. In part because I don't tick boxes, I just (try to) build good shit. Also because I don't expect every UX "best practice" from [random internet authority] from a site with JS disabled. I just expect the text on the site to render somewhere readable. Usually, the argument from the "js is bad" crowd, isn't that the site should be as functional with JS disabled... only... that the basic content... should still render...
      - axiosgunnar 5y ago
        You are 0.001% of my visitors and any rational business will refuse to invest resources to serve your unique needs. If my current frontend framework of choice happens to not render any HTML without JS, I am sorry, my site will be inaccessible to you. Because that frontend framework allows me to iterate much faster and improve my product for the vast majority of users.
leesalminen 5y ago
TFA itself concedes that we’re (generously) talking about 1% of users. Until you’re in 6-digit MRR territory, this shouldn’t even cross your mind when building a Web app. There are way more important things you should be doing to your product/business.
kissgyorgy 5y ago
I don't see NUMBERS attached to the claims.
tsegratis 5y ago
> It’s only natural that as front-end developers we want to flex our technical skills... There’s an issue with lending more of your focus to the possibilities promised by new technology though: your focus moves away from your users. > Meeting our many users’ needs is number one on our list of design principles.
iamsaitam 5y ago
The people that disable Javascript are missing a whole world of interactive applications. Not every website wants to track you down and share that information with Google.
- Nicksil 5y ago
  >The people that disable Javascript are missing a whole world of interactive applications. What? Interactive applications came way before the Web and JavaScript. Interactive applications currently exist outside of the Web and these same applications may not have been built using JavaScript.
- dredmorbius 5y ago
  The people who disable JS: - May still want to see the noninteractive element of that application. We call those "documents". - May selectively choose to enable JS in specific cases where utility outweighs other factors. But JS dependence impedes on that case.
tzs 5y ago
JavaScript kind of creeps up on you. I don't work on any web pages that are particularly fancy or sophisticated. The main page I work on is the ordering page I maintain (but did not write) for a small company. Their product is pretty simple--a subscription service with some downloadable software to use the service. The ordering page has a section where you can select your subscription length (monthly, quarterly, yearly) with some radio buttons and a checkbox for buying a copy of the software on CD-ROM, a section for entering your email address and billing address, a section for entering your credit card information, and a button to submit your order. They really want to keep this as one page. Originally I'm pretty sure they had no JavaScript on the page. That was back when we didn't have to collect sales tax except to customers in our own state, and before the state's tax laws made online sales based on buyer location rather than seller location. The checkout page simply showed your total without tax, and had a note that said if you were in our state we would add tax of X% where X was the sales tax at our office. Later, when the state switched to buyer based taxing, I believe JavaScript was added. That message about taxes started off just saying tax would be added to in-state orders without stating the rate. When you filled in the zip code, the JavaScript would see if it was an in-state zip code and update that to mention the rate for that zip (which it got from a static table in the JS). It might have even been fancy enough to also show you the total. But if you did not have JavaScript it still all worked. Somewhere in there the JavaScript started doing checks for things like missing form entries and blocking submission until the user fixed them. Still worked without JavaScript. When we started selling in Europe and the UK and had to collect VAT, the JavaScript got a little fancier. Now it knew the VAT rates by country so it could show the VAT before you ordered. The PHP script that served the page would decide what currency you probably used based on your IP. I modified that to include a dynamically generated JavaScript table on the page that had the prices of all the products on the page in USD, EUR, and GPB, added a currency select dropdown on the page, and added JavaScript to switch all the prices and totals on the page if the user changed the currency. But it still worked fine without JavaScript. You might see the prices listed in EUR say, and switch the dropdown to GPB, and your order would then be done in GBP using the GBP pricing. You just wouldn't see the actual GBP amounts until you got the receipt page. What finally stopped it working without JavaScript was a change Visa and MasterCard (and I think some others) made to what merchants have to do when accepting credit card and when storing cards for recurring or on-file billing [1]. You must show the total that will be charged and get approval from the user before submitting the card. You must tell them how often they will be re-billed and for how much. You must tell them what card will be billed (and re-billed). You must get positive confirmation that they have seen this information. For that, we added a section at the bottom of the page that spells all that out, and has a checkbox they have to check to confirm they saw it. The ordering button does not work until that checkbox is checked. As the user changes what products are selected, JavaScript is updating the total in the order summary, and updating that disclosure section at the bottom of the page. Same as they change currency. If they changed address, the JavaScript calls a tax API on the server to find the tax, and updates the page. Same if they change the credit card information. The JavaScript unchecks the acknowledgement checkbox if they make any of these kinds of changes after they acknowledged before. Making that work without JavaScript would, I think, require going to a multi-page order flow which management really does not want to do. I've done some measurements, and everyone who has tried to order over the last two years (both real and bots up to who knows what) have had JavaScript enabled so it is pretty hard to argue that adding a separate milti-page order flow to handle non-JS people is worth the development time. And so now we've got a page that requires JavaScript. No one set out to require JavaScript, but here we are. [1] Well...they said they were making this change. They originally announced it, then when it was close to going into effect many payment processors said they weren't ready and Visa pushed it back a year. The payment processor we use got it supported by that second deadline, and we got our site and backend changed, but others were still not ready and Visa delayed it again. I'm not actually sure if it ever went into effect or is still being pushed back.
dredmorbius 5y ago
Not all HTTP consumers are interactive web browsers. Web scraping may not be your value proposition (or you may not think it is), but it could very well be your users'. And yes, I'm that small but vocal minority that makes use of console browsers, wget and curl, and heavily disables JS in my graphical browsers for numerous reasons. Gratuitous breakage is utterly unnecessary, and that's the point. Not that you cannot use JS, but that functionality which is independent of JS should be supported, when JS is disabled. Everything else misses the damned point.

68 points by 0xedb 5y ago

As the world has moved to HTTPS everywhere, ISPs injecting JS is a non-issue. They can't as they can't see what's in there. They can't even block JS. It's browser plugins right now -- the main snoopers.

MereInterest 5y ago
Depending on the browser plugin, they can be there to prevent snooping. Going to booking.com (chosen by percentile dice from list of top 100 websites), there were several snooping javascript downloads blocked by ublock origin, from google analytics, google ad services, and lms-analytics.

g_p 5y ago

An interesting blog post from the UK Government digital team on progressive enhancement, suggesting from their findings that 0.9% of visits to a national government site are from people without functioning JavaScript, who haven't intentionally turned it off. https://technology.blog.gov.uk/2016/09/19/why-we-use-progressive-enhancement-to-build-gov-uk/ https://technology.blog.gov.uk/2016/09/19/why-we-use-progres... And the original research is available at https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missing-out-on-javascript-enhancement/ https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi...

Wowfunhappy 5y ago
Their research was conducted in 2013, so I do wonder how applicable it is today. For example, as I recall Blackberries didn't support Javascript in most cases, and there were probably still a lot of those in active use as of 2013. Not so much in 2021.
- rhdunn 5y ago
  I used lynx on a computer of mine a while ago when an upgrade broke the login. I could switch to a different terminal to do that, find the issue, then run the commands to fix it. I've also used the Raspberry Pi as a computer in the past and used Dillo (or similar browser) as it was lightweight.
  - Wowfunhappy 5y ago
    I don’t doubt that there are still plenty of users on browsers without Javascript (many of them here on HN), but I wonder if they would still constitute 0.9% of visits.
    - spookthesunset 5y ago
      Probably <0.1%. If you sorted your site traffic by visits per user agent, it probably would be lost in the long tail of noise.
      - grayhatter 5y ago
        I mean if you consider your uncommon users noise, I kinda get why you wouldn't want to make any effort to support them.
- jlokier 5y ago
  I encountered the "your ISP injects broken Javascript into all HTTP pages" problem around 2016. Someone thought I had done a poor job on a site I built for them. It turned out the Javascript on the page wasn't from the site I built, it was injected by the ISP, one of the UK's largest mobile data providers. We fixed the problem by switching to HTTPS.

ClearAndPresent 5y ago

When I see on an empty white page: > You need to enable JavaScript to run this app. I know I have no interest in your project as you have no interest in communicating with me, only funnelling me into your recently launched startup.

Wowfunhappy 5y ago

Hm, this makes me think about my personal website, which uses a fancy Javascript fade-in because I like fancy animations (and the site is partly my playground to do what I want). However, I also have a noscript stylesheet to ensure the website is functional without Javascript. Does anyone know what that means for e.g. flaky mobile browsers?

lexicality 5y ago
<noscript> is only activated if JS is actively disabled. None of these failure modes will trigger it. You can use onerror="foo" on <script> tags though EDIT: Actually the data saver thing is called "noscript" so you'd hope it'd activate the tags. Network failures though will trigger onerror and leave the rest up to you

towb 5y ago

"Have they switched off JavaScript? - People still do." Is that really a valid case 2021?

hookem2019 5y ago
I agree with you, this shouldn’t even be an issue in 2021.
fragileone 5y ago
Yes - see the popularity of uBlock Origin, NoScript, uMatrix etc.
- krono 5y ago
  Neither uBlock or uMatrix blanket disable JavaScript.
  - smichel17 5y ago
    My uMatrix config does :P
  - grayhatter 5y ago
    but being able to disable it is the whole point of installing it and it does disable third-party by default.
    - krono 5y ago
      I know they have the capability to block scripts, but this is the first time I'm hearing that blocking all javascript on all websites is the primary purpose of both uBlock and uMatrix. Their strength is in selective and goal-oriented blocking, in a way that doesn't break nearly every website by default.
- ceejayoz 5y ago
  HN may be giving a skewed idea of how truly popular things like NoScript are.

k__ 5y ago

I'm thinking a lot about this while planning a frontend architecture for my new project. Currently, I'm checking out Cloudflare Workers. They're compatible with service workers, so they might be a viable fallback solution for people without JS.

BillinghamJ 5y ago
I've been hearing that the Jamstack type approach, along with a supporting CDN like Netlify can achieve this pretty well. No experience actually putting into practice yet though

xet7 5y ago

Is it possible, without Javascript, to have: - drag drop reorder and move? - accessibility? - draw on top of webpage? - popup menus? - show/hide sidebar? Any links for examples?

vereis 5y ago
Popup menus, sidebars, drawing on top of a pages can all be done to a certain extent with some CSS Accessibility is possible with standard semantic HTML and aria tags (again to a certain extent) D&D is probably not workable though
devit 5y ago
1. Probably not in general? Maybe with a vertical <input type="range"> for each item and a lot of server-generated CSS hackery, for small lists? 2. Use ARIA 3. Use position: absolute? 4. Create it with position: absolute/relative and use CSS :hover selector to show it (or see #5 for explicit open/close) 5. Use <details> or a checkbox along with the appropriate CSS
Zealotux 5y ago
>accessibility? HTML is pretty accessible by itself, simply follow the standard and WAI-ARIA. >popup menus? https://www.w3schools.com/howto/howto_css_dropdown.asp https://www.w3schools.com/howto/howto_css_dropdown.asp >show/hide sidebar? You can use the checkbox way to handle that: https://codepen.io/Sfate/pen/nLBGr https://codepen.io/Sfate/pen/nLBGr The rest isn't really possible without JS as far as I know.
- no_way 5y ago
  That popup menu is not accessible though, no keyboard navigation and if you really wanted follow all accessibility guidelines you still need javascript to toggle attributes and stuff. https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-button/menu-button-links.html https://www.w3.org/TR/wai-aria-practices-1.1/examples/menu-b...
  - eldelshell 5y ago

throwaway284534 5y ago

These people march into every JavaScript discussion, carrying the same cross on their back since the first day Netscape supported AJAX. They lament what a travesty the internet has become thanks to this mongrel language which broke the purity of HTML. What really gets me is this kind of Good Samaritan plea to developers to just “do the right thing” as if every line of JavaScript was paid in orphan tears and puppy blood. It’s 2021 and at this point it really feels like they’re begging the question: “Sites that require JavaScript are not as good as sites that don’t because they can’t operate without JavaScript.” We already know that. It’s well understood what makes a site feel slow. Progressive enhancement is an ideal situation — it’s just not something that every organization prioritizes. And for some web apps, server side rendering adds significant overhead to problems like caching, authentication, and multi platform compatibility. If you’re honestly invested in progressive enhancement, contribute to open source tools that make it easier to ship.

simonw 5y ago
The author of this piece has been working to help people implement progressive enhancement for nearly two decades now.
- throwaway284534 5y ago
  I think we can agree that the author is genuinely interested in the problem. Personally, it’s exhausting to hear what I believe are the same people ask web developers to build with competing constraints at the same time. A good website must be… - Renderable to both modern and older browsers - Designed for mobile and desktop screens - Accessible to those with disabilities - Supporting some level of offline web app use, ideally avoiding a platform specific App Store There’s all of that and more, but it’s not is impossible. In fact, requirements like accessibility are often mandated by law. But if I was building a new product, I’d honestly prefer a smaller set of JS friendly customers that I can serve a great experience to, and go from there. Progressive enhancement usually runs opposite to this issue. It’s very time consuming and adds an additional platform complexity to your existing technical product problems.

axiosgunnar 5y ago

Nice list of rare edge cases. Worrying about somebody using „Chrome data saver mode“ before your startup gets 100k hits per month means to me that your focus is completely off. Instead, perhaps improve your core product and talk to actual users today?

grayhatter 5y ago
You know I want to saw a video where Linus Torvalds describes good code as code that doesn't have to handle edge cases differently from non-edge cases. HTML will always render, so why isn't that always the minimum default? why is starting with HTML and adding JavaScript harder?
- axiosgunnar 5y ago
  Feel free to try to tick all the UX best practices from Nielsen Norman with pure HTML, and be done by the end of this week since we would like to ship. See where the problem is?
  - grayhatter 5y ago
    > See where the problem is? No, I don't. In part because I don't tick boxes, I just (try to) build good shit. Also because I don't expect every UX "best practice" from [random internet authority] from a site with JS disabled. I just expect the text on the site to render somewhere readable. Usually, the argument from the "js is bad" crowd, isn't that the site should be as functional with JS disabled... only... that the basic content... should still render...
    - axiosgunnar 5y ago
      You are 0.001% of my visitors and any rational business will refuse to invest resources to serve your unique needs. If my current frontend framework of choice happens to not render any HTML without JS, I am sorry, my site will be inaccessible to you. Because that frontend framework allows me to iterate much faster and improve my product for the vast majority of users.

leesalminen 5y ago

TFA itself concedes that we’re (generously) talking about 1% of users. Until you’re in 6-digit MRR territory, this shouldn’t even cross your mind when building a Web app. There are way more important things you should be doing to your product/business.

kissgyorgy 5y ago

I don't see NUMBERS attached to the claims.

tsegratis 5y ago

> It’s only natural that as front-end developers we want to flex our technical skills... There’s an issue with lending more of your focus to the possibilities promised by new technology though: your focus moves away from your users. > Meeting our many users’ needs is number one on our list of design principles.

iamsaitam 5y ago

The people that disable Javascript are missing a whole world of interactive applications. Not every website wants to track you down and share that information with Google.

Nicksil 5y ago
>The people that disable Javascript are missing a whole world of interactive applications. What? Interactive applications came way before the Web and JavaScript. Interactive applications currently exist outside of the Web and these same applications may not have been built using JavaScript.
dredmorbius 5y ago
The people who disable JS: - May still want to see the noninteractive element of that application. We call those "documents". - May selectively choose to enable JS in specific cases where utility outweighs other factors. But JS dependence impedes on that case.

tzs 5y ago

JavaScript kind of creeps up on you. I don't work on any web pages that are particularly fancy or sophisticated. The main page I work on is the ordering page I maintain (but did not write) for a small company. Their product is pretty simple--a subscription service with some downloadable software to use the service. The ordering page has a section where you can select your subscription length (monthly, quarterly, yearly) with some radio buttons and a checkbox for buying a copy of the software on CD-ROM, a section for entering your email address and billing address, a section for entering your credit card information, and a button to submit your order. They really want to keep this as one page. Originally I'm pretty sure they had no JavaScript on the page. That was back when we didn't have to collect sales tax except to customers in our own state, and before the state's tax laws made online sales based on buyer location rather than seller location. The checkout page simply showed your total without tax, and had a note that said if you were in our state we would add tax of X% where X was the sales tax at our office. Later, when the state switched to buyer based taxing, I believe JavaScript was added. That message about taxes started off just saying tax would be added to in-state orders without stating the rate. When you filled in the zip code, the JavaScript would see if it was an in-state zip code and update that to mention the rate for that zip (which it got from a static table in the JS). It might have even been fancy enough to also show you the total. But if you did not have JavaScript it still all worked. Somewhere in there the JavaScript started doing checks for things like missing form entries and blocking submission until the user fixed them. Still worked without JavaScript. When we started selling in Europe and the UK and had to collect VAT, the JavaScript got a little fancier. Now it knew the VAT rates by country so it could show the VAT before you ordered. The PHP script that served the page would decide what currency you probably used based on your IP. I modified that to include a dynamically generated JavaScript table on the page that had the prices of all the products on the page in USD, EUR, and GPB, added a currency select dropdown on the page, and added JavaScript to switch all the prices and totals on the page if the user changed the currency. But it still worked fine without JavaScript. You might see the prices listed in EUR say, and switch the dropdown to GPB, and your order would then be done in GBP using the GBP pricing. You just wouldn't see the actual GBP amounts until you got the receipt page. What finally stopped it working without JavaScript was a change Visa and MasterCard (and I think some others) made to what merchants have to do when accepting credit card and when storing cards for recurring or on-file billing [1]. You must show the total that will be charged and get approval from the user before submitting the card. You must tell them how often they will be re-billed and for how much. You must tell them what card will be billed (and re-billed). You must get positive confirmation that they have seen this information. For that, we added a section at the bottom of the page that spells all that out, and has a checkbox they have to check to confirm they saw it. The ordering button does not work until that checkbox is checked. As the user changes what products are selected, JavaScript is updating the total in the order summary, and updating that disclosure section at the bottom of the page. Same as they change currency. If they changed address, the JavaScript calls a tax API on the server to find the tax, and updates the page. Same if they change the credit card information. The JavaScript unchecks the acknowledgement checkbox if they make any of these kinds of changes after they acknowledged before. Making that work without JavaScript would, I think, require going to a multi-page order flow which management really does not want to do. I've done some measurements, and everyone who has tried to order over the last two years (both real and bots up to who knows what) have had JavaScript enabled so it is pretty hard to argue that adding a separate milti-page order flow to handle non-JS people is worth the development time. And so now we've got a page that requires JavaScript. No one set out to require JavaScript, but here we are. [1] Well...they said they were making this change. They originally announced it, then when it was close to going into effect many payment processors said they weren't ready and Visa pushed it back a year. The payment processor we use got it supported by that second deadline, and we got our site and backend changed, but others were still not ready and Visa delayed it again. I'm not actually sure if it ever went into effect or is still being pushed back.

dredmorbius 5y ago

Not all HTTP consumers are interactive web browsers. Web scraping may not be your value proposition (or you may not think it is), but it could very well be your users'. And yes, I'm that small but vocal minority that makes use of console browsers, wget and curl, and heavily disables JS in my graphical browsers for numerous reasons. Gratuitous breakage is utterly unnecessary, and that's the point. Not that you cannot use JS, but that functionality which is independent of JS should be supported, when JS is disabled. Everything else misses the damned point.