How Programmers Stole the Web

This article is going to come as a shock to computer engineers. Unlike the Grinch, who set out to steal Christmas, engineers not only had no intentions of stealing the web, most don't even know they pulled it off.

In the late 1970s, a great flood of creative talent, drawn from the ranks of people who had never before touched a computer, took to the keyboards of the early microcomputers and started a revolution. The early programming environments and languages were simple, natural, and accessible. Within five years, that group had been disenfranchised by the advent of “serious” computing environments, such as Pascal and C, and software settled back down to being the business of professionals.

With the advent of the web, another even greater flood of talent was unleashed, but this time the end came sooner. Within two years, the originally simple HTML environment had become clouded with hacks on top of hacks, as the C++ boys moved in and took over. The new talent could only continue to produce pretty pictures, while the traditional priesthood again took up the real work of programming. The web has stagnated ever since.

How were the creative types pushed out, in favor of the engineers? By a surprising, if traditional, technique.

Enforced illogic: The key to stealing the PC

Engineers in effect stole the personal computer by building cumbersome, illogical development environments that no one other than an engineer could possibly understand.

The key to all of this is enforced illogic. If you asked one hundred programmers what sets them apart from the general populace, they would probably claim superior logical abilities. They do have superior logical abilities, but that is not what sets them apart. Millions of people have been able to learn and apply logical languages, such as BASIC. They may not be as good as many engineers in manipulating that language to its fullest, but they can muddle through well enough to create some really marvelous programs.

What common folk are not good at is memorizing totally illogical systems. The early personal computer converts did really well as long as they could work in an interpreted BASIC environment, but that environment was soon ill-supported in favor of UCSD Pascal and C.

Programming languages themselves are not typically the main source of illogic. the source more likely lies in the environment in which the program must be developed. The most inconsistent and complex environments can still produce perfectly logical compiled code. And the more complex and illogical the environment is, the more likely engineers will flock to it, not because they intend to exclude anyone, but because they really love the challenge of complexity.

Niklaus Wirth designed Pascal to force students to follow his philosophy of strictly-structured, top-down design. Those like me who naturally favored the fast, fluid interactivity of the state machine had to expend inordinate energy getting around his enforced discipline. Pascal was no place for the interested amateur.

Other advanced languages, such assembler and C, were not terribly complex in themselves, but the environments in which applications were to be developed were downright weird, with mines scattered about everywhere, ready to blow the inattentive programmer out of the water. They, likewise, were no place for anyone but the professional to tread.

By the time the Macintosh and its mimics came along, people who could have radically advanced the breadth and depth of software had been effectively excluded, and the explosion of creativity that had occurred at the beginning of the PC revolution failed to reappear.

Stealing the web

The web propelled the world forward with an accelleration never before seen. However, that explosion was fueled with tools more primative than have been seen in thirty years. HTML was designed to produce only pretty pages, with crude linking between. It lacked the most rudimentary capabilities of the early micro. If the web were to do anything useful, a language that would support traditional computer logic would have to emerge, and emerge quickly.

JavaScript, the ultimate hack

In desperation, the good folks at Netscape threw together JavaScript, a patch necessary to keep the fledgling company and their thousands of drowning developers alive. What the engineers failed to realize was that only programmers like themselves were being thrown a life preserver; while the majority of their site developers slowly drowned.

So what was—and is—so wrong with JavaScript, and what about it cut all but professionals out of the loop?

The JavaScript creators had to figure out how to combine their new code with existing HTML, and they had to do it fast! As a result, they lacked the time to sit down and figure out how to extend HTML in a fundamentally new direction. Instead, they opted to just run the two together at high speed, and depend on users to understand enough about the fundamental nature of computer languages to figure out the bizarre result.

Let's hide it!

The earlier browsers were most unforgiving of new constructs popping up in the middle of web pages, so the JavaScript developers decided they had to hide the code, resulting in the greatest, most persistent hack in computer history. Instead of writing the code in the normal code space, they hid it inside the comments of the other language! Now, for those of you without an engineer's superior ability to handle illogic, this one may be a little hard to follow, so permit me a metaphor.

HTML is all very pretty, but it doesn't do much by itself. JavaScript is the engine for the HTML car. So let's say you buy a really sleek looking sports car and decide, a couple years later, that you would really like to install an engine so you could actually make it go, instead of just having it sit there and look pretty. You've been told that such a task is beyond you, so you take it to your neighborhood engineer.

When you get the car back, your wallet is empty, but your car now actually runs, and runs well. Your friend, Harrold, drops by the house and asks to see your new engine. So you open the hood and, lo and behold, there is nothing there! You look in the trunk, but there is nothing there either. You then search the car from stem to stern, revealing nothing for your efforts. Finally, having disassembled the side panels, cut in the seats, and exhausted every other possible avenue, you open the manual. And there, in the manual, is your car's engine. Not a description of the engine, not a picture of the engine, but the engine itself. In the manual. Illogical? You bet! And that's exactly where JavaScript is, in HTML's "manual," its comments.

This would likely have been plenty to throw off all but those most talented at illogic and confusion, but it was made worse. HTML and JavaScript, coexisting within the same file, did not share a common syntax, so that, for example, if you want x to equal 3, you must say x=3 in one language, but say x="3" in the other (notice the added quotes.)

Putting quotes around an integer variable flies in the face of what those millions of BASIC users learned. It also requires the developer to shift logical gears several times a minute as the site is worked on. Enforcing maximum self-inconsistency knocks out everyone but the most die-hard engineer.

And from whence arose this new syntax? It was derived from, and I am quoting here, "the familiar C++ syntax." Familiar to whom? Certainly not the millions upon millions of people who know BASIC. Certainly not the millions upon millions who know HTML. It was familiar to the select cadre of engineers at Netscape, along with all of their friends. Did they set out to be exclusionary? I'm sure not; they just simply adapted the tools with which they themselves felt comfortable.

(VB Script is based on the familiar BASIC syntax but, inexplicably, it doesn't seem to be cross-browser, cross-platform. Go figure.)

Solutions

What occured resulted from an emergency need to provide something—anything—that could enable ecommerce and other weblications. However, this hack that should have been temporary at best has been perpetuated, with no end in site. Why is this being allowed to go on? Because the enginneers who could and should be doing something about it display a complete lack of understanding of the development population.

None of the internet committees have ever stopped for a second and said, "Hey, we seem to have left 99% of the population behind!" They haven't looked, they haven't known, they haven't cared. They were covered and so were their friends, and that is as far as it went. To everything else, they remain oblivious.

Solution one: Fix the engineers

Engineering schools have been turning out programmers who are clueless as to the wants, needs, and capabilities of their users for way too many years. It is time they got their act together. It's not like the schools don't know they have a problem; it's just that many of them have just chosen to ignore it.

No one should be able to graduate with a major in computer science without a thorough, demonstrated understanding of the capabilities of their users. And that should include those students that intend to spend all their time in the bowels of the computer, developing OSs, languages, and development systems since, inevitably, their efforts are visited on everyone.

Students should be required to take at least one course in human-computer interaction. That course must include watching real people try to find their way through software each student or team of students has written. Only by seeing the consternation on their users' faces can students realize and begin to address just how out of touch they really are.

Solution two: Address the immediate problem

HTML is good. It is self-consistent, well-thought-out, and, as far as it goes, well suited to purpose. XML is equally well designed, and picks up, data-wise, where HTML leaves off. Dynamic HTML should have formed the basis of the replacement to JavaScript, but, unfortunately, the dynamics in Dynamic HTML comes from good old JavaScript.

We need another working group, like those able fellows that brought us XML, to start working now toward a simple, integrated replacement for JavaScript that extends, rather than confuses, HTML and XML.

Solution three: Take control

The human-computer interaction community has not been properly represented on the standards committees. As a result, while much good work has been done in establishing standards for the hardware and systems communication, little has been done to address the many problems facing would-be users. The HCI community, through SIG-CHI and other organizations, needs to step up to the plate.

Why give "equal access"?

Engineers are not necessarily content experts in anything but engineering. We have cut off all the doctors, lawyers, artists, mechanics, architects, teachers, psychologists, historians, philosophers, salespeople, farmers, film makers, and journalists who are those most likely to break new ground. (It is ironic this has occurred just as the engineers are enjoying their own renaissance in Linux.)

Remember Dan Bricklin, that MBA student back in the early PC days, who turned the traditional paper-and-pencil spreadsheet he'd been taught into an electronic version called VisiCalc? It's people like him who have been responsible for the real revolution, and, until we re-enfranchise them, this renaissance is officially dead.

Don't miss the next action-packed column!
Receive a brief notice when new columns are posted by sending a blank email to asktoglist-subscribe@yahoogroups.com.

return to top