Levels of Impossibility

As a novice web developer I often thought that many site functionality ideas were impossible. Without experience or working knowledge of a variety of web languages even the most basic Javascript animations or ajax features throughout the internet lived in the realm of dark magic and mystery. Now, after years of developing web sites for clients, I understand much more of how things work, or at least how to duplicate it using more familiar technologies. When a client throws a unexpected feature request at me, I can normally figure out a way to add it into their project. However, I still believe that some things are 'impossible'... it's just a matter of how impossible they are.

Level 1: Truly, Undeniably Impossible

Even with all of the amazing things web developers can do these days we still have one solid restriction: the browser. A browser instance cannot affect other browser instance (unless they are linked). One domain cannot directly read another domain's cookies. Web sites cannot affect a user's computer unless the user allows it. This level of impossibility is usually not reached, since most clients want to duplicate web functionality that they've seen on the web instead of invent brand new ones.

Level 2: Sensibly Impossible

This level is starting to get into the idea that "just because you can do something doesn't mean you should". Websites are still about the end user and (hopefully) giving them a pleasant user experience. If a site functionality is frustrating the end user (popups on every page click, disabling core functionalities on a page, etc), a web developer should try to avoid propagating it. This especially includes sluggish Javascript behaviors that attempt to mimic behaviors.

Level 3: Morally Impossible

There's a reason why some generic practices are labeled 'best'. Moving styles to an external sheet, limiting the number of links in a navigation bar, or optimizing content pages for SEO rather than layout styles. Some of these are mostly internal items that most clients do not concern with, but I've had requests that violate basic SEO and security guidelines (cross-domain scripts and iframes, for example). Client requests like this can turn into great discussion starters for updating other portions of a website to a more compliant and 'best practices' state.

Level 4: Internally Impossible

Diving into different frameworks (and building my own) has given me some great experience with impossible updates. Frameworks have a horrific way of limiting developers. By narrowing down the scope of code for manageability, possibilities can easily become limited and unreasonable. Depending on how much time it will take to retool a framework and how much it will break internal practices (which may or may not be related to how important the extra functionality is), this level of impossiblity is solely of the web developer/department's creation.

Level 5: Personally Impossible

Similar to the last level, this is solely up to a web developer. One thing I do with my sites is try to limit the number and size of http requests for a website. Using sprite images, combining stylesheets and scripts, and keeping the dom minimal are all very important to me. It's not impossible to include separate styles and scripts to implement Facebook API logic into a website but it does raise overhead for loading times. I try to take these problems individually, weighing the pros and cons of each one, before adding something to a site that violates my best practices. If the cons are too much than it is impossible for the scope of the project.

As I stated before, only a few things are truly impossible. The majority of client requests that web developers trip over are based on a lack of understanding of web technologies and best practices. By explaining these ideas to the client instead of either just doing it (and feeling guilty later on about breaking best practices or internal guidelines) or simply saying 'No', a web developer should take the opporuntity to educate the client and find an acceptable solution that meets the demands and keeps the project sensible.