5 ms·

I really appreciate that kind of focus and dedication. I recently had another dive into web development after a couple years of absence and was pleasantly surpr

by Taig 10y ago

I really appreciate that kind of focus and dedication. I recently had another dive into web development after a couple years of absence and was pleasantly surprised by tools like react. In combination with server side rendering it allowed me to serve a solid/usable HTML page with no JS required. When I started pulling in components from popular Material Design libraries, though, I realized that nobody thought about progressive enhancement even for a second. Rather than serving a plain `<select />` and then progressively enhancing it, all I got was an unusable mix of HTML tags and styling. It's a shame that even down at the library level people don't care about progressive enhancement. Are there any (react) projects that try to do better or is the mantra more like: react without JS is nonsense?

s_kilk 10y ago
There's no substitute for caring, and unfortunately much of the contemporary JS/Web world just doesn't care about these issues.
- masklinn 10y ago
  > There's no substitute for caring Or for being paid, progressive enhancement is more work than not doing it and if the client/manager/… doesn't want to pay for it… the dev is unlikely to bother doing it on their own dime.
  - sjclemmy 10y ago
    Too right - PE costs more and unless explicitly specified and understood it's not going to be done.
    - TeMPOraL 10y ago
      PE is the default of how HTML, CSS and JS work. You have to go out of your way to screw it up. Which is precisely what the whole web world delights in doing now.
      - ecnahc515 10y ago
        Just because it's the default doesn't make it easiest nor does it make sense as the default necessarily, it's just the default because that's how he web started. I'm not saying we should skip progressive enhancement but there's truth to it being more work (when compared to how easy we can do things without it using JS only), regardless of how the web was originally designed to work.
        nickpsecurity 10y ago
        "Just because it's the default doesn't make it easiest nor does it make sense as the default necessarily" I used to throw them together in Frontpage or Dreamweaver with a few optional scripts. Scripts for things like page counters or menus I just cut and pasted off dynamicdrive.com followed by tests in several browsers. Backend handled forms and such. Worked on every browser, loaded up fast on dialup, and everyone knew what my HTML/CSS code did without training. Can't say that about most of these sites and frameworks these days. So, I'd say it's easiest and a sensible default. To be clear, I'm not critiquing complex, web applications that truly need advanced tooling client-side. I'm talking about 90+% of what's out there that just publishes content with minimal dynamic elements needed.
        robin_reala 10y ago
        It’s easy to knock something together with JS. It’s very difficult to make it work well, certainly in our experience harder than having reasonable fallbacks.
      - masklinn 10y ago
        > PE is the default of how HTML, CSS and JS work. PE is not what the client pays you for. > You have to go out of your way to screw it up. Hardly. The shortest path to the whizzbang the client wants will break PE all on its own.
        TeMPOraL 10y ago
        Quite a lot of websites don't have clients that pay for design - in many cases (especially SaaS), the person wholy responsible for the look&feel target is your colleague the designer, sitting in the office next to yours. Come to think of it, given how most websites are designed, I'm starting to think we're making a mistake with sticking to HTML/CSS/JS. We should move to "executable Photoshop image" format - so that the beautiful magazine-like layouts made by designers could be implemented without a shit ton of hackery and bloat webdevs have to put nowadays. We could also push some security and sanity decisions into the format this way, so that the tool itself would tell the designers they can't (or shouldn't) do something. (I'm only slightly sarcastic here.)
  - Cthulhu_ 10y ago
    The 80 / 20% rule applies once more - why spend 80% of work on the 20% of users that would benefit from progressive enhancement? Unless those 20% of users generate 80% of revenue, which in all likelihood they don't.
    - dasil003 10y ago
      I'm a startup guy so of course I understand this, but on the other hand accessibility is one of those things that takes practice and know-how, so if you never do it of course it seems like this giant mountain to climb. However if you make it a priority, it's not 80% of the work, more likely it influences how you do things, so maybe you spend 20% more effort and end up with a little less whiz-bang. There is a cost, but we shouldn't paint it as an insurmountable thing. This is why we have the ADA, so that people with disabilities don't have to go through life as second-class citizens.
    - buro9 10y ago
      You only have to handle the 20% of users as a special case if you have gone and made some technology choices that excludes them. There is nothing inherent about the internet or web that says that needs to be the case. A rephrasing might ask why we make technology choices that exclude 20% users? If we're not able to produce a single page web app that reaches 100% of users, that's cool... just make a many page web site without lots of JavaScript that does.
    - tukelully 10y ago
      My biggest gripe with this, though it seems sensible on the surface, is that these numbers are often simply pulled out of someone's ass to argue their stance. Often a manager or a front-end person who just wants to work with the new hotness. How do we know 20%(or whatever the number is) is at all a relevant estimation? Who are the demographics that this number makes up? Why is it important to isolate them or exclude them? Furthermore, at best this number often only accounts for the known people that the product is already not serving or poorly serving. Not the people who bail immediately upon realizing that this service isn't for them because they opted against an inclusive strategy.
  - aarongustafson 10y ago
    I did some actual math on progressive enhancement costs vs. graceful degradation in consideration of reach: https://medium.com/@AaronGustafson/the-true-cost-of-progressive-enhancement-d395b6502979#.wa9b6bhf3 https://medium.com/@AaronGustafson/the-true-cost-of-progress...

by Taig 10y ago

s_kilk 10y ago

There's no substitute for caring, and unfortunately much of the contemporary JS/Web world just doesn't care about these issues.

masklinn 10y ago
> There's no substitute for caring Or for being paid, progressive enhancement is more work than not doing it and if the client/manager/… doesn't want to pay for it… the dev is unlikely to bother doing it on their own dime.
- sjclemmy 10y ago
  Too right - PE costs more and unless explicitly specified and understood it's not going to be done.
  - TeMPOraL 10y ago
    PE is the default of how HTML, CSS and JS work. You have to go out of your way to screw it up. Which is precisely what the whole web world delights in doing now.
    - ecnahc515 10y ago
      Just because it's the default doesn't make it easiest nor does it make sense as the default necessarily, it's just the default because that's how he web started. I'm not saying we should skip progressive enhancement but there's truth to it being more work (when compared to how easy we can do things without it using JS only), regardless of how the web was originally designed to work.
      - nickpsecurity 10y ago
        "Just because it's the default doesn't make it easiest nor does it make sense as the default necessarily" I used to throw them together in Frontpage or Dreamweaver with a few optional scripts. Scripts for things like page counters or menus I just cut and pasted off dynamicdrive.com followed by tests in several browsers. Backend handled forms and such. Worked on every browser, loaded up fast on dialup, and everyone knew what my HTML/CSS code did without training. Can't say that about most of these sites and frameworks these days. So, I'd say it's easiest and a sensible default. To be clear, I'm not critiquing complex, web applications that truly need advanced tooling client-side. I'm talking about 90+% of what's out there that just publishes content with minimal dynamic elements needed.
      - robin_reala 10y ago
        It’s easy to knock something together with JS. It’s very difficult to make it work well, certainly in our experience harder than having reasonable fallbacks.
    - masklinn 10y ago
      > PE is the default of how HTML, CSS and JS work. PE is not what the client pays you for. > You have to go out of your way to screw it up. Hardly. The shortest path to the whizzbang the client wants will break PE all on its own.
      - TeMPOraL 10y ago
        Quite a lot of websites don't have clients that pay for design - in many cases (especially SaaS), the person wholy responsible for the look&feel target is your colleague the designer, sitting in the office next to yours. Come to think of it, given how most websites are designed, I'm starting to think we're making a mistake with sticking to HTML/CSS/JS. We should move to "executable Photoshop image" format - so that the beautiful magazine-like layouts made by designers could be implemented without a shit ton of hackery and bloat webdevs have to put nowadays. We could also push some security and sanity decisions into the format this way, so that the tool itself would tell the designers they can't (or shouldn't) do something. (I'm only slightly sarcastic here.)
- Cthulhu_ 10y ago
  The 80 / 20% rule applies once more - why spend 80% of work on the 20% of users that would benefit from progressive enhancement? Unless those 20% of users generate 80% of revenue, which in all likelihood they don't.
  - dasil003 10y ago
    I'm a startup guy so of course I understand this, but on the other hand accessibility is one of those things that takes practice and know-how, so if you never do it of course it seems like this giant mountain to climb. However if you make it a priority, it's not 80% of the work, more likely it influences how you do things, so maybe you spend 20% more effort and end up with a little less whiz-bang. There is a cost, but we shouldn't paint it as an insurmountable thing. This is why we have the ADA, so that people with disabilities don't have to go through life as second-class citizens.
  - buro9 10y ago
    You only have to handle the 20% of users as a special case if you have gone and made some technology choices that excludes them. There is nothing inherent about the internet or web that says that needs to be the case. A rephrasing might ask why we make technology choices that exclude 20% users? If we're not able to produce a single page web app that reaches 100% of users, that's cool... just make a many page web site without lots of JavaScript that does.
  - tukelully 10y ago
    My biggest gripe with this, though it seems sensible on the surface, is that these numbers are often simply pulled out of someone's ass to argue their stance. Often a manager or a front-end person who just wants to work with the new hotness. How do we know 20%(or whatever the number is) is at all a relevant estimation? Who are the demographics that this number makes up? Why is it important to isolate them or exclude them? Furthermore, at best this number often only accounts for the known people that the product is already not serving or poorly serving. Not the people who bail immediately upon realizing that this service isn't for them because they opted against an inclusive strategy.
- aarongustafson 10y ago
  I did some actual math on progressive enhancement costs vs. graceful degradation in consideration of reach: https://medium.com/@AaronGustafson/the-true-cost-of-progressive-enhancement-d395b6502979#.wa9b6bhf3 https://medium.com/@AaronGustafson/the-true-cost-of-progress...