Oh, javascript. Javascript, javascript, javascript. It's no secret that I don't like it. It's finicky, fickle, and prone to failure*. It rarely helps and often hinders usability and accessibility. It's a challenge on the desktop, never mind tablets or mobile.
But it looks cool. Stakeholders like how it fosters interaction, since "clicking" = "engagement". They want all the bells and whistles of Facebook or Pinterest, but aren't willing to pay for a team of javascript experts to accomplish this, so we web developers resort to the wide world of plugins available for free on the internet, more likely than not shoehorning that poor code into doing something it was never designed to do, then blaming it because it's difficult to do and conflicting with the other cool libraries that we need to use.
But web developers are at fault in another way as well - tossing in javascript willy-nilly to gain some "quick wins" or client brownie points, getting stakeholders attached to a specific style or interaction much too early in the development cycle.
I am of the strong opinion that javascript should never be required in order for an end user to successfully interact with a website. This opinion manifests as two requirements: That all design problems (or "puzzles", to use a word with less negative connotation) need to be solved without javascript, AND that we need to return back to the ideas of progressive enhancement.
Initially, to me progressive enhancement meant adding as little javascript as possible. However, I'm coming to realize that practicing it effectively also means prioritizing said enhancements and developing them strategically, in order of importance -- instead of starting with what's easy, only to have to redevelop that functionality 2 or 3 more times to avoid conflicts with higher-priority enhancements.
All of this means that, as early as possible in the design process, we need to start having discussions with clients to prioritize all of the fancy stuff. If the navigation is more important than an image gallery, then we work on the navigation first, and exclude image gallery plugins that would break the navigation.
* Failure example: Facebook widget requires linking to their server for some code. But for some reason, our site can't get to that asset right now. If this were an image, the site could display a broken image and continue on its way; but since this is javascript, the browser throws and error AND NO MORE OF THE JAVASCRIPT ON THE PAGE IS LOADED.
Posted January 24, 2016