With 2020 hindsight (literally: it's now the year 2020! ;), I think Netscape should have just gone all-in on JavaScript, forgotten about XP/COM and its ilk, and made JavaScript itself the hub for extension and component integration, by giving it an excellent robust native code integration and extension API like Python has, and plugging things into JavaScript directly, instead of plugging things directly into the web browser itself with XPCOM or NPAPI or ActiveX, and thumb-tacking JavaScript onto the side as an afterthought, like a second-class red-headed bastard stepchild.

It wouldn't have been "rocket science": Python already existed at the time, with an excellent extension and embedding API, and was well known and widely used that way. TCL was another contender that also had an excellent native code integration API, although it was a much worse language than Python.

But there were politics around TCL, because Sun had hired John Oosterhout, its author, and arrogantly unilaterally announced that they were making TCL the web's official scripting language by administrative fiat, leading to the great "TCL War" kicked off by RMS's infamous but insightful "Why you should not use TCL" posting. Then Sun dropped TCL like a hot potato, and started pushing Java obsessively instead.

https://vanderburg.org/old_pages/Tcl/war/0000.html

https://news.ycombinator.com/item?id=17059077

And of course NetScape also went a long way down the misguided road of Java applets, and worse yet "100% Pure Java TM", by announcing they were going to rewrite the entire browser in Java. In which case, instead of cloning Microsoft COM and using XP/COM as a component extension hub, they would have ended up being stuck with Java's awful "JRI" native code integration API, which was eventually superseded by the also-awful "JNI".

The problem with using Java as an integration hub was that Sun was ideologically opposed to integrating Java with any other languages, because they thought everyone should throw away all their own code and rewrite everything in "100% Pure Java TM" (linguistic supremacy instead of linguistic inclusivity).

To encourage or even allow developers to use some other language than Java would be to admit that Java wasn't perfect for everything and superior to every other language, which Sun couldn't bring themselves to do after launching their "100% Java TM" campaign. So they tried to shame and refused to support anyone who wanted to integrate Java with native code, instead of rewriting everything in Java from scratch, like Netscape tried to do but eventually gave up on.

So Sun downplayed and strangled JRI in the crib, and they also didn't give a shit about its successor JNI either, and let it wither on the vine, because they refused to recognize the importance of using any other language than Java, once they got obsessed with their "100% Pure Java TM" craze.

NetScape suffered from the Java/JRI albatross around their neck for a long time:

https://en.wikipedia.org/wiki/NPAPI#LiveConnect

>The disadvantage of LiveConnect is that it is heavily tied to the version of Java embedded within the Netscape browser. This prevented the browser from using other Java runtimes, and added bloat to the browser download size since it required Java to script plugins. Additionally, LiveConnect is tricky to program: The developer has to define a Java class for the plugin, run it through a specialized Java header compiler and implement the native methods. Handling strings, exceptions and other Java objects from C++ is non-obvious. In addition, LiveConnect uses an earlier and now obsolete application programming interface (API) for invoking native C++ calls from Java, called JRI. The JRI technology has long since been supplanted by JNI.

I wonder why NetScape didn't choose Python in the first place, instead of inventing their own language or using TCL or Java. Lua would have also been a great choice, but it wasn't nearly as far along, mature, widely supported, and popular as Python was at the time. It was probably because they just wanted to invent their own language, and not use something off-the-shelf that was already widely supported and just worked: NIH.

Here's some other stuff I wrote about the development of component technologies and Java during that time:

https://news.ycombinator.com/item?id=19837817

>Wow, a blast from the past! 1996, what a year that was.

>Sun was freaking out about Microsoft, and announced Java Beans as their vaporware "alternative" to ActiveX. JavaScript had just come onto the scene, then Netscape announced they were going to reimplement Navigator in Java, so they dove into the deep end and came up with IFC, which designed by NeXTStep programmers. A bunch of the original Java team left Sun and formed Marima, and developed the Castanet network push distribution system, and the Bongo user interface editor (like HyperCard for Java, calling the Java compiler incrementally to support dynamic script editing).

https://donhopkins.com/home/interval/pluggers/

https://donhopkins.com/home/interval/pluggers/requirements.h...

https://donhopkins.com/home/interval/pluggers/navigator.html

https://donhopkins.com/home/interval/pluggers/java.html

I'd love to hear from somebody who was at Netscape at the time, about what they thought of Python, whether or not they fairly considered it, and why they didn't end up using it instead of rolling their own language from scratch. And also what Netscape's view of the great "TCL War" was from their perspective, and why they chose to collude with Sun's Java Manifest Destiny for so long, but earlier they didn't play along with Sun's announcement that TCL would be the world's official web scripting language. Besides the obvious fact that Java was much better than TCL, yet TCL for all its flaws and limitations at the time was certainly better than initial version of JavaScript (LiveScript), which was awful.