It's funny how you can look back at even Smalltalk 70, and contemplate that for more than 50 years, we've all wanted the same damn thing, had it in the palm of our hand, realized more than a proof of concept, but even right now, today, struggle to agree on how to deliver it.

To get web GL and canvas access on desktop Safari, you have to download the technology preview package separately. Linux systems, lotsa luck with your graphics drivers. Windows? I think you might still need Flash and Silverlight installed, and Java SE running it's plugin on a developer preview of Edge or whatever.

FFS, please shoot me now. I no longer wish to gaze upon such abominations.

The complete classes are over 500kB; no one will want to download these on-line

Ah, the good old days.

I can't wait to see how huge the runtimes we'll be expected to download for WebAssembly will be.

I’m hoping eventually we’ll have some form of true content-addressable storage for the web - so browsers cache content by hash instead of address. That way we wouldn’t be re-downloading jQuery-3.0.6-min.js for each website we visit (that isn’t using a CDN), but only once - the same could be done with WebAssembly - assuming it doesn’t require monolithic statically linked blobs.

Browsers have the option to do this for javascript: with subresource integrity [0] you can add the sha256 hash of the script to a script tag. The browser could check that hash against its cache, in case it's yet another copy of jQuery-3.0.6-min.js.

No browser does this because it opens up a huge data leak: I can simply add some script to my website, claim it has the hash of the javascript used by PornHub and measure the loading time of the script (or simply whether the integrity check fails) to find out if you visited PornHub.

0: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

I find that odd. Even over a 14.4 modem (which was obsolete by that time) it would only take about 5 minutes.

Applets were supposed to be embedded into webpages like images. Given the JRE was already started, you'd expect the load time to be a few seconds at most.

For sure not 5 minutes before a page becomes interactive.

Given the JRE was already started, you'd expect the load time to be a few seconds at most. For sure not 5 minutes before a page becomes interactive.

My recollection of these times is that when the JRE was not already started (which was often the case), it took up to one minute to start - and during this start process, the whole browser was frozen, with a helpful message on the status bar pointing to Java as the culprit. No wonder people started to think of Java as slow.

I remember timing it to 30 seconds on our Mac Performa 5200. And in System 7.5 it froze up the whole OS when it was doing it's thing.

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://people.apache.org/~jim/NewArchitect/webtech/1997/10/...

While I was working at Interval Research Corporation in 1996, after playing around with and reading over the source code and documentation, I wrote up a deep comparison and analysis of Internet Foundation Classes (IFC) versus Marimba Bongo (which was written by Arthur van Hoff, who worked on Java, wrote AWT, and before Java wrote another user interface system for NeWS similar to Bongo and HyperCard in PostScript, called HyperLook), and other related user interface component technologies.

https://donhopkins.com/home/interval/ifc-vs-bongo.html

This is a comparison of two component frameworks for Java, IFC and Bongo.

IFC (Internet Foundation Classes) is from NetScape, and is similar NeXTStep, which was written in Objective C. It was written by some former NeXT developers, whose company NetScape bought because they needed a Java toolkit.

Bongo is from Marimba, and is similar to HyperLook, which was written in NeWS object oriented PostScript. Marimba was founded by some of the original Sun Java developers, who left Sun to form their own company.

[That also compares IFC with Microsoft's ActiveX/OLE/COM/MIDL stuff, and gets into some Java/JavaBeans/J++/CORBA/OpenDoc politics, and includes some comments by Arthur about IFC, AWT, Bongo, JDK 1.1, etc.]

Here's a later article I wrote about HyperLook (that article is still a work in progress, since I haven't finished the comparison to HyperCard and Bongo):

https://medium.com/@donhopkins/hyperlook-nee-hypernews-nee-g...

During 1996 I also wrote up a wide ranging survey of the interesting component, plug-in, user interface toolkit, and application framework technology at the time:

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

An Overview of Plug-In Technology circa March 1996

Don Hopkins, Interval Research Corporation

Index: Requirements Problems Companies Platforms Languages

Software Research

Our Plug-In Requirements

Somebody Else's Problems

Companies

Platforms

Languages

Software

Research

TODO

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

Somebody Else's Problems

These are problems that we aren't trying to solve, and that a lot of other people are. We should try to take advantage of other peoples work, instead of re-inventing the wheel.

the component object framework problem (Open Doc, OLE, COM)

the distributed object problem (CORBA, Electric Communities)

the application framework problem (Galaxy, MFC)

the programming language problem (Java and other languages)

the multimedia library problem (ScriptX, QuickTime, DirectX)

the garbage collection problem (COM, Java, ScriptX)

the window system toolkit problem (HyperLook, Java AWT, MFC)

the development environment problem (Metrowerks, MSDEV, Visual Basic)

the web browser problem (NetScape, CyberDog, Explorer)

the database problem (DAO, ODBC, Oracle)

the image editor problem (Photoshop, Premier)

the multimedia 8 track tape player problem (Director)

the killer app problem (Lotus 123, SimCity)

the operating system problem (Windows 95, Netscape)

the pointless standard problem (VRML, COSE)

or any combination of the above (TCL/Tk, ScriptX, NetScape)

Software index:

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

Netscape Navigator:

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

Java:

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

OLE:

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

COM:

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

MediaFlow design discussion, retrospective, and comparisons with other visual programming languages:

https://donhopkins.com/home/interval/mediaflow-design.html

Freaky Putty:

https://donhopkins.com/home/interval/freaky-putty.html

From the Netscape page:

NetScape plans to be a cross platform virtual operating system, and has embraced Java as its primary extension language in the long term, even though JavaScript (completely different language than Java) is getting a lot of cycles and attention in the short term.

I guess that short term turned out to be a lot longer than anyone anticipated :-D

Ha ha! Yes, the launch of Javagator was a lot like watching the Space Shuttle Challenger blow up.

Such glorious plans they had, then Sun and Netscape started bickering about who was going to be on top...

But Rhino, Mozilla and Phoenix eventually rose from the ashes of the Javagator Disaster.

December 30, 1997: Netscape sharpens Javagator plans

https://www.cnet.com/news/netscape-sharpens-javagator-plans/

The Internet software company says it will have an all-Java browser ready for network computers and other clients by July.

[...] Although bandied about by company executives and in the press, the term "Javagator" is strictly slang. The official code name for the browser is Maui, Gong said.

[...] Moreover, Netscape's move to develop a pure Java browser will put the company's long-standing cross-platform mantra to the test. The extent of the pure Java browser's technological success and market acceptance will most likely serve as a temperature gauge for other developers looking to test the Java waters.

February 25, 1998: Netscape puts Javagator "on hold"

https://www.itprotoday.com/windows-78/netscape-puts-javagato...

As expected, Netscape has put plans for its 100% Pure Java version of Navigator, dubbed "Javagator", "on hold". The company is hoping that an industry heavyweight with lots of cash--such as Sun or IBM--will finance the project or simply take it off their hands.

February 26, 1998: Netscape's Java browser in doubt

https://www.zdnet.com/article/netscapes-java-browser-in-doub...

Netscape Communications Corp. , still refining its client strategies, has put development of its Pure Java browser - dubbed Javagator - "on hold."

[...] Javagator was rumored to be a dead project early this year; however, Netscape officials at the January announcement of the company's source-code release plans said it was still an ongoing project.

Well at least that panned out! ;)

February 26, 1998: Whither Crawls Netscape's Javagator?

https://www.wired.com/1998/02/whither-crawls-netscapes-javag...

[You know a rumor's true when they vigorously DENY it in upper case!]

NETSCAPE OFFICIALS DENIED a report in the computer trade press today that the company has suspended work on Javagator, the nickname for Netscape's all-Java version of its Navigator browser. But their comments shed little light on the future of the special browser project.

"Nothing has changed," said Netscape spokeswoman Andrea Cook, referring to the company's position on the project, officially codenamed Maui.

[...] Sources close to Netscape say that during formation of the company's plans to release its source code, there was a professed desire to suspend Javagator's development, but partner companies dissuaded the company from doing so.

IBM representatives confirm that it and other companies with interest in the success of network computers (NC) are reviewing Netscape's call for help in the funding and development of Javagator.

[...] There has long been speculation that the Maui project was being de-emphasized at Netscape, partly due to the cool reception of NCs in the market.

"We've anticipated it for the simple reason that there's no money in browsers and that Netscape has released a free source version of Communicator," said Forrester's Schadler. "The only place you can run a Javagator today is on an NC - and there ain't none."

[...] With the announcement that it would begin free distribution of its browser software and source code, the company also said it would stop developing the Java Virtual Machine for its browser. But there are financial justifications to cut non-critical projects like Javagator, too, after the company suffered a a US$88 million, fourth-quarter loss in 1997.

Schadler said Netscape has to turn over Javagator development, at least as a separate subsidiary, for the added reason that continuing the project in-house undermines the plan to free its source code, starting with Communicator 5.0.

"The nightmare to the [Communicator 5.0] development community is the prospect of Netscape developing another code base," Schadler said. The company has to show commitment solely to the Communicator code that developers would be contributing too, he said.

April 3, 1998: Will Javagator be reborn as Jazilla?

https://www.wired.com/1998/04/will-javagator-be-reborn-as-ja...

A LOOSE COLLECTION of Java enthusiasts from around the world have seized upon Netscape's recent release of Communicator 5 source code, and are busily hacking away on Jazilla – a Java-based version of the browser.

The news comes just weeks after Netscape and Sun Microsystems acknowledged that they were seeking partners to take over "Javagator," a proposed 100-percent-pure Java version of Netscape's browser. Now, eager developers have taken matters into their own hands and are porting the Netscape C++ code, called Mozilla, to Java.

[...] "The Javagator project didn't go very well, so this is a reincarnation of that – we've had email back and forth with the people who worked on it, and they explained all of their challenges," said Rodd.

"The reason [Javagator] failed was organizational – it wasn't a priority," said Rodd.

Fortunately, Netscape's Java Rhino JavaScript engine managed to make it out into the world:

https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine)

The Rhino project was started at Netscape in 1997. At the time, Netscape was planning to produce a version of Netscape Navigator written fully in Java and so it needed an implementation of JavaScript written in Java. When Netscape stopped work on Javagator, as it was called, the Rhino project was finished as a JavaScript engine. Since then, a couple of major companies (including Sun Microsystems) have licensed Rhino for use in their products and paid Netscape to do so, allowing work to continue on it.

Javascript Jabber: 124 JSJ The Origin of Javascript with Brendan Eich

https://dev.to/adventuresinangular/aia-206-the-origin-of-jav...

https://devchat.cachefly.net/javascriptjabber/transcript-124...

Brendan Eich:

And Netscape had acquired a company called Digital Styles that was known for rendering engines of some kind. And they started doing a next-generation engine in ’97 I think based on Java. And they thought, Netscape’s doing the Javagator, Netscape and Sun are going to kill Windows, Java’s going to be the future on the client side. Let’s build a Java engine. When Java got the plug pulled from it in late ’97, when the Electrical Fire JVM that Waldemar Horwat was building at Netscape got cancelled, when Sun went away because Netscape was basically going out of business slowly, the team that was doing this Java engine, this Java web engine, rendering engine called Raptor said, “Oh, we better rewrite it in,” maybe it was called Xena, I forget. They said, “We better rewrite it in C++.” And then they said, “Let’s sell it to Mozilla.”

I thought it was the educational type of class... but then again, I shouldn't be surprised given that this was the mid-90s, pretty much the height of the OOP craze.