Common misconceptions in web application development

Over the time I have developed for the web, I have read and heard many assumptions about development practices and technologies. This is my list of common misconceptions in (web) development:

1. OO code is less performant than procedural code

The number one argument against OO application design from procedural advocates. This argument is based more on intuition than fact. The usual examples pit short procedural code against equivalent OO code in which procedural code comes out triumphant as more terse and performant.

//Procedural, quick and to the point!
$string = 'hello world';
echo $string;

//OO, verbose and ineffecient...
class Speaker {
	public function say($string) {
		echo $string;

$me = new Speaker();
$me -> say('hello world');

Actually, this example compares apples to oranges. Both approaches use ‘echo’ to output a string, only in the OO approach it is wrapped inside a class method. A more appropriate example for the procedural code would be:

function say($string) {
	echo $string;

say('hello string');

Which is very similar to the OO code written before. Strong application structure actually does not differ greatly between OO and procedural/functional approaches as my second example suggests, and it is mainly a function of the developer’s skill and experience.

OO methodology however gives more language features and scope constructs to deal with code complexities, understanding programming algorithms, and to handle code reuse, features that would require much more discipline and experience to implement using procedural programming only.

In reality, it is the efficiency of the language parser that will determine performance differences between procedural and OO code. There are no inherent noticeable performance differences between both methodologies for common usage in web applications. More typically in the web environment, IO operations such as server requests or database queries are the bottlenecks of performance / scalability.

Since it’s impossible to know in advance what the bottlenecks will be (you can only make educated guesses), I try to follow the Rules Of Optimization:

  1. First rule of optimization – Don’t
  2. Second rule of optimization – Don’t … yet
  3. Third rule of optimization – Profile before optimizing

It is much more important to pick a methodology that will promote more maintainable and structured code, as OOP does, to possible minor performance gains. With a well structured design, profiling an application and refactoring slow-performing code is a relatively straightforward process.

2. The backend is the most important part of development

I often see web developers treat HTML, CSS and Javascript as second class languages. While HTML and CSS are not programming languages per-se, correct implementation of both in a cross-browser and semantic way requires much experience and skill that I often see lacking in otherwise proficient web developers.

It is not uncommon to relegate implementation of those two markup languages to web designers or “client-side developers” (which are usually regarded as lower level developers) or to use auto-generating tools for creating markup.

Both approaches are wrong – the client side is an important aspect of the web development process, especially because of the unique environment a web site or application runs in on the Internet – the browser, which has many different flavours each with its own set of problems and constraints.

Javascript (or DHTML) is another domain expertise which is undervalued and yet has become such a common requirement in today’s rich Internet applications. Many web developers coming from a server-side language background have an intrinsic dislike for Javascript because of its weird OO syntax, its difficult debugging scheme and its un-uniform implementation across browsers . I would admit to once have thought the same way, however through necessity I came to like Javascript and now consider it an indispensable skill for a serious web developer.

Don’t disrespect the client side languages. Sometimes the greatest challenges in web development are found there.

3. Graphical designers are good at user interface design

* This is more relevant for web applications as opposed to web sites

While there is a connection between graphical design and UI design, graphical designers do not naturally make for good UI designers. I can not emphasis this enough. User interface and user experience design is a separate expertise from graphical design. How a user will interact with a site / application is different from how he will view it. It is connected – but not the same.

Quoting wikipedia:

Where traditional graphic design seeks to make the object or application physically attractive, the goal of user interface design is to make the user’s interaction as simple and efficient as possible

Graphical designers with no expertise in UI design tend to prefer aesthetics over usability, and this is only natural as it accentuates their strengths. On the flip side, (web) developers don’t usually make for good UI designers either.

UI design is important for creating a usable application. Make sure the right people are creating it.

4. The existence of a superior programming language

While some programming languages are considered superior to others (higher level, more featured, better syntax etc.), no one language can be considered the superior language. Debating that one exists is more a statement of personal preferences than a declaration of actual merit.

All modern languages have roughly the same features and can perform most tasks equally well. Some languages might be more suited to specific problems than others, however no one language does everything better than the others.

Some promote specific languages because of highly acclaimed frameworks developed for them (I’m referring to Ruby on Rails, naturally). While this is a more relevant argument, currently all the major languages have at least one serious framework (Django for python, Zend Framework / CakePHP / Symphony for PHP).

Use the language you are comfortable with, but don’t deride others based on your inexperience with them.

5. XML is more economic than a DB

Database are notorious for being the major bottleneck for many successful web sites / applications. It is this notoriety that prompts novice developers to seek out alternative persistence layers – and XML is the common alternative.

In general, parsing XML is slower and more resource intensive than querying a database. This is dependent on the complexity of the query, but holds true for 99% of the cases. Furthermore, databases have a much more complete language to fetch, order and manipulate result sets.

XML is a portable format for storing hierarchical data. It is useful for porting data between different databases or between databases and interfaces. However XML is not a database, so don’t treat it as one.

If you have more to add to this list, I would love to hear about it.

To know when the next article is published, please subscribe to new articles using your Email below or follow me on Twitter.

Subscribe to Blog via Email

Enter your email address to receive notification about new posts.