4 ms·

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

by 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.

by micampe 12y ago

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.