Let's face it, web-design has had some huge anti-patterns to grow out of. Luckily, I started a bit later in the game where things like the new HTML5 and CSS3 specs helped remove some of these headaches. But, there are some things that get confused as anti-patterns in Web-Development when they are actually best practices. Unfortunately because of past anti-patterns we ignore major technolgies in our field.

Tables

In school, I remember playing with HTML (XHTML something if we want to talk about the spec) and it was a wonderful land of yellow font on purple backgrounds. Javascript powered snow and GIFs were just icing on the cake. It was a land where if you didn't have Dreamweaver or something similar, your site likely would turn out looking like a slightly colored version of whatever your user's browser decided to do that day. These were the days of table layouts: everything was backgrounds slices and magical whitespace to move things around the page for designing.

Then, HTML5 and CSS3 came out and said "DEATH TO TABLE LAYOUTS". The argument was great: don't use tables when you can wrap content in semantic markup. Even better, you no longer needed a WYSIWYG editor to make a sensible design with more advanced features. But, then somewhere in playing developer training telephone, the message went from "stop using table layouts for content" to "HTML will soon not allow <table> tags." This is absurd, but many young (and some returning devs) were caught up in this idea. Suddenly if your portfolio said HTML5 experience and you had a table on any of your portfolio peices, you were a lier.

But, this went too far. I was at a user group touting my handspun HTML5 over WYSIWYG editors and one of the gents said "If you're using HTML5 why do you have a table there?" Well, the site was a result listing showing multiple properties so there was a table. The funny thing is: <table> are the only semantic choice for TABULAR data.

Query Strings

If you read any tutorials, take a class, or watch a video in web development, you are immediately hit with the statement that "Query strings are evil." It's presented as fact. There's a good reason for the adversion as we have grown out of the age of a form submitting login information on a get request. If your app ever has a login URL that looks like http://site.com/login?user=john&password=1234 just go home, you're drunk. That's great, we know not to use query strings for login, but why is it a big deal that we should leverage query strings.

Since the popularity of frameworks such as Rails, Django, Code Ignigter, and Laravel, web developers have gone crazy to make semantic routing. It started with RESTful routing, but like many things on the game of self-taught telephone, the world went wild. Soon, users were using raw URLs for everything: customization and all. If it needed a page refresh then it should have a nice flashy URL. All over I have seen Rails apps (and other frameworks too) that have searches, sorts, and all types of things in the raw URL. But, these are optional parameters that could be assigned in any order, and don't need to be first class citizens. If you have a URL that looks like http://site.com/resource/2/search/homes/type/3-3/ go sit in a corner and think about what you did.

So, with the power of REST and APIs, developers soon started to hide these options behind POST requests and Javascript AJAX magic. But, this actually breaks REST principles: POST requests should have some type of persistance in the server, you are using POST where a GET request should be used. And, we break the power of bookmarking as the URL only brings us to the standard URL and it can neither remember our previous state or make a POST request from a bookmark.

I think you are starting to understand the simple solution here: Query Strings. Yes, responding to them can be a headache, but they are the cleanest and predictable user experience. But, query strings are for asking information that modifies the existing request. Think of when you are sorting, searching or modifying the presentation of data: these are optimal times for query strings.