3 ms·

I wonder if this is the dying gasp of javascriptless web browsing

by droopyEyelids 11y ago

AceJohnny2 11y ago
javascriptless web browsing died in 2004, and its killer is called Ajax.
- wwweston 11y ago
  Nah. For a long time after AJAX was birthed as a concept, people actually believed in progressive enhancement. It's only somewhere in the last 5 years the SPA trend seems to have reached critical mass and instead of starting from the idea of meeting user needs by serving reasonable media types from resource endpoints (and then building up interactivity on top of that), people want to treat browsers as just another cross-platform runtime (an inferior one, naturally) that happened to win out instead of Java or Flash or Silverlight.
  - jacques_chester 11y ago
    Users don't care why Site A is swooshy and clicky and shiny, while Site B isn't.
    - uxcn 11y ago
      Wikipedia works just fine in w3m.
  - kstrauser 11y ago
    That's because industry analytics showed that approximately 1% of visitors lack JavaScript. AJAX and things like jQuery are ubiquitous and powerful, and it can be ludicrously expensive to build a site that looks nice and works well for that extra 1% of visitors who've deliberately crippled their browsers. Pros for expecting JavaScript to be enabled: - Cheaper development because you can assume a common, featureful baseline. That leads to less code complexity on both the client and the server because you don't have to implement parallel code paths. - Freedom to add features that would be difficult or impossible to emulate with traditional static pages Cons for expecting JavaScript to be enabled: - The site won't look and act right for the 1% of visitors who are used to every other site also not looking and acting right There are lots of reasons to use JavaScript in the browser and almost no reasons not to, so everyone collectively decided to stop hamstringing themselves to cater to a teensy portion of users.
    - wwweston 11y ago
      > it can be ludicrously expensive to build a site that looks nice and works well for that extra 1% of visitors who've deliberately crippled their browsers. Huh. If you think that one of the advantages of JS-required SPA-style applications is that they will help you avoid things getting expensive somehow... I'm not sure where to start, actually. Maybe the situation here is kindof like the old saw about mediation: you should do it for 20 minutes a day, unless you don't have time, then you should do it for an hour a day. My experience is that sites that start with the focus on their shiny new JavaScript framework and their app-like UI tend to devolve into architectures with overspecific and mixed concerns pretty quickly. If you want to keep things from getting complex and expensive, start by keeping discipline involved in conceiving of the app in terms of plain HTTP and different media representations of the same relevant resources/data. For back ends already producing well-modeled JSON documents, producing equivalent HTML representations should be easy. If it's not, something is likely wrong (and if you're already producing well-modeled HTML documents, it's exceptionally rare that producing good JSON docs with the essential content is anything other than trivial). Now it's true that some apps just aren't about resources and media types, and you need the browser-as-runtime instead of the browser as document/media viewer. It's nice that the browser keeps growing in capabilities here. But let's be honestly: most of the JS-required apps we're seeing out there these days aren't even close to meeting this bar. And the "extra costs" you're invoking of supporting clients without JS are, in those cases, self-inflicted. > That's because industry analytics showed that approximately 1% of visitors lack JavaScript. And I bet those same analytics probably showed even fewer visitors without JS after they used those stats to require it -- problem solved!

I wonder if this is the dying gasp of javascriptless web browsing

AceJohnny2 11y ago

javascriptless web browsing died in 2004, and its killer is called Ajax.

wwweston 11y ago
Nah. For a long time after AJAX was birthed as a concept, people actually believed in progressive enhancement. It's only somewhere in the last 5 years the SPA trend seems to have reached critical mass and instead of starting from the idea of meeting user needs by serving reasonable media types from resource endpoints (and then building up interactivity on top of that), people want to treat browsers as just another cross-platform runtime (an inferior one, naturally) that happened to win out instead of Java or Flash or Silverlight.
- jacques_chester 11y ago
  Users don't care why Site A is swooshy and clicky and shiny, while Site B isn't.
  - uxcn 11y ago
    Wikipedia works just fine in w3m.
- kstrauser 11y ago
  That's because industry analytics showed that approximately 1% of visitors lack JavaScript. AJAX and things like jQuery are ubiquitous and powerful, and it can be ludicrously expensive to build a site that looks nice and works well for that extra 1% of visitors who've deliberately crippled their browsers. Pros for expecting JavaScript to be enabled: - Cheaper development because you can assume a common, featureful baseline. That leads to less code complexity on both the client and the server because you don't have to implement parallel code paths. - Freedom to add features that would be difficult or impossible to emulate with traditional static pages Cons for expecting JavaScript to be enabled: - The site won't look and act right for the 1% of visitors who are used to every other site also not looking and acting right There are lots of reasons to use JavaScript in the browser and almost no reasons not to, so everyone collectively decided to stop hamstringing themselves to cater to a teensy portion of users.
  - wwweston 11y ago
    > it can be ludicrously expensive to build a site that looks nice and works well for that extra 1% of visitors who've deliberately crippled their browsers. Huh. If you think that one of the advantages of JS-required SPA-style applications is that they will help you avoid things getting expensive somehow... I'm not sure where to start, actually. Maybe the situation here is kindof like the old saw about mediation: you should do it for 20 minutes a day, unless you don't have time, then you should do it for an hour a day. My experience is that sites that start with the focus on their shiny new JavaScript framework and their app-like UI tend to devolve into architectures with overspecific and mixed concerns pretty quickly. If you want to keep things from getting complex and expensive, start by keeping discipline involved in conceiving of the app in terms of plain HTTP and different media representations of the same relevant resources/data. For back ends already producing well-modeled JSON documents, producing equivalent HTML representations should be easy. If it's not, something is likely wrong (and if you're already producing well-modeled HTML documents, it's exceptionally rare that producing good JSON docs with the essential content is anything other than trivial). Now it's true that some apps just aren't about resources and media types, and you need the browser-as-runtime instead of the browser as document/media viewer. It's nice that the browser keeps growing in capabilities here. But let's be honestly: most of the JS-required apps we're seeing out there these days aren't even close to meeting this bar. And the "extra costs" you're invoking of supporting clients without JS are, in those cases, self-inflicted. > That's because industry analytics showed that approximately 1% of visitors lack JavaScript. And I bet those same analytics probably showed even fewer visitors without JS after they used those stats to require it -- problem solved!