5 ms·

> I have a theory that a grave mistake was made in 1995 - the decision not to have a neat, succinct and declarative way of representing html elements in javascr

> I have a theory that a grave mistake was made in 1995 - the decision not to have a neat, succinct and declarative way of representing html elements in javascript. It may be interesting to recall that initially the only way to output HTML was by `document.write()` using strings (which was pretty declarative). The genuine way of generating HTML in JS were various methods of `String.prototype` for generating HTML formatted output, as `anchor()`, `big()`, `blink()`, `bold()`, `fixed()` (providing "<TT>…</TT>"), `italics()`, `link()`, `small()`, `strike()`, `sub()`, `sup()`. However, there was no provision to set an ID or any other attributes or className, since these things (and CSS) hadn't been introduced yet, with the notable exception of the "name" attribute for anchor tags, the value of which was to be supplied as an argument to the `string.anchor()` method. This was pretty much sufficient to generate any of the HTML required then. The first occasion for a more complex approach was the introduction of the `Link` and `Image` objects, which allowed for the first time not only a representation of a DOM object, but also means to manipulate their attributes on the fly (e.g., changing image sources), but this came only with Netscape Navigator 3.0 / JavaScript1.1. Also, keep in mind that the JS object notation (object and array literals) was only introduced in the ECMA standard, which came another browser iteration later. Initially, in JavaScript1.0 (AKA LiveScript), there hadn't been even Array or Object constructors in the core language (these came, again, with JavaScript1.1), but only functions. (Meaning, you had to construct your own arrays from generic functions). Hence, something like a declarative HTML-in-JS syntax would have been totally out of place.

masswerk 6y ago
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
- irrational 6y ago
  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).
  - masswerk 6y ago
    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.)
  - sethammons 6y ago
    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.
  - kalleboo 6y ago
    The other major uses of JavaScript were hover-over-button effects, and scrolling text in the status bar
TedDoesntTalk 6y ago
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!
- masswerk 6y ago
  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 https://en.wikipedia.org/wiki/ViolaWWW [1] http://viola.org 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.)
- kevin_thibedeau 6y ago
  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.
- thayne 6y ago
  >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.
- 6y ago
matwood 6y ago
> 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.
- masswerk 6y ago
  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.)
  - pjmlp 6y ago
    Ah, the render one scanline at a time effect in analog modems. I even used to disable images and just selectively download them.
- BerislavLopac 6y ago
  > 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! ;)
  - matwood 6y ago
    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.
slifin 6y ago
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
underwater 6y ago
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.

masswerk 6y ago

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

irrational 6y ago
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).
- masswerk 6y ago
  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.)
- sethammons 6y ago
  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.
- kalleboo 6y ago
  The other major uses of JavaScript were hover-over-button effects, and scrolling text in the status bar

TedDoesntTalk 6y ago

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!

masswerk 6y ago
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 https://en.wikipedia.org/wiki/ViolaWWW [1] http://viola.org 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.)
kevin_thibedeau 6y ago
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.
thayne 6y ago
>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.
6y ago

matwood 6y ago

> 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.

masswerk 6y ago
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.)
- pjmlp 6y ago
  Ah, the render one scanline at a time effect in analog modems. I even used to disable images and just selectively download them.
BerislavLopac 6y ago
> 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! ;)
- matwood 6y ago
  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.

slifin 6y ago

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

underwater 6y ago

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.