1997: The Butterfly That Flew Through the Browser War
· 45 min read · Views --

1997: The Butterfly That Flew Through the Browser War

Author: Alex Xiang

Essays

In the previous essay, I wrote that in 1996 screens were still small, but the world had just begun to grow larger. At the end of that article, I left a butterfly behind: in 1997, I wrote a small JavaScript program that let a butterfly fly around a web page.

Looking back now, this was a tiny thing.

It was not a system, not a project, not a product that could go into production, and not an experience worth putting on a resume. It was only a small web animation. A mouse, a window, a script, an image, coordinates, and a timer were put together so that a butterfly could fly back and forth inside a browser.

But thirty years later, I feel that butterfly represents its era better than many formal projects.

Because when it flew, the Web was not yet stable in the way we know it today. HTML was a page. JavaScript was a novelty. CSS was just beginning to give pages a more serious presentation layer. Browser vendors were competing fiercely, standards were chasing reality, and even a small animation could force programmers to face completely different browser behaviors.

That butterfly was not flying on a mature platform.

It was flying through the cracks of the browser war.

First, Make the Page Move

Today, web animation is easy to write. CSS animation, requestAnimationFrame, Canvas, SVG, WebGL, frameworks, and component libraries can all produce far more complex effects than what we had then.

1997 was different.

If you wanted to make a page move, you first had to believe one thing: a browser was not only a document reader. It could execute scripts, respond to users, change page content, and turn static HTML into something with behavior.

That idea is obvious today. It was fresh then.

The butterfly probably started from the plainest thing: coordinates. There was an image element on the page, and the script kept changing its position. To make it look less mechanical, I gave it some vertical floating, some speed variation, and some boundary bouncing. The butterfly did not really fly; its coordinates changed and the browser repainted.

But that fake flight made a web page feel alive for the first time.

An imagined butterfly animation inside a 1997 browser

A pixel butterfly flying inside an early browser window. This is a period-inspired illustration.

The technical difficulty looks low today. But the hard part then was not animation math. It was browser differences.

The same script might run in one browser and fail in another. This object existed here but not there. This property had one name in one implementation and another elsewhere. This event fired in one browser but behaved differently in another. You wrote checks, tested, changed things, and remembered browser quirks in your head.

Many years later, frontend engineering grew a whole toolchain: compatibility layers, build tools, polyfills, Babel, frameworks, tests, bundlers, and components. They look modern, but at the root they still solve the same problem: the Web is open, and openness means differences; the Web is open, and openness also means nobody fully controls it.

Programmers in 1997 did not have mature tools for this. They handled differences by hand.

So that butterfly did not fly lightly.

Every flap carried a pile of if statements behind it.

DHTML: When Web Pages First Wanted to Be Apps

In 1997, the browser war was not a slogan. Every web author could feel it directly.

Netscape was still strong. Microsoft was catching up quickly with Internet Explorer and binding the browser more tightly to the Windows ecosystem. That year, Netscape Communicator 4 and Internet Explorer 4 were both released. Both browsers told developers the same thing: pages should not merely display content; they should move, change, and respond.

The fashionable word was DHTML: Dynamic HTML.

DHTML was not a single technology. It was more like a bundle: HTML, CSS, JavaScript, plus the page object model exposed by browsers. Its promise was attractive: without reloading the whole page, you could change content, style, and position on the client side.

Today this sounds like basic frontend development.

In 1997, it felt like a door had just opened. Web pages began moving from “formatted documents” toward “interactive interfaces.” Menus could expand, images could move, text could change color, and windows could respond to the mouse. A page no longer depended entirely on the server returning a new HTML document; it began doing some work on the client.

That was the shadow of the later Web App.

Of course, early DHTML was not elegant. Netscape had its layer model; Microsoft had document.all. The standard DOM had not become the shared daily ground. To build a cross-browser effect, you often did not “read the documentation and implement it”; you tried your way toward something that survived.

It felt like walking on a bridge that was not yet finished. The direction was right, but some planks under your feet were not nailed down.

My butterfly flew on that bridge.

Its meaning was not the animation itself. It made me realize that the runtime environment programmers faced was shifting from “my machine” to “the user’s machine,” from “a deterministic system” to “a complicated ecosystem.”

This was completely different from my 1996 assembly experience.

In assembly, the world was hard: instructions, registers, memory addresses. Wrong was wrong. The Web was much softer. Browser versions, user settings, screen size, network condition, and vendor implementation all affected your code. You were no longer talking only to a machine; you were also talking to standards, commercial companies, and user environments.

For later software work, this was character training.

The Speed of the Dial-up Era

If we only talk about browsers and scripts, it is easy to forget a more basic fact of 1997: the network was slow.

Going online did not simply happen when you turned on the computer. You dialed in, heard the modem make a strange sequence of sounds, and waited for the connection to establish. The phone line was occupied. If someone picked up the phone, the connection might drop. Web pages did not open instantly; images appeared piece by piece. Downloading software meant calculating time and hoping the connection would not break midway.

US Robotics 56K modem

US Robotics 56K modem. Image source: Wikimedia Commons.

That speed changed development habits.

Today we often complain about oversized frontend bundles, slow first paint, or slow API responses, but most of the time this “slow” is an experience problem. Dial-up slowness was more concrete and more oppressive. Every image, every script, every request had a real cost.

So web pages were usually restrained. Images could not be too large. Scripts could not be too heavy. Page structure could not be too complicated. You naturally cared about file size and were willing to trade features for a few kilobytes.

Later, broadband, CDNs, and mobile networks became common. Frontend resources grew larger and engineering systems became more complex. Yet every few years, the industry rediscovers “performance.”

That is interesting.

When resources increase, software eats them again. Then the next generation of programmers relearns restraint.

The dial-up era taught not only waiting, but a sense of scale.

Standards Began to Name the Chaos

Another event in 1997 looked less dramatic but had deep influence: the first edition of ECMA-262 was approved, and the ECMAScript standard formally appeared.

People later often ask: what is the relationship between JavaScript and ECMAScript?

Simply put, JavaScript is the familiar language name that came from Netscape; JScript was Microsoft’s implementation; ECMAScript was the common base that could be standardized. Browser vendors could compete, but developers could not be torn apart by vendor differences forever. The language needed a specification, even if the first version was imperfect.

The first edition of ECMA-262 in 1997 gave chaos a formal name.

Of course, a standard does not make the world better overnight. Browser compatibility problems continued for many years. Frontend developers later lived through IE6, box-model differences, DOM variations, and countless nights debugging themselves into despair.

But having a standard is better than only having vendor implementations.

The meaning of a standard is often not that it solves the problem immediately, but that it gives everyone a common direction. Without it, developers can only chase vendors. With it, vendors at least have to explain why they are different.

This is one of the reasons the Web survived.

Open standards made the Web messy, and also made it resilient. It is not as neat as a closed platform, but it crosses systems, devices, companies, and eras. JavaScript in 1997 was still crude, yet it eventually became one of the world’s most important programming languages not only because of the language design, but because it lived at the browser entrance.

Entrances change destiny.

Languages, too.

A Small Program Inside a Large Era

Later, I built many things much more complex than that butterfly.

In 1998, I began building MIS systems. In 1999, I built bank front-end systems and wrote sockets in production on SCO UNIX. Later came Linux, large company platforms, Weibo big data, recommendation, graph databases, and AI tools. Any of those had far greater engineering complexity than the butterfly on a web page.

But complexity does not always represent an era better.

The butterfly was small, but it stood at a turning point. It told me that software was moving from “programs on machines” to “experiences on the network.” Users no longer only opened executables; they opened URLs. Programs were no longer distributed only through installation; they could reach users through browsers. Interaction no longer happened only in desktop windows; it began happening inside web pages.

This affected all software that followed.

Enterprise systems became web-based. Office systems became web-based. Email, documents, development tools, and design tools all became web-based. Today we write code, hold meetings, design, analyze data, and use AI tools in browsers. The cause can be traced back to that direction.

Back then, the butterfly was only an image on a page.

Years later, the entire software industry flew into the browser.

From Certainty to Compatibility

In 1996, I was still closer to the low level: assembly, machines, memory, instructions. These things felt deterministic. If you understood the machine well enough, you could trace the problem to the bottom.

The Web in 1997 showed me another reality: not every problem can be solved by understanding one machine.

You need to understand user environments, platform differences, vendor competition, and standards evolution. Your code no longer runs only on the machine in front of you. It runs on someone else’s desk, in someone else’s browser, under someone else’s network speed. Your control decreases, while the software boundary expands.

Many programmers experience a similar step.

At the beginning, we want certainty. After working longer, we learn that real software engineering is about building order inside uncertainty. Databases become slow, networks break, browsers behave strangely, users make mistakes, requirements change, dependencies upgrade, and teams change people. A large part of engineering ability is making systems work as steadily as possible amid these unstable factors.

That butterfly did not teach me JavaScript syntax.

It taught me that the world had begun to grow larger than code.

Next: The Butterfly Lands on a Form

The Web in 1997 was exciting, but systems that could be paid for, deployed, and funded by companies soon appeared in another form.

In 1998, I began doing MIS development.

That was another world. No butterfly, no romantic browser war, no grand narrative of “changing the world.” There were more forms, fields, databases, reports, permissions, workflows, office computers, and business systems that users truly needed every day.

If the butterfly in 1997 showed me that web pages could move, MIS in 1998 showed me how software entered organizations, turned paper workflows into database records, and helped companies begin managing themselves through systems.

From then on, Delphi and Borland would become important.

The next essay is about enterprise informatization inside those forms.

IT Milestones of 1997

  • The first edition of ECMA-262 was approved. In 1997, ECMAScript received its first standard. It provided a common base for JavaScript/JScript as browser scripting languages. Standards did not immediately eliminate compatibility problems, but they gave later frontend development a direction: vendors can compete, but the language itself needs a public specification.
  • Internet Explorer 4 and Netscape Communicator 4 were released. These two browsers pushed DHTML, scripting, styles, and page object models into a more visible position. Web pages moved from “documents” toward “application interfaces,” while compatibility problems became sharper. Writing a web animation in 1997 meant balancing between these two browser worlds.
  • IEEE 802.11 was approved. The first Wi-Fi standard was approved in 1997. It was far from consumer mainstream at the time, but it began freeing LANs from cables. Years later, wireless networks changed laptops, phones, home routers, offices, public spaces, and software’s assumptions about where users work.
  • IBM Deep Blue defeated Kasparov. In May 1997, Deep Blue defeated world chess champion Garry Kasparov in a six-game match. It was not AI in today’s large-model sense, but it was an important moment when computer intelligence entered public imagination.
  • Steve Jobs returned to Apple. After Apple acquired NeXT, Jobs returned to Apple in 1997 and gradually took control again. At the time this looked like internal restructuring and product-line cleanup. Later it became one starting point for iMac, Mac OS X, iPod, and iPhone.
  • Mac OS 8 was released. Mac OS 8 was released in 1997. It was not only a system update, but also reflected Apple’s transition between classic Mac OS and the later NeXT-based line that would become Mac OS X.
  • Netflix was founded. Netflix was founded in 1997 not as a streaming company, but as a DVD-by-mail rental business. It later moved from logistics and memberships into online video and recommendation systems, becoming a classic example of the internet reshaping a traditional industry.

References

More in this column

View all posts in "Thirty Years in IT and Me"