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 got this crazy idea that maybe we could do it in the web browser using JavaScript. When I first saw JavaScript in 1995, I thought it was the stupidest thing I had ever seen. The language had improved a little with ES3. I wrote a demonstration in which you could drag and drop cartoon figures on a web page. Most of the people who saw it were amazed. It was widely assumed that JavaScript could not do that. Our customer liked that it did not require an installation process, which was important because children were expected to use their site, and there are laws about what online systems can ask minors to do.
I showed my plan to my team of experienced Java coders and asked who wanted to work on the JavaScript part. Everyone refused. So I had to write the JavaScript stuff myself. At the same time, in parallel, we were building a system that we would operate ourselves that would be ad supported. We finished both systems on time. Our customer was happy and launched their service. We launched ours as well, but there was a problem: Advertisers were afraid to place their ads next to user generated content. They were worried about obnoxious trolls saying bad things about their products in a forum that they were paying for. Eventually, the advertisers got comfortable with the model, but it was too late for us.
I recently wrote a solitaire game. It has some similarities to what we were making at Electric Communities. A lot has changed.
The documentation is a lot better now. Much of what was written back then was based on the premise that JavaScript is a subset of Java, which is false. I eventually learned that the only reliable source was David Flanagan's Definitive Guide. As good as it was, it was too big, so it was sometime difficult to find stuff. It was also incomplete. It warned about problems with the with statement, but did not say what they are. And it completely left out closure, which is JavaScript's best part. Today, we can google the MDN web docs, which I do a lot.
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 style="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.