In the early 1990's I co-founded a company called Electric Communities. We were going to develop a system for interactive socialization and commerce. Unlike the current Wobbly Wobbly Wobbly, our goal was to produce a global social network that was secure and decentralized. Since the current state of the web is insecure and highly centralized, you might rightly guess that our company was not successful.
The worst technical decision I will ever make was to build it in Java. Java was a brand new language at the time. The hype around it was hysterical. Wild claims were made about its security, which we didn't trust, but Sun claimed it was going to be an open language which would give us the opportunity to fix it. When Sun reneged on the openness thing, we were trapped. I invested tens of millions into making Java into a language suitable for secure, distributed programming. Martin ("Scala") Odersky developed our compiler. Our first demonstration was a massively multiplayer 3D virtual world. It looked great, and it was fun to play. And it took 3 minutes to load the class files.
So we pivoted. We acquired two other failing social networking companies, OnLive and The Palace. In 2000 we received a contract from a major media company to develop an online gaming system. We thought that we could modify The Palace to meet their specifications. We had reengineered The Palace server into something workable, but we were lacking a client. There had been two prior attempts to make a client in Java, and both were disappointments. I didn't want to do that again.
I recently wrote a solitaire game. It has some similarities to what we were making at Electric Communities. A lot has changed.
The language is a little better now because of the array methods. I don't use most of the crap that came with ES6.
In 2000, the bugs were plentiful, and they did not go away. Every browser release fixed some bugs and introduced new bugs. Most people were using older releases, so we had to run on every release. Bugs didn't go away. Bugs only increased. Especially problematic was IE Mac. I have a suspicion that Microsoft does not put its smartest coders on its Apple products. So I had to find a way to code as much as possible in the intersection of what worked everywhere, and that intersection was constantly shrinking. Sometimes I had to
if around IE and NS differences. I am very happy that that is now a bad practice. At the time, it was the only thing that worked. The implementations of the language have gotten much better. The ES test suites have been very effective in converging the engines toward quality.
The DOM was a disaster. The standards were completely inadequate, so the browser makers would just make stuff up. The interfaces were very different from one brand to another. The only way to manage it was with libraries. The first important library was Dan Steinman's DynAPI. It attempted to hide the differences between Netscape's
<layer> and IE's
<div position=absolute>. It inspired me to develop several libraries, starting with the KA library. I attempted to hide all of the web sicknesses in the library so that our application code could be free of the consequences of browser deficiencies, differences, and bugs. Based on that experience I have long taught that you should always use a good library. Touching the DOM directly only results in pain and misery.
Since then, the web standards movement has been successful in reforming the DOM. It now operates pretty consistently everywhere. Maybe it helps that everyone seems to be converging on a single core. So I am not using any libraries now. I am touching the DOM and relying more on CSS.