Web Development as a science

I was talking with some co-workers this week and I commented that I think we are getting to that point in the web development industry where things need to start coming together as a science. And by science I mean a discipline that is able to give you a predictable outcome. At the moment web development borrows a lot of skills, from graphic design to programming, without forming a consistent body of knowledge. I like this quote form Kelly Norton on the Google web tool kit blog

I’ve sometimes thought that optimizing web applications is as much a science as dowsing. (No offense intended, dowsers of the world — but you have to admit it’s a hard thing to explain even when it does work out.) Even when you are completely willing to invest time and energy into optimizing an application, how do you actually go about it?

I think dowsing is an apt metaphor but what woud this body of knowledge look like?

1. Design: A pattern for designing achievable websites.

You can get a some Photoshop templates including some nice grid based designs. But seriously, don’t talk about pixel perfect development if you don’t have pixel perfect designs.

Developer: Oh, I like that transparency (but really thinking, epic fail in IE6). Are we supporting IE6?

Designer: Yes.

Developer: (To project manager) How long is this supposed to take?

And don’t even start about using JavaScript to fix PNGs in IE6. Been there, done that and it can still be a huge time sink depending on the design. You know what happens when a developer comes across a huge time sink and an impending deadline? Bugs. Sorry, guys the secret was already out in Peopleware.

2. Develop: Guidelines for solving problems effeciently – this includes CSS, HTML and JavaScript.

I think the best way forward for HTML is the Semantic web including Microformats because you can write the same mark-up and use it in many different ways. The Mozilla Development Community has this nice article about writing effecient CSS and there is a movement towards Object Oriented CSS which I like – probably because of my formal programming background. The less redundancy I have in my life the better. The rule of thumb for JavaScript seems to be “Find a framework and stick with it”. jQuery is what I use most.

3. Test: A testing framework

This is where it gets interesting because I think there is a big need for this. There’s NUnit and JUnit and all kinds of gangsta sounding testing frameworks for other languages but on the net all we have is JS Lint. No offense to JS Lint but can we have some regression testing with ketchup please? But what would you expect when we are still terrorised by the Internet Explorer Trident Engine which is built on the mysteries of the Universe? Testing is important to ensure code quality and shorten lead times.

And then you say, “But Peter, you can use JUnit with the Google web toolkit”.

Segregation vs. Integration

I couldn’t really think of a better title so this will do for now. What I am trying to get at is two approaches to getting consistent results in a web development process – less time troubleshooting and more time having fun. On one hand I can see Yahoo!’s YUI and on the other Google’s Web Toolkit and now Closure Library. Yahoo! and Adobe seem to be on the same page on this where it feels like a design led approach.


Bring me all your layouts, CSS and semantic HTML – plug it into my library and let me upgrade you.

Which is great for existing web development teams that are broken along functional lines of designers and developers. So the product of each process remains segregated: they can live independently of each other. Your HTML can have a different life-cycle to your CSS or JavaScript. This is nice because many people with different skill sets can work on the same problem. Also nice if you already have site that you want to spice-up a bit.


Google seems to be saying,

Come to me all who are object oriented and are strongly typed and I will give you HTML.

If you’ve already worked out your sweet science in Java, Python et al. why re-invent the wheel? Just port it into whatever format you need – integration. Great for code monkeys . . maybe you can fit a designer or two into the workflow but I think there is less variety in this process.

Hammers and nails

The problem with only having a hammer in your toolbox is that every problem looks like a nail. I can see how for enterprise applications Google’s philosophy is a god-send. You might already have a Java code base and all you need is a new interface or two. Write a few facade classes and you are on your way to a new intranet site or whatever.

But I am biased to the idea that the web offers such a rich range of experiences and possibilities. Do you remember how boring the internet was without Flash? All that reading, reading, reading. Having a diverse group of people working on a platform, in cross-disciplinary manner, will create rich set of possibilities.

Ideally I would like to believe that the integrated development environment will generate the best code possible but what if I want to make changes to the generated code? Maybe put in some microformats? Some hacks for IE9 perhaps? It’s the same problem that Model Driven Architecture has.

To be fair, this is an abstract thought experiment and time and experience will have their say. . and so can you.


2 thoughts on “Web Development as a science”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s