9 ms·

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

• gleenn 3y ago
  Java Applets were a thing for a long time though. Interesting but very dead tech.
  • cabalamat 3y ago
    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?
    • nohuck13 3y ago
      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/ https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/
      • shiomiru 3y ago
        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.netscape.com/library/documentation/communicator/dynhtml/index.htm 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 http://www.dannyg.com/dl/JSB4RefPoster.pdf
    • bowsamic 3y ago
      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.
    • pmontra 3y ago
      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.
      • Sharlin 3y ago
        Not only that, but they were notoriously vulnerable to attacks.
      • mynameishere 3y ago
        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.
        • andai 3y ago
          Does anyone know why applets loaded so slowly and flash loaded so fast?
        • amlib 3y ago
          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...
    • andylynch 3y ago
      It was also because they were slow to load, and especially because unlike flash targeting newer Java plugins was painful and unreliable.
    • vbezhenar 3y ago
      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 3y ago
        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-essential-to-java.html 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.
    • andsoitis 3y ago
      > 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 https://en.wikipedia.org/wiki/Document_Object_Model
    • beebeepka 3y ago
      I think it was possible to view the source of applets.
• oaiey 3y ago
  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.
• bazoom42 3y ago
  Netscape had a line of web servers supporting server-side JavaScript. But who in their right mind would use JavaScript on the server side?
  • pmontra 3y ago
    They were very slow even compared to the Java of that age.
  • fuzztester 3y ago
    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 3y ago
    As did Microsoft with ASP (your choice was VBScript or JScript for a scripting language)
    • leptons 3y ago
      JScript still runs in modern Microsoft servers. I still have one site running with ASP.NET/JScript.
  • ttepasse 3y ago
    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 https://github.com/antville/helma
• afandian 3y ago
  The book "JavaScript: The Definitive Guide" had a server-side component since I think the first edition in 1996.
  • distcs 3y ago
    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?
    • dspillett 3y ago
      > 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).
• severino 3y ago
  >> 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.