Blog

The Road to Front-end Engineering

November 6th, 2008

Web Development

Opera has been on something of a roll lately (at least on the development front). They recently released a bundle of research into the “state of the web” as it is from their MAMA (Metadata Analysis and Mining Application) search engine, and a few months ago started a wonderful set of educational resources for front-end people with their Web Standards Curriculum.

A little while back Rob posted about the idea of Frontend Engineers and the information that Opera has been releasing got a bit of a discussion going among our front-end folks around that idea and trying to understand what it is that really leads a person to that point.

After some self-reflection I think there’s three “stages” in the development of someone in that sort of role.

Stage One – The Basics

The basics begin with some learning about the browser application itself (speaking in broad terms, of course, since the various specific applications and engines all have their own minor differences) and how it sees the world. The browser is a reader of text, but it’s not a human reader. Human readers look at a page of text and see a large bold line at the top and say “Ah ha! A title!” followed by blocks of text separated by lines of whitespace and think “Ah ha! Paragraphs!”

But a browser sees only the text, the application itself can’t make the same sort of vision-based semantic leaps that a human reader would make. That’s where markup comes in. If we invert the process of making that semantic leap and instead send the browser a file where the text has the semantics represented in it, then the computer can apply the visual styles for humans based on that data.

To me, that’s really the key lightbulb moment of the first stage. Following that you can start to see that by using the elements of HTML to send semantics to the browser, then the visuals can be applied to them automatically. Enter CSS for controlling that display of elements and you begin to see the forest for the trees.

Stage Two – Apples and oranges, never the twain shall meet.

The next “Big Thing” as it were, is usually reaching the point where you can work with the various moving parts of a web page while keeping them all separate. Keeping CSS in external files rather then embedded in a document using STYLE tags, applying JavaScript to the page unobtrusively so that the page can function even with JS disabled. Understanding that while the three can remain separate, they can still interact or even change one another (as in the case of using JavaScript to change the CSS class applied to a page element to show or hide it from view).

Stage Three – The cognitive leap

I think the largest “leap” comes as a side-effect of project workflow. (At least it’s easy to identify it that way based on the workflow we usually have around the office here.) Designers do what they’re good at, and then hand off their Photoshop comps to the developers who then translate the designs into HTML. Being able to see a design and start to make the translation while looking at it is the big cognitive breakthrough that I think even experienced front-end folks still strive for. Visually identifying things like levels of headers and their variations, how the parts of a page should be positioned, what order some items in the source code should go in to allow for easy translation to other media types, etc. All of these things build on top of the understanding of everything from the previous stages and provide the stepping stone to doing even better work.