Hacker News Reader

Comment by TedDoesntTalk | Hacker News Reader

There was also the the idea that JavaScript was just one way of scripting the page. VisualBasic Script (VBScript) had momentum in IE releases. The general idea was that the user-agent was going to be able to parse multiple scripting languages, the list of which would probably grow as time went on. Think native TypeScript parsing in a browser today!

View on HN

There were even things like ViolaWWW [0][1], using a HyperCard-like approach, which exposed all its objects (even a canvas for drawing) and methods in its own scripting language. This was probably the nearest thing to the Web, we know today, but also an absolute security nightmare.

[0] https://en.wikipedia.org/wiki/ViolaWWW [1] http://viola.org

Edit: The basic building blocks of ViolaWWW were horizontal and vertical layout panes, which behaved much like flex elements and allowed the implementation of all the common HTML tags. These were accessible to viola-scripts and could also be generated by a script. Moreover, ViolaWWW also featured stylesheets (in a maybe more declarative form than CSS).

Styles were also much like this, with multiple concurring standards. While MS IE featured CSS, Netscape used JavaScript styles. (However, Netscape soon adopted CSS syntax, but this remained a mere bridge to the original JS styles for all of the NS4.x life cycle.)

Tcl added sandboxed subinterpreters in a bid to become a safe web scripting language. The plan didn't work out but it is a killer feature for untrusted input.

>Think native TypeScript parsing in a browser today!

If only...

Or better yet, a bytecode format that is easy to target for scripting languages like typescript, clojurescript, scalajs, coffeescript, dart, and even plain JavaScript. Webasm is too low level (at least currently) since it doesn't have a GC, direct DOM access, etc. Most js engines have an intermediate bytecode representation anyway, it would be cool if you could target that instead of textual js.

ActiveState had browser plugins for Perl, Python and Tcl. I think they were IE only via COM extensions.

Netscape had a plugin API and there was a Tcl plugin for it. As I recall the Netscape API was the de facto standard for as long as plugins were a thing, so the Netscape plugin was usable in conforming browsers.

Well, with a bit of luck you just need to ship a TypeScript compiler/AOT/JIT shipped as WebAssembly module. :)

The best way to take advantage of WebAssembly, since it is here anyway, is to abuse it to recover all plugins that were taken away.

Reply on news.ycombinator.com