Comments on Interaction Is an Enhancement

22 Reader Comments

Back to the Article
  1. “Just don’t put all your eggs in the JavaScript basket.”

    As a web application developer, this is our only option. Yes, content publishers can produce something quite valuable in HTML since content production and distribution are paramount, but rendering the equivalent of a desktop application on the server is just out of the question. Separating content from presentation concerns is still a great idea everywhere though.

    Copy & paste the code below to embed this comment.
  2. You made this case really well but it’s almost a shame it needs to be made at all anymore.

    “Unfortunately, traditional software developers who are relatively new to the Web have not come to terms with this [lack of control] yet.”

    When I first started out in the industry, there was some derision amongst Developers for the ‘Print Designer turned Web Designer’—largely because they designed for an environment they simply didn’t have. It looks a parallel can be made for certain ‘traditional’ Developers turned Web Developers, both in terms of status and mental models.

    Copy & paste the code below to embed this comment.
  3. I can’t imagine that browsing the Internet with JavaScript disabled is a good experience for the user.

    Copy & paste the code below to embed this comment.
  4. The best thing about the GDS experiment was not the results and conclusions, but that they actually showed the code they used. 

      https://github.com/alphagov/frontend/pull/452/files

    The generated markup for the script-enabled test is also still on the www.gov.uk home-page. It is an **inline-script** with the following code.

    (function(){
      var a=document.createElement(“img”);
      a.src=“https://assets.digital.cabinet-office.gov.uk/frontend/homepage/no-cache/with-js-8337212354871836e6763a41e615916c89bac5b3f1f0adf60ba43c7c806e1015.gif”;
      a.alt=”“;
      a.role=“presentation”
      a.style.position=“absolute”;
      a.style.left=”-9999em”;
      a.style.height=“0px”;
      a.style.width=“0px”;
      document.getElementById(“wrapper”)
      .appendChild(a)
    })();

    For some reason 0.9% of browser visits didn’t successfully run this code (or utilize the noscript markup).

    Because it is a simple **inline script with no dependencies** I think it is fair to conclude that:
    - it probably doesn’t have any errors
    - it won’t fail due to a library dependency
    - it won’t fail due to a CDN outage
    - it won’t fail due to a delayed or incomplete script download
    - it won’t be broken by third party code

    (There is a slim possibility that in the fraction of a second between the base img request and the script img request the user abandons the page or the network.)

    I don’t think it safe to draw a strong conclusion from this experiment, but the explanation I find most likely is plugins or proxies that block all JS (including inline).


    Another (slightly different) warning about depending on JS is the AngluarJS docs.

    The latest stable version of Angular supports IE9:
      https://docs.angularjs.org/guide/ie

    But if you visit the docs in IE9 it won’t work (hasn’t worked for at least a year).

    Why?

    Well, the main factor is that no-one visits the docs site in IE9.

    But the specific cause of the failure is that the *site-specific scripts* throw before configuring Angular.

    And the actual error in the site-specific scripts is that they call `console.log()`, which only exists in IE9 **after** you open the console. No wonder the docs maintainers never found the error.

    So the warning is, just because the framework you use supports all browsers you are interested in, this doesn’t guarantee your site is working in all those browsers (even if JS is enabled and loading).

    Copy & paste the code below to embed this comment.
  5. @Matt Motherway

    It’s about knowing your context.

    When writing a complex application, you can demand more from your users than if you’re writing a news site or blog. On a “read only” site, like most company websites and news sites, you should not need to rely on JS to read text. However, in a more interactive environment where you might trigger business processes, pass data around and talk to a database - things are a bit different, since you can, to a degree, control the execution environment (“Always use Chrome latest when at work”).

    ...and of course, then there are the blurry, grey areas that are hard to define.

    Copy & paste the code below to embed this comment.
  6. <q>“I can’t imagine that browsing the Internet with JavaScript disabled is a good experience for the user.”</q>

    Indeed. And that would be because web developers insist on building things (even reading **plain-text magazine articles**) to be a bad experience that way.

    In many cases, I should put “building” in air-quotes.

    Copy & paste the code below to embed this comment.
  7. Thank you, Aaron, for this enlightening piece.

    Copy & paste the code below to embed this comment.
  8. A trivial misclosed html tag can make your site inoperable too. This is an indictment of bad development practices, not a technology. Most companies cannot afford to greatly increase their development efforts for 0.9 percent of potential users.

    I agree JavaScript can be overused for simple sites, but the time is gone when we have to worry about it not being available at all. Worry about experience and quality.. not fundamental tech.

    Copy & paste the code below to embed this comment.
  9. @JamieT “Worry about experience and quality.. not fundamental tech.”

    Progressive enhancement leads to quality and good experience.

    Copy & paste the code below to embed this comment.
  10. @Michiel, its simply one way. It also leads to more complexity and significantly increased development and testing effort. I have no problem with PE in concept. If I had unlimited time and money I would support every device and user choice ever made. I guess it’s up to you to decide how to use finite resources. For us, supporting the 99.x% of users running JavaScript comes first.

    Copy & paste the code below to embed this comment.
  11. @JamieT, sure it takes more time. The result is a website better prepared for the world wide web though. I’d like to compare it to a wooden versus a stone house. A wooden house is cheaper, faster and easier to build than the same house made of stone. The stone version is more durable; it will not be blown away by a tornado, nor will it crumble as easily during an earthquake. The wooden version will rot away without maintenance, the stone version will be covered by plants and what not, but will still function as a house.

    Starting in the stone age and building up to a light and fast wood version just makes sense. It’s not only JavaScript that can fail to load (for what ever reason), but also images, fonts, css, or any other content type you might load. You have to be very optimistic to think that all of those will always load.

    I wouldn’t want to live in a house that collapsed if a fundamental technology—say electricity—failed.

    Copy & paste the code below to embed this comment.
  12. “I can’t imagine that browsing the Internet with JavaScript disabled is a good experience for the user.”

    Ultimately, isn’t that up to us to decide? If the user is reading an article or other piece of primarily-text information (like, for example, this page), the user experience ought to be just fine - and if it isn’t, that’s the developer’s fault, not the user’s. There are some applications where Javascript can be reasonably expected to be necessary for a good user experience, but reading the news isn’t one of them. Try reading this very site with Javascript turned off - there are slight changes in the UX and some things take a couple more clicks, but the only thing that’s really lost by disabling JS here is the ads.

    It may be rare for users to intentionally disable Javascript, but just the same, you have no control over whether or not users are executing JS, so that’s a dependency you introduce at your own peril. If your fancy web app absolutely, positively, simply just can’t work without Javascript, then that’s fine. But when you’re building it, you should ask yourself whether the thing you’re trying to accomplish absolutely NEEDS to be done in a way where even basic functionality is totally dependent on JS. Is that dependency absolutely critical and unavoidable, or are you tacking on an unnecessary dependency?

    Don’t think of progressive enhancement as building the thing to be dependent on JS and then doing extra work to put in no-JS fallbacks for everything. Instead, try building for the no-JS case, and then putting in JS enhancements for users that do have scripting enabled.

    Copy & paste the code below to embed this comment.
  13. About the Gds experiment, I wouldn’t jump to a conclusion without really knowing what’s happening. There could be some totally valid scenarios where JavaScript is not the one to blame. For example there could be a crawler visiting the page. Or the user could be on a flaky connection where the http keep alive connection resets or times out between the two image requests. Remember this can happen even in a no js setup. In fact, a good js web app can detect these failures and give the user meaningful error messages and a chance to retry while providing good offline experience (with cached data and templates) rather than a dinosuer page. Above all, those numbers are for two years ago. That’s a lot time in the tech industry.

    What I can say is frontend development has always been tricky. It’s not because the client code runs on an unknown machine (that’s what VMs are created for), but rather ambiguous specs, incorrect implementation of those specs and flaky connections. Although we all know about this, but we sometimes have really high expectations from the web. Today people create native mobile apps just for a particular OS, a particular Api version, etc. They already know they are just aiming for say 60% of the market, but that is as much budget as they have. Of course they’ll expand when they grow. The same should be true for web too. You don’t have that much budget, drop support for ancient browsers. If under the same budget constraints you can achieve the same user experience for a greater audience with techniques such as PE or using better tools, then great, go for it, but if you can’t don’t get obsessed that there are 1% users I won’t be able to support. (Remember when this 1% is quite some number, more likely than not you will have quite some money to support them!)

    I’ve recently seen another trend (by React fans) that CSS is the problem of the web by saying “the worst thing about CSS is cascading and stylesheets”. It seems that the next in line to blame is Html itself. I believe these approaches are not really constructive and web ecosystem is overall a great place. We just have learn from past mistakes and try solve them in the future.

    Copy & paste the code below to embed this comment.
  14. @piloop: I think you’ve said it perfectly. Why is it that people always assume that just because the web is an open platform, that developers can’t set restrictions? JavaScript always seems to take the hit, for reasons I can’t fathom. Why, just the other day YouTube failed to load CSS (and this was on a stable connection on a powerful computer running a fully current browser). The site was completely unusable. Should we all account for those times when CSS fails to load? Heck, no! As developers, we have the power to say that “this site will not work without JavaScript and CSS, sorry”. There’s not some law that says we have to support every possible scenario, or else we’ll be thrown in gaol. We can say to this tiny proportion of people to whom it applies, “deal with it, if you want to use my site, upgrade your browser”.

    Ultimately, it comes down to, do we even care about 1% of people? And unless you’re Google, the answer is often, “No”.

    Copy & paste the code below to embed this comment.
  15. Max:“Don’t think of progressive enhancement as building the thing to be dependent on JS and then doing extra work to put in no-JS fallbacks for everything. Instead, try building for the no-JS case, and then putting in JS enhancements for users that do have scripting enabled.”

    Or, build your house from the foundation up instead of from the roof down.

    Copy & paste the code below to embed this comment.
  16. @cmart,

    In regards to accessibility, yes you should actually try and account for when CSS and JavaScript do not load. In fact, I find your example of YouTube not functioning correctly without the CSS on an argument for them to actually do a better job of ensuring the site is functional without CSS rather than an argument for it to be okay.

    Copy & paste the code below to embed this comment.
  17. I can’t help but draw parallels with the fashion show

    Copy & paste the code below to embed this comment.
  18. I’m right up there with @ Arve on this one and is one of the flaws I see in this article.

    I think the context plays a key role in determining if interaction is simply an enhancement versus a necessity.

    When you create a news or blog site you tend to be more focused on content which requires less input from the user.

    If on the other hand you are building an app, interaction tends to be essential to building the unique interfaces you need to receive the input from the user and accomplish a given task.

    Did Gawker done f*ck up? Sure they did, but I think the horror stories of companies doesn’t mean we go all pessimistic against Javascript which has been around since the dawn of the browser.

    I know the stats show very few people turn off Javascript and if Gawker planned things out better it would have saved them some embarrassment.

    I don’t think they were wrong with pushing for a more modern app feel out of a blog so long as you warrant the need as this article has kind of pointed out.

    I don’t personally agree with their choice but hey I also don’t manage mega online content properties like they do. I give them props for experimenting and maybe it worked out better in the end for them.

    I think with a content-rich blog it seems like its a high cost to pay a team of developers to shift to a dedicated JS framework. In a blogging context there is less of a need for JS so I agree the enhancement side of things makes sense in this context, but even that is transforming (as you’ll read below).

    In the app world Javascript is essential and I don’t see that going away any time soon.

    If you don’t build a highly interactive app experience will you disappear into oblivion? Not at all but you also won’t have as great of a user experience as your competitor who has put a lot of thought into the interactive elements and how the customer gets their data in and out of the app.

    WordPress powers around 25% of the sites on the internet. (http://venturebeat.com/2015/11/08/wordpress-now-powers-25-of-the-web/). Automattic just recently pushed wordpress.com to React for their new Javascript front-end interface. They are making a strong push for turning WordPress into an API so it can interface with JS frameworks with the merging of the WP API.

    A beloved small sibling to Wordpress is Ghost. Ghost.org runs a Node.js server stack with the Javascript Handlebars templating language for the front-end.

    I think its wise to pay attention to the key players and the moves they make before assuming Javascript is simply an enhancement for interaction.

    And to top it off in the general sense of “interaction” it goes beyond just Javascript. Its an essential part of designing any system and if I didn’t read into the article and have context beyond the title I’d be a bit confused.

    If you don’t value the user flows and essential forms of your users interactions going through your system you won’t be going anywhere real fast.

    Copy & paste the code below to embed this comment.
  19. @JamieT
    “A trivial misclosed html tag can make your site inoperable too. This is an indictment of bad development practices, not a technology. “

    Not true. Both HTML and CSS are highly fault tolerant, unlike JavaScript. Miss a closing tag, don’t enclose attributes in quotations, insert invalid attributes, incorrectly nest elements, or place raw text outside of an element and HTML still renders. Write a line of complete junk in CSS and it just skips to the next parseable line. Alternatively, I don’t need to tell you the tiny syntax deviations required to make JavaScript fail. Not only that, but in JS MVC world a JavaScript failure now equals an HTML and CSS failure, i.e. a total failure.

    “Most companies cannot afford to greatly increase their development efforts for 0.9 percent of potential users.”

    PE is not only about JavaScript support, but also about providing content to the greatest amount of users, it’s about following a model that is represented in just about every technology stack: the most basic layer followed by progressively more advanced layers, e.g. HTML-CSS-JavaScript. By making JavaScript the foundation you have now made HTML, which originally required nothing else to render, dependent upon JavaScript. You have also made CSS, originally only dependent upon HTML, now also dependent upon JavaScript. You’ve taken the most brittle and fault intolerant language of the three and made it the gatekeeper and controller; it’s like making the foundation of a building dependent upon the windows.

    Regarding costs, it is a lot cheaper to develop HTML content that is guaranteed consumable by all internet devices and then enhance for superior user experience on advanced devices than it is to start with the latest funkiness on the edge device and then find and fix the bugs and lack of support for other devices.

    I think Chris Droom (above) has a point. The JavaScript MVC supporters are behaving exactly how the Web Designers behaved towards the print Graphic Designers, with a dismissal of anything that isn’t cutting edge.

    Copy & paste the code below to embed this comment.
  20. well and good article thanks.

    Copy & paste the code below to embed this comment.
  21. Good information in artikel, so heplful.. for more information..Harga Sepatu Converse Terbaru

    Copy & paste the code below to embed this comment.
  22. Sorry, commenting is closed on this article.