12 ms·

Back in 2006/7 I remember we'd use "progressive enhancement" to make a site work without JavaScript and then add JavaScript enhancements for those who had JS en

Back in 2006/7 I remember we'd use "progressive enhancement" to make a site work without JavaScript and then add JavaScript enhancements for those who had JS enabled. At some point (maybe after the popularity of Google Maps?) nobody wanted progressive enhancement and it was totally cool to just ignore users who had JS turned off. It made web app development so much easier, but probably less user friendly. It feels like JS is a hammer to fix the nail of the page reload. I always thought it was too bad that browsers choose to show the blank page instead of sending the request and just rendering the difference themselves.

wgerard 8y ago
> I always thought it was too bad that browsers choose to show the blank page instead of sending the request and just rendering the difference themselves. FWIW there are libraries that work around this, e.g. turbolinks - which I heavily suspect Github is using, and is probably a large part of why they're able to support progressive enhancement.
realusername 8y ago
> Back in 2006/7 I remember we'd use "progressive enhancement" to make a site work without JavaScript and then add JavaScript enhancements for those who had JS enabled. I still do that on my case, a good 95% of the features I develop work without Javascript. One additional benefit is that if your JS crash for any reason, most of the things are still working.
- brightball 8y ago
  I continue to do it as well. Web frameworks make it so easy it’s hard to justify not doing it. There are so few web apps that actually need the SPA treatment. It’s a lot simpler to ignore the tool chain headaches that come from committing to the SPA when you don’t need it and gracefully degrade. It’s so rare that I actually run into an SPA that doesn’t feel slow...I just wonder why people bother sometimes.
  - TeMPOraL 8y ago
    > It’s so rare that I actually run into an SPA that doesn’t feel slow...I just wonder why people bother sometimes. It's fashion over function on the business side, and CV-driven development on the frontend people's side.
    - ropeadopepope 8y ago
      > It's fashion over function on the business side Oh, there's a function to it. The 7 year tech cycle generates huge amounts of money for everybody involved. Consultants and consulting companies get a nice influx of billable hours every time the tech changes. Software companies pay to upgrade to the coolest tech because it's relatively cheap compared to the amount of money it generates. Users like it because with each tech upgrade comes an increase in convenience and graphical design. And, in some ways, having the latest version of the hot apps is another way of keeping up with the Joneses. Everybody's happy except for the power users. They tend to get left out in the cold.
- SquareWheel 8y ago
  I've never even heard of Javascript "crashing". Is that a thing that happens?
  - realusername 8y ago
    If you have a big website with lots and lots of different kind of visitors you either have: - Visitors with a bandwidth so low it takes a long time for the JS to download completely (so making it work in the mean time helps a lot). - Visitors with outdated browsers where your JS will stop on some unsupported feature you forgot to polyfill (I usually add a polyfill after when I see it but in the mean time it works), that's what I meant by "crashing", it never works 100% of the time in 100% of the cases, it depends on the browser as well.
  - TeMPOraL 8y ago
    I've seen it plenty of times. Something triggers a JS execution bug that breaks the entire script. Suddenly, the site is dead. If you're lucky, it might start working after reload. If not, you'll have to wait until developers figure out something is wrong. Causes vary. Sometimes it's a resource that fails to load. Sometimes it's a race condition. Sometimes, it's just dumb coding[0]. The more JS is put on site, and the more the site depends on it, the more likely it is to happen. -- [0] - Like one of the large food order sites in my country that won't let you submit a form if it contains a number in the comment box - the very comment box you're supposed to use to add details like floor number. The problem persisted for the last couple times I used them (in a space of several weeks), so I wonder if they even realized they have a problem and are losing business because people see the checkout form broken without explanation, and order elsewhere.
acomjean 8y ago
I thought progressive enhancement. I think people expect much more interactivity now, (I think google maps was a driver and web based email as well), so it became harder to do pure back end. For example a lot of the queries I run now show a dynamically generated graph. I can do that on the back end, but much easier to use a javascript charting package. I guess I could just use javascript all the way down
- reitanqild 8y ago
  > I think people expect much more interactivity now, This keeps coming up. Personally I keep thinking that devs and cv-driven development might be to blame as I rarely hear any customer demand anything that demands a frontend framework for their web sites (now web apps, that's another story).
  - TeMPOraL 8y ago
    Seconded. Actual users have little demand. Especially non-tech users. They just take what devs give them. Frontend stuff seems mostly fashion-driven these days, with designers copying other designers. I can't imagine any user actually asking for hero images, hamburger menus, floating headers/footers, webfonts, or making JS required to render article text.
    - pjmlp 8y ago
      It is not without its own set of quirks, but native frontend is surely much more sane.
    - CamTin 8y ago
      It is fashion-driven, but that's not to say that it ignores what users want. Nobody was asking for bell bottoms or leisure suits either, but people bought millions of them. Customers will say "our site needs a refresh" or "our site looks dated", when what they mean is that, regardless of whether or not its functional, they seem old and stodgy compared to their competitors. This happens in brick-and-mortar too: restaurant or shop owners will remodel even if there's nothing really wrong with their existing shop functionally. The real problem is that fashions are even possible on the web. This is what Ted Nelson calls the "triumph of typesetters over authors," and it's one of the great tragedies of the computer age. We could have had a real, global, hypertext system with working two way links and micropayments, but instead we got HTTP and HTML.
Androider 8y ago
It does make development easier, and at some point it just doesn't make sense to support any longer. If the number of people who visit your site with JavaScript disabled is less than the number of people who visit using the Opera browser, does it really make sense to add [number of supported browsers] x [JS on | JS off] permutations to your testing workload? Is spending the time and resources on creating a non-JS site worth it, or would it better spent somewhere else (usability, accessibility, etc.)? Everything is a trade-off. I personally feel the JS ship has long sailed. I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome. That is definitely a bit sad.
- zeveb 8y ago
  > It does make development easier, and at some point it just doesn't make sense to support any longer. It depends on what you're doing. If you're building an app (something which would make more sense as a native program anyway), then sure — use JavaScript. But if you're displaying text and images, then HTML & CSS are perfectly capable of handling that. In general, I think that a good content-focused website will work equally well across all browsers. There's no need to force end-users to allow you to execute code on their machines in order to display paragraphs or images. > I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome. And I'm worried about the long-standing trend of sites not even working in lynx, links, elinks, eww or w3m anymore, just Firefox, Chrome & IE.
  - ocfx 8y ago
    Such a small minority use lynx or links, why even bring it up, they don't matter. A business isn't going to spend money so their app renders properly in a text based web client that nobody will access their site with.
  - pishpash 8y ago
    Worse, some sites don't even work for pdf-print any more.
- reificator 8y ago
  > If the number of people who visit your site with JavaScript disabled is less than the number of people who visit using the Opera browser, does it really make sense to add [number of supported browsers] x [JS on | JS off] permutations to your testing workload? If your site doesn't work for people with JS disabled, you're unlikely to see significant traffic from people with JS disabled.
gear54rus 8y ago
You are correct that it is simply not worth it. It was not worth it and we dropped it thankfully. Hopefully we can drop stuff like internationalization with all its wasted effort soon as well. Regarding JS, I hate its overusage as much as the next guy, but it is in no way a reason to block it all. Nobody is going to waste time to develop for inferior platform (web without JS logic) just so you alone could see an inferior version of the website. Just ignore shitty sites or identify them and block JS on them instead. Also saying it's just for page reload is simply wrong. When I don't want to download Skype or Discord, I go to the website and they work. Will they work without JS? Will for example dynamic content rendering when I write a comment work? Will P2P file transfers and calls work? JS is used to make web site experience drastically better by good developers, we should strive to be those better developers instead of going back to dark ages of text-only web. This movement to get rid of JS because there are idiots out there who have the audacity to show the banner that is 3/4 of a screen is frankly just dumb. Why are you trying to ban the tool when it's misused? The web gods gave you the ability to block only the parts of the page or parts of JS you don't want. Use it!
- mattmanser 8y ago
  What do you mean about dropping i18n? How can we drop that, force everyone to speak Esperanto?
  - gear54rus 8y ago
    English obviously. It is quite far fetched, but I'm just tired of seeing countless hours wasted because the numbers aren't localized properly or RTL breaks layout. It's superfluous, people should have their native tongue and should learn English as means of international communication. Also imagine encoding problems which are also great PITA going away with ascii-only technologies.
    - pjmlp 8y ago
      Good luck with that.
    - SolaceQuantum 8y ago
bitwize 8y ago
Iron law of Web development: You develop your site for tge platform that has 95% of your user base, and tell the other 5% to join the 21st century because supporting them is not worth the cost. Back in the early 2000s, this meant you had to check your site in IE. Stragglers still using Netscape could pound sand.
- cptskippy 8y ago
  Actually we use to tout Graceful Degradation back in those day. Most sites were either static, rendering information from a DB, capturing simple form input, or a combination of the three. AJAX wasn't a thing and the concept of Web Apps didn't exist. If you were checking user agents then chances are you were doing something stupid or lazy.
  - icebraining 8y ago
    Yet "Best Viewed With Internet Explorer/Netscape" was common back then.
    - c22 8y ago
      I put one of those graphics on my very first angelfire site, because all I had was IE and I hadn't checked how it would work in anything else. When people started paying me for web development, though, I started installing browsers, operating systems, and even acquiring whole new devices (wap phones) to see how my client's sites were rendering in the real world. I spent whole nights agonizing about tiny tweaks and compatibility hacks to make sure everything looked good, this was the majority of the job in the early aughts. Now, in 2018, if you stick to a somewhat conservative set of html and css you can build nice looking sites that render great in any moderately modern browser across thousands of devices. It's insane to me that web developers now would rather descend back into compatibility hell by making their sites rely on a stack of unwieldy and opaque javascript.
  - bitwize 8y ago
    > Actually we use to tout Graceful Degradation back in those day. I don't know who "we" is, but what was touted and what was actually done were, then as now, two different things. The client wanted something fancy, was only willing to pay developers who would deliver, and (crucially) was running IE as their browser. As was most of the audience for the page. Stupid or lazy it may have been, it's still what web developers did to feed their families.
mattmanser 8y ago
It's more than that, they could have fixed html to support snippets without needing a full page reload. They haven't and now we're in this javascript SPA mess.
- NoGravitas 8y ago
  This, so much. There's a reasonable set of common JS usage patterns out there that really ought to be replaced with declarative statements in HTML and supported by browsers, so that doing things like dynamic forms, drag-and-drop areas, page transitions without reload, notification badges, etc. would not have to require running arbitrary code. Intercooler.js provides a preview of what this could be like, but, of course, it's layered on top of javascript since that's the hammer we have to work with.
  - mattmanser 8y ago
    MS actually did somethinng like this in IE5/6 in VB, but it never caught on. You could write a sort of reusable code snippet. I can't remember for the life of me what they were called though. Probably had the word "Active" in it. Active control or something like that.
romaniv 8y ago
>It made web app development so much easier I aim to develop web UIs using (mostly) progressive enhancement. I adopted several practices and developed some libraries supporting this process. As a result: 1. When I need to create something, I know exactly which data structures to use. This is determined by what is available in modern browsers. 2. I can quickly prototype solutions using plain HTML focusing on logic rather than style. 3. Since my data is by definition contained in HTML, I can easily query it using CSS queries. This makes working with nested data a breeze. 4. I factored code I reuse into generic, self-contained behaviors. Things like "when this form is invalid, this control should be inactive". There is usually very little to none page-specific code. 5. Once a behavior is written and tested, "debugging" usually involves simply making sure the page has the right attributes. I can do this by running a CSS query in console or looking at DOM. No breakpoints, no stepping, no watches. 6. The most important part: I can add one behavior at a time and the result is something that works and makes sense. 7. A lot of UI "logic" I used to have in scripts naturally migrated to CSS. I like this process way more than fiddling with tons of page-specific "glue" JavaScript. I especially like it when I'm in a crunch, because it pre-defines a lot of the things I would have to "design" on the fly in a traditional development workflow. Also, if I run out of time I have a working (if ugly) app. If I introduce a bug somewhere in UI or run into a compatibility issues, it usually doesn't result in the entire user workflow stopping dead.
- pjmlp 8y ago
  This is also my approach, when I am allowed to set the rules. Server side rendering with vanilaJS for the snippets that actually matter.
  - NetOpWibby 8y ago
    Yes! Glad to see I’m not crazy.
- scaryclam 8y ago
  You sir (or ma'am), are a credit to modern web developers :) I love that you're using PE as a development tool and not just doing it because it's a good way to build robust websites and applications. I may have to try and sell your reasoned approach to some of my colleagues (they're not PE averse, but don't always see it as a great benefit).
cptskippy 8y ago
I remember when we used the term "Graceful Degradation". It really isn't that hard to design a functional HTML site and then layer Javascript and AJAX over top of it to enhance the experience. There are very few sites that actually need to be using Frameworks like Angular and React. Sometimes I wonder if most developers would even be able to design a functional site using only HTML. It seems like most don't know the difference between a button and an anchor. With modern server side frameworks it's even easier to support graceful degradation or progressive enhancement as the frameworks will handle the accept header processing for you.
- Grumbledour 8y ago
  However, its also important to mention, that with react and careful planing, a no-js version is basically included for free. One might debate if a page really needs hundreds of kb of js to function, but then again, this is not much different than the classical progressive enhancement site with jquery etc. layered on and reacts server rendering can make to page easily available and working when js is disabled.
  - cptskippy 8y ago
    > However, its also important to mention, that with react and careful planing, a no-js version is basically included for free. Careful planning is required of all frameworks to make a JS free version. I wouldn't say it's a feature of React or that it's free. > One might debate if a page really needs hundreds of kb of js to function, but then again, this is not much different than the classical progressive enhancement site with jquery JQuery was a crutch that wasn't strictly necessary and with modern browsers you can largely do without it and write pure JavaScript. Assuming you know how, which I would wager most developers don't.
reaperducer 8y ago
I built a website for a mid-sized health care company, and the primary goal was to communicate with as many people using as many devices as possible, not to be flashy. With that mandate, the site (about 300 pages) ended up almost completely js-free. I think there was only one page that had js, and that was for a calculating widget. js is great for certain things, but certainly not necessary for all the things it's used for.
- dredmorbius 8y ago
  Sounds like a potentially sane organisation. Care to mention them?.
  - reaperducer 8y ago
    Not really. I'm still "the new guy" and I'm not sure how they'd feel about me outing it. Though the consultants keep talking about submitting the site for some kind of award. So maybe you'll see it eventually.
    - dredmorbius 8y ago
      Understood, thanks. Maybe throw this in the pot: There are those of us who care about such things, and honest signalling counts for something.
- sireat 8y ago
  Admirable, what type of stack did you use for the back-end? I remember there was a movement to be completely JS free in late 90s/early 2000s.
  - reaperducer 8y ago
    Nothing fancy. Just a plain LAMP stack. IDE was Coda2. I can't tell you about server stuff, though; that's handled by a different department.
yosito 8y ago
> At some point (maybe after the popularity of Google Maps?) I feel like there was a huge uptick in developers ignoring users with JS turned off when Angular and React started becoming popular. It's interesting to note that big tech companies, who have a financial interest in pushing websites away from progressive enhancement techniques, were the ones behind the creation of those frameworks.
amelius 8y ago
> It feels like JS is a hammer to fix the nail of the page reload. JS is useful for much more, e.g. collaborative editing, where the user doesn't have to wait for a server round-trip. JS is essential for a real-time multi-user interactive web.
majani 8y ago
There was a viral post on HN back in the day that demoed how the web would look like with seamless page loads instead of JavaScript. The consensus then was that the blank page and spinning gifs were good UI for showing that your click has led to a major change, while seamless JS communicated a minor action to the users

wgerard 8y ago

> I always thought it was too bad that browsers choose to show the blank page instead of sending the request and just rendering the difference themselves. FWIW there are libraries that work around this, e.g. turbolinks - which I heavily suspect Github is using, and is probably a large part of why they're able to support progressive enhancement.

realusername 8y ago

> Back in 2006/7 I remember we'd use "progressive enhancement" to make a site work without JavaScript and then add JavaScript enhancements for those who had JS enabled. I still do that on my case, a good 95% of the features I develop work without Javascript. One additional benefit is that if your JS crash for any reason, most of the things are still working.

brightball 8y ago
I continue to do it as well. Web frameworks make it so easy it’s hard to justify not doing it. There are so few web apps that actually need the SPA treatment. It’s a lot simpler to ignore the tool chain headaches that come from committing to the SPA when you don’t need it and gracefully degrade. It’s so rare that I actually run into an SPA that doesn’t feel slow...I just wonder why people bother sometimes.
- TeMPOraL 8y ago
  > It’s so rare that I actually run into an SPA that doesn’t feel slow...I just wonder why people bother sometimes. It's fashion over function on the business side, and CV-driven development on the frontend people's side.
  - ropeadopepope 8y ago
    > It's fashion over function on the business side Oh, there's a function to it. The 7 year tech cycle generates huge amounts of money for everybody involved. Consultants and consulting companies get a nice influx of billable hours every time the tech changes. Software companies pay to upgrade to the coolest tech because it's relatively cheap compared to the amount of money it generates. Users like it because with each tech upgrade comes an increase in convenience and graphical design. And, in some ways, having the latest version of the hot apps is another way of keeping up with the Joneses. Everybody's happy except for the power users. They tend to get left out in the cold.
SquareWheel 8y ago
I've never even heard of Javascript "crashing". Is that a thing that happens?
- realusername 8y ago
  If you have a big website with lots and lots of different kind of visitors you either have: - Visitors with a bandwidth so low it takes a long time for the JS to download completely (so making it work in the mean time helps a lot). - Visitors with outdated browsers where your JS will stop on some unsupported feature you forgot to polyfill (I usually add a polyfill after when I see it but in the mean time it works), that's what I meant by "crashing", it never works 100% of the time in 100% of the cases, it depends on the browser as well.
- TeMPOraL 8y ago
  I've seen it plenty of times. Something triggers a JS execution bug that breaks the entire script. Suddenly, the site is dead. If you're lucky, it might start working after reload. If not, you'll have to wait until developers figure out something is wrong. Causes vary. Sometimes it's a resource that fails to load. Sometimes it's a race condition. Sometimes, it's just dumb coding[0]. The more JS is put on site, and the more the site depends on it, the more likely it is to happen. -- [0] - Like one of the large food order sites in my country that won't let you submit a form if it contains a number in the comment box - the very comment box you're supposed to use to add details like floor number. The problem persisted for the last couple times I used them (in a space of several weeks), so I wonder if they even realized they have a problem and are losing business because people see the checkout form broken without explanation, and order elsewhere.

acomjean 8y ago

I thought progressive enhancement. I think people expect much more interactivity now, (I think google maps was a driver and web based email as well), so it became harder to do pure back end. For example a lot of the queries I run now show a dynamically generated graph. I can do that on the back end, but much easier to use a javascript charting package. I guess I could just use javascript all the way down

reitanqild 8y ago
> I think people expect much more interactivity now, This keeps coming up. Personally I keep thinking that devs and cv-driven development might be to blame as I rarely hear any customer demand anything that demands a frontend framework for their web sites (now web apps, that's another story).
- TeMPOraL 8y ago
  Seconded. Actual users have little demand. Especially non-tech users. They just take what devs give them. Frontend stuff seems mostly fashion-driven these days, with designers copying other designers. I can't imagine any user actually asking for hero images, hamburger menus, floating headers/footers, webfonts, or making JS required to render article text.
  - pjmlp 8y ago
    It is not without its own set of quirks, but native frontend is surely much more sane.
  - CamTin 8y ago
    It is fashion-driven, but that's not to say that it ignores what users want. Nobody was asking for bell bottoms or leisure suits either, but people bought millions of them. Customers will say "our site needs a refresh" or "our site looks dated", when what they mean is that, regardless of whether or not its functional, they seem old and stodgy compared to their competitors. This happens in brick-and-mortar too: restaurant or shop owners will remodel even if there's nothing really wrong with their existing shop functionally. The real problem is that fashions are even possible on the web. This is what Ted Nelson calls the "triumph of typesetters over authors," and it's one of the great tragedies of the computer age. We could have had a real, global, hypertext system with working two way links and micropayments, but instead we got HTTP and HTML.

Androider 8y ago

It does make development easier, and at some point it just doesn't make sense to support any longer. If the number of people who visit your site with JavaScript disabled is less than the number of people who visit using the Opera browser, does it really make sense to add [number of supported browsers] x [JS on | JS off] permutations to your testing workload? Is spending the time and resources on creating a non-JS site worth it, or would it better spent somewhere else (usability, accessibility, etc.)? Everything is a trade-off. I personally feel the JS ship has long sailed. I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome. That is definitely a bit sad.

zeveb 8y ago
> It does make development easier, and at some point it just doesn't make sense to support any longer. It depends on what you're doing. If you're building an app (something which would make more sense as a native program anyway), then sure — use JavaScript. But if you're displaying text and images, then HTML & CSS are perfectly capable of handling that. In general, I think that a good content-focused website will work equally well across all browsers. There's no need to force end-users to allow you to execute code on their machines in order to display paragraphs or images. > I'm more worried about the recent trend of sites not even working in Firefox anymore, just Chrome. And I'm worried about the long-standing trend of sites not even working in lynx, links, elinks, eww or w3m anymore, just Firefox, Chrome & IE.
- ocfx 8y ago
  Such a small minority use lynx or links, why even bring it up, they don't matter. A business isn't going to spend money so their app renders properly in a text based web client that nobody will access their site with.
- pishpash 8y ago
  Worse, some sites don't even work for pdf-print any more.
reificator 8y ago
> If the number of people who visit your site with JavaScript disabled is less than the number of people who visit using the Opera browser, does it really make sense to add [number of supported browsers] x [JS on | JS off] permutations to your testing workload? If your site doesn't work for people with JS disabled, you're unlikely to see significant traffic from people with JS disabled.

gear54rus 8y ago

You are correct that it is simply not worth it. It was not worth it and we dropped it thankfully. Hopefully we can drop stuff like internationalization with all its wasted effort soon as well. Regarding JS, I hate its overusage as much as the next guy, but it is in no way a reason to block it all. Nobody is going to waste time to develop for inferior platform (web without JS logic) just so you alone could see an inferior version of the website. Just ignore shitty sites or identify them and block JS on them instead. Also saying it's just for page reload is simply wrong. When I don't want to download Skype or Discord, I go to the website and they work. Will they work without JS? Will for example dynamic content rendering when I write a comment work? Will P2P file transfers and calls work? JS is used to make web site experience drastically better by good developers, we should strive to be those better developers instead of going back to dark ages of text-only web. This movement to get rid of JS because there are idiots out there who have the audacity to show the banner that is 3/4 of a screen is frankly just dumb. Why are you trying to ban the tool when it's misused? The web gods gave you the ability to block only the parts of the page or parts of JS you don't want. Use it!

mattmanser 8y ago
What do you mean about dropping i18n? How can we drop that, force everyone to speak Esperanto?
- gear54rus 8y ago
  English obviously. It is quite far fetched, but I'm just tired of seeing countless hours wasted because the numbers aren't localized properly or RTL breaks layout. It's superfluous, people should have their native tongue and should learn English as means of international communication. Also imagine encoding problems which are also great PITA going away with ascii-only technologies.
  - pjmlp 8y ago
    Good luck with that.
  - SolaceQuantum 8y ago

bitwize 8y ago

Iron law of Web development: You develop your site for tge platform that has 95% of your user base, and tell the other 5% to join the 21st century because supporting them is not worth the cost. Back in the early 2000s, this meant you had to check your site in IE. Stragglers still using Netscape could pound sand.

cptskippy 8y ago
Actually we use to tout Graceful Degradation back in those day. Most sites were either static, rendering information from a DB, capturing simple form input, or a combination of the three. AJAX wasn't a thing and the concept of Web Apps didn't exist. If you were checking user agents then chances are you were doing something stupid or lazy.
- icebraining 8y ago
  Yet "Best Viewed With Internet Explorer/Netscape" was common back then.
  - c22 8y ago
    I put one of those graphics on my very first angelfire site, because all I had was IE and I hadn't checked how it would work in anything else. When people started paying me for web development, though, I started installing browsers, operating systems, and even acquiring whole new devices (wap phones) to see how my client's sites were rendering in the real world. I spent whole nights agonizing about tiny tweaks and compatibility hacks to make sure everything looked good, this was the majority of the job in the early aughts. Now, in 2018, if you stick to a somewhat conservative set of html and css you can build nice looking sites that render great in any moderately modern browser across thousands of devices. It's insane to me that web developers now would rather descend back into compatibility hell by making their sites rely on a stack of unwieldy and opaque javascript.
- bitwize 8y ago
  > Actually we use to tout Graceful Degradation back in those day. I don't know who "we" is, but what was touted and what was actually done were, then as now, two different things. The client wanted something fancy, was only willing to pay developers who would deliver, and (crucially) was running IE as their browser. As was most of the audience for the page. Stupid or lazy it may have been, it's still what web developers did to feed their families.

mattmanser 8y ago

It's more than that, they could have fixed html to support snippets without needing a full page reload. They haven't and now we're in this javascript SPA mess.

NoGravitas 8y ago
This, so much. There's a reasonable set of common JS usage patterns out there that really ought to be replaced with declarative statements in HTML and supported by browsers, so that doing things like dynamic forms, drag-and-drop areas, page transitions without reload, notification badges, etc. would not have to require running arbitrary code. Intercooler.js provides a preview of what this could be like, but, of course, it's layered on top of javascript since that's the hammer we have to work with.
- mattmanser 8y ago
  MS actually did somethinng like this in IE5/6 in VB, but it never caught on. You could write a sort of reusable code snippet. I can't remember for the life of me what they were called though. Probably had the word "Active" in it. Active control or something like that.

romaniv 8y ago

>It made web app development so much easier I aim to develop web UIs using (mostly) progressive enhancement. I adopted several practices and developed some libraries supporting this process. As a result: 1. When I need to create something, I know exactly which data structures to use. This is determined by what is available in modern browsers. 2. I can quickly prototype solutions using plain HTML focusing on logic rather than style. 3. Since my data is by definition contained in HTML, I can easily query it using CSS queries. This makes working with nested data a breeze. 4. I factored code I reuse into generic, self-contained behaviors. Things like "when this form is invalid, this control should be inactive". There is usually very little to none page-specific code. 5. Once a behavior is written and tested, "debugging" usually involves simply making sure the page has the right attributes. I can do this by running a CSS query in console or looking at DOM. No breakpoints, no stepping, no watches. 6. The most important part: I can add one behavior at a time and the result is something that works and makes sense. 7. A lot of UI "logic" I used to have in scripts naturally migrated to CSS. I like this process way more than fiddling with tons of page-specific "glue" JavaScript. I especially like it when I'm in a crunch, because it pre-defines a lot of the things I would have to "design" on the fly in a traditional development workflow. Also, if I run out of time I have a working (if ugly) app. If I introduce a bug somewhere in UI or run into a compatibility issues, it usually doesn't result in the entire user workflow stopping dead.

pjmlp 8y ago
This is also my approach, when I am allowed to set the rules. Server side rendering with vanilaJS for the snippets that actually matter.
- NetOpWibby 8y ago
  Yes! Glad to see I’m not crazy.
scaryclam 8y ago
You sir (or ma'am), are a credit to modern web developers :) I love that you're using PE as a development tool and not just doing it because it's a good way to build robust websites and applications. I may have to try and sell your reasoned approach to some of my colleagues (they're not PE averse, but don't always see it as a great benefit).

cptskippy 8y ago

I remember when we used the term "Graceful Degradation". It really isn't that hard to design a functional HTML site and then layer Javascript and AJAX over top of it to enhance the experience. There are very few sites that actually need to be using Frameworks like Angular and React. Sometimes I wonder if most developers would even be able to design a functional site using only HTML. It seems like most don't know the difference between a button and an anchor. With modern server side frameworks it's even easier to support graceful degradation or progressive enhancement as the frameworks will handle the accept header processing for you.

Grumbledour 8y ago
However, its also important to mention, that with react and careful planing, a no-js version is basically included for free. One might debate if a page really needs hundreds of kb of js to function, but then again, this is not much different than the classical progressive enhancement site with jquery etc. layered on and reacts server rendering can make to page easily available and working when js is disabled.
- cptskippy 8y ago
  > However, its also important to mention, that with react and careful planing, a no-js version is basically included for free. Careful planning is required of all frameworks to make a JS free version. I wouldn't say it's a feature of React or that it's free. > One might debate if a page really needs hundreds of kb of js to function, but then again, this is not much different than the classical progressive enhancement site with jquery JQuery was a crutch that wasn't strictly necessary and with modern browsers you can largely do without it and write pure JavaScript. Assuming you know how, which I would wager most developers don't.

reaperducer 8y ago

I built a website for a mid-sized health care company, and the primary goal was to communicate with as many people using as many devices as possible, not to be flashy. With that mandate, the site (about 300 pages) ended up almost completely js-free. I think there was only one page that had js, and that was for a calculating widget. js is great for certain things, but certainly not necessary for all the things it's used for.

dredmorbius 8y ago
Sounds like a potentially sane organisation. Care to mention them?.
- reaperducer 8y ago
  Not really. I'm still "the new guy" and I'm not sure how they'd feel about me outing it. Though the consultants keep talking about submitting the site for some kind of award. So maybe you'll see it eventually.
  - dredmorbius 8y ago
    Understood, thanks. Maybe throw this in the pot: There are those of us who care about such things, and honest signalling counts for something.
sireat 8y ago
Admirable, what type of stack did you use for the back-end? I remember there was a movement to be completely JS free in late 90s/early 2000s.
- reaperducer 8y ago
  Nothing fancy. Just a plain LAMP stack. IDE was Coda2. I can't tell you about server stuff, though; that's handled by a different department.

yosito 8y ago

> At some point (maybe after the popularity of Google Maps?) I feel like there was a huge uptick in developers ignoring users with JS turned off when Angular and React started becoming popular. It's interesting to note that big tech companies, who have a financial interest in pushing websites away from progressive enhancement techniques, were the ones behind the creation of those frameworks.

amelius 8y ago

> It feels like JS is a hammer to fix the nail of the page reload. JS is useful for much more, e.g. collaborative editing, where the user doesn't have to wait for a server round-trip. JS is essential for a real-time multi-user interactive web.

majani 8y ago

There was a viral post on HN back in the day that demoed how the web would look like with seamless page loads instead of JavaScript. The consensus then was that the blank page and spinning gifs were good UI for showing that your click has led to a major change, while seamless JS communicated a minor action to the users