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!

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.

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.

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.

> It may be interesting to recall that initially the only way to output HTML was by `document.write()` using strings (which was pretty declarative).

I think people also forget how slow a lot of JS was really until V8. I remember having server code generate JS arrays (creating them from an xhr request was too slow), that in turn would document.write (manipulating the DOM was also super slow) data on the client to make the web page 'interactive'. It was messy.

It wasn't just JS, you could actually watch JPEG images becoming decoded, esp. on a computer which wasn't exactly new. Layout of complex markup could take seconds, reflowing and repainting was out of question. JS as an interpreteded language was accordingly much slower than native code. There was no way to do fast, declarative HTML in JS – and not much of a use case for this. (For much the same reasons, there was no way to have optimizing client-side JS engines, even if JS hadn't been just in its infancy.)

Ah, the render one scanline at a time effect in analog modems.

I even used to disable images and just selectively download them.

> creating them from an xhr request was too slow

You had XHR? Luxury! We had to embed a 1x1 px Java applet to communicate with the server without reloading the page! ;)

Haha...at the time I was writing internal business applications where everyone could be forced to use IE. Another thing people forget is that at one time IE was the best browser. It was because that IE had such a lead it stagnated and we ended up in the IE6 situation.

So, if initially there were no Array nor Object constructors (there were arrays and objects, but only prepopulated ones, representing anchors, forms, etc, found in the document), how were arrays done in a script?

  function MyArray() {
     this.length = 0;
  }

  function arrayPush( value ) {
     return this[this.length++] = value;
  }

  function arrayPop() {
     return this[--this.length];
  }

  MyArray.prototype.push = arrayPush;
  MyArray.prototype.pop = arrayPop;

  var a = new MyArray();
  a.push("frist");
  // no console available, debug using alert()
  alert( a[0] );     // "frist"
  alert( a.length ); // 1
  alert( a.pop() );  // "frist"
  alert( a.length ); // 0

I have been using JS since the mid 90s, but I don't recall needing arrays or objects back then. Frankly we weren't trying to build applications and any real programming work was done on the back end (remember that xmlHttpRequest wouldn't exist for years to come, so any changes to the page were made by going to a new page which would require a round trip to the server, so the server could do anything it needed to do to the page before returning it). The only things I can recall using JS for back in the early days was displaying the date and time at the bottom of the page (why we felt like that was useful is beyond me).

There were a few interactive scripts, usually interacting with a form as an UI. The first JS book, I knew, was the "Official Netscape JavaScript Book" (1996), which was based on Netscape 3 beta. This one featured a pretty complex area code application as a demonstration object and things like order forms. I started pretty much with the introduction of NS3, when NS2 and JavaScript1.0 were still the common platform.

Fun fact, for a year or so, you'd frequently include a script twice, once in a simpler form for NS2 and similar, and once targeting Netscape 3 (and, later, IE3) using a `<script language="javascript1.1">` tag, which was ignored by the earlier browsers, implementing a more complex version of the same functions. (This scheme was used again, when DHTML became a thing, this time using the `language="javascript1.2"` attribute. However, this switch came with a few caveats, since it also activated some rather odd behavior, like negative zero as a numeric value, which could break a few things.)

what a trip, I forgot about displaying the current time and date haha. The other major usage I had for JS back in the day was to focus the cursor on the login box on page load.

The other major uses of JavaScript were hover-over-button effects, and scrolling text in the status bar

Oh my. I'd forgotten about scrolling text. Why did we do that? LOL

What a magical time... I remember being wowed by having a string of text follow my mouse around.

There was no `prototype` and `constructor` properties

    o = new Object
    o.foo = 'bar'
    a = new Array
    a[0] = 'baz'

But functions were constructors

    function hello() { return this.name }
    function Person(name) {
      this.name = name
      this.hello = hello
    }
    new Person('James')

Array push

    var length = 0
    a[length++] = 'foo'
    a[length++] = 'bar'

Actually it was not bad for scripting language, no WAT:

    new Object + new Array
    //null is not a number

No `typeof` (so no `typeof null`), better `parseInt`

    parseInt("foo")
    //0

Much better start than ECMAScript 1

> There was no `prototype` and `constructor` properties

You are correct. The prototype property was yet another JavaSript1.1 (NS3) feature. (Totally forgot about that.) So, ignore '.prototype' in my example. But you could assign properties and methods to objects. Therefor it was more like,

  var a = new MyArray();
  a.pop = arrayPop();
  a.push = arrayPush();

> No `typeof` (so no `typeof null`), better `parseInt`

Fun fact: also no `isNAN()`. This was, once again, introduced with JS1.1/NS3 and still nonfunctional in IE3 – yes, IE3 had a few of those nonfunctional implementations.

(`isNAN()` was actually available in the Unix implementation of Netscape 2, but this was of lesser concern for the public Web.)

On the positive side, the access to forms and the various form elements was pretty sound and mature, right from the beginning, since this was what JS was pretty much all about.

Sorry, NN2 does not agree, it overwrites `length`:

  function MyArray() {
     this.length = 0;
  }
  var a = new MyArray();
  alert(a[0]) // 0
  ...

  alert( a[0] );     // "frist"
  alert( a.length ); // "frist"
  alert( a.pop() );  // JavaScript Error: length is not a numeric literal.
  alert( a.length );

How clever - https://www.javaworld.com/article/2077150/using-javascript-s... - all you have to do is count from 1

You are correct, once again, all properties were available both by property name (if used in an associative context) and by numeric index. Since we assigned 'length' already in the constructor, we would have to accommodate for this, i.e., start counting at 1.

Turns out, my recollections are a bit on the rosy side… :-)

Edit: This should work:

  function MyArray() {
     this.length = 0;
  }
  function arrayPop() {
     return this[this.length--];
  }
  function arrayPush( value ) {
     return this[++this.length] = value;
  }

  var a = new MyArray();
  a.pop = arrayPop;
  a.push = arrayPush;
  a.push('a');
  a.push('b');
  alert( a[1] ); // 'a'
  for (var i = 1; i <= a.length; i++) alert( a[i] );

at which point it is much simpler to do:

  function MyArray() {};

  var a = new MyArray(), aLength = 0;
  a[aLength++] = 'a';
  a[aLength++] = 'b';
  for (var i = 0; i < aLength; i++) alert( a[i] );

  var b = new MyArray(), bLength = 0;
  // etc

which is also, what was actually used.

Strings are so tempting because they are there and everyone knows how to use them.

But they are the wrong abstraction for building DOM nodes. They're error prone (no guarantees of correctness) , encoding woes) and are write only (how do you modify a node that is encoded in a string). And what do expressions like html.substr(0, 7) even mean?

First class HTML composition in JS is pretty dang important.

HTML should be expressed in the data literals of your programming language, this is easier if you have a literal data type for names like Erlang and Clojure

Once you have that, you have a always "parsed" HTML that you can serialize, send over the wire to other languages, rewrite with ease and change the render target if need be

Some other commenters have shown what that looks like in practice