What are the most dreaded antipatterns in web development?

Commentary: Web developers do tremendous good but also, occasionally, fix problems with really bad solutions.

Development web, developer.

Image: iStockphoto/oatawa

Ever since Tim Berners-Lee wrote the first webpage in 1991, web developers have delivered seemingly endless innovation. Most of that innovation is great--but not always.

Begin cofounder Brian LeRoux asked an innocent question on Twitter: "What is the most dreaded web development antipattern?" An antipattern is a "commonly reinvented but bad solution to a problem." In other words, it's developers applying fixes that are worse than the problems. 

What does that mean? Well, let's take a look at a few examples from web development.

SEE: The best programming languages to learn--and the worst (TechRepublic Premium)

We come in peace

Take, for example, those sites that hijack the CTRL+F (find in page) shortcut to replace it with their own custom site search. You can hit CTRL+F twice to circumvent this nit, but it's an annoying case of developers thinking they're doing site visitors a favor with custom search, while slowing a significant percentage of their users down. Nor is it simply on vanilla webpages, as some have pointed out: "Stash/Bitbucket also does this. They recently removed it from the PR diff view but are still doing it in source view." 

Or consider feature flags, a "popular" peeve of many developers. A feature flag should be useful, right? A feature flag allows a developer to toggle on/off functionality at runtime, thereby enabling you to give users a tailored experience. While some developers swear by them, others swear at them. You don't have to dig too far to see the potential problems with feature flags: permissive access to the flags can result in unintended impacts on users (if someone flips the "off" switch when customers expect the functionality to be "on"), or inadvertent reuse of an old flag can result in nearly a half billion in losses (and a Wikipedia eulogy). 

SEE: Developer code reviews: 4 mistakes to avoid (free PDF) (TechRepublic)

And then there's the disconnect between URIs and the output, as Corey Ward called out. Refreshing a webpage should keep you where you were (composing a tweet, reading a tweet, etc.) but instead forces you to scroll back through tweets to get back to where you were. The problem, as he explained, is that the URL possesses very little state; is "nearly all client-side and ephemeral." Apparently this is a developer's way of keeping things "fresh," but it mostly manages to disorient the user. (Related to this? "AJAXing down page content and not altering the URL textbox--even with an anchor link! So on a reload you [lose] your browsing state.")

But wait! There's more.

How about CAPTCHAs that are so hard to decipher (due to bad fonts, etc.) that they confuse people more than they outfox the machines? Or what about web developers who simply want to help you stick with their site...by altering your browsing history such that hitting "back" keeps you right where you were? And shortening URLs to make them easier for users to grok, and thereby losing the human readability of a URL such that they become harder to grok?

And so on. But let's return to where I began: Developers are amazing, and web developers build the things we get to use every day, all day long in our browsers. For all that amazing, however, these antipatterns arise far too often, sometimes because developers are focused on their own business needs, and sometimes due to not listening to their users through A/B testing or other means. Any developer who wants a refresher on what not to do can keep Leroux's tweet thread bookmarked (which, fortunately, won't disappear when you hit refresh). 

Disclosure: I work for AWS, but the views expressed herein are mine

Also see