4 ms·

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 mi

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.
      - micampe 12y ago
        We are talking about people disabling JavaScript in their browser. One in several thousands is still a large over estimation.
        TheLoneWolfling 12y ago
        [Citation needed]
        micampe 12y ago
        What a thoughtful and insightful remark. If you don't believe that statement to be in the right ballpark you are out of touch with the world outside HN.
Smudge 12y ago
I find that "progressive enhancement", while perhaps a bit more work, results in a more robust and maintainable webapp. The fact that results in pages that work without JS is almost a side-effect and barely needs to be tested. The point for me is that links behave like links (perform GET requests against a URL and change the page from one state to another), buttons behave like buttons (perform POST requests and update some internal state), and the effect they have on the page is much the same with or without Javascript. The only difference is that with Javascript I can intercept the action and make the state change a lot more streamlined, or add a fancy animation if I so desire. By simply intercepting buttons and links (similar to how pjax and turbolinks work) I don't have to dig through JS to find where a specific AJAX request is fired-off and what it does. It just works, and when it returns, it simply updates part or all of the page with whatever the server returned, which could be part or all of a page. There are, of course, obvious limitations, like local state that changes with user interaction but that isn't preserved on the server in any way. But the more I can get working without Javascript, the more I know will be easily maintainable and translatable going forward even if I do something crazy like get rid of jQuery or convert everything to a React app. Maybe I'm just a bit odd, but I find this approach a lot easier to manage and a lot more productive in the long run than in marrying myself to any particular client-side framework.

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.
    - micampe 12y ago
      We are talking about people disabling JavaScript in their browser. One in several thousands is still a large over estimation.
      - TheLoneWolfling 12y ago
        [Citation needed]
        micampe 12y ago
        What a thoughtful and insightful remark. If you don't believe that statement to be in the right ballpark you are out of touch with the world outside HN.

Smudge 12y ago

I find that "progressive enhancement", while perhaps a bit more work, results in a more robust and maintainable webapp. The fact that results in pages that work without JS is almost a side-effect and barely needs to be tested. The point for me is that links behave like links (perform GET requests against a URL and change the page from one state to another), buttons behave like buttons (perform POST requests and update some internal state), and the effect they have on the page is much the same with or without Javascript. The only difference is that with Javascript I can intercept the action and make the state change a lot more streamlined, or add a fancy animation if I so desire. By simply intercepting buttons and links (similar to how pjax and turbolinks work) I don't have to dig through JS to find where a specific AJAX request is fired-off and what it does. It just works, and when it returns, it simply updates part or all of the page with whatever the server returned, which could be part or all of a page. There are, of course, obvious limitations, like local state that changes with user interaction but that isn't preserved on the server in any way. But the more I can get working without Javascript, the more I know will be easily maintainable and translatable going forward even if I do something crazy like get rid of jQuery or convert everything to a React app. Maybe I'm just a bit odd, but I find this approach a lot easier to manage and a lot more productive in the long run than in marrying myself to any particular client-side framework.