8 ms·

What stands out to me is how much more foresight they had than I'd thought about the ways JS would be used: > With JavaScript, an HTML page might contain an in

What stands out to me is how much more foresight they had than I'd thought about the ways JS would be used: > With JavaScript, an HTML page might contain an intelligent form that performs loan payment or currency exchange calculations right on the client in response to user input. A multimedia weather forecast applet written in Java can be scripted by JavaScript to display appropriate images and sounds based on the current weather readings in a region. A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly. A page might contain JavaScript scripts that run on both the client and the server. We tend to think of JS as having started out as just a way to dynamically show/hide elements, maybe add an animation or two, on top of fundamentally HTML-based web pages. But I see here described what we now think of as "web apps", and even web servers (!) written in JS. They even talk about code-sharing on the front and back ends, a la React in hybrid-mode. I had no idea those things were in people's minds at its inception. Edit: Apparently they already ran JS on the server! I had no idea > Netscape LiveWire enables JavaScript programs to be installed, run and managed on Netscape servers

drblast 6y ago
The industry is cyclical and to be forward thinking all you have to do is describe what's already happened and assume it will happen again. ;-) The things being done with JavaScript today are not new, nor is the idea that a server and client would coordinate to run interactive apps. That fundamental concept has been reimplemented in many different ways until we've landed on the current rube goldbergian monstrosity that are web apps. It shows that the desire to have users interact with a service in particular ways will not go away. The technology used to do that is mostly irrelevant.
- brundolf 6y ago
  I'm not surprised that the architecture isn't new, I'm surprised that web apps were already being talked about this way using JS specifically. JS's early design flaws are often written off as, "well it was never intended to be a real programming language like it is today". But from reading this, that doesn't sound to be the case.
  - ChrisSD 6y ago
    I think JS' early design flaws were a result of being written in a day more than anything to do with a specific purpose (I exaggerate but not by much). Though it is true that most people at the time used JS (if they used it) for much simpler tasks than described in the article.
    - jrumbut 6y ago
      I think in some ways the problems people have experienced come back to a language design that is fairly ambitious. Specifically the inclusion of a prototype OO system is confusing if you aren't aware what that is and have only been exposed to Java-like OO programming. But in fact it's very powerful and not so hard to learn once you realize you have to. As with other web technologies, it's simple at first glance but the learning curve gets steeper at some point.
    - blululu 6y ago
      It was written in 9 days, which is astounding. I suspect that the project was given a week to complete and it came 2 days late. In any case it seems unlikely that it’s problems would go away if given another 5 days. A lot of the wired things in a scripting language only become obvious at scale.
  - tracker1 6y ago
    I don't so much think of them as flaws... the first use case was form validation, and most of the fuzzy type coercion makes a ton of sense through that lens, where ''. 0, etc. coercion to falsy is easy for dealing with user input. It's also why it's one of my favorite options for ETL workloads. It's just a matter of understanding the langauge. That said, it's been my favorite language since well before the "good parts" book.
    - brundolf 6y ago
      I use JS every day; I would say I like it. I would even say that in 2020, if you know what you're doing, it's a pretty good language on the whole. But I don't think it's controversial to say that the following were objectively bad decisions (in hindsight, of course, but still): - Automatic casting behavior between the core types (you're the only person I've ever heard suggest that this might be a good thing) - Automatic semicolon insertion - A core Date object that lacks basic control over time-zones and reasoning about time-zones - Assigning to an undeclared variable silently creates a global - Allowing duplicate function parameter names where later ones just hide the earlier ones - Distinction between undefined and null (this one might have a few defenders) Some of these are now prevented by "strict mode". Others have been patched-over, for example by the addition of === which prevents casting behavior for comparisons at least. Others can be bridged by libraries (Moment.js) or by best-practices (use foo == null to smooth over the null/undefined distinction, never use a value's implicit falsiness in a conditional, etc). But the point is that JavaScript has this giant asterisk that will never go away, of things you need to do/avoid/utilize in order to get the most basic behaviors right.
- ezekiel68 6y ago
  I agree with your basic premise. However, in this particular instance, what would have been the historical equivalent ("already happened") of scripts sent by the server to the client during the request response cycle, which could perform layout and logic in the client? If you're simply referring to code that could run on both client and server, your point is clearer to me.
  - deleted 6y ago
    [deleted]
  - cubano 6y ago
    AJAX is part of the request response cycle? Let's face facts...AJAX is the real secret sauce with JS and what makes it truly useful.
    - bryankaplan 6y ago
      Long before the term "AJAX" was coined, we used hidden iframes to do the same thing.
  - ptx 6y ago
    Display PostScript[1] maybe? Developed by NeXT in 1987. Or NeWS[2], also based on PostScript. [1] https://en.m.wikipedia.org/wiki/Display_PostScript https://en.m.wikipedia.org/wiki/Display_PostScript [2] https://en.m.wikipedia.org/wiki/NeWS https://en.m.wikipedia.org/wiki/NeWS
- smnrchrds 6y ago
  > already happened and assume it will happen again So say we all!
  - osullip 6y ago
    Under appreciated BSG reference. Well done!
- cubano 6y ago
  Yes for sure..I worked as a corporate contractor for AT&T in 1990's and I was doing client/server apps using MSVC++ that are basically identical to React-type wideweb dev... Indeed, your absolutely correct in saying it was obvious where webapps had to go, and that HTML and CSS just wasn't going to get us there.
  - amenod 6y ago
    Nitpick: "...and that HTML just wasn't going to get us there" (CSS came out in 1996).
    - BearOso 6y ago
      And CSS wasn’t widely used until a few years into the ‘00s. Only then did more consistent layout engines finally make it viable for stuff other than just styling text.
      - cubano 6y ago
        Damn...I've forgotten more about the timelines of this stuff then most people know.
        amenod 6y ago
        Me too. But your comment surprised me as I remember hearing about this new thing "JavaScript" waaaaay earlier than about CSS. I didn't actually know they came out this close together.
AntiRush 6y ago
Philip Greenspun has a great review of Netscape LiveWire from the time. https://philip.greenspun.com/wtr/livewire.html https://philip.greenspun.com/wtr/livewire.html You can see that the current JavaScript tooling complains are nothing new under the sun: So what used to be a few keystrokes in Emacs or Netscape Gold now requires three steps: edit the .html file recompile the .web file restart the LiveWire app from the appmgr
- Lammy 6y ago
  This quote is adorable considering the size of most pages today: "This approach has several disadvantages, the first of which is speed. You are gratuitously transporting potentially many kilobytes of data back and forth across the network."
  - pmontra 6y ago
    I was there, kB were an issue. We had 56 kb/s modems vs (let's say) 56 Mb/s fiber now. We gained a x1000 factor and we're dealing with many MB now instead of many kB back then. Page size grew x1000 too. But loading pages was really slow, mainly because browsers were slow. No parallel loading of images, no progressive rendering. Those were the first optimizations.
    - icedchai 6y ago
      I think you underestimate the effects of high bandwidth. There was a sweet spot in the late 90's when some people had broadband (early cable modems, generally 3 megabits, or DSL.) I had an ISDN line from 1996 through 1998, then a cable modem after that. The web was fast because it was built for dial up. As broadband gained more and more market-share, the bloat increased.
- icedchai 6y ago
  Working with LiveWire was incredibly painful. Often the server would crash during the restart phase (this was under WinNT 4.0 back in 1997.)
giovannibonetti 6y ago
Running the same logic and the same technology in the server and the client was mandatory for realtime multiplayer games since the 1990s. See this article from Valve [1] for a briew overview of how client side prediction works. You should also have the server process the data to avoid cheating by modificating the client app. [1] https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin...
- cubano 6y ago
  Wait a minute here...I was writing realtime multiplayer games for Galacticomm's MajorBBS in thr late 80's and we just pushed ANSI and made VERY interactive games without the need for a rich client...altho we did envy AOL's bitmapped graphic capabilities at times...
NegativeLatency 6y ago
Didn't visual basic support some kind of client side code?
- aidos 6y ago
  IE (3? 4?) let you specify vbscript instead of JavaScript as the language in your script tags. Edit: introduced in IE3 (1996) apparently. https://en.m.wikipedia.org/wiki/Internet_Explorer_3 https://en.m.wikipedia.org/wiki/Internet_Explorer_3
  - dfox 6y ago
    IE 3 does support VisualBasic as another script language. Later IE versions simply supports any scripting language that is provided by the underlying platform (including javascript). People tend to regard the whole IE4/Windows 98/"Desktop enhancement package" thing as Microsoft being anticompetitve and trying to kill Netscape, but the whole thing has solid technical background. Well, the whole "PWA" concept existed at the time except it wasn't called that.
deft 6y ago
ASP, the original one before .net, had a language called jscript that ran the ie js engine on the server. https://en.wikipedia.org/wiki/JScript https://en.wikipedia.org/wiki/JScript
- drittich 6y ago
  Yes, I coded in JScript happily for about 3 years. Even better, using Windows Scriptlets let me write dynamically-compiled COM components in JavaScript that I would call from the web pages. As a result, I could launch updates independently in a microservice-like fashion, share the same libraries (like validation) on client and server, and use the same COM components in crons. Not bad at all! Also, because we had COM components, we could now use Window's built-in message queue MSMQ for async processes like payment transactions. I started doing this in 2003 - looking back, that was a pretty good developer experience.
GordonS 6y ago
> Edit: Apparently they already ran JS on the server! I had no idea Hmm, I started work as a web developer back in 2000, and I don't remember ever coming across such a notion. The first time I heard of JavaScript being used server-side was NodeJS many years later.
sergeykish 6y ago
Server side JS had to write(): <HTML> <HEAD> <TITLE> Hello World </TITLE> </HEAD> <H1> Hello World </H1> <P>Your IP address is <SERVER>write(request.ip)</SERVER> But client side JS had to write() too (there was no DOM), and so we have 'foo'.link('http://example.com') // "<a href="http://example.com">foo</a>" 'bar'.bold() // "<b>bar</b>" http://web.archive.org/web/19961115040956/http://developer.netscape.com/library/documentation/livewire/index.html http://web.archive.org/web/19961115040956/http://developer.n...
29athrowaway 6y ago
Pei-Yuan Wei created the ViolaWWW browser in 1991. His browser had many features, including: - Stylesheets, similar to CSS - Scripting support, using a scripting language (like JavaScript). - The equivalent of Iframes Pei-Yuan Wei is the man.
stevefan1999 6y ago
> a la React in hybrid-mode Isomorphic app?

drblast 6y ago

The industry is cyclical and to be forward thinking all you have to do is describe what's already happened and assume it will happen again. ;-) The things being done with JavaScript today are not new, nor is the idea that a server and client would coordinate to run interactive apps. That fundamental concept has been reimplemented in many different ways until we've landed on the current rube goldbergian monstrosity that are web apps. It shows that the desire to have users interact with a service in particular ways will not go away. The technology used to do that is mostly irrelevant.

brundolf 6y ago
I'm not surprised that the architecture isn't new, I'm surprised that web apps were already being talked about this way using JS specifically. JS's early design flaws are often written off as, "well it was never intended to be a real programming language like it is today". But from reading this, that doesn't sound to be the case.
- ChrisSD 6y ago
  I think JS' early design flaws were a result of being written in a day more than anything to do with a specific purpose (I exaggerate but not by much). Though it is true that most people at the time used JS (if they used it) for much simpler tasks than described in the article.
  - jrumbut 6y ago
    I think in some ways the problems people have experienced come back to a language design that is fairly ambitious. Specifically the inclusion of a prototype OO system is confusing if you aren't aware what that is and have only been exposed to Java-like OO programming. But in fact it's very powerful and not so hard to learn once you realize you have to. As with other web technologies, it's simple at first glance but the learning curve gets steeper at some point.
  - blululu 6y ago
    It was written in 9 days, which is astounding. I suspect that the project was given a week to complete and it came 2 days late. In any case it seems unlikely that it’s problems would go away if given another 5 days. A lot of the wired things in a scripting language only become obvious at scale.
- tracker1 6y ago
  I don't so much think of them as flaws... the first use case was form validation, and most of the fuzzy type coercion makes a ton of sense through that lens, where ''. 0, etc. coercion to falsy is easy for dealing with user input. It's also why it's one of my favorite options for ETL workloads. It's just a matter of understanding the langauge. That said, it's been my favorite language since well before the "good parts" book.
  - brundolf 6y ago
    I use JS every day; I would say I like it. I would even say that in 2020, if you know what you're doing, it's a pretty good language on the whole. But I don't think it's controversial to say that the following were objectively bad decisions (in hindsight, of course, but still): - Automatic casting behavior between the core types (you're the only person I've ever heard suggest that this might be a good thing) - Automatic semicolon insertion - A core Date object that lacks basic control over time-zones and reasoning about time-zones - Assigning to an undeclared variable silently creates a global - Allowing duplicate function parameter names where later ones just hide the earlier ones - Distinction between undefined and null (this one might have a few defenders) Some of these are now prevented by "strict mode". Others have been patched-over, for example by the addition of === which prevents casting behavior for comparisons at least. Others can be bridged by libraries (Moment.js) or by best-practices (use foo == null to smooth over the null/undefined distinction, never use a value's implicit falsiness in a conditional, etc). But the point is that JavaScript has this giant asterisk that will never go away, of things you need to do/avoid/utilize in order to get the most basic behaviors right.
ezekiel68 6y ago
I agree with your basic premise. However, in this particular instance, what would have been the historical equivalent ("already happened") of scripts sent by the server to the client during the request response cycle, which could perform layout and logic in the client? If you're simply referring to code that could run on both client and server, your point is clearer to me.
- deleted 6y ago
  [deleted]
- cubano 6y ago
  AJAX is part of the request response cycle? Let's face facts...AJAX is the real secret sauce with JS and what makes it truly useful.
  - bryankaplan 6y ago
    Long before the term "AJAX" was coined, we used hidden iframes to do the same thing.
- ptx 6y ago
  Display PostScript[1] maybe? Developed by NeXT in 1987. Or NeWS[2], also based on PostScript. [1] https://en.m.wikipedia.org/wiki/Display_PostScript https://en.m.wikipedia.org/wiki/Display_PostScript [2] https://en.m.wikipedia.org/wiki/NeWS https://en.m.wikipedia.org/wiki/NeWS
smnrchrds 6y ago
> already happened and assume it will happen again So say we all!
- osullip 6y ago
  Under appreciated BSG reference. Well done!
cubano 6y ago
Yes for sure..I worked as a corporate contractor for AT&T in 1990's and I was doing client/server apps using MSVC++ that are basically identical to React-type wideweb dev... Indeed, your absolutely correct in saying it was obvious where webapps had to go, and that HTML and CSS just wasn't going to get us there.
- amenod 6y ago
  Nitpick: "...and that HTML just wasn't going to get us there" (CSS came out in 1996).
  - BearOso 6y ago
    And CSS wasn’t widely used until a few years into the ‘00s. Only then did more consistent layout engines finally make it viable for stuff other than just styling text.
    - cubano 6y ago
      Damn...I've forgotten more about the timelines of this stuff then most people know.
      - amenod 6y ago
        Me too. But your comment surprised me as I remember hearing about this new thing "JavaScript" waaaaay earlier than about CSS. I didn't actually know they came out this close together.

AntiRush 6y ago

Philip Greenspun has a great review of Netscape LiveWire from the time. https://philip.greenspun.com/wtr/livewire.html https://philip.greenspun.com/wtr/livewire.html You can see that the current JavaScript tooling complains are nothing new under the sun: So what used to be a few keystrokes in Emacs or Netscape Gold now requires three steps: edit the .html file recompile the .web file restart the LiveWire app from the appmgr

Lammy 6y ago
This quote is adorable considering the size of most pages today: "This approach has several disadvantages, the first of which is speed. You are gratuitously transporting potentially many kilobytes of data back and forth across the network."
- pmontra 6y ago
  I was there, kB were an issue. We had 56 kb/s modems vs (let's say) 56 Mb/s fiber now. We gained a x1000 factor and we're dealing with many MB now instead of many kB back then. Page size grew x1000 too. But loading pages was really slow, mainly because browsers were slow. No parallel loading of images, no progressive rendering. Those were the first optimizations.
  - icedchai 6y ago
    I think you underestimate the effects of high bandwidth. There was a sweet spot in the late 90's when some people had broadband (early cable modems, generally 3 megabits, or DSL.) I had an ISDN line from 1996 through 1998, then a cable modem after that. The web was fast because it was built for dial up. As broadband gained more and more market-share, the bloat increased.
icedchai 6y ago
Working with LiveWire was incredibly painful. Often the server would crash during the restart phase (this was under WinNT 4.0 back in 1997.)

giovannibonetti 6y ago

Running the same logic and the same technology in the server and the client was mandatory for realtime multiplayer games since the 1990s. See this article from Valve [1] for a briew overview of how client side prediction works. You should also have the server process the data to avoid cheating by modificating the client app. [1] https://developer.valvesoftware.com/wiki/Latency_Compensating_Methods_in_Client/Server_In-game_Protocol_Design_and_Optimization https://developer.valvesoftware.com/wiki/Latency_Compensatin...

cubano 6y ago
Wait a minute here...I was writing realtime multiplayer games for Galacticomm's MajorBBS in thr late 80's and we just pushed ANSI and made VERY interactive games without the need for a rich client...altho we did envy AOL's bitmapped graphic capabilities at times...

NegativeLatency 6y ago

Didn't visual basic support some kind of client side code?

aidos 6y ago
IE (3? 4?) let you specify vbscript instead of JavaScript as the language in your script tags. Edit: introduced in IE3 (1996) apparently. https://en.m.wikipedia.org/wiki/Internet_Explorer_3 https://en.m.wikipedia.org/wiki/Internet_Explorer_3
- dfox 6y ago
  IE 3 does support VisualBasic as another script language. Later IE versions simply supports any scripting language that is provided by the underlying platform (including javascript). People tend to regard the whole IE4/Windows 98/"Desktop enhancement package" thing as Microsoft being anticompetitve and trying to kill Netscape, but the whole thing has solid technical background. Well, the whole "PWA" concept existed at the time except it wasn't called that.

deft 6y ago

ASP, the original one before .net, had a language called jscript that ran the ie js engine on the server. https://en.wikipedia.org/wiki/JScript https://en.wikipedia.org/wiki/JScript

drittich 6y ago
Yes, I coded in JScript happily for about 3 years. Even better, using Windows Scriptlets let me write dynamically-compiled COM components in JavaScript that I would call from the web pages. As a result, I could launch updates independently in a microservice-like fashion, share the same libraries (like validation) on client and server, and use the same COM components in crons. Not bad at all! Also, because we had COM components, we could now use Window's built-in message queue MSMQ for async processes like payment transactions. I started doing this in 2003 - looking back, that was a pretty good developer experience.

GordonS 6y ago

> Edit: Apparently they already ran JS on the server! I had no idea Hmm, I started work as a web developer back in 2000, and I don't remember ever coming across such a notion. The first time I heard of JavaScript being used server-side was NodeJS many years later.

sergeykish 6y ago

Server side JS had to write(): <HTML> <HEAD> <TITLE> Hello World </TITLE> </HEAD> <H1> Hello World </H1> <P>Your IP address is <SERVER>write(request.ip)</SERVER> But client side JS had to write() too (there was no DOM), and so we have 'foo'.link('http://example.com') // "<a href="http://example.com">foo</a>" 'bar'.bold() // "<b>bar</b>" http://web.archive.org/web/19961115040956/http://developer.netscape.com/library/documentation/livewire/index.html http://web.archive.org/web/19961115040956/http://developer.n...

29athrowaway 6y ago

Pei-Yuan Wei created the ViolaWWW browser in 1991. His browser had many features, including: - Stylesheets, similar to CSS - Scripting support, using a scripting language (like JavaScript). - The equivalent of Iframes Pei-Yuan Wei is the man.

stevefan1999 6y ago

> a la React in hybrid-mode Isomorphic app?