The job of a web developer (or front end engineer or interaction architect or web designer or [insert your job title of choice here]) is in a constant state of flux. Best practices that were the cat’s pajamas in the end 90ies are terrible solutions now and solutions that sounded like science fiction then are feasible now.

Browsers are getting better

The environment our code is executed in is still largely unknown but at least the software that renders what we develop becomes more and more sophisticated and reliable. Whilst we can thank the browser vendors to open up more and more to our needs (with IE8 now rendering by default with the new engine as per the latest news – cheers!) we have a different challenge ahead of us, which is once again a change in the market and usage needs of web surfers.

Challenges of the past

This is nothing new - after all we faced it before:

• In the beginning browsers and slow connections were our main boundaries. Making sites work and pretty was the main issue in an environment of flaky browsers and low-spec machines.
• In the late 90s and the start of the millennium we needed to explain to clients that WYSIWYG editors are a quick solution but do not result in maintainable and universally working web sites. We did this battling the PR of the companies building software that promised to make our jobs redundant.
• After that it was the CMS vendors satisfying the need of a market to constantly change content without touching the markup. The solution? Just use a (can you guess it?) rich text WYSIWYG editor and templates to build your sites.

None of this was really scary to a clever developer as most likely you already used a sort of templating engine or IDE to create static pages for you. The challenge to move from static pages to writing templates for CMS wasn’t that hard then.

A change in perception of web site rendering needs

The main challenge was and is that clients need to grasp that the benefits of templating also come with a few drawbacks. These are first of all that you can’t design every page differently and you don’t know how much or what text will be used in the final page. If your CMS has hundreds of templates it becomes as hard to maintain as static pages and you wasted a lot of time and money.

To me, acknowledging these drawbacks is great step in becoming more mature developers and content producers: we embrace change as a given rather than just trying to prevent things from breaking. My classic way of doing that was battling the “This link is three words, so we don’t need more space” statement by showing the German or Finnish translation for these three words, subsequently breaking the layout.

There is a new challenge on the horizon that will become more and more important over the next years. I’ve talked to several companies and we all seem to go the same way on that. Here’s what web developers have to face now:

The web of data and modules is coming – be prepared!

All the companies I talked to are moving away from a page-based concept of web publishing to one that is a canvas with independent modules. These modules could be of your own making – actually most enterprise level CMS work that way already - but will subsequently also mean third party modules and modules the site user can choose to add, remove and customize.

This is a wonderful concept as it allows us to work a lot faster, more user-focused (by offering content that is related to interests and profile) and allows for parallel development of different modules. The problem however is that the current technologies we render content in browsers with are not catered for that.

The main challenges are the following:

• styling and UI consistency
• performance
• security

Styling and UI consistency is a real issue as the technology for styling documents in user agents – CSS – is by definition not catered for independent modules. The main power of CSS is the cascade – you define a setting once and let the browser apply it to every element that matches a selector. This allows you to create wonderfully small CSS files that are easy to maintain as you can change all the look and feel by changing a few selectors. If your CSS solutions have IDs and classes on every HTML element then you haven’t played the technology to its strengths.

If the modules we’re talking about are built to blend into a consistent look and feel and just need some colour changes or other minor display changes then this is not really a problem. However, if you are afraid that CSS settings inherited from the page CSS and parent elements will render your module unusable you are in trouble.

The missing HTML element

HTML has no <reset> element that would allow you to override the cascade. For now, the consensus for a lot of companies seems to be to use <iframe> when they need to have a fixed look and feel that is not allowed to inherit from the main document.

This, and other hacks like inline styles or artificially enhanced specificity with several IDs and classes doesn’t seem right and results in massive CSS files that slow down the overall page.

The use of iframes hinders the performance of the page as each needs to be loaded separately. In a perfect environment, you’d want the document to render in one go with as few HTTP requests as possible.

On the security front, iframes are actually a nice-to-have as they’ll “sandbox” the (possibly third party) scripts in the different modules. From an overall application perspective, this is a hindrance though as you’d want to communicate between modules without having to resort to a server-side component.

In any case, there are a lot of new challenges for us to face in the nearer future and I for one think it is a great chance to marry the knowledge of UI-focused web developers with backend engineers to build a new way of defining web applications.

Articles on-topic:

• Event driven application design
• The YUI Module pattern
• Caja - an attempt to create secure JavaScript

We’re going to watch this challenge closely and are happy to hear your thoughts and solutions.

Chris Heilmann