Impressive Pixel

Frontend engineering is a unique discipline in the world of software engineering in that it is maddeningly heterogeneous. The markup, design and scripting we write is interpreted by a wide variety of different host environments, many of which operate in deliberately eccentric ways. All genres of software engineering try to account for heterogeneity, but F2E is among the most challenging in this regard. Jeremy Zawodny gets this, and he articulates it as well as anyone. But sometimes it seems like a hard story to tell.

As part of a series of conversations we’ve been having within F2E at Yahoo, I offered one specific lens through which to view the challenge. It’s neither complete nor mathematically accurate, but it’s useful nonetheless as a way of thinking about the dimensionality of F2E and the scope and variety of work done within it.

The thesis is that there exists a set of knowledge areas within F2E. I’m suggesting there are at least seven of these — that’s an oversimplification, but probably an acceptable one for this purpose:

1. X/HTML: Markup;
2. DOM: The abstract node tree created by the browser after it parses markup;
3. CSS: The presentational rules that tell the browser how to translate the DOM into a two-dimensional screen representation, including some limited rules about interactive characteristics like hover states;
4. BOM APIs…
5. …and DOM APIs: The rule-driven interfaces we have into the browser object model and the document object model — interfaces that allow us to alter the DOM and communicate with the BOM and that comprise the platform on which we write interactive software in the browser;
6. JavaScript: The interpreted language with which we create in-browser logic and with which we communicate via BOM and DOM APIs;
7. Data transport: The mechanisms (like XHR) and the data formats (like JSON) we use to send data back and forth to the server from within a web page.

For each of these seven knowledge areas, there are four irreducible dimensions with which F2Es must wrangle:

1. Specification: At some level, each of the knowledge areas is governed by a specification that documents how it is meant to behave. Many knowledge areas are affected by a variety of specifications — for example, "X/HTML" as a knowledge area is beholden in some respects to a series of HTML specifications through version 4.01, is affected by discussions about a possible 5.0 specification, and is also shaped in part by XHTML (and therefore by more general XML) specifications.
2. Implementation: Browser manufacturers don’t implement the specification to the letter; rather, in any given release they support parts of it, depart from it in specific ways, and introduce new, unspecified features and characteristics (XHR itself is a good example of this). Many often-used innovations in each of the knowledge areas derives from features that are (or were originally) proprietary, unspecified features.
3. Defects: If the implementation introduces a tension between what the browser actually does versus what is in the governing specification (in some cases we might call these differences "deliberately introduced defects"), there are also many differences that the browser manufacturer did not intend — accidental defects. Defects often live long enough in mainstream browsers to require accommodation on the part of the F2E world. In some cases, that accommodation results in an ecosystem of web content that will break unattractively (or even cease to function) if the defect is corrected, and as a result some defects become permanent, unspecified characteristics of a given knowledge area.
4. Theory and Practice: To deal with tensions between specification, intended implementation, and accidental defect, F2Es construct theoretical and practical approaches to each knowledge area. Semantic markup is a commonly referenced school of theory and practice within the knowledge area of X/HTML, for example.

Looked at this way, there are at least 28 different knowledge dimensions that an F2E has to care about when s/he sits down to work each day. But, of course, it would be 28 only if there were a single browser manufacturer making a single browser. In fact, there are many different OS platforms and on each of those there are numerous browsers that matter very much to the people that use them; try telling an ardent Opera user that s/he needs to switch browsers to use your website (s/he’ll switch websites instead, and rightfully so). If we factor in different browsers and different platforms, we can apply some fuzzy math to some arbitrarily selected (but quite conservative) numbers:

Again, this isn’t precise and it’s not meant to be. For one thing, it assumes that you don’t care about server-side technologies, screen readers, the hundreds of supported user-agents in the mobile world, and things like XUL and ATLAS that are wholly wed to a single platform or browser. But you may find that understanding the 672 things that an F2E has to worry about when coming to work each day is a useful way to ground yourself in the complexity of F2E and its intrinsic challenges.

Remember when webcams were edgy and cool? Or, at least, when they were cool? This one still is, to me.

Especially fun to watch Half Dome through the winter months…until the snow gets deep enough to obscure the view.