Geoff Chappell - Software Analyst
DRAFT
If it’s not already obvious from what you’ve yet seen of this website, it soon will be: I am not a web programmer!
I do, however, write a website and as much as anything is ever just one person’s work, this website is all my own work. For better or worse, that includes the writing of text in plain English—for, sadly, I’m also not really a writer—and it includes the web programming too, from the HTML markup, through the CSS formatting, to the JavaScript.
This website’s scripting is nowhere near the most sophisticated that has ever been written, but it’s not insubstantial. To weigh how much the scripts contribute to the site’s appearance, compare with the bare presentation you get when scripts don’t run. Before you dismiss me as crazy for thinking you’ll go to the trouble of reconfiguring your browser to disable scripts, please consider that my scripts let you simulate: click here to open a window (or tab) for just this one page to show as if the scripts hadn’t run.
Do this and the new window shows you just the document page as written. That you ordinarily see the page with slightly different styling and with separate panes at the top for a banner and at the left for a table of contents (TOC) is because of scripts. That you can expand the TOC in multiple branches according to whatever relations you happen to find as you browse is because of scripts. Also the work of scripts are the movable divider between the TOC and the document pane, the context-sensitive tooltips that show while you operate the TOC or the divider, and everything else that’s interactive on many of the site’s other pages (as with tooltips that clarify for you whether some technical term is formatted in bold because it’s the name of a function, a structure or who knows what else).
People call themselves web programmers for having written scripts that do a lot less or which farm the work out to third-party libraries (and still do not very much, especially for all their bloat). So, I perhaps should not be saying “I am not a web programmer.”
But, truly, I’m not a web programmer. I’m even less of a web programmer than I am a writer. At least I have written elsewhere. I have even been paid to. In contrast, I have not done any web programming except for this site—and I almost certainly never will.
I am, however, more than merely competent as a low-level Windows programmer, in no small part because I am supremely accomplished as a reverse engineer of Windows. This gives me a possibly unusual perspective on web programming.
For all its versions, there is just the one Windows. Given that my attention is directed only to Windows on real computers, there are just two processor architectures to deal with, and they anyway are closely related. For all that Windows has grown, it is still mostly true that if something about Windows interests me enough—or bugs me enough—then it’s not completely impractical for me to find the relevant binary code, pick it apart, and discover what’s going on. I can do this to whatever depth I want in whatever detail I want. For many problems of Windows programming, it is feasible to answer what Windows is doing that’s unexpected (or even wrong) and to develop a true solution. There is a sort of precision to it.
Justifying the depth and detail is helped by the reverse engineering of Windows being, in effect, my field of study for research and writing. If what I find is interesting enough, which it often is, it becomes the content for a write-up. I might not finish the write-up. I might not publish it. But writing about Windows is plainly much of what I do. If not for the study, there’d be no writing.
Even without the reverse engineering, I might still do pretty well with Windows programming because there is a stability to it. Say what you will about Microsoft, and I certainly do disparage them for many of their attitudes and practices, but something they have almost always attended to very well is backwards compatibility. In general, a sound solution last year will still be a sound solution next year—so much so that you can reasonably claim surprise if a program written a quarter-century ago does not still work on the latest Windows version as well as it ever did on any long-gone version.
Web programming is, for me, some sort of opposite of Windows programming on nearly every point.
There never has been just one browser. Though there is just the one standard, give or take, for each of HTML, the DOM, CSS and JavaScript, the many browsers implement selectively. Even when all have some implementation, they may interpret differently. Even if the interpretation is uncontested, the implementations can have bugs—and, of course, different implementations have different bugs. Studying browsers like I study Windows is wildly impractical. There are too many and they are spread too thinly to justify the effort that I know is needed for depth and detail. It might be just about practical for a programmer whose work is to maintain a particular browser (including perhaps to study a competitor’s), but it seems not to be, given the ease with which I’ve encountered problems even in very old functionality. The best that’s realistic to hope for with browser problems is that some hack is seen to work and is supported by general arguments for why it should work, preferably hedged with some awareness of what particular cases might cause it not to work. There is no sort of precision in this.
In the early days of my experience with web programming, Internet Explorer was still overwhelmingly the most used browser. By regarding it as part of Windows (a perspective which Microsoft had been happy to encourage), I did frequently justify studying its behaviour and bugs. Even then this was a stretch. I study Windows. I write about Windows. I write in HTML, style with CSS, and make it interactive with JavaScript and the DOM. None of these, to me, are things to study. They are things that should just work.
WRITING IN PROGRESS