[barosl]

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

This is exactly what we do with server-side rendering today, huh. So the originally intended uses of JavaScript included servers too.

> Java programs and JavaScript scripts are designed to run on both clients and servers, with JavaScript scripts used to modify the properties and behavior of Java objects

This, not quite so.

[bazoom42]

Netscape had a line of web servers supporting server-side JavaScript. But who in their right mind would use JavaScript on the server side?

[ttepasse]

Back in 2000 there was a the Helma Object Publisher, a web application framework, written in Java, based on Netscape’s Rhino, afair, and enabling serverside Javascript including a form of ORM which mapped the db into JS objects. Antville, for a time the biggest austro-german blogging community, was and I think still is written in it.

https://github.com/antville/helma

[fuzztester]

Yes, it was called Netscape Application Server. They changed the product line name later, to IPlanet Application Server, IIRC.

Modules written in JavaScript and run on the server were called AppLogics (bad name, IMO).

[peteri]

As did Microsoft with ASP (your choice was VBScript or JScript for a scripting language)

[leptons]

JScript still runs in modern Microsoft servers. I still have one site running with ASP.NET/JScript.

[pmontra]

They were very slow even compared to the Java of that age.

[severino]

>> Java programs and JavaScript scripts are designed to run on both clients and servers, with JavaScript scripts used to modify the properties and behavior of Java objects

> This, not quite so.

Well, technically, one can (and often does) use Javascript to send an asynchronous request to a server that -when programmed using a Java based framework- will probably modify the properties of one or more Java objects, i.e., some entity, etc.

[gleenn]

Java Applets were a thing for a long time though. Interesting but very dead tech.

[cabalamat]

They were essentially the same idea as WASM -- a portable machine code that runs on web browsers -- but a quarter of a century earlier.

I suspect Java applets fell out of fashion because they could only manipulate a rectangular area of the screen and not the DOM. Did the DOM even exist in 1995?

[vbezhenar]

The problem with Java was flawed sandbox implementation. Every month there was escape sandbox vulnerability. People didn't keep their JVMs up to date. Installing JVM plugin for browser, between x86, amd64 Edge, IE, with multiple JVMs on the machine, was a holy mess.

So in the end it was security nightmare.

Jobs finally killed it, by declining to support Java on iPhones. So from that point it was doomed.

WASM is part of the browser. Browser vendors figured out how to keep their browsers evergreen. You don't need to install anything, it just works. It works on iPhones.

So, yes, idea was the same, but implementation was actually good and supported by everyone.

[unscaled]

The vulnerabilities and constant updates where the final straw that killed Java applets, since they convinced browsers that the unpopular Java applets plugin was a liability more than an asset. Java's security story was broken from day 1, but back when Java applets were trying to gain a mindshare security awareness just not there, and almost-weekly nag screens asking you to update your JRE were not a thing yet.

It's also not the fact that users rejected the idea of apps that are restricted to a rectangle inside the web browser - after all, Flash and even ActiveX (to a limited degree) managed to churn out popular apps running inside a (badly) sandboxed rectangle. Some of the popular use cases (e.g. games) did not die, and are now faithfully served by WASM. Rectangle-constrained applets are obviously not good for every use case, but Java applets failed to succeed even at the places where Flash shined later.

Looking back, I think what killed Java applets was that they were just slow, ugly, hard to interact with and had bad developer experience. Developing HTML pages was easy - just a change/reload cycle. The same goes for cgi-bin scripts. Java applets required compilation, packaging and then testing, at the time when automated building tools were not there. IDEs with RAD designers that tried to improve the experience did come, but at least most Java IDEs I tried back then were quite cumbersome to use compared to incumbent native RAD tools like Delphi or Visual Basic.

In addition to that, Java applet support was initially spotty during the browser wars, and features such as JAR files and different JDK 1.1 (and later JDK 1.2) APIs were not evenly supported across Netscape Navigator and Internet Explorer[1]: https://www.infoworld.com/article/2076251/applets--still-ess...

And then there's the slowness and ugliness. You really only had AWT available for your UI and graphics, and it sucked. It was ugly, buggy and slow. In theory, it shouldn't have been so, but the technology just wasn't ready and just wasn't mature enough.

I think Flash was so wildly successful because it took an entirely different (and less ambitious) route at the beginning. Flash started as a multimedia player with user-friendly authoring tools. They later added ActionScript and Flash itself become the RAD tool that could penetrate the web frontend.

[panick21_]

Ease of development and speed of loading really makes a difference.

I remember just sitting around looking at these Java Applets loading whole applications. While Flash games were snappy.

The moment you hit some webpage and it shows you a Java Applet loading bar you knew the website was useless basically.

I think this had quite a bit to with Java and the way it implemented UIs. Also just serving a whole bunch of unnecessary stuff. To be fair this eventually became an issue with JS as well, but not the the same degree compared to the network speed.

[pmontra]

They fell out of fashion because you had to install JRE on the client machines and because they ended up with an icon in the Windows task bar that obnoxiously asked again and again to download a 100+ MB update week after week. Internet was slow, still a lot of 56 kbps modems, and many people never upgraded and ended up hating the experience. Flash was better looking and they had a much compelling reason to download it, games.

[mynameishere]

No, Applets were just clunky and slow-loading--that's why they weren't popular. Any website loading one would freeze up the whole machine. But there were definitely Java Applet games, and I happen to remember the last one I ever played: Minecraft.

Flash loaded quickly and seamlessly, but otherwise had all the same problems.

[amlib]

Damn, I remember playing creative minecraft back in 2010, a surprisingly good experience for a java applet embedded in the browser. All running on linux with fairly smooth opengl rendering. I also remember using a wrapper/front-end called world of minecraft that allowed you to run the jar outside of the browser and even had multiplayer support...

[andai]

Does anyone know why applets loaded so slowly and flash loaded so fast?

[Sharlin]

Not only that, but they were notoriously vulnerable to attacks.

[nohuck13]

Nope, at least not as a standard. The original DOM spec is dated 1 October 1998.

https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/

[shiomiru]

Notably though, in 1997 Netscape 4 already had document.layers and IE4 document.all, two incompatible precursors to the DOM.

Some info about the LAYER API (which Netscape eventually killed, as the MS/W3C DOM prevailed):

http://web.archive.org/web/19971015223701/http://developer.n...

Also, a DOM compatibility guide can be found here:

http://www.dannyg.com/dl/JSB4RefPoster.pdf

[bowsamic]

I think in the end they were basically replaced by Flash and Shockwave, which were much easier to use for what most people were using Java applets for. Then, of course, Flash was abandoned because Adobe, being Adobe, seemed to absolutely refuse to fix many of the huge security issues that Flash had. Steve Jobs then led the fight against Flash, and that basically leaves us at today.

Remember that even after JS was released it still took many years until it became fast enough to use for big applications. If I'm not wrong, Google Chrome was made partly with the explicit goal to have super fast JS.

Also no the DOM did not exist until 1998.

[andsoitis]

> Did the DOM even exist in 1995?

While the limited facilities provided in the first generation of JavaScript and JScript for detecting events and manipulating HTML elements eventually came to be known as "DOM Level 0", it wasn't until 1998 that the first DOM specification was published. Source: https://en.wikipedia.org/wiki/Document_Object_Model

[andylynch]

It was also because they were slow to load, and especially because unlike flash targeting newer Java plugins was painful and unreliable.

[beebeepka]

I think it was possible to view the source of applets.

[afandian]

The book "JavaScript: The Definitive Guide" had a server-side component since I think the first edition in 1996.

[distcs]

I never understood these books. Who reads a 1000 page book to learn a programming language? I bought this particular book some 10 years ago hoping to "master" javascript. The book was so dull that I could not even get to the 3rd chapter. There are books about much more complex subjects that wrap up in < 400 pages. What's really the market of these doorstop books?

[sanitycheck]

There's a lot of value to having "everything in one place" during the learning process and later for reference, plus the convenient dead-tree format means bookmarks are instantly accessible. They're also written by competent people and edited by professionals. I'm a fan.

Of course when one's chosen tech is too new, and/or moving faster than the book publishing process then one is stuck with Stack Overflow, random blog posts and insufferable YouTube vids. Which all also go out of date within a year.

[andylynch]

It’s mostly gone now with the Web but having a go to book used to / can still be a really good reference. In the nineties ones like the Camel book for Perl were practically required reading in their fields.

[dspillett]

> I never understood these books.

How long have you been in the industry?

They don't make a lot of sense now, reference material is generally kept in electronic form, often online not locally, both because it saves resources (paper, space to store it) and because things change and online content is so much easier & cheaper to keep up to date. That and things change faster ATM in most tech fields.

But think back to the late 90s when many, even devs, had little more than a slow and expensive (per-minute phone call costs) dial-up connection that blocked other calls while active, and having a local resource that you could flick through to find details makes a lot more sense. Also not having convenient easily portable devices with which to store and read the information makes a huge difference. Even if you did have a laptop it was bulky and the screen was not particularly nice to read from. Heck, desktop screens were headache inducing compared to modern kit (imagine a goldfish-bowl like CRT, 14" diagonal, less because you shrunk the display to avoid the really rounded bit at the edge, 15" if you were lucky, 17" if you were rich, displaying at 640×480 or maybe 800×600 resolution (maybe 1280×1024, again: if rich), in 16 or 256 colour depth so no font smoothing, with a pretty low refresh rate) making reading the information from the book much more pleasant even if you did have a local online copy at your fingertips.

Those books tended to have three parts and you weren't expected to read them all cover to cover:

1. Fundamentals, which you would probably read fully unless you had a fair amount of relevant experience of similar languages/environments in which case you'd skim to pick out the key differences.

2. Specific parts in detail, which you would read some sections of but ignore others until you needed them later. This might include worked examples of using common parts of the standard library and so forth.

3. Reference detail. This might be half the book or more, maybe two thirds in some cases. This you would not read as such, you would use it like a dictionary or mini-encyclopedia. That is the part that makes least sense in the modern world.

If you want a really extreme example: I had a copy of the the MS's C/C++ compiler, the full documentation for included a printed reference to the Windows API of the time (Win 3.x era). IIRC that stack of books, piled on the floor, came up to noticeably more than half my height. The vast majority of that was tools and API reference material, though small chunks were intended for more end-to-end reading.

The huge books did seem to hang around beyond their really useful period. I don't think I bought a dead tree like that as late as 2010, so your “about 10 years ago” is probably when they were well past prime. Even in their prime there were some really terrible examples (poor tutorial sections, reference sections that were out of date before they were even published, and full of errors on top of that).

[ttfkam]

Yeah, a lot of younger folks don't get this. In 1995, the web wasn't like today, only slower. There were no web search engines, only catalog pages like Yahoo. Documentation was often so hard to come by, View Source really was your only option if you wanted to learn newer techniques. That AND it was slow: a 14.4 modem downloaded 1MB every 10 minutes under optimal conditions (no one called while you were connected).

CGI.pm was king.

[jasomill]

While the modern Internet has certainly changed how documentation is published, your suggested three-part breakdown seems as relevant today as it did when documentation was mostly delivered in print.

It's also worth pointing out that being able to skim comprehensive, reference-style documentation to get a general overview of a technology without getting bogged down in irrelevant-for-present-purposes detail is a useful skill to learn.

“As the art of reading (after a certain stage in one’s education) is the art of skipping, so the art of being wise is the art of knowing what to overlook.”

— William James[1]

[1] https://archive.org/details/theprinciplesofp00jameuoft/page/...

[dave333]

At the time there wasn't really a good search engine, Yahoo's hierarchy of interesting sites was just starting. No Slashdot and no Google to find it to see how to do things or fix particular problems. Not much OSS to take as an example. Online doc was dry and limited. Blogging only started in 1994 so not much out there yet. But as the web took off books quickly became almost irrelevant.

The framework obstacle course for developers took off. My particular path through it was POJS, YUI-ext, EXTJS, Dojo, jQuery, Backbone, Angular, React - probably about 2 years each give or take.

[pmontra]

They were also language references. What we are googling now was in those books back then. The second half of 90s was the tipping point between books and web docs. Books were at least 6 months behind the web docs and web technology moved faster than today. It was less wide in scope but it changed a lot. Think about the times when Javascript changed a lot in the early 2010s. It was something like that.

[afandian]

I have a dead-tree copy of the JVM Specification. I'm never going to need it, but it's a fascinating read and stands up well as a book.

https://docs.oracle.com/javase/specs/jvms/se17/jvms17.pdf

[teh_klev]

You could dip into sections of these books and pick and choose what you needed to learn. I don't think I ever read most of the three or four hundred books I bought in the period from 1985 to 2006 in a linear fashion. By 2006 I'd mostly switched to learning new stuff from online sources.

[joeframbach]

> Who reads a 1000 page book to learn a programming language?

Uh, I did, in 1999. My parents would drive me to Barnes and Nobles and I sat there and read the definitive guide cover to cover.

[oaiey]

Following that time frameworks like ASP or Coldfusion (?) had server side JavaScript for code snippets similar to what the browsers were doing on the client. So I think, the JavaScript on the server note here is more addressing the ASP use case then the nodejs one.