[overkill28]

I still don't know why they stuck the "Java" name on JavaScript. Very confusing when the two languages are completely unrelated.

> 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, so the range of live online applications that dynamically present information to and interact with users over enterprise networks or the Internet is virtually unlimited.

Was this level of integration ever achieved? Did Java applets actually have a JS API? Or is this just corporate double speak.

[astura]

Brendan Eich addresses that topic in this interview. The whole interview is (very much!) worth a read but here's some key parts about the name

https://www.infoworld.com/article/2653798/javascript-creator...

>It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language.

>[The idea of an accessable scripting language] was very strongly held by Marc Andreessen and myself. Bill Joy at Sun was the champion of it, which was very helpful because that’s how we got the name. And we were pushing it as a little brother to Java, as a complementary language like Visual Basic was to C++ in Microsoft’s language families at the time.

[blakesterz]

Interesting!

"JavaScript would have been the ideal name because that’s what everyone called it and that’s what the books call it. Microsoft couldn’t get a license from Sun so they called their implementation JScript. So ECMA wanted to call it something and they couldn’t get anybody to donate or they couldn’t get everybody to agree to a donation of the trademark, so they ended up inventing ECMAScript, which sounds a little like a skin disease. Nobody really wants it. "

[calibas]

I think if you combined the two "different" answers to why it's named JavaScript, you get the truth. Yes, it was promoted as a companion scripting language for Java, but that was in part because Java was so hot at the moment, so marketing had something to do with the decision to name it JavaScript.

[JxLS-cpgbe0]

Why "script" though? Aren't Java and JavaScript both script(ing languages)?

Why not call it e-Java or Java XYZ or something?

[mlyle]

How could one consider Java a scripting language? It's compiled to .class files, has no reasonable interactivity, strict structure enforced upon the code, etc. E.g. the antithesis of what makes us call something a scripting language in basically every category.

[JxLS-cpgbe0]

So JavaScript meant "complement to Java, but converted to machine language in the browser, instead of compiled?"

(Thank you, genuine question)

[mlyle]

JavaScript is "logically" run line by line from the beginning of the script. This may not be exactly true anymore for performance reasons, but it's the logical model behind it. A single set of expressions to run in order "a=1+1;" is a conformant JavaScript script; hence, it's a scripting language. It doesn't take much imagination about how to have a JavaScript console that operates interactively from user input.

Java code has lots of structure required to write a minimal program. Java is transformed by compilation into a set of .class files. Then, in turn, a loader loads, resolves all the classes, and begins transforming and executing code.

These distinctions can be muddy sometimes.

[pan69]

> So JavaScript meant "complement to Java

The whole JavaScript thing was just marketing. In 1995, Java was THE hottest thing so associating it with Java might fuel adoption/acception.

There is an old saying; Java is to JavaScript what Car is to to Carpet.

Re. your compiled question. It's up to the browser on how to execute JavaScript. E.g. Chrome has the V8 engine. This is the VM that compiles and executes JavaScript within Chrome. Other browsers might have different engines.

https://en.wikipedia.org/wiki/V8_(JavaScript_engine)

[gpvos]

More like interpreted rather than compiled. (I'm pretty sure a google search on "interpreted versus compiled" will get you up to speed with the basics on this point.) This is generally seen as one of the main differences between "scripting" and "serious" languages.

The twist is that the JVM (Java Virtual Machine) is also a kind of interpreter, but can do on-the-spot ("just-in-time") compilation of parts of the code as well.

[hi41]

Sorry I am not an expert in Java, but doesn’t the jvm execute the .class files like bash would execute the .sh scripts.

[layer8]

Class files contain compiled bytecode, not source code like shell scripts do. “Script” implies human-readable source code. Java bytecode is binary, a kind of portable machine language.

[nostoc]

A scripting language is generally thought as a language suitable for quick easy project, less so for large scale software engineering. Verbosity of syntax, compilation, presence of boilerplate code, static typing are all things that make java unattractive as a scripting language.

Java is great at what it does, which is not scripting.

[calibas]

This is all semantics, but the idea was that Java is a "real" language for serious use and JavaScript is a "script" that's much easier to use and doesn't involve all the complications of a "real" programming language.

It was only kind of true back then, and not even remotely true now. There really isn't a solid line you can draw between a "script" and a "programming language". To me, something like Python is right in between.

[sdenton4]

I feel like "requires compilation" is a good first order differentiator. And "has a somewhat sane type system" is another.

[triceratops]

TypeScript requires compilation and has a rich type system. It also has "script" in the name.

I think "scripting" vs "programming" language differentiation is elitist nonsense. This isn't a meaningful boundary. It's more useful to speak of languages in terms of strong/duck/loose typing, syntax, supported programming paradigms, ecosystems, available libraries and tooling, and intended use cases.

[cozzyd]

Well, C++ can be interpreted (sort of, see CINT) and can certainly be semi-transparently jitted (see cling). Although it's certainly not designed for that!

[kevin_thibedeau]

tcc is fast enough to run C code (or langs targeting C) as scripts.

[vlunkr]

> There really isn't a solid line you can draw between a "script" and a "programming language"

I think it's easier to draw the line if you have the requirements right. That's not the line that was being drawn. it was scripting vs compiled languages. It was very clear then which sides Java and Javascript fell on. There are some weird cases now like compiling scripts into different scripts, but in general it's pretty clear, and Python is definitely a scripting language.

[calibas]

The great "script vs programming language debate". The difference is clear to you because you have a clear definition in your mind. The problem is that the definition changes depending on who you talk to, which invites endless debate.

[mlyle]

To me, if something acts logically like it is run from top to bottom, it's a scripting language. Python scripts and JavaScript are in this category; Java isn't.

Additionally, explicit compilation/linking/assembly shouldn't be required for a scripting language, even if the interpreter does stuff kind of like this behind the scenes for performance.

[zepto]

That makes Ocaml and Haskel into scripting languages.

[Scarblac]

I've never seen Java called a scripting language before, actually.

[derefr]

So, basically, JavaScript was originally annointed to serve the function within the JVM ecosystem, that ended up being served by Groovy?

Why didn’t that happen? And why did it take so long before we got Groovy instead, if Sun wanted was imagining something like it way back in 1995?

[ojosilva]

No. JavaScript was a web language for web developers to be able to automate forms, etc, client-side. AFAIK, originally it was never intended to run on the JVM server-side like Groovy does.

Netscape did try to position server-side JavaScript as part of its Enterprise Server package though, but it was not JVM-based. But the environment was proprietary and not compelling enough for a myriad of reasons. It ran server JavaScript in CGI mode.

JavaScript took a long time to actually make it server-side. First with standalone interpreters (ie. Spidermonkey) and later with a full-fledged runtime and development environment (NodeJS).

[derefr]

> No. JavaScript was a web language for web developers to be able to automate forms, etc, client-side. AFAIK, originally it was never intended to run on the JVM server-side like Groovy does.

Sure, but that's not an argument against JavaScript having potentially been a planned part of the JVM ecosystem (or, at least, a language playing a role in the JVM ecosystem, without itself being hosted on the JVM, instead maybe interacting with the JVM through some kind of IPC or FFI bridge.)

Remember, Sun used to be trying to squeeze the JVM into web browsers as well, in the form of Java applets. But we never saw any real ability to script against these applets. "Java applet 'engines' under JavaScript control", could have been the portable equivalent to "ActiveX components under JavaScript control."

You know how modern games involve 1. a self-contained game engine written in C++ or C#, plus 2. the game itself being mostly Lua scripting? If Sun had pushed harder, we could have seen something like that in 1995, with web browsers running JavaScript-scripted games calling into Java game engines; long before we got equivalent HTML5 APIs like Canvas.

Probably, if the world had gone down that path, we would have seen JavaScript gradually moving "into" the JVM; and the JVM gradually coming to take the position that the JavaScript engine takes in modern web browsers.

[ojosilva]

The JVM wasn't a thing you "targeted" until much later. In 1996 there was java and javac. People were ecstatic running the same programs written in Java on every architecture (SPARC, PowerPC, Itanium, 8086...), and even as a client or as a web applet. The "portability" wars of 80s and early 90s were over (that's where C and C++ were born into). Nobody really talked about JVM, because there was basically 1 Java vm, no HotSpot or OpenJDK and no real bytecode documentation. JS was not planned for the JVM. So much that there wasn't even a half decent JS to JVM compiler implementation until recently. JS was a joke until ES3, and a very subpar environment until v8 got fast, Node got serious and TC39 got their shit together after the ES4 clusterfuck.

If the Java@Netscape story came about earlier than 1995 then maybe yes, the JVM could have made into the browser as THE scripting environment for an eventual JavaScript language, because Java the language was not suited for webpage designers to throw something together un a highly evente environment. The browser was the place to be and Java just didn't make it there (they fought hard though with their applet crap).

[zepto]

You actually could script against applets, it was just incredibly clunky and slow, and so not worth it.

[ebruchez]

I did exactly this as part of a school project back in 1996! The applet was doing the computations, and the JavaScript, with this thing called "LiveConnect", was calling into the applet and back :)

[fiddlerwoaroof]

I think part of the original goal was for apps to be written as Java applets and JavaScript use to bridge between HTML and the applets.

[alisonkisk]

Sun had some great people and some good ideas and products, but as a coherent business it was a rolling train wreck.

[Mountain_Skies]

Sun had an unhealthy Microsoft obsession. When I was a senior in college, Microsoft came to campus and gave a two hour presentation on why we should work at Microsoft. About a month later Sun came to campus and gave a two hour presentation on why we should not work at Microsoft. Sun workstations were very common in our engineering program so we were ripe for the picking but Sun never explained to us what was so great about working for them. Well, except for one absolutely ridiculous video clip of Scott McNealy standing on the roof of Sun HQ, playing the electric guitar. Eyes were rolling out of everyone's heads upon seeing that.

Looking back at interviews and industry articles from that era, there is a common theme of Sun hating Microsoft. Lots of companies and people hated Microsoft but Sun seemed to make it their central ideology. As a result, they took their eye off of making great technology that customers could use to solve their problems. It's a pity because they were so far ahead of the game at that point that they could have developed into something wonderful instead of being absorbed by Oracle, with little trace left besides Java sleepwalking through the modern era.

[munificent]

> Sun had an unhealthy Microsoft obsession.

I think basically everyone did back then. There was a pervasive understanding that if you were small enough, Microsoft would use underhanded business practices to crush you if you became a threat. If you made a compelling product, Microsoft would clone it and use their might to make it win.

It felt like taking a pottery class with a grizzly bear in the room. Really hard to be like, "I should just make the prettiest bowl I can" when you know at a moment's notice your head might be swiped off.

[alasdair_]

>Sun had some great people and some good ideas and products, but as a coherent business it was a rolling train wreck.

I had an internship at Sun in 2002. I distinctly remember a town-hall meeting hosted by Johnathan Schwartz (CTO at the time, later to be CEO) where an engineer asked something to the effect of "this all sounds great, but how does this actually make us money?" The engineer was told in no uncertain terms that he shouldn't ask such questions, that he should focus on engineering and that he should trust that other people would handle the money side.

[hutzlibu]

Which why they sadly ended up digested by Oracle.

[pjmlp]

Only after Google sent a couple of torpedoes and then went as if it wasn't their business.

[hutzlibu]

What torpedoes do you mean?

[smt1]

It's too bad JVM happened. Solaris was innovative before Java, which became monetized primarily by the fees. They released Self, SmallTalk, and Squeak before that. I think the latter is still very innovative today, because of it's Morphic interface (it's category theoretic). I think you could teach kids the computational equivalent of pretty high level mathematical physics, which is pretty interesting relative to other standard CS101 intros (like python, etc). TeleScript, which was basically inverse JVM was also made around this time, it would have been interesting if the Newton hadn't been discontinued:

https://en.wikipedia.org/wiki/Telescript_(programming_langua...

These days, ironically, Telescript is a model for how distributed computation works in the 3rd world, and even in the first world. But Telescript basically would have made the lattice structures more hybridizable to project information and jobs within the context of already existent social networks and maybe provided a better nexus for useful work done vs power given up (it was made on a very astute observation about the energy, work, power, time, information, transmission nexus) before anyone named a "peer to peer network", a distributed consensus protocol, or introduced money into the picture.

[acdha]

Marketing. Java was The Next Big thing and they wanted to jump on board that bandwagon. The direct integration wasn’t very common but a lot of the JavaScript objects had similar names (toString, etc.) and JS was commonly explained as a sort of junior relationship.

Edit: expanding my not very common claim — I first started using JavaScript when it was called LiveScript in Netscape betas, the second non-static website I built was Java (using DB/2 on OS/2 — I sure could pick winners!), and I worked at a web development company until 2001. During that time, you'd commonly hear about Java (along with Perl, PHP, Cold Fusion, and even C++) and we used JavaScript heavily but I never once met a client who was actually using server-side JavaScript although they certainly existed.

[ChrisRR]

It's very odd, if someone nowadays called their language CSharpScript, they'd get slapped with a C&D

[astura]

Netscape had permission from Sun to use the "Java" name, it was a partnership.

This press release itself even says it in the first sentence

>Netscape Communications Corporation (NASDAQ: NSCP) and Sun Microsystems, Inc. (NASDAQ:SUNW), today announced JavaScript

[flowerlad]

Remember, Sun needed Netscape to make Java successful. Today Java is a server-side technology, but that's not how it started its life. Java started its life as a technology to build more powerful web pages (using embedded applets). Sun needed Netscape to bundle Java into its browser. So if Netscape wanted to leverage the hype that existed around Java at that time then Sun had to let them.

[alasdair_]

>Java started its life as a technology to build more powerful web pages

I'm pretty sure Java came from the work James Gosling did on Oak, which was mostly used for embedded systems. I remember a lot of the early documentation being OO designs for devices like microwaves and CD players.

[flowerlad]

> I'm pretty sure Java came from the work James Gosling did on Oak, which was mostly used for embedded systems.

Yes, when it was conceived it was indeed intended for embedded systems but when it was released it was intended as a tech for building client-side smarts into web pages.

Java was originally conceived as Sun's response to General Magic's intelligent agent technology. Microsoft's response to General Magic was Microsoft Bob, because they saw General Magic's social interface as a threat to Windows.

[pjmlp]

They also needed Oracle and IBM, their two major partners in the early Java days.

[acdha]

This was voluntary. You have to remember that at the time the residing hype kings were the so-called 4GLs (e.g. Clarion, Clipper, PowerBuilder) and things like Visual Basic, Pascal (Delphi), etc. so Sun and Netscape were trying to present this as the pair of languages which you used to build the web, which was already emerging as the white-hot new thing starting to transform the world.

[ajuc]

Such a shame Clipper and Delphi didn't worked out.

In early 90s my uncle (now 60 years old electrical engineer) taught himself clipper from 0 (no programming background whatsoever, and no English language) and wrote a software for capturing and analysing temperature curves of polymer ovens at a factory where he works that is still used to this day. They keep a DOS PC just to run it :)

I don't think it's possible to do this with modern programming technology, there's too many layers of abstraction and unrelated asides blocking people from "just making it work".

[pjmlp]

Delphi is still around, and there is a striving community in Germany, big enough to keep conferences and magazines going.

But yeah, Borland really messed up.

[725686]

My older brother still maintains clipper code that is used in production.

[hajile]

Everything was fine because Sun owned the Javascript trademark.

Oracle now owns that trademark today

https://tsdr.uspto.gov/#caseNumber=75026640&caseType=SERIAL_...

For what it's worth, Microsoft lost a lawsuit over their Java clone called J. Their Javascript clone was called JScript.

They made .net and C# instead and probably would have tried to make a new web language except that there was no room. One could argue that that VB.net was that language to some degree.

[ojosilva]

In fact Microsoft had their own browser scripting language, called VBScript. It was released in 1996 and only ran (runs) on Internet Explorer browsers (client-side) and Windows as an interpreter (Wscript.exe).

I ended-up using it extensively for a period of time from 1998 to 2002 to automate webpages that only ran in the intranet. I also used Wscript to run certain OLE or ODBC based automation (ie. grab data from Excel and write to a file) that was clunky to write in Perl.

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

[DonHopkins]

Now look at what's become of Sun's trademarked logo:

Zuckerberg’s not-so-subtle message to Facebook employees: Don’t end up like Sun Microsystems

Facebook CEO Mark Zuckerberg has put a pretty hefty reminder for Facebook employees to keep striving for relevancy right outside the front door. An aging Sun Microsystems sign, on the back side of the Facebook sign, is a well-placed message to them.

https://www.geekwire.com/2014/zuckerbergs-not-subtle-message...

[codetrotter]

Sun was literally in on it though?

So it'd be like if whoever was announcing this hypothetical C#Script was doing so together with Microsoft..

[bluedino]

Nobody outside of developers knows what C# is, though.

Java was one of the biggest buzzwords of the late 90's.

[identity0]

That's true, it's more like naming your language "BlockchainScript". I could totally see someone doing that today.

[JackFr]

"Scrypto"

[cozzyd]

I just checked and bitcoinscript.org seems to be owned by a domain parker.

[Arnavion]

Bitcoin already has a script (it's what transactions are made of) so that's not unexpected.

[m_st]

According to the interview with Eich linked above: "Bill Joy at Sun was the champion of it, which was very helpful because that’s how we got the name." Sure helps :-)

[jen20]

scripts [1] suggests this has not been the case!

[1]: https://github.com/scriptcs/scriptcs

[AndrewStephens]

Partly marketing but the integration certainly existed. As I recall, public methods in the main applet class are exposed to JavaScript. It was a little slow and clunky but it worked.

The idea was similar to how web components are used today. Your web page would contain custom applets for a fancy input field, a calendar control date picker, and whatever other controls html didn’t provide, all implemented as Applets.

It could have worked out and the web today would have looked very different except that Java applets always performed terribly on first load. Nobody wanted to have their customers wait 30 seconds for the custom controls to initialize.

I sometimes wonder what might have been if Sun had actually fixed the initialization of Applets. In many ways Applets were nicer to develop than today’s web components.

[ethbr0]

Technically, why are / were Java applets so slow? I never dug into the ecosystem deeply enough to understand (plus a bit before my time).

Was it JVM startup time, Java xfactory-begat-y-begat-z code init time, what?

Also, applets run outside the browser, correct? I.e. on the browser's host system in a separate JVM process?

[AndrewStephens]

Sun seemed to have a real mental block when it came to applets - people screamed at them for years about performance and they refused to do anything about it. Indeed, in 1995 the simpliest applet would take several seconds to appear. In 2005 (about the time everyone stopped caring), the same applet would take ... several seconds to appear. They never got faster even as CPUs improved by several hundred percent.

The Applets ran fast enough (even on 1995 machines) once loaded, at least fast enough to be useful. But that delay at startup when your CPU went to 100% and your hard drive buzzed away, freezing everything else you machine was doing, just killed any interest the public had in using applets.

Part of the problem is that they JIT'ed everything without caching it and that included the standard Java libraries. So every applet started to execute, called some standard API, the API was JIT'ed, that called some other part of the API which was JIT'ed, etc, etc. I could never understand why they didn't compile at least the standard libraries on install or first use and save the result.

[ethbr0]

From everything I've touched Sun was always very... Unix in regards to UX.

As in "Well, just learn to deal with it. And be grateful you have a graphical interface at all."

Making things better, or pushing the state of graphical presentation art never seemed to even be a core interest, much less competency.

Which is ironic, because a lot of that organizational choice seems reflected in Java, e.g. having to boil the ocean and re-implement everything for major arch changes.

[smm11]

Sun briefly toyed with OpenStep, or essentially the UI of the NeXT machines that morphed into today Apple's OS X interface.

Anything would have been better than CDE or OpenWindows at the time, and the NeXT GUI was quite innovative in the 90s.

[DonHopkins]

I always thought JIT should be spelled JATWPT, for Just At The Worst Possible Time (when the user's waiting for the app to start up).

[lenkite]

This was deliberate - they were afraid Java would become too popular on the browser side and people would stop buying their heavyweight servers. They always pushed Java as the server side language. If they wanted Java at the client side - they wanted pure Java clients (webstart, etc) not browsers hosting Java applets. Browsers hosting Java applets were sneered upon.

JS eventually won the game here after IE advanced Web 1.0 with great support for AJAX, etc.

The funny thing is that if Sun was on the ball and didn't abandon HotJava, your modern day browser would have been a Java app.

[anthk]

>your modern day browser would have been a Java app.

Not so distant to J2ME browsers like Opera Mini, and today with Android I am not sure. Chrome is C++, but on Android everything gets blurred.

[pram]

Yeah I dunno about that. HotJava was aggressively awful to use.

[AndrewStephens]

I agree. One of the many, many, many areas where Sun dropped the ball was the failure to implement a good HTML control in Java. HotJava was very basic.

[lolive]

I think they still have the problem today. Which makes any JVM language to be slow to run in elastic environments (where hardware instances and server runs quickly come and go depending on the load).

[bitwize]

The browser had an embedded JVM and applets ran right on the page. It was very similar to WebAssembly today, just a fair bit chuggier.

Two things caused people to backpedal from the applet strategy:

1) Because there was a large hiring pool of millions of fresh grads leaving college with a little Java under their belts, it having displaced C++ and Pascal as an introductory language, companies began Java projects and Java came to be seen as an enterprise language.

2) The JVM that Microsoft implemented inside IE had proprietary Microsoft extensions for greater Windows integration. Sun sued Microsoft over this, and won. After this, Sun pivoted to having Java be a browser plug-in in order to provide a consistent cross-browser experience, rather than having each browser vendor provide their own implementation. The browser plug-in was way clunkier even than the original embedded JVM was.

[Mountain_Skies]

The death of Microsoft's JVM is when I lost most of my interest in Java. I understand why Sun didn't want Microsoft's JVM to exist. They could see Embrace, Extend, Extinguish coming for them but wow, did Microsoft's version ever work better. I did go on to create a good bit of Java code professionally but never touched it for hobby work.

It really hurt Java in the browser when Microsoft refused to ship Sun's code with Windows. Not sure why Sun assumed that after suing Microsoft about the JVM, they'd be willing to distribute Sun's bits for them. They really seemed surprised and angry when this happened and were unprepared for it. Maybe pivoting to browser plug-ins was the only way forward they could see. Seems like the actual path forward would have been to make the Sun JVM better.

[ethbr0]

It was a weird time.

Now, there's a straightforward business case and examples of the many strategic and financial benefits of owning development and guidance of an open platform.

Then... you either owned a platform completely (closed) or didn't (someone else owned it). Vis: all the bs machinations around proprietary Unix distributions.

Sun + Microsoft was likely seen more in the context of "ceding ownership to Microsoft" than "growing the platform, that we still have majority ownership of."

Ultimately, hardware vs platforms thinking. Or my-share-of-zero-sum vs growing-the-market. Unfortunate.

[kalleboo]

My memory of the time (as a Mac user) was that the JVM startup time was the big killer. It took like 30-60 seconds, during which it completely froze the (cooperatively-multitasked) OS. Of course it ate up a big chunk of memory at a time when our Mac had 16-24 MB of RAM total. And Netscape 3 was unstable enough that in a decent browsing session you'd have to relaunch it 2-3 times (each time unloading the JVM). Lowering the available memory of course worsened the stability.

The applets themselves performed alright. They took a few seconds to initialize but we were used to waiting for JPEGs and hover effects to load over a 14.4 modem so that wasn't too bad relatively.

[other_herbert]

They didn’t have to be slow and you can communicate between the two with a parameter in the applet tag “ mayscript” with that methods in the applet could be called from JavaScript. I used that for an invisible applet that would handle communication and drawing HTML to the browser.. kind. Spa like way back in the Wild West days when applets could nearly do anything.

[hajile]

Java apps didn't integrate with regular HTML. They were more like Flash apps with all those downsides.

Even today JS is interpreted before compiling to bytecode because the startup latency is much lower (JIT only kicks in once the background parsing is complete). Back in those days, the extent of JS was a few click handlers or similar. The JS interpreter would be done long before the JVM was even loaded into memory.

[mikro2nd]

Oh, but they did. The DOM API was there from about 1.3 (iirc).

[dtech]

A combination of needing a heavyweight VM separately from the browser and being either interpreted or having to wait for a slow JIT.

Remember Javascript was slow as ass too until the late 2000's when browsers were implementing efficient JS engines. If web pages would've been build like common JPAs they would've been as bad as applets.

[commandlinefan]

> the integration certainly existed.

Definitely. Even the fourth edition of Javascript: The Definitive Guide (published in 2002) still had an entire chapter on Java/Javascript compatibility.

[reaperducer]

Very confusing when the two languages are completely unrelated.

I once had a boss who thought I could write Java Android apps because I knew Javascript from web development. "They're the same thing, right?"

Lifting a line from somewhere deep in the bowels of the internet, I told him that, "Java is to Javascript as ham is to hamster."

Got fired shortly after that. Company folded a couple of weeks later. Life moves on.

[Rompect]

I always use "Java is to Javascript as a car is to carpet" but yours is also good.

[bawolff]

Yes, there was an api. https://developer.mozilla.org/en-US/docs/Archive/Web/LiveCon...

That said, the nomenclature was pure marketng bs.

[bobince]

> Did Java applets actually have a JS API?

Sure. LiveConnect was commonly used as glue to invoke and interact with applets from JS.

I wouldn't necessarily say that it enabled a virtually unlimited blah blah enterprise parp, but it had its uses. A common hack was to put some shared storage in an applet so multiple documents could use it to persist and communicate cross-document data, back before browsers could do that natively.

There was some really tedious bug in IE with the Sun VM that occasionally allowed JS events to fire concurrently whilst LiveConnect was waiting for a response from a method called on an applet, which we never quite figured out. This was one of many things that made JS+applet development unreliable and unpleasant.

[ahlschwede]

Before Ajax one way to do Web 2.0 style interactions was to hide a Java applet in an invisible iFrame and feed data back and forth from the page using JavaScript.

I think people forget that the early web had a proliferation of plug-ins. JavaScript was most often used as glue between HTML and plug-ins which had fewer platform incompatibilities than the browsers. One of the reasons Flash became the dominant plug-in was because it was universal enough to duplicate the features of other plug-ins, including asynchronous communication via Java applet.

[moron4hire]

IFrames were invented later (and initially, only in IE). You also didn't ever need to put the applet in a separate frame. You could just put the applet on the page. Indeed, putting it in a frame would have defeated the purpose, because there was no way to communicate across frames at the time.

[nickbauman]

Yeah it was called Live Connect and it was pretty amazing. It's long since gone though.

https://developer.mozilla.org/en-US/docs/Archive/Web/LiveCon...

FWIW as a Clojure/Script developer this technology would have been kind of mind-bending if it still existed.

[Tade0]

> Did Java applets actually have a JS API?

It was possible to expose something:

https://www.codejava.net/java-se/applet/liveconnect-the-api-...

[Yaggo]

Not only the name, but also the C-like syntax was borrowed from Java because of marketing reasons, despite the semantics were inspired by quite different languages such as Scheme and Self. What a pity!

[robbrown451]

They aren't really unrelated as they explicitly made JavaScript syntax "look like Java" which in turn "looked like C and C++".

This also helped with their LiveConnect stuff which allowed the two to talk to each other. I think it was a huge selling point that the languages felt similar, and felt comfortable to those who already knew C and/or C++.

In those days I was doing a lot of pasting from one language to the other, and editing "int" into "var" etc. Java and JavaScript were similar in that, compared to C and C++, you just sort of forgot about pointers and pointer syntax. (even though they still sort of existed).

They sure seemed to me to be related. This is obviously most true for light use of the languages (JavaScript especially was designed for very light use)

[pqb]

> I still don't know why they stuck the "Java" name on JavaScript.

It is still funny to see a job offer with a mistaken Java and JavaScript posted in a title or in requirements section.

[spullara]

A few answers based on my recollections. JavaScript was a trade with Sun. Sun allowed them to name it that and Netscape integrated Applets into the browser.

As for the API, yes. You could control the DOM from Java without the big grey square of an applet through an API built into browers at the time:

https://web.mit.edu/java_v1.5.0_22/distrib/share/docs/guide/...

However, it was rarely used. The world might be a far different place if folks had used a higher performance (and at the time far more capable) language for manipulating the DOM early on rather than the focus on recreating the whole UI of the application on a canvas.

[makecheck]

There is a JavaScript interpreter built in to Java (or more than one, in that you could choose at least one older one at the time I tried it). I used this for a fairly complex app and found it surprisingly easy to let it parse JavaScript and affect the Java program, moving data back and forth.

[dragonwriter]

> There is a JavaScript interpreter built in to Java

Are you referring to Nashorn? If so, wouldn't "was" be the correct verb, not "is"?

https://en.wikipedia.org/wiki/Nashorn_(JavaScript_engine)

[forgotmypw17]

It's because you could integrate a Java applet with JavaScript in the page and have it all interoperate.

Pretty cool, too bad Java was so heavy...

[Azleur]

Marketing move. Same reason they shoehorned constructors into a prototype based language. Java was all the rage in '95.

[valw]

When you're in the business of sneaking in a Scheme-inspired language into the universal programming platform in a world of object-oriented dogma, you'd better add some camouflage ;)

And so the language was compromised in its name, and arguably in its syntax and (lack of) macro system.

[tbranyen]

Definitely, HTML has several tags to help work with external types. You can interface with java, vbscript, flash, pdf, etc. You could absolutely expose top level methods and invoke them in JS.

[hi41]

As a new developer in early 2000, I couldn’t tell the difference between Java and JavaScript. I felt very ashamed of that.

[everlost]

The biggest irony is that they believed Javascript "complemented" Java!

[stephenhuey]

As others in this discussion have pointed out, Sun intended this because they wanted people to see Java as the server side language so even though applets could run Java in the browser they never did much to improve performance because they expected people to rely on JavaScript in the browser (and buy their expensive servers to run Java).

[coliveira]

It was just a marketing ploy based on the cooperation between Netscape and Sun. Sun would provide interoperability between JS and Java in the browser. Netscape would get the public support of a major corporation at a strategic time in its fight against MS.

[Supermancho]

Some of the JS api (method names) matched the uniquely Java api.

[hathym]

That is why it was renamed to ECMAScript

[andi999]

Especially when you couldnt even google it (the other search engines never found anything related to my keywords...)