5 ms·

It does make development easier, and at some point it just doesn't make sense to support any longer. If the number of people who visit your site with JavaScrip

It does make development easier, and at some point it just doesn't make sense to support any longer. If the number of people who visit your site with JavaScript disabled is less than the number of people who visit using the Opera browser, does it really make sense to add [number of supported browsers] x [JS on | JS off] permutations to your testing workload? Is spending the time and resources on creating a non-JS site worth it, or would it better spent somewhere else (usability, accessibility, etc.)? Everything is a trade-off. I personally feel the JS ship has long sailed. I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome. That is definitely a bit sad.

zeveb 8y ago
> It does make development easier, and at some point it just doesn't make sense to support any longer. It depends on what you're doing. If you're building an app (something which would make more sense as a native program anyway), then sure — use JavaScript. But if you're displaying text and images, then HTML & CSS are perfectly capable of handling that. In general, I think that a good content-focused website will work equally well across all browsers. There's no need to force end-users to allow you to execute code on their machines in order to display paragraphs or images. > I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome. And I'm worried about the long-standing trend of sites not even working in lynx, links, elinks, eww or w3m anymore, just Firefox, Chrome & IE.
- ocfx 8y ago
  Such a small minority use lynx or links, why even bring it up, they don't matter. A business isn't going to spend money so their app renders properly in a text based web client that nobody will access their site with.
- pishpash 8y ago
  Worse, some sites don't even work for pdf-print any more.
reificator 8y ago
> If the number of people who visit your site with JavaScript disabled is less than the number of people who visit using the Opera browser, does it really make sense to add [number of supported browsers] x [JS on | JS off] permutations to your testing workload? If your site doesn't work for people with JS disabled, you're unlikely to see significant traffic from people with JS disabled.
- TeMPOraL 8y ago
  Also, if you use JavaScript trackers instead of server logs, guess which group won't show on those trackers at all...
  - scient 8y ago
    Most trackers have a way to handle non-JS clients by rendering a tracking pixel - a solution that has been out there for a long time now.
    - dredmorbius 8y ago
      The anti-JS crowd also tends to block tracking pixels. E.g., New Relic's tracking beacon.
    - etatoby 8y ago
      Last time I checked, the default embed code provided by Google Analytics (which covers 99% of website stats) was a single script tag.
- NetOpWibby 8y ago
  I just launched a product last week that solves this very use case (for Express apps): https://chew.sh https://chew.sh. It is VERY much an alpha and a lot of things aren’t working, just the bare minimum.
  - etatoby 8y ago
    > requires JavaScript, please enable it to ensure a joyful browsing experience (followed by some horribly formatted content, at least on my phone) Guess which product I will not be buying today?
godzillabrennus 8y ago
Firefox was amazing tech that changed how many of us used the web. Competition is good for the web. Hopefully they take back market share.
c22 8y ago
> Is spending the time and resources on creating a non-JS site worth it, or would it better spent somewhere else (usability, accessibility, etc.)? Even a naive approach to making a javascript-rich site render with JS turned off will have profound positive impacts on usability and accessibility, so I'd say it's still worth it.
romaniv 8y ago
> Is spending the time and resources on creating a non-JS site worth it Comments like these make me wonder if any of the people saying PE is hard ever tried it at all. The whole point of progressive enhancement is that you don't create a separate non-JS website.
- NoGravitas 8y ago
  Of course they haven't tried it. Some thought leader told them PE was dead (or smelled funny), so they were able to write it off and go ahead with what they wanted to do anyway.
- ergothus 8y ago
  I do not understand your comment. Progressive Enhancement (and I've done it) has a lot going for it, but "easier" or "as easy" isn't the case. Thus time and resources are spent to get the same functionality. Example: I make a form. It works without JS, so my server has to generate the form, handle the request where the form is submitted, and generate the result HTML. If I'm practicing good separation of concerns, the work is done in a service/contained library that the webserver code calls and assembles into a page. Then I go to add a "nice" Js experience: disable the normal form submit, read the form data, send the request, parse what I need out of the HTML result ("parse" = easy cut here) and replace the portion of the DOM involved. A nice, maintainable PE site. Nothing wrong with that. But if I have the server generate the original page only, I can have JS read the form, call the service, and update the DOM. I was able to completely skip the server composing a new page. And that's for a bone-simple form, if my site has any interaction on that form before submit, each step represents duplicated effort. Checking if a name is already used? JS to call a service and add a line. Server/service absolutely needs to check that, but if we're not worrying about PE we can completely skip worrying about a nice UI generated on the server-side (which would involve re-populating the form we got, so it's not just "same HTML + one line"). And that's still the stupid-simple stuff. To do this I need to design the application w/o JS and then find nice ways to improve it. But my designers, my PMs, they are all thinking from a JS-first point of view, so without PE when they say "do X" I can do X. With PE when they say "do X" I need to figure out how to do Y (a flow they didn't consider at all), and make sure it can behave like X. Anywhere it's hard to do so, it's on me to fix that because neither design nor business consider PE remotely important or valuable. PE is great, and I'd love to work on more sites that use it...but I'll confess I rarely put forth the effort myself, even when I do have the space to do so in a project. Because Progressive Enhancement IS effort (most importantly time), effort that will most likely be seen by a single digit number of users and I've got a lot of stuff I want to do and a lot I need to do. Even a free hour can improve my productivity or quality for far more users if I spend it in something other than PE. PE has very real benefits beyond just working without JS...but even those benefits rarely outweigh the time/effort costs in an industry where there's always far more work than time.

zeveb 8y ago

> It does make development easier, and at some point it just doesn't make sense to support any longer. It depends on what you're doing. If you're building an app (something which would make more sense as a native program anyway), then sure — use JavaScript. But if you're displaying text and images, then HTML & CSS are perfectly capable of handling that. In general, I think that a good content-focused website will work equally well across all browsers. There's no need to force end-users to allow you to execute code on their machines in order to display paragraphs or images. > I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome. And I'm worried about the long-standing trend of sites not even working in lynx, links, elinks, eww or w3m anymore, just Firefox, Chrome & IE.

ocfx 8y ago
Such a small minority use lynx or links, why even bring it up, they don't matter. A business isn't going to spend money so their app renders properly in a text based web client that nobody will access their site with.
pishpash 8y ago
Worse, some sites don't even work for pdf-print any more.

reificator 8y ago

> If the number of people who visit your site with JavaScript disabled is less than the number of people who visit using the Opera browser, does it really make sense to add [number of supported browsers] x [JS on | JS off] permutations to your testing workload? If your site doesn't work for people with JS disabled, you're unlikely to see significant traffic from people with JS disabled.

TeMPOraL 8y ago
Also, if you use JavaScript trackers instead of server logs, guess which group won't show on those trackers at all...
- scient 8y ago
  Most trackers have a way to handle non-JS clients by rendering a tracking pixel - a solution that has been out there for a long time now.
  - dredmorbius 8y ago
    The anti-JS crowd also tends to block tracking pixels. E.g., New Relic's tracking beacon.
  - etatoby 8y ago
    Last time I checked, the default embed code provided by Google Analytics (which covers 99% of website stats) was a single script tag.
NetOpWibby 8y ago
I just launched a product last week that solves this very use case (for Express apps): https://chew.sh https://chew.sh. It is VERY much an alpha and a lot of things aren’t working, just the bare minimum.
- etatoby 8y ago
  > requires JavaScript, please enable it to ensure a joyful browsing experience (followed by some horribly formatted content, at least on my phone) Guess which product I will not be buying today?

godzillabrennus 8y ago

Firefox was amazing tech that changed how many of us used the web. Competition is good for the web. Hopefully they take back market share.

c22 8y ago

> Is spending the time and resources on creating a non-JS site worth it, or would it better spent somewhere else (usability, accessibility, etc.)? Even a naive approach to making a javascript-rich site render with JS turned off will have profound positive impacts on usability and accessibility, so I'd say it's still worth it.

romaniv 8y ago

> Is spending the time and resources on creating a non-JS site worth it Comments like these make me wonder if any of the people saying PE is hard ever tried it at all. The whole point of progressive enhancement is that you don't create a separate non-JS website.

NoGravitas 8y ago
Of course they haven't tried it. Some thought leader told them PE was dead (or smelled funny), so they were able to write it off and go ahead with what they wanted to do anyway.
ergothus 8y ago
I do not understand your comment. Progressive Enhancement (and I've done it) has a lot going for it, but "easier" or "as easy" isn't the case. Thus time and resources are spent to get the same functionality. Example: I make a form. It works without JS, so my server has to generate the form, handle the request where the form is submitted, and generate the result HTML. If I'm practicing good separation of concerns, the work is done in a service/contained library that the webserver code calls and assembles into a page. Then I go to add a "nice" Js experience: disable the normal form submit, read the form data, send the request, parse what I need out of the HTML result ("parse" = easy cut here) and replace the portion of the DOM involved. A nice, maintainable PE site. Nothing wrong with that. But if I have the server generate the original page only, I can have JS read the form, call the service, and update the DOM. I was able to completely skip the server composing a new page. And that's for a bone-simple form, if my site has any interaction on that form before submit, each step represents duplicated effort. Checking if a name is already used? JS to call a service and add a line. Server/service absolutely needs to check that, but if we're not worrying about PE we can completely skip worrying about a nice UI generated on the server-side (which would involve re-populating the form we got, so it's not just "same HTML + one line"). And that's still the stupid-simple stuff. To do this I need to design the application w/o JS and then find nice ways to improve it. But my designers, my PMs, they are all thinking from a JS-first point of view, so without PE when they say "do X" I can do X. With PE when they say "do X" I need to figure out how to do Y (a flow they didn't consider at all), and make sure it can behave like X. Anywhere it's hard to do so, it's on me to fix that because neither design nor business consider PE remotely important or valuable. PE is great, and I'd love to work on more sites that use it...but I'll confess I rarely put forth the effort myself, even when I do have the space to do so in a project. Because Progressive Enhancement IS effort (most importantly time), effort that will most likely be seen by a single digit number of users and I've got a lot of stuff I want to do and a lot I need to do. Even a free hour can improve my productivity or quality for far more users if I spend it in something other than PE. PE has very real benefits beyond just working without JS...but even those benefits rarely outweigh the time/effort costs in an industry where there's always far more work than time.