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.
Right after New Years 1971,
Bob Taylor scored an enormous
coup by attracting most of
the struggling Berkeley
Computer Corp to PARC.
In the summer of '71 I refined
the KiddiKomp idea into a
tighter design called miniCOM.
It used a bit-slice approach
like the NOVA 1200, had a
bit-map display, a pointing
device, a choice of "secondary" (
really tertiary) storages,
and a language I now called
"Smalltalk" - as in "programming
should be a matter of ..."
and "children should program in ...".
This Smalltalk language (
today labeled -71) was very
influenced by FLEX, PLANNER,
LOGO, META II, and my own
derivatives from them. It
was a kind of parser with
object-attachment that
executed tokens directly.
But, rounding errors and such, so maybe 1970 is kinda okay...
To get web GL and canvas access on desktop Safari, you have to download the technology preview package separately.
I'm sorry but this is simply not true. I occasionally run desktop Safari and it supports both canvas, and WebGL and has done for years - since at least 2014 in fact. Prior to this versions 5.1 (released in 2011) onwards supported WebGL via the experimental context. Canvas2D has been fully supported since 2009.
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.
News to me, but yea that’s an excellently described reason that why that isn’t used. The natural inclination would be to say “well, we just need a central repository of shared libs” but now you move to a familiar spot of the big wheel of problems we keep trying to fix.
It would only be for widely distributed scripts - not site-specific resources for that reason. Think things like jQuery, Angular, Vue.js and RxJS. This would be especially useful for heavier frameworks like Angular because browsers could then have the entire full-fat edition available in-cache so then smaller Angular sites could make use of more features without making their entire site a slow download.
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.
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).
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.
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):
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:
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)
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
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"
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
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?
[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?
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:
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
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.”
The last bit is interesting. I hadn't heard of the Electrical Fire JVM and was wondering how they could possibly think that implementing the browser in Java could ever be practical, with its horrible performance at the time - but the answer is apparently that Netscape were writing their own JVM with a JIT compiler?
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.
Both the name and the software IFC ("Internet Foundation Classes") were intended to be the Internet's answer to Microsoft's MFC ("Microsoft Foundation Classes").
I recall hearing that they also considered calling it NFC ("Netscape Foundation Classes"), but they settled on IFC because they wanted it sound more inclusive and Internetty.
Other than raising that one middle finger to Microsoft, I can understand why name is confusing: the "Internet Foundation" sounds like a non-profit educational foundation that teaches classes in computer networking.
I know somebody who was admitted into the UK on an educational teaching visa, ostensibly to teach classes, when he was actually developing commercial software, not teaching students. Technically he WAS actually teaching classes -- just to computers.
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.
So, Smalltalk didn't really exist until 1971/72...
http://worrydream.com/EarlyHistoryOfSmalltalk/
But, rounding errors and such, so maybe 1970 is kinda okay...
I'm sorry but this is simply not true. I occasionally run desktop Safari and it supports both canvas, and WebGL and has done for years - since at least 2014 in fact. Prior to this versions 5.1 (released in 2011) onwards supported WebGL via the experimental context. Canvas2D has been fully supported since 2009.
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...
News to me, but yea that’s an excellently described reason that why that isn’t used. The natural inclination would be to say “well, we just need a central repository of shared libs” but now you move to a familiar spot of the big wheel of problems we keep trying to fix.
It would only be for widely distributed scripts - not site-specific resources for that reason. Think things like jQuery, Angular, Vue.js and RxJS. This would be especially useful for heavier frameworks like Angular because browsers could then have the entire full-fat edition available in-cache so then smaller Angular sites could make use of more features without making their entire site a slow download.
Are you trying to encourage investment in hash collision technologies? ;)
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.
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.
Cooperative multitasking at its finest.
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
[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:
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/
February 25, 1998: Netscape puts Javagator "on hold"
https://www.itprotoday.com/windows-78/netscape-puts-javagato...
February 26, 1998: Netscape's Java browser in doubt
https://www.zdnet.com/article/netscapes-java-browser-in-doub...
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!]
April 3, 1998: Will Javagator be reborn as Jazilla?
https://www.wired.com/1998/04/will-javagator-be-reborn-as-ja...
Fortunately, Netscape's Java Rhino JavaScript engine managed to make it out into the world:
https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine)
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.”
The last bit is interesting. I hadn't heard of the Electrical Fire JVM and was wondering how they could possibly think that implementing the browser in Java could ever be practical, with its horrible performance at the time - but the answer is apparently that Netscape were writing their own JVM with a JIT compiler?
IFC was the start of Swing...
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.
Both the name and the software IFC ("Internet Foundation Classes") were intended to be the Internet's answer to Microsoft's MFC ("Microsoft Foundation Classes").
I recall hearing that they also considered calling it NFC ("Netscape Foundation Classes"), but they settled on IFC because they wanted it sound more inclusive and Internetty.
Other than raising that one middle finger to Microsoft, I can understand why name is confusing: the "Internet Foundation" sounds like a non-profit educational foundation that teaches classes in computer networking.
I know somebody who was admitted into the UK on an educational teaching visa, ostensibly to teach classes, when he was actually developing commercial software, not teaching students. Technically he WAS actually teaching classes -- just to computers.
For screenshots, see the chapter "Using components" in the documentation: https://stuff.mit.edu/afs/sipb/project/java/packages/ifc/doc...
Java in the browser almost had the staying power of Flash, or even the Javascript + Canvas we have today.