Thursday, September 19, 2013

Why Some Web Sites Suck

I am an active Internet user. I visit and use a lot of different web sites including those for all kinds of e-commerce and utilities. Being at the same time an experienced professional web developer allows me to understand why some web sites are not as good as others and some of them simply suck. The first and foremost reason from my experience is that web site's developers do not follow web development best practices and most likely do not test their creations thoroughly.

In this article I am trying to analyse and describe most commonly occurring problems not visible to a non-professional eye but significantly affecting users' experience.

Base technology platform selection

Often a web site could be built on top of a platform that is familiar to a development team but not necessarily a good choice for a new project but sill would be selected. One particular example is a high traffic e-commerce web site built upon Microsoft Sharepoint Portal Server because the developer team used this technology for a corporate news portal. The platform choice always brings its limitations and must be validated against a particular web site goals and usages. How fast do you expect it to work? How cross-browser compatible do you expect it to be? Those and other similar questions should be asked to make sure the technological platform choice is proper.

Web development framework

Obviously the platform choice limits the options for a Web development framework but if you are a .NET developer you most likely have at least two choices: ASP.NET WebForms and ASP.NET MVC. Both frameworks are modern first-class web development tools and support all the recent technological advances of web development. However regardless of the framework choice a team needs to make sure it uses all those advances and follows known best practices for a selected framework.

Most frequently noticed ASP.NET development bad practices

When I come across a web site that I don't like but still have to use I usually take a pick at the source code and easily spot some from the known bad practices listed below.

  • HTML 4.01 Transitional. Remind me what year is it?
  • JavaScript and CSS references neither bundled nor minified. Page load time, anyone?
  • Inline JavaScripts that are neither minified nor obfuscated. See the previous point.
  • Inline JavaScripts do not use OOP: still the old school functions only.
  • Inline handling of cross-browser differences like "<!--[if IE 7]>". Well, this is really old school. No need to do that any more especially with JS libraries like jQuery.
  • Inline CSS using ASP.NET long IDs. Shame on you, development team. That was considered poor poor practice since I can remember. Basically it's just a hack.
  • Still using long ASP.NET IDs. You really need to do your home work and read documentation.
  • Viewstate embedded right on a page. No comments here. If I see that my only hope that it's properly encrypted. How fast have you expected it to load?
  • Still using hidden input elements to manage state. Have you considered other methods like Session maybe?
  • Still using server controls for simple HTML like 'a' or 'li'. I call this lazy and I want to blame your team's coding best practice policies for that.
  • Multiple different JavaScript libraries are present for example jQuery and Microsoft Ajax, that functionally overlap with each other. You do need to make up your mind and pick up just one.


Try follow the suggestions below as they are proven best practice and help develop much better web sites.

  • Use HTML 5.
  • Minify and bundle CSS and JavaScript files. Not only doing that improves web site load times but also makes development and maintenance easier. Take a look at and also try to search for ASP.NET Bundling.
  • When develop on JavaScript treat it as a first class programming language and apply all the same practices as you would for a server-side language like C#. Read this and notice that it's from the year 2009.
  • Use proven JavaScript libraries that handle cross-browser compatibility well and do not try to invent your own wheel.
  • Implement well known solutions for hiding framework's specifics like client IDs, Viewstate, etc. Even though you need to use them it does not mean you cannot do it right.
  • Always prefer server-side technique instead of client-side for handling application state. If nothing else Session is your best friend.
  • Learn and use HTML directly for simple cases instead of server controls. It's not 2001 any more and you call yourself a Web developer.
  • Do not use multiple client-side libraries that functionally are similar. Not only that makes development and maintenance a nightmare but also tells a lot about your software design skills. Make your choice and use the best tool for your job.

User Experience

It's enough of technical stuff. Let me become just a regular user and tell you that when a  web site is slow, confusing, inconsistent and not cross-browser compatible it sucks. Test it thoroughly and remember the web site is your professional resume. 


This post was not intended as a thorough review of web development best practices and more like a spur of a moment cry-out, but come on! It is 2013 and professional web developers are supposed to build Web 3.0 web sites today for tomorrow and not for a day before yesterday. It also touches me personally when I visit web sites with similar issues because they bring shame on all the web professionals not just those who worked on a web site. Colleagues, please listen up and make improvements. Everybody will like that.