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.
Sometime you have to cut corners, sure, but if you know what you are doing, the PE way is probably the easier one from the start.
Server side rendering with vanilaJS for the snippets that actually matter.
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.
If your site doesn't work for people with JS disabled, you're unlikely to see significant traffic from people with JS disabled.
It is VERY much an alpha and a lot of things aren’t working, just the bare minimum.
(followed by some horribly formatted content, at least on my phone)
Guess which product I will not be buying today?
No worries etatoby, just wanted to share an alternative.
EDIT: Thanks for your comment though, I just thought of some ways I can improve usability by using <noscript> to explain why JS is used for something.
Hmm there is a pretty big "Pricing" section in the middle of the page for me
Comments like these make me wonder if any of the people saying PE is hard ever tried it at all. The whole point of progressive enhancement is that you don't create a separate non-JS website.
Example: I make a form. It works without JS, so my server has to generate the form, handle the request where the form is submitted, and generate the result HTML. If I'm practicing good separation of concerns, the work is done in a service/contained library that the webserver code calls and assembles into a page. Then I go to add a "nice" Js experience: disable the normal form submit, read the form data, send the request, parse what I need out of the HTML result ("parse" = easy cut here) and replace the portion of the DOM involved. A nice, maintainable PE site. Nothing wrong with that.
But if I have the server generate the original page only, I can have JS read the form, call the service, and update the DOM. I was able to completely skip the server composing a new page. And that's for a bone-simple form, if my site has any interaction on that form before submit, each step represents duplicated effort. Checking if a name is already used? JS to call a service and add a line. Server/service absolutely needs to check that, but if we're not worrying about PE we can completely skip worrying about a nice UI generated on the server-side (which would involve re-populating the form we got, so it's not just "same HTML + one line"). And that's still the stupid-simple stuff.
To do this I need to design the application w/o JS and then find nice ways to improve it. But my designers, my PMs, they are all thinking from a JS-first point of view, so without PE when they say "do X" I can do X. With PE when they say "do X" I need to figure out how to do Y (a flow they didn't consider at all), and make sure it can behave like X. Anywhere it's hard to do so, it's on me to fix that because neither design nor business consider PE remotely important or valuable.
PE is great, and I'd love to work on more sites that use it...but I'll confess I rarely put forth the effort myself, even when I do have the space to do so in a project. Because Progressive Enhancement IS effort (most importantly time), effort that will most likely be seen by a single digit number of users and I've got a lot of stuff I want to do and a lot I need to do. Even a free hour can improve my productivity or quality for far more users if I spend it in something other than PE.
PE has very real benefits beyond just working without JS...but even those benefits rarely outweigh the time/effort costs in an industry where there's always far more work than time.
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.
Even a naive approach to making a javascript-rich site render with JS turned off will have profound positive impacts on usability and accessibility, so I'd say it's still worth it.
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.
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.
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.
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.
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.
It's fashion over function on the business side, and CV-driven development on the frontend people's 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.
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.
- 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.
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.
I remember there was a movement to be completely JS free in late 90s/early 2000s.
Maybe throw this in the pot: There are those of us who care about such things, and honest signalling counts for something.
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.
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.
They haven't and now we're in this javascript SPA mess.
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.
Probably had the word "Active" in it. Active control or something like that.
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
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).
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.
If you have other content though, it's not OK to not show anything; only the graph should be missing without javascript, the rest of the page should still render.
You can put data for the graph into a table, then use a script to render that table as a graph. If people cared enough, graph libraries could expect heir data in table format.
Saddly most graph libraries seem to love json data formats, which aren't logically table oriented... though if you used the json data and javascript to load the table and create the graph...
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.
How can we drop that, force everyone to speak Esperanto?
In other words, remove the need for i18n before removing i18n.
It's almost a caricature of the stereotypical redneck who has never left the country and gets mad when they overhear someone speaking Spanish at Fiesta, muttering "but this is America" under their breath.
It IS a caricature.
IMO what's really being self-centered is - when dealing with international things like the Internet - to insist on making everyone else's life harder for the sake of whatever random local tradition you grew up with.
And I say that as European with plenty of weird localized ways of writing dates, numbers, currencies, etc. Ways which I abandoned pretty much as soon as I got exposed to computing.
--
[0] - https://xkcd.com/1179/
"I find it to be too much work, and I derive no value from it, so we shouldn't do it."
The segregation between these language spheres on the web is incredibly effective. For instance, the Spanish and the English web rarely link to each other (and if they do it is most likely a link from the Spanish part to the English part). Ditto with many other language pairs.
A single world language is a nice thing to strive for, but I don't see why it would have to be English by default, even though that's what it probably will end up being anyway.
The French have always felt that their language is somehow special and that it should be given preference in the EU, and until not all that long ago it was the 'official' language in quite a few European countries by virtue of being the language of the wealthy. For the longest time the Dutch driving license still had the words 'permis de conduire' on it for that reason (and not as a convenient translation for any French police that might take an interest in the document).
French as a second language was the default, English a distant third. That's all changed now, but it is no different if it is imposed rather than of free will.
So if you want to go to that common meeting place that's fine, but if you're forced to go that common meeting place because a bunch of tech bozos have decided your culture, script and language don't matter because they have already mastered English because it was a requirement for them to be employed then that isn't.
A people's language is a window into their culture and their being. Each language (and even dialect) have their own insightful and delightful quirks.
I could only lamely elaborate here on own experience.
Sure. But you won't be able to enjoy it on a random website. Most of the time the translation quality is mediocre.
Back in the early 2000s, this meant you had to check your site in IE. Stragglers still using Netscape could pound sand.
If you were checking user agents then chances are you were doing something stupid or lazy.
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.
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.