5 ms·

Not being on the web until the late 90s, the part I've never figured out is, what could you actually _do_ with JavaScript in the initial versions? The way I un

Not being on the web until the late 90s, the part I've never figured out is, what could you actually _do_ with JavaScript in the initial versions? The way I understand it, early JavaScript could only address HTML forms, links, and images. Can't modify HTML tags. Can't insert new elements. Can't update the page and re-render until DHTML in the version 4 browsers. Can't query the network until XHR. Ok, so now what? Do you just pop up an alert() when someone types 4 digits for a Zip code instead of 5? Image rollovers? Is that it?

petercooper 6y ago
Check out the JavaScript newsgroup from 1996 to see what people were discussing and trying to achieve :-) https://groups.google.com/g/comp.lang.javascript/search?q=after%3A1994-12-08%20before%3A1996-12-11 https://groups.google.com/g/comp.lang.javascript/search?q=af...
cygx 6y ago
You could output HTML via document.write().
gmac 6y ago
As I recall you could do what felt like quite a lot by abusing image swapping and frames + document.write.
commandlinefan 6y ago
One of the big things back then was form validation. Web pages in the late 90's were necessarily very form driven (no AJAX back then), and users were frustrated to submit a form, wait for a response, only to be told that they were missing a required input (or as you suggest, 4 digits for zip code). So there were complex frameworks to let Javascript validate the form before it was submitted - the Struts framework would even generate the Javascript for you and keep it synchronized with the backend. But yeah, there wasn't really a whole lot of functionality. You could do fancier things with the Layer API in Netscape, but it only worked in Netscape.
- duxup 6y ago
  Yeah wiithout validation form validation still is wonky if you want to do it on the browser / client end. I see so many "you don't need JS" articles that mention some of the basic HTML type form field validations and they're nice-ish... they're never enough.
  - commandlinefan 6y ago
    Yeah - OTOH, it was a double-edged sword, since you had to re-run the same validation on the server side, and you had to be careful to make sure they were in sync. Of course, this brings back painful memories of multiple occasions where somebody said, "this is dumb, we already validated it on the client side, we don't have to re-validate it on the server side" and took out the server-side validation (even after I tried in vain to explain to them why that was a security hole...)
    - duxup 6y ago
      It's just hard to avoid the whole two pronged validation situation. You just have to accept you're going to do it on both ends. If at all possible I think of client side as "active" validation with lots of feedback and such built in. Back end is "passive / defensive" where validation is more 'nope just not gonna do that'. Every time I think "let's see how much I can do this on the back end" it ends up being kinda wonky, I'm sure it is possible but just human interaction type stuff, I like it on the front. Security, detailed rules, etc, back.
sodapopcan 6y ago
...and don’t forget pre-loading images! We didn’t have CSS :hover back then and had to resort to image swaps for fancy hover effects in menus :)
Zelphyr 6y ago
JavaScript was quite limited at that point but then, so was everything else. So by comparison, it actually gave a developer a lot of relative control and power over a page.
sergeykish 6y ago
Check out JavaScript Guide by Netscape: for Navigator 2.0 http://web.archive.org/web/19970613234917/http://home.netscape.com/eng/mozilla/2.0/handbook/javascript/index.html http://web.archive.org/web/19970613234917/http://home.netsca... for Navigator 3.0 http://web.archive.org/web/19970614042441/http://home.netscape.com/eng/mozilla/3.0/handbook/javascript/index.html http://web.archive.org/web/19970614042441/http://home.netsca... You have frameset and can document.write() — enough to implement ToDo MVC — dynamic list on Netscape 2.0: Marcin Szczepanski: What's new in Netscape Navigator 2.0 | JSConf EU 2017 https://www.youtube.com/watch?v=Z-nXRZkge2U https://www.youtube.com/watch?v=Z-nXRZkge2U

petercooper 6y ago

Check out the JavaScript newsgroup from 1996 to see what people were discussing and trying to achieve :-) https://groups.google.com/g/comp.lang.javascript/search?q=after%3A1994-12-08%20before%3A1996-12-11 https://groups.google.com/g/comp.lang.javascript/search?q=af...

cygx 6y ago

You could output HTML via document.write().

gmac 6y ago

As I recall you could do what felt like quite a lot by abusing image swapping and frames + document.write.

commandlinefan 6y ago

One of the big things back then was form validation. Web pages in the late 90's were necessarily very form driven (no AJAX back then), and users were frustrated to submit a form, wait for a response, only to be told that they were missing a required input (or as you suggest, 4 digits for zip code). So there were complex frameworks to let Javascript validate the form before it was submitted - the Struts framework would even generate the Javascript for you and keep it synchronized with the backend. But yeah, there wasn't really a whole lot of functionality. You could do fancier things with the Layer API in Netscape, but it only worked in Netscape.

duxup 6y ago
Yeah wiithout validation form validation still is wonky if you want to do it on the browser / client end. I see so many "you don't need JS" articles that mention some of the basic HTML type form field validations and they're nice-ish... they're never enough.
- commandlinefan 6y ago
  Yeah - OTOH, it was a double-edged sword, since you had to re-run the same validation on the server side, and you had to be careful to make sure they were in sync. Of course, this brings back painful memories of multiple occasions where somebody said, "this is dumb, we already validated it on the client side, we don't have to re-validate it on the server side" and took out the server-side validation (even after I tried in vain to explain to them why that was a security hole...)
  - duxup 6y ago
    It's just hard to avoid the whole two pronged validation situation. You just have to accept you're going to do it on both ends. If at all possible I think of client side as "active" validation with lots of feedback and such built in. Back end is "passive / defensive" where validation is more 'nope just not gonna do that'. Every time I think "let's see how much I can do this on the back end" it ends up being kinda wonky, I'm sure it is possible but just human interaction type stuff, I like it on the front. Security, detailed rules, etc, back.

sodapopcan 6y ago

...and don’t forget pre-loading images! We didn’t have CSS :hover back then and had to resort to image swaps for fancy hover effects in menus :)

Zelphyr 6y ago

JavaScript was quite limited at that point but then, so was everything else. So by comparison, it actually gave a developer a lot of relative control and power over a page.

sergeykish 6y ago

Check out JavaScript Guide by Netscape: for Navigator 2.0 http://web.archive.org/web/19970613234917/http://home.netscape.com/eng/mozilla/2.0/handbook/javascript/index.html http://web.archive.org/web/19970613234917/http://home.netsca... for Navigator 3.0 http://web.archive.org/web/19970614042441/http://home.netscape.com/eng/mozilla/3.0/handbook/javascript/index.html http://web.archive.org/web/19970614042441/http://home.netsca... You have frameset and can document.write() — enough to implement ToDo MVC — dynamic list on Netscape 2.0: Marcin Szczepanski: What's new in Netscape Navigator 2.0 | JSConf EU 2017 https://www.youtube.com/watch?v=Z-nXRZkge2U https://www.youtube.com/watch?v=Z-nXRZkge2U