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.

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:

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 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:

First rule of optimization - Don't

Second rule of optimization - Don't ... yet

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.

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.

Awesome article. I think you have pretty much hit the nail on the head. As a PHP Developer I run into the problem of frameworks. Everyone around thinks they are an application that you have to install… it’s so hard to explain to them that it is just CODE.

http://www.kapustabrothers.com/ Shaun

Awesome article. I think you have pretty much hit the nail on the head. As a PHP Developer I run into the problem of frameworks. Everyone around thinks they are an application that you have to install… it’s so hard to explain to them that it is just CODE.

http://www.breckyunits.com Breck

Great post. Particularly #1. I can’t tell you how many times in the past I’d cook up something procedurally in order to get it done quick or it make it run fast. Nearly everytime I’d later kick myself for not using OO as I’d always encounter similar problems in the future or would need to modify the original procedural code. The 2nd benefit(speed), as you show, isn’t actually an issue. (well, maybe in the .01% of cases where your site’s traffic explodes).

Also, might I suggest a:

#6 Design Matters More than Statistics.
The first thing you should add to EVERY website is data collection. It doesn’t matter how pretty you think your site looks, what matters is performance. Are your sales high? Are visits increasing? What’s your bounce rate? Entrance sources? So many times people squabble over design when all that really matters is the traffic data.

http://www.breckyunits.com Breck

Great post. Particularly #1. I can’t tell you how many times in the past I’d cook up something procedurally in order to get it done quick or it make it run fast. Nearly everytime I’d later kick myself for not using OO as I’d always encounter similar problems in the future or would need to modify the original procedural code. The 2nd benefit(speed), as you show, isn’t actually an issue. (well, maybe in the .01% of cases where your site’s traffic explodes).

Also, might I suggest a:

#6 Design Matters More than Statistics.
The first thing you should add to EVERY website is data collection. It doesn’t matter how pretty you think your site looks, what matters is performance. Are your sales high? Are visits increasing? What’s your bounce rate? Entrance sources? So many times people squabble over design when all that really matters is the traffic data.

http://www.scidept.com BJ Clark

Totally agree on #2 & #3. Good stuff.

http://www.scidept.com BJ Clark

Totally agree on #2 & #3. Good stuff.

http://www.techfounder.net Eran Galperin

@Shaun:
Totally agree. Frameworks are becoming another buzzword that a lot of people don’t understand.

@Breck:
I’d say design and statistics are both important aspects for the success of a website. Having one without the other can only get you so far.

http://www.techfounder.net Eran Galperin

@Shaun:
Totally agree. Frameworks are becoming another buzzword that a lot of people don’t understand.

@Breck:
I’d say design and statistics are both important aspects for the success of a website. Having one without the other can only get you so far.

tc

“Many web developers coming from a server-side language background have an intrinsic dislike for Javascript … through necessity I came to like Javascript and now consider it an indispensable skill for a serious web developer.”

They’re not mutually exclusive: we can both hate it and find it an indispensable skill, like “supporting IE”.

“All modern languages have roughly the same features and can perform most tasks equally well.”

I don’t know where you got this idea.

tc

“Many web developers coming from a server-side language background have an intrinsic dislike for Javascript … through necessity I came to like Javascript and now consider it an indispensable skill for a serious web developer.”

They’re not mutually exclusive: we can both hate it and find it an indispensable skill, like “supporting IE”.

“All modern languages have roughly the same features and can perform most tasks equally well.”

I don’t know where you got this idea.

http://www.techfounder.net Eran Galperin

@tc:

we can both hate it and find it an indispensable skill, like “supporting IE”

I liked :P

Regarding modern web languages – they differ mostly on syntax and some edge features, but not to the point anyone of them trumps the others. Hence they perform most tasks equally well – and it is mainly up to the developer’s skill.

http://www.techfounder.net Eran Galperin

@tc:

we can both hate it and find it an indispensable skill, like “supporting IE”

I liked :P

Regarding modern web languages – they differ mostly on syntax and some edge features, but not to the point anyone of them trumps the others. Hence they perform most tasks equally well – and it is mainly up to the developer’s skill.

http://www.ok-cool.com/ Tom

I’d love to have the job of the guy that’s spending his time worrying about the performance difference between OO and procedural coding. He (or she) clearly has too much time on their hands.

The important thing with any coding I think is to keep it simple. I’ve always made it a point of telling less experienced developers that the most important thing to do is ‘make it obvious’. Misused OO code is just as bad as scrappy thrown together procedural code, in fact, sometimes worse.

Also, point 1, I’m not sure having an echo inside an object is such a smart move either!

http://www.ok-cool.com/ Tom

I’d love to have the job of the guy that’s spending his time worrying about the performance difference between OO and procedural coding. He (or she) clearly has too much time on their hands.

The important thing with any coding I think is to keep it simple. I’ve always made it a point of telling less experienced developers that the most important thing to do is ‘make it obvious’. Misused OO code is just as bad as scrappy thrown together procedural code, in fact, sometimes worse.

Also, point 1, I’m not sure having an echo inside an object is such a smart move either!

http://www.beansoft.de Andy

Agreed. Especially for web applications there are a few more considerations i’ve seen ignored in too many projects so far:

I think of the famous back-button, bookmarking somewhere in the middle of the application, user double-clicking links or buttons, etc. Ideal would be using a framework/environment dealing with all these problems without any impact on the application code…

http://www.beansoft.de Andy

Agreed. Especially for web applications there are a few more considerations i’ve seen ignored in too many projects so far:

I think of the famous back-button, bookmarking somewhere in the middle of the application, user double-clicking links or buttons, etc. Ideal would be using a framework/environment dealing with all these problems without any impact on the application code…

http://www.inverse2.com Steve

Eran

I like your point about Javascript (Don’t disrespect the client side languages). Coming from a server side background I have found that it does drive me mad (not because of its OO syntax, but because I like a type-safe safety net), however it does allow you to do some powerful things!

Regarding XML and the DB (#5)… myself and a few colleagues have been working on an open source project called AjaxToaster that is designed to bridge the gap between a database back-end and the data format that a client applications wants to consume (XML or JSON). It might be something that you’d find interesting.

http://www.inverse2.com Steve

Eran

I like your point about Javascript (Don’t disrespect the client side languages). Coming from a server side background I have found that it does drive me mad (not because of its OO syntax, but because I like a type-safe safety net), however it does allow you to do some powerful things!

Regarding XML and the DB (#5)… myself and a few colleagues have been working on an open source project called AjaxToaster that is designed to bridge the gap between a database back-end and the data format that a client applications wants to consume (XML or JSON). It might be something that you’d find interesting.

Bob

XML *is* a database. It’s a navigational database rather than a relational database, which is how all databases were designed back when people thought that the relational model was a ridiculous idea that had far too much of an overhead to be practical. Even a CSV or tab-delimited text file is a database, since “A database is a structured collection of records or data” (wikipedia).

XML just isn’t a very good database.

Bob

XML *is* a database. It’s a navigational database rather than a relational database, which is how all databases were designed back when people thought that the relational model was a ridiculous idea that had far too much of an overhead to be practical. Even a CSV or tab-delimited text file is a database, since “A database is a structured collection of records or data” (wikipedia).

XML just isn’t a very good database.

http://www.techfounder.net Eran Galperin

Well obviously from my post I disagree with you, bob ;)
XML is a markup language for defining hierarchical information (and so is HTML by the way), it was not meant to be used as a database.

http://www.techfounder.net Eran Galperin

Well obviously from my post I disagree with you, bob ;)
XML is a markup language for defining hierarchical information (and so is HTML by the way), it was not meant to be used as a database.

http://www.evanscode.com/ Laran Evans

Good points. Generally I think people put too much emphasis on the tools and not enough emphasis on the skill of the developer. The best advice I could give anyone, designer, manager or developer would be to spend a portion of each week working on something outside of your comfort zone. If you consistently do this you’ll realize that most tools do almost the same exact thing as most other comparable tools. It will become clear that there’s no single perfect programming language. You’ll see that all the reasons why you shouldn’t use javascript are more-or-less bunk. You’ll discover how XML and relational databases differ, and what each is better suited for. You’ll see that you can make OO code just as fast if not faster than procedural code.

I’m reminded of MacGyver. He could build a car out of tweezers, a stick of bubble gum, a bottle cap and a peanut. He didn’t spend all his time figuring out what the absolute best materials would be. He just used what was available and did the best he could with it. As developers, designers, managers and engineers I think our time and money is best spent doing the same.

I look forward to more good posts.

http://www.evanscode.com/ Laran Evans

Good points. Generally I think people put too much emphasis on the tools and not enough emphasis on the skill of the developer. The best advice I could give anyone, designer, manager or developer would be to spend a portion of each week working on something outside of your comfort zone. If you consistently do this you’ll realize that most tools do almost the same exact thing as most other comparable tools. It will become clear that there’s no single perfect programming language. You’ll see that all the reasons why you shouldn’t use javascript are more-or-less bunk. You’ll discover how XML and relational databases differ, and what each is better suited for. You’ll see that you can make OO code just as fast if not faster than procedural code.

I’m reminded of MacGyver. He could build a car out of tweezers, a stick of bubble gum, a bottle cap and a peanut. He didn’t spend all his time figuring out what the absolute best materials would be. He just used what was available and did the best he could with it. As developers, designers, managers and engineers I think our time and money is best spent doing the same.

I look forward to more good posts.

http://www.techfounder.net Eran Galperin

@Laran Evans:
Liked the McGuyver reference :P I’ll be using that in an upcoming post, no doubt.
Can’t even count the number of times I pulled myself out of a development stew using a pair of tweezers and a stick of bubble gum…

http://www.techfounder.net Eran Galperin

@Laran Evans:
Liked the McGuyver reference :P I’ll be using that in an upcoming post, no doubt.
Can’t even count the number of times I pulled myself out of a development stew using a pair of tweezers and a stick of bubble gum…