4 ms·

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

by 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.
- oneeyedpigeon 12y ago
  If you use progressive enhancement, you don't really need two versions. You have the base version, and you layer javascript and css on top of it. Granted, it might be a bit more work than just rushing out a javascript-dependent version, but it's definitely not twice the work. And you then have a much better structured, more solid base to work on - in the long-run, I'd be surprised if it weren't less work to do things the progressive way.
  - micampe 12y ago
    Yes, that's the ideal. Try and do it. Remember to test all the different progressively enhanced paths that only a tiny minority of your users is using.
    - oneeyedpigeon 12y ago
      Do you also take that attitude to your code? I.e. "it's alright, that code path only executes one time out of fifty, doesn't matter that it crashes the program".
      - micampe 12y ago
        That is not what I meant. I meant: “that code path only executes one time out of fifty (thousand), but you have to test it exactly like the core code that runs thousands of times more, so maybe you can drop the feauture since it's used by a handful of users”. (I have my doubts one in fifty people disable Javascript)
        oneeyedpigeon 12y ago
        Well now you're talking about an analogy that's 3 orders of magnitude away from what we're actually dealing with, so it doesn't really hold up. BTW, we're not really talking about 'testing' here, either - you don't actually need to test plain HTML beyond the most cursory of glances.
        12y ago
- A_COMPUTER 12y ago
  For eight-ish years, 2002-2010, I made websites that worked with or without Javascript, precisely because I didn't want to make two websites. I would have had to, because a lot of blind people used to use readers that didn't always handle Javascript well, and the sites I made were required to be accessible. Admittedly, they did not look as good as sites do today.
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.

by Smudge 12y ago

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.
oneeyedpigeon 12y ago
If you use progressive enhancement, you don't really need two versions. You have the base version, and you layer javascript and css on top of it. Granted, it might be a bit more work than just rushing out a javascript-dependent version, but it's definitely not twice the work. And you then have a much better structured, more solid base to work on - in the long-run, I'd be surprised if it weren't less work to do things the progressive way.
- micampe 12y ago
  Yes, that's the ideal. Try and do it. Remember to test all the different progressively enhanced paths that only a tiny minority of your users is using.
  - oneeyedpigeon 12y ago
    Do you also take that attitude to your code? I.e. "it's alright, that code path only executes one time out of fifty, doesn't matter that it crashes the program".
    - micampe 12y ago
      That is not what I meant. I meant: “that code path only executes one time out of fifty (thousand), but you have to test it exactly like the core code that runs thousands of times more, so maybe you can drop the feauture since it's used by a handful of users”. (I have my doubts one in fifty people disable Javascript)
      - oneeyedpigeon 12y ago
        Well now you're talking about an analogy that's 3 orders of magnitude away from what we're actually dealing with, so it doesn't really hold up. BTW, we're not really talking about 'testing' here, either - you don't actually need to test plain HTML beyond the most cursory of glances.
        12y ago
A_COMPUTER 12y ago
For eight-ish years, 2002-2010, I made websites that worked with or without Javascript, precisely because I didn't want to make two websites. I would have had to, because a lot of blind people used to use readers that didn't always handle Javascript well, and the sites I made were required to be accessible. Admittedly, they did not look as good as sites do today.

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.