Recently, a newsletter editorial by Louis Lazaris caused some furore by questioning whether we find ourselves in the middle of a scripting-dependency backlash.
The ensuing debate rolled back and forth, with some people insisting that catering for users with JavaScript disabled is a dreadful waste of time, whilst others questioned how you could ignore even a small percentage of potential customers.
Time and again, in the 132 responses (and counting) that this editorial provoked, the term “progressive enhancement” was brought to the fore, before the discussion turned towards what progressive enhancement is and what it actually means.
It’s certainly a contentious term. On the one hand there are well-known JavaScript framework authors telling us it’s dead and that we should not be ashamed to build 100% JavaScript applications. Yet on the other, we have prominent developer evangelists telling us we need to embrace it fully.
And now SitePoint’s Craig Buckler has added his voice to the melee. In a piece entitled Myth-Busting Progressive Enhancement, he attempts to dispel the myths around the subject, tell us why it does matter, and to finally silence the critics.
Personally, I think that Craig makes some very good points and, whether or not you agree with him, that this debate is healthy for our industry as a whole.
But what do you think? Do you agree with Craig’s myth busting, or is progressive enhancement just a technique recommended by the old timers?
My experience today just reaffirms my belief that PE is the way to work. My company’s proxy server is having fits, and it’s made it nearly impossible to do anything today. Content provided server side is working relatively OK, but anything loaded from a CDN and/or via javascript just isn’t working.
Google - search working OK, gmail being temperamental.
Other web mail services - nope.
SPF? - barely working. Forget the iconography/FA icons.
Slack? - nope, not at all unless you count the goofy sayings splash screen as working.
msn - somewhat, but flaky. Sub-sites, barely if at all.
cnn? nope
In a majority of these cases, most of what’s being loaded could be done in simple css, and the JS isn’t needed. Yes, it makes the experience better, but shouldn’t be dependent just to get the bare minimum job done.
Even before starting to discuss the benefits of PE he fist covers those few types of site where a JS framework is basically a requirement for the application to work. Obviously PE cannot apply to those very specific situations (which currently make up a minority of sites on the web).
Perhaps one of the greatest reasons for people’s confusion is that they are thinking specifically of that small group of sites where the use of JavaScript is impossible to avoid rather than the vast majority of sites that could function without JavaScript.
Thanks Felgall. I think that’s the crux of the problem. Use a JS framework for a while and it quickly becomes a crutch. You can’t imagine walking without it.
The same could be said for jQuery but that doesn’t force a JavaScript dependency or prevent you using PE techniques.
Solid data on how many users leave pages while pages load would be interesting. In other words, is the SPA movement making good on the UX promise? Does the interaction while loading keep users engaged? I don’t know, but there’s a lot to be gained from UX, where the efforts might be better spent.
My point was, that features often-wise compete for a fixed amount of time and money. You can’t have your cake and eat it to without paying for both or worse. Examples?
Wether to ad cost to cater to ~3% of users? …It depends.
Could you do something smarter within your budget ? …It depends.
OK, so you’re just generally saying that you have to consider which features/areas/methodologies/etc are worth the most to your users, what’s worth development time, etc - such as general UX improvements, responsiveness, building with a PE approach, building JS effects in, adding a time-space continuum portal, etc?
That makes sense to me. You have to do what makes sense for your application/users.
If Tidal shows nothing but a blank page on your company VPN who cares? If on the otherhand you have just been commissioned to build the next GOV website and your end users can’t fill in their tax returns because they can’t see the form then you have a problem.
You shouldn’t have to support for the sake of supporting. If there is money to be made and you/the client can justify the additional development time then great.
Sure it’s a trade off, but are your managers and your manager’s managers really aware of what the trade off is? Sort of like security: if the software compiles and functions properly, we can ship it. The security of the software is not in the budget. But when software exploits are found, heads will roll.
Sure, only 3% of the users of our website will see a blank screen. But when one day the boss of your biggest customer decides to access your website on a mobile device while traveling on a train and sees the website malfunctioning every 5 clicks, is he going to think, “no problem I’m just the 3%”, or is he going to call his head of IT and demand to switch to another company?
A website is like a store front and represents your company. Your company may accept the staff cafeteria to be a little dirty, but if just one of the bulbs in the farthest corner of the main entrance is out and isn’t replaced promptly, it hurts the image of your company even though only 3% of the customers may notice that that bulb was out.
I’m not saying we have to spend money on this, but the problem of websites not working because of no JavaScript is a clear and present problem.
It isn’t even like it is an on/off situation with JavaScript. There are lots of JavaScript commands that work in some browsers but not others. Just because a given JavaScript works in one browser it doesn’t mean that it will work in all browsers as it is possible that the script uses commands that are valid JavaScript but which the browser being used doesn’t understand.
For example:
document.getElementById - not recognised by IE4 or Netscape 4 or earlier
document.addEventListener - not recognised by IE8 or earlier
The built in static Reflect object is currently only supported by Microsoft Edge (or IE12 as the MDN web site calls it).
So depending on the particular JavaScript you use you will have a range of older browsers that cannot run the script because of one or more statements that they don’t understand.