7 ms·

I agree with the principle of this, but i disagree with including the javascript-is-disabled errors. If you browse the internet with one of the most important

I agree with the principle of this, but i disagree with including the javascript-is-disabled errors. If you browse the internet with one of the most important components of the internet disabled, you're going to find that a lot of stuff is broken, and displaying a warning that "hey, things are going to be broken here" is preferable to just displaying broken stuff.

Siecje 12y ago
What about if you are using a screen reader?
- wukkuan 12y ago
  That's a valid concern, but unrelated to JavaScript being required. Making a JavaScript web application screen reader accessible is no problem.
Smudge 12y ago
You might be surprised at what can be accomplished with HTML and CSS alone. Most of github.com works just fine without Javascript. Much of Twitter and Facebook work too. Facebook does give a warning, but they say you should enable Javascript "for a better experience" instead of "for any experience." I agree that showing a "hey this is broken" warning is better than rendering a totally broken page, but it's still not as good as presenting at least a partially working version, perhaps minus all of the usual bells and whistles. Now, of course, this is not super-feasible if you've chosen to build most of your site using client-side code, especially if that's where most of the rendering happens. But then again, the lack of server-side rendering is the obvious downside of building your site that way.
- micampe 12y ago
  Not everyone has the resources that Twitter and Facebook have to mantain what essentially are two version of their website. My position is that if you disable Javascript you get what you get (both you and I will be happy to know that I don't do web development anymore).
  - Smudge 12y ago
    You could always just build one version that is capable of rendering either server-side or client-side. React.js and other similar frameworks (that do diff-based updates) work well with this, or at least better than frameworks where the state changes are discretely coded. The react-rails gem is capable of doing server-side rendering out of the box: https://github.com/reactjs/react-rails https://github.com/reactjs/react-rails
    - micampe 12y ago
      In my experience, when discussing development problems, there are two types of people: those that say “well, you could just […]” and those that tried to do it and learned from experience how many unexpected problems you are going to have, how much work it's going to be, how much more testing you need, etc.
      - Smudge 12y ago
        Fair. I haven't tried rendering server-side with React. I'm sure it's as much a maintenance nightmare as much as any major feature. But I do have apps I maintain that started as traditional Rails apps and have been progressively enhanced to a point where they perform a lot like more modern client-side apps. And an interesting property I've discovered to be true of such an app is that it's really quite easy to convert that traditional view-rendering pipeline to React, because there is almost no JS-soup being relied on for core pieces to function. On the flip side, I also work on a couple apps where most of the functionality exists as JQuery DOM manipulation or as Bootstrapified data binding, and these are nearly impossible to port to a diff-based rendering library like React without rewriting most of the functionality. So while I haven't exactly tried rendering React on the server, I've found that the more traditional server-side rendering flow still holds up quite well on the modern web. It's a good way of thinking about how your app should look/behave given a set of states, and it holds up well even in places where Javascript is required. The fact that it can be accomplished without Javascript is more of a side-effect, but also a good indication that it's not any particular bit of Javascript that is holding it all together.
  - 12y ago
- aroman 12y ago
  I just tried disabling JavaScript and visiting Facebook and Twitter... both were entirely unusable. Nothing on Facebook worked, and on Twitter, all of the links and interactions were broken.
  - Smudge 12y ago
    I guess it depends on what you mean by 'works' -- I was able to view my facebook profile, click on links, visit other profiles, and even view a few entries on my news feed. Same with Twitter -- profile, news feed, a few other pages. Posting is broken, certainly, but to do that on Facebook I could click on "switch to our mobile site".
- sanderjd 12y ago
  I think one problem is that it's actually a lot more expensive to build an interactive application-style site that works with well with javascript disabled. So sure, rich companies like Github, Twitter, and Facebook can (and I think should) invest in making things work relatively well. But a less rich company is faced with a choice between giving up that interactivity or committing to it. Most people have gotten used to the interaction patterns of javascript-heavy sites, so giving it up can put a company at a UX disadvantage, with no real pay-off, because it is very uncommon for people to turn off javascript. On the further end of the scale are applications like Google's inbox, which are largely designed around interactivity of the sort you need javascript to achieve, and are never going to work any other way (though it's very silly that it requires Chrome).
  - Smudge 12y ago
    Whatever happened to "progressive enhancement"? It's possible to build a very rich experience around standard HTML+CSS and then enhance it with Javascript. This is how much of Github works. I'm not saying you should always take that approach, but if you're a small company with limited resources you can still choose which route you want to go down, and if you choose "progressive enhancement" then you have a site you know will (mostly) work without JS, without having to do any extra work on top of you usual development process. Rich companies can, of course, take both routes, but if you're going to build a javascript-heavy site you should at least understand the trade-offs and alternatives before you dive in head-first.
    - notatoad 12y ago
      What happened to progressive enhancement is that it's a fair bit of work, and putting in extra hours to support the three "power users" who have decided they want to run noscript isn't worth my time.
    - sanderjd 12y ago
      I feel like I specifically spoke to this in my comment that you responded to, but I guess I wasn't clear. My whole point was that doing progressive enhancement really well is much more expensive and has very little practical pay off (because within the margin of error, everybody has javascript turned on), so if you know you want lots of interactivity, it is reasonable to require javascript from the start. That is an understanding of the trade-offs. The part I might be wrong about is "doing progressive enhancement really well is much more expensive" - that's just my opinion based on anecdotal experience.
Zirro 12y ago
While I agree that a user with JavaScript disabled should not expect all fancy features to work, the site should still be able to present its main content in a non-broken visual environment. A minimal version built only with HTML and CSS, which is then expanded upon with JavaScript. This does appear to be the case with the first warning published on the blog, where the site is put into a "read-only mode" and I disagree with it being listed there, but I come across many other sites which do not display any form of content at all when JavaScript is disabled.
- oneeyedpigeon 12y ago
  It used to be the case (I haven't checked lately) that certain documentation pages on Apple's site were javascript-only - they were actually blank unless you had javascript on. These were literally just standard text-heavy pages with no discernible client-side behaviour that I ever saw. Whatever side of the argument anyone reading this is on, surely you have to agree that such behaviour is strange in the very least.
joshstrange 12y ago
Could not agree more! We have an mainly internal-only app that I work on that started out as PHP+HTML+CSS only and then over the years JS has been bolted on in various places. At first it was just to make life easier (Autocomplete, minor AJAX) but now we have entire components that will not function without JS and could not function without JS. Recently some devs have pushed for supporting browsers without JS enabled and I have been vehemently against it for a couple reasons: 1) MAJOR parts of our app will not and can not work without JS. Period, exclamation point. 2) Because of point 1 it doesn't make sense to waste dev time on making some views work with/without JS (We are a younger company and don't have time to waste on something like this especially when it isn't public-facing, not to mention QA can't handle testing everything twice). 3) Even if V1 of a component does support both JS and no JS there is no guarantee that future updates will be able to keep feature-parity or have time to code for that. For me JS is part of the web, not an optional add-on. It would be like saying "make a webpage that works with HTML" (IMHO). I also feel that it's not fair to complain about the GOOGLE CHROME app store requiring GASP GOOGLE CHROME (Same for GOOGLE cloud print). Not shit sherlock. As for Apple not allowing their video feeds on anything but Safari+OS X I think this is BS, there is no good reason I can think of to alienate so many people on other OS's especially since I would think THOSE are the people you might want to reach with your keynotes to convince them why they should switch. So while I like the idea of this Tumblr I can't help but think the JS/Google Chrome examples don't really fit and distract from the overall message. To be honest looking through the Tumblr again the ONLY valid concern is the one with Apple's keynote streaming, the other ones make complete sense. How is it Google's fault that they are pushing the envelope in terms of what is possible, even Google doesn't have the time/resources to make every one of their ideas (which may or may not make it long term) work across the board and that is their prerogative.
- oneeyedpigeon 12y ago
  "I also feel that it's not fair to complain about the GOOGLE CHROME app store requiring GASP GOOGLE CHROME" I read that as complaining about a WEB APP store requiring google chrome. Web apps tied to a specific browser are destructive to the overall ecosystem; you might as well just distribute native apps.
chestnut-tree 12y ago
I understand the necessity of Javascript if you have a web app, but a lot of sites fail to display a page of text or a list of links if Javascript is disabled [1]. In my view, this is poor practice. What seems to be happening is that more and more people are using Javascript frameworks to build web sites (not web apps). This probably makes things easier for the developer. I'm not convinced it always makes for a better experience for users. [1] Some examples of sites that won't display anything if Javascript is disabled (even though they're most displaying text): http://googlecommerce.blogspot.co.uk/ http://googlecommerce.blogspot.co.uk/ http://googleandyourbusiness.blogspot.co.uk/ http://googleandyourbusiness.blogspot.co.uk/
imanaccount247 12y ago
Javascript is not an important component if the internet. You can argue it is an important component of the web, but even that is pretty sketchy. I do browse without javascript. And 90%+ of the sites I have to turn it on for are just text. Javascript being required for webapps makes sense. Javascript being required for every blog on the planet does not.

Siecje 12y ago

What about if you are using a screen reader?

wukkuan 12y ago
That's a valid concern, but unrelated to JavaScript being required. Making a JavaScript web application screen reader accessible is no problem.

Smudge 12y ago

You might be surprised at what can be accomplished with HTML and CSS alone. Most of github.com works just fine without Javascript. Much of Twitter and Facebook work too. Facebook does give a warning, but they say you should enable Javascript "for a better experience" instead of "for any experience." I agree that showing a "hey this is broken" warning is better than rendering a totally broken page, but it's still not as good as presenting at least a partially working version, perhaps minus all of the usual bells and whistles. Now, of course, this is not super-feasible if you've chosen to build most of your site using client-side code, especially if that's where most of the rendering happens. But then again, the lack of server-side rendering is the obvious downside of building your site that way.

micampe 12y ago
Not everyone has the resources that Twitter and Facebook have to mantain what essentially are two version of their website. My position is that if you disable Javascript you get what you get (both you and I will be happy to know that I don't do web development anymore).
- Smudge 12y ago
  You could always just build one version that is capable of rendering either server-side or client-side. React.js and other similar frameworks (that do diff-based updates) work well with this, or at least better than frameworks where the state changes are discretely coded. The react-rails gem is capable of doing server-side rendering out of the box: https://github.com/reactjs/react-rails https://github.com/reactjs/react-rails
  - micampe 12y ago
    In my experience, when discussing development problems, there are two types of people: those that say “well, you could just […]” and those that tried to do it and learned from experience how many unexpected problems you are going to have, how much work it's going to be, how much more testing you need, etc.
    - Smudge 12y ago
      Fair. I haven't tried rendering server-side with React. I'm sure it's as much a maintenance nightmare as much as any major feature. But I do have apps I maintain that started as traditional Rails apps and have been progressively enhanced to a point where they perform a lot like more modern client-side apps. And an interesting property I've discovered to be true of such an app is that it's really quite easy to convert that traditional view-rendering pipeline to React, because there is almost no JS-soup being relied on for core pieces to function. On the flip side, I also work on a couple apps where most of the functionality exists as JQuery DOM manipulation or as Bootstrapified data binding, and these are nearly impossible to port to a diff-based rendering library like React without rewriting most of the functionality. So while I haven't exactly tried rendering React on the server, I've found that the more traditional server-side rendering flow still holds up quite well on the modern web. It's a good way of thinking about how your app should look/behave given a set of states, and it holds up well even in places where Javascript is required. The fact that it can be accomplished without Javascript is more of a side-effect, but also a good indication that it's not any particular bit of Javascript that is holding it all together.
- 12y ago
aroman 12y ago
I just tried disabling JavaScript and visiting Facebook and Twitter... both were entirely unusable. Nothing on Facebook worked, and on Twitter, all of the links and interactions were broken.
- Smudge 12y ago
  I guess it depends on what you mean by 'works' -- I was able to view my facebook profile, click on links, visit other profiles, and even view a few entries on my news feed. Same with Twitter -- profile, news feed, a few other pages. Posting is broken, certainly, but to do that on Facebook I could click on "switch to our mobile site".
sanderjd 12y ago
I think one problem is that it's actually a lot more expensive to build an interactive application-style site that works with well with javascript disabled. So sure, rich companies like Github, Twitter, and Facebook can (and I think should) invest in making things work relatively well. But a less rich company is faced with a choice between giving up that interactivity or committing to it. Most people have gotten used to the interaction patterns of javascript-heavy sites, so giving it up can put a company at a UX disadvantage, with no real pay-off, because it is very uncommon for people to turn off javascript. On the further end of the scale are applications like Google's inbox, which are largely designed around interactivity of the sort you need javascript to achieve, and are never going to work any other way (though it's very silly that it requires Chrome).
- Smudge 12y ago
  Whatever happened to "progressive enhancement"? It's possible to build a very rich experience around standard HTML+CSS and then enhance it with Javascript. This is how much of Github works. I'm not saying you should always take that approach, but if you're a small company with limited resources you can still choose which route you want to go down, and if you choose "progressive enhancement" then you have a site you know will (mostly) work without JS, without having to do any extra work on top of you usual development process. Rich companies can, of course, take both routes, but if you're going to build a javascript-heavy site you should at least understand the trade-offs and alternatives before you dive in head-first.
  - notatoad 12y ago
    What happened to progressive enhancement is that it's a fair bit of work, and putting in extra hours to support the three "power users" who have decided they want to run noscript isn't worth my time.
  - sanderjd 12y ago
    I feel like I specifically spoke to this in my comment that you responded to, but I guess I wasn't clear. My whole point was that doing progressive enhancement really well is much more expensive and has very little practical pay off (because within the margin of error, everybody has javascript turned on), so if you know you want lots of interactivity, it is reasonable to require javascript from the start. That is an understanding of the trade-offs. The part I might be wrong about is "doing progressive enhancement really well is much more expensive" - that's just my opinion based on anecdotal experience.

Zirro 12y ago

While I agree that a user with JavaScript disabled should not expect all fancy features to work, the site should still be able to present its main content in a non-broken visual environment. A minimal version built only with HTML and CSS, which is then expanded upon with JavaScript. This does appear to be the case with the first warning published on the blog, where the site is put into a "read-only mode" and I disagree with it being listed there, but I come across many other sites which do not display any form of content at all when JavaScript is disabled.

oneeyedpigeon 12y ago
It used to be the case (I haven't checked lately) that certain documentation pages on Apple's site were javascript-only - they were actually blank unless you had javascript on. These were literally just standard text-heavy pages with no discernible client-side behaviour that I ever saw. Whatever side of the argument anyone reading this is on, surely you have to agree that such behaviour is strange in the very least.

joshstrange 12y ago

Could not agree more! We have an mainly internal-only app that I work on that started out as PHP+HTML+CSS only and then over the years JS has been bolted on in various places. At first it was just to make life easier (Autocomplete, minor AJAX) but now we have entire components that will not function without JS and could not function without JS. Recently some devs have pushed for supporting browsers without JS enabled and I have been vehemently against it for a couple reasons: 1) MAJOR parts of our app will not and can not work without JS. Period, exclamation point. 2) Because of point 1 it doesn't make sense to waste dev time on making some views work with/without JS (We are a younger company and don't have time to waste on something like this especially when it isn't public-facing, not to mention QA can't handle testing everything twice). 3) Even if V1 of a component does support both JS and no JS there is no guarantee that future updates will be able to keep feature-parity or have time to code for that. For me JS is part of the web, not an optional add-on. It would be like saying "make a webpage that works with HTML" (IMHO). I also feel that it's not fair to complain about the GOOGLE CHROME app store requiring GASP GOOGLE CHROME (Same for GOOGLE cloud print). Not shit sherlock. As for Apple not allowing their video feeds on anything but Safari+OS X I think this is BS, there is no good reason I can think of to alienate so many people on other OS's especially since I would think THOSE are the people you might want to reach with your keynotes to convince them why they should switch. So while I like the idea of this Tumblr I can't help but think the JS/Google Chrome examples don't really fit and distract from the overall message. To be honest looking through the Tumblr again the ONLY valid concern is the one with Apple's keynote streaming, the other ones make complete sense. How is it Google's fault that they are pushing the envelope in terms of what is possible, even Google doesn't have the time/resources to make every one of their ideas (which may or may not make it long term) work across the board and that is their prerogative.

oneeyedpigeon 12y ago
"I also feel that it's not fair to complain about the GOOGLE CHROME app store requiring GASP GOOGLE CHROME" I read that as complaining about a WEB APP store requiring google chrome. Web apps tied to a specific browser are destructive to the overall ecosystem; you might as well just distribute native apps.

chestnut-tree 12y ago

I understand the necessity of Javascript if you have a web app, but a lot of sites fail to display a page of text or a list of links if Javascript is disabled [1]. In my view, this is poor practice. What seems to be happening is that more and more people are using Javascript frameworks to build web sites (not web apps). This probably makes things easier for the developer. I'm not convinced it always makes for a better experience for users. [1] Some examples of sites that won't display anything if Javascript is disabled (even though they're most displaying text): http://googlecommerce.blogspot.co.uk/ http://googlecommerce.blogspot.co.uk/ http://googleandyourbusiness.blogspot.co.uk/ http://googleandyourbusiness.blogspot.co.uk/

imanaccount247 12y ago

Javascript is not an important component if the internet. You can argue it is an important component of the web, but even that is pretty sketchy. I do browse without javascript. And 90%+ of the sites I have to turn it on for are just text. Javascript being required for webapps makes sense. Javascript being required for every blog on the planet does not.