Netscape and Sun announce JavaScript (1995) | Hacker News Reader

Netscape and Sun announce JavaScript (1995)

web.archive.org

337 pointsdamethos302 comments

I'm not sure about this. The web is first and foremost a document platform. Adding scripting to it could cause security problems, hurt usability and destroy the reliability of this new approach some startups are trying called "web search" which promises to automate index directories. I also wonder what's the difference between Java and JavaScript, at first glance, they look very similar.

I don't see what's wrong with embedding a programming language in the browser. It's light weight, and rather simple.

As long as this stays in the browser, and is not also used server-side, I don't think there's much to worry about. Since it's designed to be Java like, I suspect most developers would opt to use server-side Java, and this in browser. This probably won't change.

You could just buy WebObjects from NeXT and build amazing dynamic web applications with the best GUI tools and a true object-oriented language.

It’s only $50,000 but surely everyone making real web apps can afford that. It’s a rounding error compared to what you’re paying Sun for your server hardware.

I’ve seen an interesting approach for a lightweight, Open Source server side scripting language by a Danish programmer. It’s called PHP/FI and has been created specifically to make handling forms and dynamically generated Web pages easier. It might even evolve to be an alternative to buying WebObjects.

I don't see how it's going to beat Perl, which already lets you do the same things, but inside a full-fledged programming language. Many webmasters and server admins have already learned some Perl, and it's considered very easy to use (and even easier when you try to read other people's code).

I looked at PHP/FI for my own homepage before, but it's really nothing more than a rudimentary template language, a slightly more powerful version of httpd's Server Side Includes. Rasmus (the developer) seems to be quite happy with keeping it simple. Perhaps you'll be lucky and he'll change his mind and convert it to a full scripting language. Heh, maybe we'll even get two frustrated undergrad students who hate Perl to rewrite the parser so they can use it to write their computer science project. Maybe you'll even be very lucky and somebody will decide to write a popular system for writing web journals in PHP/FI that would take over the world (but how many people would be so self-absorbed as to maintain a web journal anyway).

And you still don't have the database and hardware side covered. PHP/FI seems to support mSQL. mSQL is cheap for commercial use, but still not free, and it doesn't even support JOINs! And you also need a server. You also need a server. httpd used to be cool, but NCSA is no longer maintaining that. There's a serious of patches running around, so you could just run a patchy version of httpd, but how far will that take you? Next you need a proper OS to run that thing on, but while we're all waiting for GNU Hurd, there's a guy from Finland who made a free *nix OS that's been gaining quite some traction recently. These Scandinavian guys are full of surprises. Maybe you'll be lucky again and there's yet another guy in Finland waiting to unleash a free software SQL database with joins, who knows.

> I don't see how it's going to beat Perl, which already lets you do the same things, but inside a full-fledged programming language

I don't know if you've heard of CPAN - it was introduced less than 2 months ago (October '95) and it's fantastic: you can browse and download modules off the world-wide web without hunting down tarballs on obscure FTP servers! The number of Perl modules on CPAN is growing daily! Any functionality a webmaster may want can be achieved using Perl CGI scripts - I highly recommend the latest CGI.pm (v2) whixhbyou can get from CPAN

I like your optimism but lets get real here: the future of server-side web programming is emacs-lisp talking to Postgres95.

What’s open source?

I don't know, Java is such a new untested language, I'm not sure anyone will choose it for CGI programming over C, or maybe something like Perl.

[outside of kayfabe, Java was really first released in May 1995, only a few months before this press release, and was mostly used for applets and desktop applications (building a web browser!) - server side usage came a while later]

I've taken a look at Java and its standard lib and it's really bad at the kind of text processing that 99% of CGI programming is. Hell, it doesn't even have regexps! To be fair, C is even worse, but that's why we have Perl.

> As long as this stays in the browser, and is not also used server-side

It looks like this is exactly what they intend to do at some point. From the article:

> A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly.

I don't see how this would work, tbh.

Yes, this does not make much sense to me. I will stick with Java and Perl until I see a viable reason to Go to something else. Maybe someone will create an improved version of C++ (though my skills there are rather Rusty).

Yeah, you’d have to install yet another runtime on all of your nodes to support server-side JavaScript.

I’ve been playing around with this new language called Python. The indenting syntax takes a little getting used to, but the code is way more readable than Perl. Just be sure to set indent-tabs-mode: nil if you use Emacs.

Perl is the only way to go for serious CGI scripts. It’s so powerful, Python is limited and clunky by comparison. And a new language with syntactically important whitespace? Seriously? It will never displace Perl!

Eh, maybe. well, nice talking. I'm going to go back to writing CFML. My boss bought a bunch of licenses with our last funding round, so I have to use it. I don't think it's going to make it any easier to write our reverse auction site for pet food discount coupons (don't tell anybody - we're still in stealth,) but whatever.

Python will never work on the web since different platforms use different characters to indicate line break.

I know a guy Rasmus, working on this server side bit called Personal Home Page. Maybe worth checking out.

I think it’s fine so long as they come up with a consistent way to package this JavaScript code into modules. It would be crazy to have 3-4 competing standards.

> 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. On the server, the scripts might dynamically compose and format HTML content based on user preferences stored in a relational database, and on the client, the scripts would glue together an assortment of Java applets and HTML form elements into a live interactive user interface for specifying a net-wide search for information.

JavaScript is obviously meant as a glue language. Component-based programming is quickly replacing binary files as the method of deployment with technologies like CORBA and COM (the base technology for OLE 2.0). Java Applets are Java's answer to portable, client-side UI component. But in order to integrate them with a static web page or with each other you need some glue code, and this is where JavaScript stands: write reusable components that unleash the full power of Java, and tie them up together using JavaScript glue code.

I expect that in the near future Sun will introduce a server-side component model to accompany Java applets. It'd be cool if they use some coffee-related name for that, idk, maybe Java Beans? This is going to revolutionize servers and everybody is going to throw away their cgi-bin/ folder with hacky perl scripts and move to components. Think about it! Instead of writing your own code, you can wire up mature components developed, each developed by an industry leader:

- Advanced Forms Applet by Microsoft - Server components for converting submitted forms into Excel spreadsheets, also by Microsoft - Database client developed by Oracle - Automatic stock ticker from Bloomberg - Integrated website search from Lycos - News applet from CNN

Sun is graciously aware of the great danger posed by the first company on this list, but in their great foresight they are going to define generic interfaces for every common type of component, and insert clauses into their license that will allow them to sue companies which try to extend these interfaces in an anti-competitive manner. Now, if you want to switch from Excel to Lotus 1-2-3 or from Oracle to Sybase or Informix you're also free to do so. The same goes for your OS, as all Java components are fully platform-independent. This is truly the future!

> I suspect most developers would opt to use server-side Java, and this in browser

But why create a new language just for the browser? It clearly makes more sense to use Java in both the server and the browser. We could write little Java applications inside the browser; say we call them "applets"?

> As long as this stays in the browser, and is not also used server-side, I don't think there's much to worry about.

I'm kind of breaking the immersion here, but I'm quite sure at some point Netscape was selling a Javascript powered web server.

I recall a web browser[1] written in /Java/ ... I don't remember any servers using javascript back then.

1. http://www.java.sun.com/products/archive/hotjava/index.html

https://dev.to/macargnelutti/server-side-javascript-a-decade...

That's definitely server side JS, but I thought the person I was replying to meant a web server that was written in JS, but I suppose "powered" could mean that it just runs JS.

I saw that link elsewhere in this thread after my reply, and I also thought that this might have been what was being referred to.

I don't see the point of this; you can already achieve something quite similar by compiling GNU PITA (Processor of Interactive Text Activity) with J.P. Blacker patch on top of it, which is publicly available on his FTP server.

Then to get interactive content; you just pipe the content of each page to the pita daemon using UNIX sockets and write the output to a file descriptor in the /dev/screen directory (just compile and mount the "interactive-wp" filesystem on /dev/screen first, of course).

The only gotcha is to ensure compatibility between these components, but someone shared a compatibility matrix on IRC a while ago, Sio it's common knowledge at this point.

Really these companies "innovations" are a joke.

> I also wonder what's the difference between Java and JavaScript, at first glance, they look very similar.

JavaScript is a scripting language and therefore much easier to use. No slow compilation and build step, no complex and rigid type system yelling at you, no dependency hell. Just type the code in notepad and press f5 in the browser to see it run. You dont need to understand advanced concepts like classes or packages or exceptions. It is as simple to write as an Excel macro.

Java on the other hand requires professional programmers, which are a lot more expensive than web designers, and less fun.

It's 1995. What's a "Web designer"?

You mean those graphic design people who try to make the whole page as a GIF, like they're making a print brochure, and just don't get hypertext?

Don't worry, they'll clue in or get left behind.

The power of a global distributed hypertext for free sharing of information is so superior that it can't be subverted.

The Internet sees these advertising-type designers as damage, and routes around them.

> You mean those graphic design people who try to make the whole page as a GIF, like they're making a print brochure, and just don't get hypertext?

> Don't worry, they'll clue in or get left behind.

Time traveler here. People with this same mentality are still working in 2023, but instead of making the whole page an image, they're making the whole page a "web app". Almost three decades later, they still don't get hypertext.

Whole-page gifs were only necessary because of the lack of layout support in HTML. But with the recent introduction of the powerful TABLE-tag, HTML now has a future-proof layout model which will surely be enhanced further with more tags, giving a fine-grained control over typography and layout.

> JavaScript is a scripting language and therefore much easier to use.

There are already scripting languages available. Why not just use something like Tcl which is lightweight and easily embeddable? Why re-invent the wheel?

Some history can be found at least here [1] and [2]. Based on that, the original idea was to build something that was based on Scheme. Then Sun came to the picture. They already had Java and there was pressure to have something that looked like Java. Story was that you would Java for the big stuff and Javascript for more light-weight client-side tasks.

That (marketing) worked out pretty well. At least for me it took years to figure out what kind of language Javascript really was. Seeing jQuery for the first time was kind of revelation.

[1] https://auth0.com/blog/a-brief-history-of-javascript/ [2] https://2ality.com/2011/03/javascript-how-it-all-began.html

> There are already scripting languages available. Why not just use something like Tcl which is lightweight and easily embeddable? Why re-invent the wheel?

This just begs the question: why are there already multiple scripting languages available.

And this further begs the question: why are people still "re-inventing" the wheel by building new languages?

https://stancarey.wordpress.com/2015/12/09/raising-the-quest...

"There was once a dream that was Rome. You could only whisper it. Anything more than a whisper and it would vanish, it was so fragile. And I fear that it will not survive the winter."

Thanks for the illuminating explanation.

Sounds like I can blame whoever translated to English in a 1581 text of Aristotle’s Prior Analytics, the wrong usage of “beg”.

At the same time, I intend to use the phrase correctly in the future!

You did use it correctly.

Anyone arguing that you can't use words to mean what they obviously mean and that everyone takes them to mean, but instead must only use them to refer to obscure logical fallacies is clearly nuts and should be ignored.

> At the same time, I intend to use the phrase correctly in the future!

These kinds of dual usages come up pretty often, but in that spectrum I find this one very interesting because it is somehow very good at scratching some sort of intellectual/elitist itch in all of us. Both usages are fine, but one is more rare (but not too rare) and "came first" so is ostensibly more "correct." Which makes it very satisfying to bring up in these kinds of conversations :-)

Or what millions of windows developers already know and love: visual basic.

I hope Microsoft comes up with something like it, so we are not forced to learn java in order to add scripts to html pages.

There is great synergy in having the two complementary language using (almost) the same syntax. E.g. Both use ‘this’ to refer to the current object, ‘new’ to create a new object, ‘==‘ to compare values, both use the same Date library which is throughly tested and future proof, both have wrappers to turn primitives into objects etc.

Surely this will avoid a lot of mistakes when switcing between the two languages.

Wow, that’s exciting! Maybe I’m being too optimistic, but does this mean we’ll soon be able to write single pieces of code that can execute on both client- and server-side?

It sounds like pure Java will get us part of the way there thanks to applets – which are also supported in Netscape 2.0 – but JavaScript gives much more control of the whole page. I played with it in an early beta when it was called LiveScript and wrote a crossword puzzle that didn’t need to reload the page at all. Amazing! Now if I can write the backend part in Java and have it work the same way…

I can’t wait for the Java and JavaScript syntaxes to unite and make web page development simpler. Netscape and Sun HQs are just a handful of miles apart, so come on folks, don’t drag it out! Could we get this before the end of the year?

If they had to chose an existing scripting language, surely Perl would be the obvious choice? Perl is designed after how humans think, where other languages force you to think like a computer.

Perl was pretty complex and not easy to embed. Self would have made sense, as Sun already had a very good implementation.

Don't worry, Tcl is also being proposed as the internet scripting language standard. I'm sure wiser heads will prevail.

Two things:

1) Introducing scripting to the web can introduce security concerns, but this is the wrong way to think about interconnected systems. By far the greater security concern is trust models built over anonymous connections. When you can eliminate anonymity or the security implications therein most of the security issues that arise from the availability of scripting are like wise mitigated.

2) The greatest difference between JavaScript and Java is that Java will force OOP on you, in JavaScript functions are first-class citizens, and the scope model is always lexical. I abhor OOP and completely avoid the ambiguity of inheritance and keyword pronouns when writing JavaScript. Always choose composition over inheritance. When I see people intentionally do otherwise I immediately assume they have no idea what they are doing.

> keyword pronouns when writing JavaScript.

This, when read using 2023 political correctness caused me to have to wipe coffee off of my laptop screen. I'm picturing HR paying me a visit because my last commit misgendered the Person object.

...or deadnamed a deleted reference.

Clearly the right approach is to embed a native plugin into webpages so that an actually responsible company can be put in charge of building high performance and secure runtime for this. Let's call it FutureSplash.

I'm really confused, is JavaScript just a rebranding of Java applets? maybe with some minor overlays on top of it?

That sounds more like a marketing stunt to me.

I don't see how this could cause any security issues. The language barely does anything.

> A server-side JavaScript script might pull data out of a relational database and format it in HTML on the fly.

They must be joking. Who runs a server in a browser?

Really disappointed this isn't a full Lisp in the browser.

Lisp is so obviously the future of the web, so this seems like a backward step to me.

A Lisp which used < > instead of ( ) would itegrate very nicely with HTML.

That existed: MDL.

Well, MDL has < > conses and ( ) conses. These have a different type tag, but are otherwise identical. MDL uses that to give the two different semantics, situationally.

Ah, that's what the L is XSLT stands for!

It's not like this will affect a lot these companies bottom line. Sounds like they just spent 5 or 10 days of R&D on it...

I’m still hard-pressed to see what advantages HTTP offers over more mature protocols such as FTP and Gopher.

But the web can change, to allow all kinds of online applications, running in a sandbox, so no one has to install anything, but can play games, write emails, share and edit images or whatever - all in the browser in one language. Ok, we might have to tweak js a bit, to get there ..

Ground control to hutzlibu

I agree, but I wouldn't worry too much. This just adds new functionalities that weren't previously possible using straightforward documents, and may save some bandwidth and time by reducing the need for back-and-forth request/response to CGI servers for doing small calculations that could take place on the client.

As this has no relevance for serving and requesting pure documents there will be no need for us to use a java-script capable web browser if all we want is to read websites.

You can basically do this in Java or Lisp or Smalltalk right? This is not going to work. No one will use this ever.

I agree with this comment. I will now email the webmaster to ask them to update the vote count for your post because it deserves attention.

Agree, if we are to go in this direction I’d rather wait and see what Microsoft is doing with VBScript next year. It uses the COM to access elements of the environment within which it is running. That’s the future. Or Perl.

I can’t see the security issues you are talking about. But if there are, I’m sure it will be patched in a future release - so nothing to worry about there.

I think they are exaggerating. They will just use it to animate some images on websites. What can go wrong? Nobody would be crazy enough to program large applications in such a slow and sketchy language.

I don't know, the world is full of crazy people. In the end this will be used so much, that it will be heavily optimized, so people will compile their normal languages towards it. I mean, I am obviously joking, but in a crazy world anything is possible.

How will this affect my beloved CompuServe subscription?

That’s exactly what marketing said and tried to kill mocha in the crib. Engineering snuck it in anyways then they’re all about damage control.

Source: I was there

> The web is first and foremost a document platform.

I'm here from the future to tell you there's never been much difference between an app UI and a document.

> Adding scripting to it could cause security problem

Everyone eventually gets their shit together after witnessing the catasrophically bad security issues caused by idiots desperately avoiding javascript with even worse ideas and implementations.

What the hell is an "object scripting language"? I'm skeptical, but if there's a natural mapping of JavaScript objects to HTML element hierarchies, and an easy way for JavaScript to parse structured information received from a server, I suppose it could be a good thing.

Is JavaScript a Java scripting language for terminals? Can I do #!/bin/javascript ?

It might even encourage every single webpage to be a bloated, user-hostile mess.

The information superhighway won’t stand for that.

Btw the security problems are solved by having Java and JavaScript running in a secured “sandbox” isolated from the underlying system. So security issues will be a thing of the past.

The web is first and foremost a document platform.

The web is what we make it. If we want apps running in browsers (say, email clients) then that's what the web will become.

Really hope no one uses this to mess up the behavior of anchor tags

I just want to say that I absolutely adore all of you making comments like it's Usenet back in the day.

Now do the Netscape open sources Mozilla announcement on /.

You're all making me remember what it was like to delve into the weird and wonderful world of httpd, perl cgi-bin, and Slackware 3. (My first Linux!! I kept wondering why the system was so aggressive because it said it wanted to bash me for making mistakes: "bash: syntax error"!)

I have fond memories of working on Sony Broadcast's Linux-based digital interactive TV servers in London. Then packing everything up and transporting it to Amsterdam for IBC 1999 (I think?). Setting everything up was a real slog, but I got to see a trade show spring up from a bare floor into an amazing variety of booths. The construction was crazy complex and I'm astounded that it came together in time.

Thank you all, from this old dude, for the huge nostalgia trip :)

Going through the comments and felt the same nostalgia. Everyone is pitch perfect with the tone of the conversation 30 years ago. Camps of "leave well enough alone", "not another language", "big corporations trying to cash in on this internet trend".

Back in the day, some of us were programming snobs. Personally guilty of making comments downplaying the value of HTML and JavaScript.

As I read it and it took me back to the start of my career, I just thought to myself: "Can I retire now? Have I not earned that?"

Quick look at bank account says no.

> … with JavaScript scripts used to modify the properties and behavior of Java objects

Something I didn’t know was a consideration in the original spec of JavaScript: some sort of Java applet interop. I really thought the name was just a nod to it being a curly-brace object-y language! Does anyone know what that looked like? I know of <object> to embed applets into the document, which you could pass arguments to via attributes set by JavaScript, but the wording in this doc sounds like JavaScript could somehow use Java object instances?

Oh wow. A blast from the past. It was called "LiveConnect" and allowed JavaScript to call applet's methods, via reflection on the Java side.

Here you go: https://docs.oracle.com/javase/tutorial/deployment/applet/in...

I remember using it to implement hardware key security for a website. A Java Applet loaded a JNI library, after exploiting a JRE security bug to escape confinement, which interacted with the hardware key. The JavaScript then handled all the "browsery" stuff like setting cookies.

That was in 2001...

I wrote the beginnings of a Javascript game that used LiveConnect to connect to the TCP game server.

this video shows netplay between tabs but i also tested it on a lan in a house (physically moving between computers): https://www.youtube.com/watch?v=vcwPOfVXRc0

https://github.com/fuz/jspkmne

the java applet: https://github.com/fuz/jspkmnengine/blob/master/JSPKMNe.html...

netplay code that Java applet calls: https://github.com/fuz/jspkmnengine/blob/master/netplay.js

here's the java applet calling the Javascript of the game: https://github.com/fuz/jspkmnengine/blob/master/server/Clien...

For some reason I typed the repository name wrong

https://github.com/fuz/jspkmnengine is the correct URL to the repository.

> Reflections on the Java side.

Am I reading this correctly meaning you send a "some_variable_that_i_know_about=deleteAll()" via Javascript and it will just run `deleteAll()` method on a Java applet that has god knows what access it has to things on your machine?

Yes. Applets were very slow to load, and more dangerous than flash. I think applet was the first tag removed. But at the time, you could load up excel in a tag with the right com magic.

The early web boom was wild.

> I think applet was the first tag removed.

<applet> was never removed from HTML, but it was deprecated by HTML4.01 - but only because they wanted to use <object> as a single replacement element: https://www.w3.org/TR/html401/struct/objects.html#h-13.4

Looks like <applet> was officially obsoleted sometime during the switch from HTML4.01 to the Living Specification version: https://html.spec.whatwg.org/multipage/obsolete.html#other-e... - but the spec still permits using <object> or <embed> for Java applets: https://html.spec.whatwg.org/multipage/iframe-embed-object.h...

If the applet chooses to expose such a method; reflection is about finding out what methods are exposed. And while Java had plenty of security holes applets were definitely not supposed to have a lot of access to your computer.

Signed applets had access to your computer. Even just before they were completely removed from the browser, which was just 8 years ago. You had to click "confirm" here and there, but in the end it worked.

JavaScript was originally going to be called LiveScript, associated with LiveConnect. It was renamed for marketing reasons, because Java components were seen as the future for code on web pages, and it could script the interaction between different Java components (potentially from different sources).

That fact it could be used equally for components written in other languages, if they were ever supported by object tags in common web UAs is why it had a more generic name initially.

Fun fact: LiveScript is a FP-oriented language which compiles to JavaScript. It's been around for a while now :-)

https://livescript.net/

Was it even an exploit? I seem to recall reading something about code-signed applets being allowed to load native dlls by design. Which is crazy, one single "trust signature" dialog prompt from infecting a system with malware...

> one single "trust signature" dialog prompt

Sweet summer child ;)

I mean I'm sure there were a million exploits that would bypass even the check and prompt, but that doesn't change the fact that it's pretty crazy that native code execution was part of the design with just one small incomprehensible trust dialog.

I don't think there was any dialog at all. IIRC.

At first, people weren't worried about security. It was just a bunch of us nerds on there. You interacted with real people that didn't seem like they were trying to swindle you. The world still used paper checks for anything big, and credit/debit cards were there, but not like today. It wasn't that uncommon to write a check and ask the shop owner to cash it next week, at least in my poor household.

There wasn't "online banking" or "online identities" to steal, so it didn't seem all that important. The worst thing that would happen is you would lose access to a chat handle.

The sad truth is that executables on desktop haven’t inched much closer to security in the following decades (thankfully mobile did).

Nope, I used an actual exploit, a type confusion bug somewhere within the RMI that allowed to escape the applet's ClassLoader. It then allowed it to access COM objects and basically do everything it needed.

The result was a "zero-touch" installation, with seamless login experience. It was a really crazy time.

Wild. So any other website could then do the same thing as you, accessing the hardware key and all...? Did anyone stop to think maybe this wouldn't be the best way to expose a hardware key? I mean, if you care about security at all, which you probably do if you're even bothering with a hardware key...??!?! %-)

> one single "trust signature" dialog prompt from infecting a system with malware

How many dialog prompts are there to launch signed downloaded exe?

At least running an .exe should be somewhat obvious to computer literate people. When I saw those signed applet dialog prompts, even as a developer it was not obvious to me that it also meant granting unsandboxed x86 code execution to a .dll/.so from the internet.

I remember developing an "interactive CD" with an Encyclopedia in 1998, which distributed a customized version of IE 3.2 (IIRC using something called the "Internet Explorer Development Kit"). The search function consisted of Javascript code calling an applet (which did the search using an internal database implemented in pure data structures within the code) and writing the results in the HTML. The database inside the Applet was so big, that I had to split it in two to be able to compile it (or was it for it to run? I don't remember the exact issue). That's 25 years ago. Wow.

It was quite a direct and ergonomic interface iirc. The magic term was LiveConnect, do I googled that and got to this amazing piece of history: https://www.oracle.com/java/technologies/javase/liveconnect-...

The first example is quite illustrative I think. You’d call custom methods on a Java applet the way you call DOM methods on a div.

I designed and implemented LiveConnect. Previous comment here: https://news.ycombinator.com/item?id=1894374

Invoking Applet Methods From JavaScript Code - https://docs.oracle.com/javase/tutorial/deployment/applet/in...

Invoking JavaScript Code From an Applet - https://docs.oracle.com/javase/tutorial/deployment/applet/in...

It depended on a bit of other libraries installed (the live connect specification which really meant "just Netscape" - https://www.oracle.com/java/technologies/javase/plugin2.html... ).

I remember extremely old advice to use java.util.Date from JS, thought I was going crazy but this article from 1996 mentions it: https://www.infoworld.com/article/2077267/new-javascript-fea...

That was a big draw back then, along with the ability to interact with ASF and Real AV objects. We did a lot of really useless sites that did that in the late 90s.

AKA ActiveX in Microsoft land...

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

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

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

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

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

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

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

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

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

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?

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.

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.

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.

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.

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.

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

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

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

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/

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

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.

> 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

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

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

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

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?

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.

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.

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

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.

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

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.

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.

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

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.

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

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.

What really funny here are few things.

First, Sun should really have implemented its own browser. They basically already had something that shared most of what a modern browser can do when they did NeWS. Basically NeWS that loads postscript over the internet is most of what a modern browser does. Sun should really have done its own browser, rather then do the deal with Netscape.

Second, Sun had developed Self and made it really fast. It shares a lot with Java Script and would have served perfectly fine in that roll. But instead it took 15-20 years until some of the same people who worked on Self and later Strongtalk to make JS fast at Google. Java Script could have been fast as soon as it came out if it was based on Self, rather then scripted together in a few weeks by Netscape.

I think Sun systematically messed up with the whole software division staring in the 80s and got worse in the 90s. Amazing things like NeWS were kill, tons of bad ideas were adopted that around Java/Corba that were clunky.

https://en.wikipedia.org/wiki/HotJava

> HotJava (later called HotJava Browser to distinguish it from HotJava Views) was a modular, extensible web browser from Sun Microsystems implemented in Java.

Are you saying they should have added JavaScript to their Java based browser?

I remember that and also remember them releasing a new version that literally didn't work on yahoo.com. I complained and they said some snarky comment about not complaining about things that were given for free.

That browser didn't last long, and was terrible.

I only remember running it and rotating some 3D model of a helicopter or something within the browser.

It really was a demo, never a serious product.

It wasn't being marketed as just a demo at the time.

That's Sun management for you. At Sun some people wanted to build a browser and really invest into it, but Sun made deal with Netscape instead. And the HotJava thing never had to many resources for development.

James Gosling tells stories of how hard it was and what it took to get basic demos running and then a little later its a product.

I would have preferred the write a real browser in C that was far and add Self to it for Scripting and maybe Java Applets directly in the Browser.

Implementing the browser itself in Java isn't a great idea, specially in the 90s.

They really did mess up their software division. So much lost potential.

Sun, like many of the other Unix vendors of the time, wanted not only to invent the new world but to fully own and charge for it. Self only got open sourced long after it was of any interest or relevancy, NeWS never was, and the OpenLook stuff generally only got really "open" after Motif "standardized" (itself a joke since it never got actually used outside of proprietary-land) and it wasn't until well into the 21st century that the JDK became properly open sourced.

But in fact the relative openness of Java at the time it was launched seemed like a bright spot in this, and in part this was why it was so ascendant through the 90s.

BTW I like Self, but I actually don't think it would have made a good JS-equivalent in a document browser. It really is, like Smalltalk, something that wants to rebuild the whole world in its image, and not much of a "glue" language, like JS was initially pitched as.

The problem was they spend 10 year going on Java crazy but didn't actually develop many good products that made them money. At a time when IBM and others were actually making money from Java.

I think Self could be made into that, it just a challenge of API and how its integrated. And at the end of the day you want to have a full featured language fully integrated anyway, as JS basically became overtime.

>Second, Sun had developed Self and made it really fast. It shares a lot with Java Script and would have served perfectly fine in that roll.

What it doesn't share with JavaScript is the C and Java-like syntax.

They didn't want to risk yet another Lisp and Smalltalk disaster where something far superior was created and then almost nobody used it.

Then change the syntax of it. Not that hard. JS was also scheme at first.

But even so, even with 'C' syntax Java Script wasn't used much for a while.

Who remembers when it was called LiveScript?

Then they got excited about Java and renamed it which confused generations of programmers.

No one understood the power of JavaScript when it first came out. For example at first hardly anyone understood Closures, and the full power of JavaScript being a functional language.

And when Google made Google Maps which was dynamic unlike MapQuest it was a revelation and influenced so many people in what JavaScript (and the web) could do.

I always thought the name was just a little wink and a nod towards Java and nothing more. So I was surprised to see this in the press release:

> complementary to and integrated with Java

Was this ever true around the time, and if so was it ever really used? I know that now we have a couple of JS implementations on the JVM, like Nashorn, that would represent some level of integration (you could call JVM methods from JS) but the idea that Javascript was "integrated with" Java back in 1995 sounds a little far-fetched.

The whole point was to let websites interact with java applets on the site. If that’s not integration then what is? Either you’re splitting hairs or you’re forgetting that applets were touted as Java’s killer application at the time.

Well I was 9 years old in 1995, didn't get the internet until 1999, and only started programming in 2001 (and even then it was Perl + C) so that was an honest question from someone who didn't experience any of this first-hand.

If one of its original use-cases was to facilitate some kind of browser/applet integration then fair enough. But in the linked article there are only vague references to this that sound a bit weird or confused, like "the scripts would glue together an assortment of Java applets" or like "JavaScript will allow us to easily create personalized applets for the Excite service".

I found some docs @ Oracle from ~2013 that demonstrate calling some applet methods, but I can't tell if that is a later addition or was present from the start: https://docs.oracle.com/javase/tutorial/deployment/applet/in...

edit: looks like Bill Joy himself said "JavaScript will be the most effective method to connect HTML-based content to Java applets" in the article, but I'm still curious how deep this connection is, or if it's just hand-wavy "our new tech is great and I have to tie it to another currently-popular tech somehow"

Fwiw if you really are asking an honest question, consider not calling things a little far-fetched, esp if said things were true.

Anyway, I’m your age so I’m not 100% sure either but my understanding is that applets, for quite a while, were considered the software delivery platform of the future. Just open a webpage and get an entire end-user program running right there, no downloading or installing, nothing. It turned Netscape into something of a universal app store and people were very excited. JavaScript very much was intended to let the rest of the web page interface with the software program (the applet) running on it.

Your excite quote shows a key use case: ship a generic compile applet in a site which contains user-specific data, write a little JavaScript to send the data to the applet and poof, it’s personalized! Magic.

That success never happened though (and I’m not sure why), and most uses of applets I saw were of slow, ugly navigation menus with hover effects and stuff like that.

This isn't debate club or a courtroom, there aren't rules on how we can share how something sounds to us in an informal setting like this. If you want a nice discussion consider being a bit more polite, less confrontational and assuming good faith.

The intention was that Java components could be combined and scripted through JavaScript. Such a component-based development model had proven succesful in Visual Basic, and Netscape hoped to create something similar for client-side web development.

I think where I was confused is that the applets were already programmable and interactive, so I'm just not sure what throwing JS into the mix brings. But it could be that there's some functionality it gained (XHR, perhaps?) in the intervening period that it lacked at the time.

The thinking was that JavaScript was a scripting language and therefore much simpler to use than Java. So web designers who were not professional programmers could combine a few predesigned Java applets and script them using JavaScript.

Of course these days with package managers and build systems and TypeScript, JavaScript is a lot more complex than Java ever was.

Yes, applets were already interactive and programmable.

But they sort of ran "in a box", like Flash. So you have this particular rectangle in the page, inside of it something runs and works and does its thing... but outside of it, the rest of the page knows nothing of that.

What JavaScript was supposed to bring into the mix was that you might have a Java applet doing some "heavy-lift" stuff and then, you'd use the results of that to operate on other elements in the page. Like maybe you'd update a form, or some data in the HTML, or whatever. Also, obviously, the other way around. You might have some HTML controls that would then feed user data into the applet.

Yes, you could do everything inside the applet, but this offered an additional option.

Integrated in the sense that JavaScript and Java-applets on the same page could communicate through an API.

It was certainly used, since I remember using it out of curiosity. I don’t think the use was widespread since it only worked in Netscape.

Netscape was pretty widespread for a while there.

> For example at first hardly anyone understood Closures

At first, closures weren't even available. I mean, in 1.0 and 1.1 you could only declare global functions. 1.2 introduced function expressions and closures. That was June 1997; the language was still changing quite a bit and it wouldn't be until ECMA standardization that things would become stable and clear enough for people to use. (Even though there would still be huge differences across browsers for years)

Arguably the real game-changer was GMail, which pre-dates GMaps. It introduced a lot of people to XHR, which was previously used only by people keen on XML/XSL.

The innovation of Gmail was “so much storage you never have to delete emails again”. The UI wasn’t too different from contemporary incumbents such as Hotmail.

It had that as well, and undoubtedly it was the main attraction, but iirc it was already not refreshing the whole page when clicking on the email index to read a single email - if not at launch, very shortly after. They later added "html mode" for compatibility with older browsers.

Storage was definitely the killer feature, but I remember thread view, good search and AJAX navigation to be significant improvements over eg hotmail at the time

It wasn't Gmail that started XHR though. Gmail wasn't even first online email service to use XHR. The first app to use XHR, which is also the first email service to use XHR was Outlook Web Access.

It's funny that Microsoft were the who were innovating with better features and a more coherent vision during the late browser wars, but they failed to capitalize on this innovation once they won the war and they could now just release IE6 with a shiny Media Bar and then fail to update it for 5 years. Nothing would ever go wrong, and no competitor could threat Microsoft, since all these toolbars everybody seem to adore are only compatible with Internet Explorer anyway. Yeah...

It was the Web 2.0 era. Delicious, Flickr, Digg, Netvibes, YouOS - they all had AJAX interfaces that used innovative techniques in JavaScript.

JavaScript was not very powerful when it came out though. It couldn’t modify the DOM (except input controls) and it couldnt perform background requests.

> at first hardly anyone understood Closures, and the full power of JavaScript being a functional language

Especially that it wasn’t. JavaScript in Netscape 2 didn’t even have function expressions.

Maps was amazing but I remember being blown away by xmlHttpRequest and the dynamic search that autocompleted. It had hilariously little to do with XML.

> It had hilariously little to do with XML

Er, it had everything to do with XML. It was introduced to give pages the possibility to fetch XML (typically feeds) and render their content dynamically; which is basically what it ended up being used for, except XML feeds were then replaced by simpler files.

> except XML feeds were then replaced by simpler files

Yes. XML was basically superceded by JSON, which was far less verbose and clunky.

XML in XMLHttpRequest was first superseded by HTML and then by JSON. And JSON only because the JavaScript API for XML (aka. the DOM API) is the worst thing imaginable compared to the simplicity offered by JSON.parse and then the JS native representation of it as objects. The same ugly DOM API let to the advent and rule of jQuery.

The success of JSON has less to do with verbose/clunkiness but a lot with the available APIs in the JavaScript frontend.

> compared to the simplicity offered by JSON.parse

JSON.parse() came a lot later. People started with eval(), which lead to quite some problems (executing code returned from some third party service, what could go wrong ....) and then various other attempts at parsing.

XML is to XmlHttpRequest like Java is to JavaScript?

It is good to remember that that JavaScript is not the JavaScript of today even if the programming languge is the same (taking away the evolution).

For years JavaScript was only used for very small stuff like changing the color of a button in a mouse over.

The inflection point began lately with the inclusion of XMLHttpRequest [1] which enabled to have web apps instead of static pages with basic transaction forms. Then obviously another inflection point was NodeJS (and Google Chrome launch with the V8 engine).

My point is that the launch of JavaScript in 1985 is independent from it success later.

Beyond this, my personal opinion is that launching a VM specification would be better than announcing a specific programming language. WebAssembly comes very late to the game.

[1] https://en.wikipedia.org/wiki/XMLHttpRequest

Wouldn't it be more accurate to say that V8 itself is the second inflection point?

NodeJS (which is just the V8 engine plus a server-side runtime environment) seems to owe a lot of its success to Google creating an actual fast, JIT-compiling JavaScript implementation in the form of V8.

In fact, the entire Cambrian explosion of new Javascript frameworks in the 2010s probably would not have taken place without V8 enabling them to run with acceptable performance.

I said exactly that above.

The inflection point was later. Significant client-side logic in javascript was not a thing until gmail and google maps showed the way in 2004/2005. Even then it wasn’t until jquery in 2006 that the ball really started rolling. The browser could do it in 2001, but it took half a decade for web development to catch up.

What can today’s browsers do that web development hasn’t caught up to?

> What can today’s browsers do that web development hasn’t caught up to?

With WebGPU, WASM, WebXR, WebBluetooth, WebUSB, WebTransport and more already/soon enabled, I'm fairly sure we're just scratching the surface currently on what use cases can be built with today web technologies.

Also, things outside browsers are changing enough that the use cases also expand. Bandwidth, latency, availability and more are also improving, enabling fancy stuff we couldn't dream about some years ago. The other day one of the HN submissions loaded a multi-GB file for client-side evaluation of a Stable Diffusion model, as just one example.

100%. Now those technologies offer an independent platform way of having a new kind of "OS".

I agree. GMail and Google Maps showed a complete different web but XMLHttpRequest was needed for that and was a milestone even if there was no web app to show at that time.

We should also take into account that Flash [1] was the technology that ate the limitations of the web. Flash was really powerful. More in a moment with low bandwidths around the world. For example this late 90 animation would be impossible to stream [2].

[1] https://en.wikipedia.org/wiki/Adobe_Flash

[2] http://swain.webframe.org/zeek.html (SWF files) available for streaming in YouTube: https://www.youtube.com/results?search_query=zeek+locomotion

> even if there was no web app to show at that time

Wasn't OWA ("Outlook Web Access") the web app that XMLHttpRequest was made for?

ActiveXObject("Msxml2.XMLHTTP") was important but it was introduced with IE 5 in 2001 and it was a few years before it was available everywhere. DHTML (D for Dynamic) started in 1997 or so with IE 4. XmLHtTpReQuEsT wasn't entirely novel -- people were using iframe tricks to make server requests. iframe hackery continued for a few years afterwards since xmlHTTPrequest support was still iffy.

> Company Contacts:

Imagine if companies provided contact information on software releases today. You know, where you could call and a human being would pick up. Maybe you could even get some customer support!

I doubt you would get customer support from a press contact. Companies still provide phone numbers in these kinds of statements and just like then they don’t deliver support.

Au contraire. Post on twitter and, if you've got enough social capital, you'll get fast-tracked.

There is a special place in hell for the people on social media with followers who use that leverage to shame companies into priority customer support.

"@TimeWarner! My connection is down! Help me NOW!"

Get in line, you privileged twit.

1995: javascript is deeply integrated with java

2023: java is to javascript like car is to carpet

Funny enough they've more gone from being integrated with each other to being in some sense parallels of each other, if you're willing to stretch the definitions a little bit, as one of several languages executing on top of a VM (V8 and friends and the JVM).

very true

"JavaScript is an easy-to-use object scripting language designed for creating live online applications that link together objects and resources on both clients and servers."

Interesting to note the mention of servers!

I actually forsee a wave of JavaScript innovation within the concept of a traditional backend server coming soon, and it's interesting to see them mention a server here.

I've forever been from the school of "Rule number 404: thou shall never use JavaScript on the server side.".

But with React 18 and the serverless wave, I can totally see myself writing backend controller code in TypeScript that gets deployed by Vercel in the near future.

We migrated our api server from flask Python to node-express-typescript. The gains of async, stricter typing and being able to share api schema types with frontend were totally worth it.

We got a nice boost on performance as well.

Love js for api server.

then 1 year later MS brought IE 3.0 with "JScript" to "embrace, extend and extinguish" JavaScript

https://news.microsoft.com/1996/05/29/microsoft-internet-exp...

it was a real pita debugging JScript compatibility issues before the days of jQuery.

i guess we did get XMLHttpRequest later in IE 5.0. strange how things turned out.

That and the DOM. We dump on it today, but compared to Netscape's <layer> tags, it was mana from Heaven.

IE 4's early stabs at CSS were also already superior to the existing:

    <font face="arial" color="red" size="8">

The web back then was wild in all senses of the term.

I don't know, that looks a lot like Tailwind to me.

So you're saying we've regressed then? ;-)

Imagine if time travel was possible and we could go back in time and avoid this :-)

If Netscape hadn’t introduced and managed to establish their scripting language before Microsoft steamrolled them, then the standard language on the web would be Microsoft’s contemporary alternative which was VBScript — in other words, BASIC.

Be careful what you ask for.

Yeah, people here seem to forget that Javascript had actual competition in the browser space back in the day. It was very likely the winning browser-side language would have been a proprietary one, which isn't the world I want to live in.

While I very much wouldn't want to live in this world too, I'm pretty sure VBScript was an answer to JavaScript. Internet Explorer 3.0 implemented both VBScript and JScript (Microsoft's slightly incompatible version of JavaScript) at the same time.

Microsoft of the 1990s seemed to never be able to decide whether they want to follow "Embrace, Extend and Extinguish" or NIH, so they usually both implemented slightly-incompatible versions of popular technologies, and then shoved in their own in-house technologies alongside.

That's how you got both ActiveX Controls and Java Applets (both sucked). That's how you got both Visual J++ and Visual Basic (J++ was superior), and later both J# and C# (this time C# was superior, but could you expect anything less from Anders Hejlsberg?). That's how you got both VBScript and JScript running on JScript (a little know fact that made it possible for me to script Windows 2000 machines without running through a decade's supply of vomit bags).

If there was no JavaScript, I think Microsoft would have gone with something like ActiveX, instead of rushing to deliver their own a quick and dirty implementation of a scripting language. But we wouldn't get an almost-decent scripting language embedded in every windows machine, and I would have had to automate all these machines using BATCH files!

Imagine how much complexity, churn, standards etc. we could have avoided if they put a Scheme in Netscape (like they initially wanted).

- language features like module loading, async, classes arrow functions etc. would be unnecessary or trivially implementable within the language

- libraries like React et al would be much simpler

- plenty of FP libraries would be either unnecessary or much simpler

- things like "hot reloading" during dev time would be much simpler and actually work out of the box

- simpler parsing and more cross pollination in terms of runtime performance

- type annotations could be implemented trivially in user space, the runtime could evolve into respecting them for performance gains

- tooling complexity would be much reduced because of all of the above

Nah, if I were to go back in time I'd just push them to clean it up a bit before launch.

In the end, JS has been a net good for the industry. I don't work in it, but it's turned into something decent over the years though the frameworks around it are insane. But it took 15 years to get to this place and become a "grown up" tool, imho partially because of some odd choices early on.

Scoping: Especially initially, the scoping rules were really wonky.

OO: I am actually a fan of prototype inheritance (Self & LambdaMOO FTW) but the form implemented in JS was confusing for most people and they never understood it, esp given Java was ascendant at the time with its very strict and boring class-based model. I think some clarity was needed here. Lack of standardization around how to do objects, inheritance, encapsulation led to a total bizarre mixture of approaches and misunderstandings.

Essentially I just think having it passed over by some more sober minded language designer types who had research background in e.g. Scheme, Lisp, Self, etc. would have been good.

Going all in on JS instead of wasting time with the ill-fated Java applet stuff would have been good for the industry. It's what the industry ended up doing eventually anyways, but it took until the 2000s before this really clicked for people and they finally gave up on the various half-baked dynamic plugin solutions (Flash, ActiveX, Java applets, etc).

The "Java" in the name was/is a problem and led to a decade of stupidity. I understand how it happened, but it shouldn't of.

> Lack of standardization around how to do objects, inheritance, encapsulation led to a total bizarre mixture of approaches and misunderstandings.

That void never really existed. There was the right way to do it, basically the same way that ES6's class syntax actually works today, and then there were a bunch of people fooling themselves into believing that the impedance mismatch that resulted from writing code against their own derpy metaprogramming system they'd devised themselves was acceptable. The attitudes associated with that mindset never really went away—it's what drives the demand for stuff like Webpack, along with NodeJS's CommonJS-inspired approach to modularization infecting everything and the README for create-react-app providing list of steps to get someone up and running requiring them to download half a gigabyte of packages to their disk before they can successfully complete the Hello, World exercise, not to mention the abstraction (and resulting boondoggle) that is React itself.

If I put myself back there in the mid 90s, I actually don't think Netscape paid it (OO semantics & standards) much heed because the purpose of the language at the time really was just to add some minor scripting behaviour / actions to pages, not to build out applications.

Actual "serious" uses of JS didn't really ramp up until the end of the decade, and by then people were doing what you're saying, yes.

Netscape releasing a style guide with the language, and a set of standard libraries that used them, that would have helped.

But everyone back then was too distracted with "Java is the Future of the Browser" (Narrator: It Wasn't)

Death of SWE: 1995.

Nobody could've known how bad things would become after Js was inflicted on the world... right?

This could have been a great plot for the Terminator movies lol.

Sun had Self that was already incredibly fast. Instead of suffering threw 10+ years of terrible performance, we could have had a fast language back then.

... and we could all be writing Java applets today.

No, no, Java is old and slow. Let's compile typescript to javascript, write the user interface in React and HTML (with some parts hidden in CSS files with some selector and expression magic to make it more fun), and WebAssembly for the performance critical stuff. Easy-peasy.

You forgot the small configuration file required with Webpack 4 just to bundle your stuff. It's a close call to being a bit smaller than the bible.

Why would you not want to make your application's build process dependent on a dozen plugins that will no longer be compatible with each other in the next version? Are you even a real programmer? /s

Everybody kills JavaScript on their first trip.

I know it's the fashion on HN to hate Javascript but it opened the gateway for programming to generations of people and made the web substantially more fun and useful in many ways. It's not Javascript's fault the language was ruined by SV and survellance capitalism.

I think that the way we build user interfaces today on the Web is fundamentally flawed. One need to learn JavaScript/TypeScript, then HTML and DOM, then CSS. Then most likely you need to learn Angular or React or Vue or whatever, some widget toolkit like Bootstrap, get accustomed with Webpack, minification, uglification, rely on countless MIT-licensed libraries whose authors may come and go because the base runtime (=the browser) just gives you DOM, CSS and plain JavaScript.

Did you ever tried implementing a desktop UI using an object-oriented multi-platform toolkit like SWT or QT or GTK? There are good chances that all the dependencies you will need are already "there", you learn the widget toolkit bindings for your preferred programming language and you can start. It's so much more productive and fun (at least for me) and most of the time you don't need to mess up with colors, styles etc. etc. because you will want the operating system to take care of that.

On the Web you have so much more freedom, because the web page is almost a canvas, but at the same time (for me at least) it looks way less productive and everytime I think of it, I always wonder why nobody is proposing anything better for the Web and the industry keeps on building layers of complexity on top of JavaScript/DOM/CSS.

> Then most likely you need to learn Angular or React or [...]

For a very loose definition of "need".

> Did you ever tried implementing a desktop UI using an object-oriented multi-platform toolkit like SWT or QT or GTK?

There's an abundance of desktop application code written in JS from the GTK+ folks themselves. They embraced SpiderMonkey (the Mozilla JS engine) years ago and have been shipping stuff on it for just as long. Anyone who has booted into the default desktop on Ubuntu—or any other installation running Gnome—has already come in contact with it, perhaps even today. That doesn't get a lot of attention, though, because it's not "squeaky": it isn't plagued by the same problems that people (stupidly) associate with "JavaScript" despite the fact that what they're really thinking of are problems with the NodeJS/NPM community in particular and its spectacular tooling + other webdev-oriented accomplishments. I.e., all the things it insists are requirements for the Modern Programmer—a mission which their detractors assist them on by perpetuating the story themselves (cf "need")...

I am not familiar with JS in GTK+, but if it's a JS binding for GTK+ it's exactly what I meant when I said that on the desktop you can implement a user interface using your preferred language as long as bindings exist for a decent widget toolkit.

And it sounds totally legit to me. If instead what you are referring to is something similar to Electron, that is something I "hate"; I understand it's a cheap way for a Web Developer to reuse the skills and build a desktop application, but the result is typically buggy, bloated, slow, and does not integrate properly with the desktop environment (fonts, colors, clipboard, accessibility are just the first things that come mind).

I'm responding to your thread—the one where in response to your suggestion that it would be a good thing if it were possible to prevent "this" (presumably the introduction of JS in 1995, the topic of the submission), the person replying to you wrote, "I know it's the fashion on HN to hate Javascript[...] It's not Javascript's fault the language was ruined by SV and survellance capitalism."

The things you're complaining about are not a JavaScript problem. They're a programmers-who-have-their-feet-firmly-planted-in-the-world-of-NPM-and-modern-webdev-tooling problem.

> something similar to Electron[...] is something I "hate"

Wait till you find out how Firefox itself (i.e. the UI and other application logic) is implemented: "DOM, CSS and plain JavaScript". Mozilla was doing Electron-style apps before Electron ever existed. Somehow it's a higher quality app than the sorts of things you had in mind when you brought up Electron. Again: that's because it's not a JavaScript problem.

Sure, I am not against JavaScript per se (although my preference goes to strongly typed languages), my first comment had a smiley at the end, I just firmly believe that the way we build UI for the Web today is flawed.

This reminds me. Co-Recursive episode: JSON vs XML With Douglas Crockford

https://corecursive.com/json-vs-xml-douglas-crockford/

Some really wild stuff about the genesis of JavaScript. I've never heard about HyperCard until now.

Some really wild stuff about the genesis of JavaScript. I've never heard about HyperCard until now.

Great example of why it's so important to understand computer "innovations" with as much historical context as possible, so as not to fall into the pop-culture mindset, which completely ignores that which went before, and thus is extremely unlikely to create something new without that understanding.

I started with the Internet in the late 90s, so you could say I've been here most of the way, and I am still always fascinated by the stories and movies about the early days.

Not only does it stir up the memories of the craziness, but it reminds me that most of the things we do today are not that ground-breaking. The young generation of engineers is just relearning the lessons we did - with faster CPUs and bigger screens.

P.S.: I could not stop watching Valley of the Boom: https://en.wikipedia.org/wiki/Valley_of_the_Boom