Maybe it should just be pronounced eck-ma-script so it's got the same number of syllables as ja-va-script.
In terms of standard, the specs already use "ECMAScript" and don't even mention JavaScript (https://github.com/tc39/ecma262/), although TC39 website does use it frequently. I guess they could officially recommend people stop using "JavaScript", but I doubt they care.
Otherwise, the petitioner Deno here is only a small part of the ecosystem and barely controls anything (and really nobody other than TC39 controls anything, which is good). They (or anyone else) can't just shout "stop saying JavaScript!" and expect people to follow.
Not to mention JavaScript is a simple, easy to pronounce word compared to ECMAScript despite the baggage, which is probably why they chose it in the first place.
Let's say the "JavaScript" name is officially deprecated somehow. People will continue to use the name for as long as it exists.
So Deno's petition tackles these problems, addresses the root cause and appears to be legally viable. That is the "right thing to do" here. Avoiding the name does not solve the problem. It never does.
Probably if we were in the early 2000s this could have been a battle worth fighting. But considering we're in 2025 and probably more people are aware of JavaScript than Java at this point, even when you're deep in enterprise-land, I'm not sure it'd be less confusing.
Anyways, you're about two decades too late to this discussion :/
Or go back to calling it “LiveScript”
We all know this.
> Oracle has no business claiming javascript as a trademark.
You think so. That's okay. But ultimately it is up to a judge to decide. Right?
I agree with the EcmaScript. Just ditch the stupid name. Get all the petition signers to agree an move on. Fuck Oracle. Fuck JavaScript (it's nothing like Java anyway).
Sounds appropriate to me.
I think we are getting a rude awakening about what is legal versus what is actually right are not always the same thing. There are some the horrible, horrible things here and the laws need updating, as opposed to us simply saying this is for a judge to decide and there is nothing else we can do.
I am ok with ditching the JavaScript name. I understand this cuts the problem entirely. However, there are other problems we have that we can't bypass so easily.
We need copyright terms to be much reduced. We need CFAA fully repealed and not replaced by anything. We need to abolish software patents. There is a lot we need to do that will likely take a century to accomplish and that's likely being too optimistic.
What we can't do is leave everything up to the judges because clearly even if we get a favorable ruling today, the precedent can be removed by another stroke of a pen.
"Now" makes it sound like this is a recent acquisition of the JavaScript trademark. Oracle obtained it in 2009 as a result of the Sun purchase and if I remember correctly, Sun initially was issued the trademark back in the 90s sometimes.
I'm not sure who "we" are here (Americans perhaps?), but humanity as a whole have known this for a long time, and acted accordingly. This is why presidents in some countries have the right to pardon people, as just one very evident example. That the USA exists as a country today is another example, which at the time when they were trying to create it, was clearly illegal, but since winners write history, still a "good" action.
The the laws aren't 100% unambiguous and strict is also another example, so there is room for interpretation, as something can be "by the book legal" but because of the clear evil motivations and "ignoring the spirit of the law", still be illegal. Of course, highly dependent on the country and lots of counter-examples.
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
> 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.
> "Programmers have been overwhelmingly enthusiastic about Java because it was designed from the ground up for the Internet. JavaScript is a natural fit, since it's also designed for the Internet and Unicode-based worldwide use," said Bill Joy, co-founder and vice president of research at Sun. "JavaScript will be the most effective method to connect HTML-based content to Java applets."
This was all actually implemented. JavaScript functions could call Java applet methods and vice versa (see https://docs.oracle.com/javase/8/docs/technotes/guides/deplo... ). Of course over time everyone abandoned applets because of all the security problems, and JavaScript became a good enough language to write application logic directly in it. Still, there's more meaning behind the name than it just being a cynical marketing move.
Take it to Twitter
Haha, or because it froze the whole browser for a few seconds upon loading. Unlike Macromedia Flash by the way.
All the same, I probably get as many calls from recruiters to fill Java positions as I do JS positions. I've never used the former, and explaining it is always awkward!
Of course 100% of that cpu is probably 1/10 of one core on any of my modern machines, so an ordinary and not-broken ad laden page routinely eats several times as many cycles now. Progress!
In this case, it's Oracle's circus and we are the monkeys.
You might not be aware, but this is a trivial thing to do.
One possibility is thus just make some vocalic derivation, which align with well known spontaneous evolution of languages like ablaut[1]. Following that, and keeping the dance connotation, jive[2] is an option. Or closer on phonetic distance to java (/ˈd͡ʒɑː.və/), there is jovial (/ˈd͡ʒəʊ.vɪ.əl/ or /ˈd͡ʒoʊ.vɪ.əl/ or /ˈd͡ʒoʊ.vəl/)[3].
Might our jovial·script enjoy our life.
[1] https://en.wikipedia.org/wiki/Indo-European_ablaut
Unrelated but, the JavaScript capitalization is so odd
> 1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.
You'll still get all the strong typing without have to wait for it to run.
For example an error in a little used branch would cause an error before the branch even runs.
Invoking Applet Methods From JavaScript Code - https://docs.oracle.com/javase/tutorial/deployment/applet/in...
and
Invoking JavaScript Code From an Applet - https://docs.oracle.com/javase/tutorial/deployment/applet/in...
Aside from the "Java is cool, name everything Java" in the early days - there was scripting between the browser and the applet using a language named JavaScript.
This cramming did not have any regard for whether Java was a good solution for a given problem, or indeed whether the Java of that era could solve the problem at all. It did not matter. Java was Good. Good was Java. Java was the Future. Java was the Entire Future. Get on board or get left behind. It was made all the more infuriating for the fact that the Java of this time period was not very good at all; terrible startup, terrible performance, absolutely shitty support for anything we take for granted nowadays like GUIs or basic data structure libraries, garbage APIs shoved out the door as quickly as possible so they could check the bullet point that "yes, java did that" as quickly as possible, like Java's copy-of-a-copy of the C++ streaming (which are themselves widely considered a terrible idea and an antipattern today!).
I'm not even saying this because I'm emotional or angry about it or hate Java today. Java today is only syntactically similar to Java in the 90s. It hardly resembles it in any other way. Despite the emotional tone of some of what I'm saying, I mean this as descriptive. Things really were getting shoveled out the door with a minimum of design and no real-world testing so that the Java that they were spending so much marketing money on could be said that yes! It connected to this database! Yes! It speaks XML! Yes! It has a cross-platform GUI! These things all barely work as long as you don't subject them to a stiff breeze, but the bullet point is checked!
The original plan was for Java to simply be the browser language, because that's what the suits wanted, because probably that's what the suits were being paid to want. Anyone can look around today and see that that is not a great match for a browser language, and a scripting language was a better idea especially for the browser in the beginning. However, the suits did not care.
The engineers did, and they were able to sneak a scripting language into the browser by virtue of putting "Java" in the name, which was enough to fool the suits. If my previous emotional text still has not impressed upon you the nature of this time, consider what this indicates from a post-modern analysis perspective. Look at Java. Look at Javascript. Observe their differences. Observe how one strains to even draw any similarities between them beyond the basics you get from being a computer language. Yet simply slapping the word "Java" on the language was enough to get the suits to not ask any more questions until much, much later. That's how crazy the Java push was at the time... you could slip an entirely different scripting language in under the cover of the incredible propaganda for Java.
So while the press release will say that it was intended to glue Java applets, because that's what the suits needed to hear at that point, it really wasn't the case and frankly it was never even all that great at it. Turns out bridging the world between Java and Javascript is actually pretty difficult; in 2025 we pay the requisite memory and CPU costs without so much as blinking but in an era of 32 or 64 MEGAbyte RAM profiles it was nowhere near as casual. The reality is that what Javascript was intended to be by the actual people who created it and essentially snuck it in under the noses of the suits is exactly what it is today: The browser scripting language. I think you also had some problems like we still have today with WASM trying to move larger things back and forth between the environments, only much, much more so.
We all wish it had more than a week to cook before being shoved out the door itself, but it was still immensely more successful than Java ever could have been.
(Finally, despite my repeated use of the term "suits", I'm not a radical anti-business hippie hacker type. I understand where my paycheck comes from. I'm not intrinsically against "business people". I use the term perjoratively even so. The dotcom era was full of bullshit and they earned that perjorative fair and square.)
I can't imagine writing anything of substance primarily in groovy.
That's solely based on a poor imagination, not trying...
Is it? My experience in the past decade is that there are more memes about people who confuse the 2 than people that confuse the 2.
I see that there's something called that related to javascript already, but like -- very similar spelling, ".js" still works, we lose the Java confusion etc etc.
There are more important battles to fight.
But it doesn't mean there's much commonality - beyond superficially C-like syntax - between the languages, and certainly not between their "standard libraries" (aka the browser APIs in JavaScript's case).
It's also better if there's one ecosystem instead of one fragmented with different languages where you have to write bindings for everything you want to use.
Judges is the best we have. US has juries, not sure if that makes it better.
More importantly we need to criminalize lobbying in order to get control back over "our democracies" (what ever that still means today).
But they DO work in an office, and use a web browser for 8 hours a day.
https://docs.oracle.com/javase/tutorial/deployment/applet/in...
> LiveConnect is a feature of web browsers which allows Java applets to communicate with the JavaScript engine in the browser, and JavaScript on the web page to interact with applets. The LiveConnect concept originated in the Netscape web browser, and to this date, Mozilla and Firefox browsers have had the most complete support for LiveConnect features. It has, however, been possible to call between JavaScript and Java in some fashion on all web browsers for a number of years.
https://www.oracle.com/java/technologies/javase/liveconnect-...
--
The naming appears to be confused.
https://web.archive.org/web/20101115234856/http://www.oracle...
> Improved Java/JavaScript communication. The bridge between the JavaScript engine in the web browser and the Java programming language has been completely reimplemented. The new implementation is backward-compatible and features improved reliability, performance and cross-browser portability, for both Java calling JavaScript as well as JavaScript calling Java. Formerly Mozilla-specific "LiveConnect" functionality, such as the ability to call static Java methods, instantiate new Java objects and reference third-party packages from JavaScript, is now available in all browsers.
The "LiveConnect" relating to the original LiveScript maybe? And that LiveConnect was a Netscape/Mozilla driven thing.
My point was more one of "JavaScript was the glue between applets and the HTML page itself early in the development of the language."
Renaming LiveScript to JavaScript and promoting the LiveConnect functionality wasn't an unreasonable thing at the time.
The alternative is not "User sees no error", it's "user sees the error at runtime".
In which case, yeah, having the user see the type error is vastly preferable to having the user see a runtime JS error.
It is really powerful as compared to Javascript. It is even really powerful as compared to most other languages people normally use. But not very powerful as compared to languages that have 'proper' type systems. Typescript still relies on you writing tests for everything.
The type system is a huge boon for the developer experience, of course. It enables things like automatic refactoring that make development much more pleasant (although LLMs are getting better at filling that void in dynamically typed languages). But it doesn't save you from bugs in a way that the tests you have to write anyway won't also save you from. And those same tests would also catch the same bugs in Javascript, so you're in the same place either way with respect to that.
Put another way, I'm fine with the TS syntax (and use TS because there aren't other choices), but the TS semantics aren't a good long-term solution.
We'll probably get there again with wasm, eventually. But it's taking a very long time.
This argument is slightly backwards. This is essentially the argument used for "javascript in the backend" and "let's package the whole browser as application runtime so we can use javascript". The core of the argument is that javascript is ipso facto the best language/runtime to write any code in, including refactoring existing codebases. Bringing javascript out of the browser also means you have to write bindings for javascript and recreate the existing ecosystems anyway.
Even if you approach this from "single codebase across runtimes" angle, the conclusion to bridge the gap between browsers and languages with existing codebase, expertise and ecosystems is much more reasonable than rewrite everything in javascript.
They explained that in detail in the article. You don't need to remember correctly, you need to read the article. People who comment like you without doing the bare minimum, i.e. read what they're commenting on, should stop and think, what do you think you're contributing by doing that??
Right now, sure.
But if TS is supported natively in the browser, wouldn't your editor highlight the errors as you type? In which case the chance of deploying a broken TS file to the browser is minimal - you'll have to go out of your way to do so, like writing the TS file in plain notepad.
To go even further, having TS supported in the browser does not mean that you are forced to abandon your build step(s). You are still free to run a build step that either:
1. Does the full compilation to JS, and that's what gets deployed.
or
2. Just lints the file, and has the original TS file deployed.
Nothing in "Native TS in the browser" enforces a no-build-step dev process; it just makes it optional.
There's also the fact that, if JS is no longer the target (either browser-byte-code or native-code will be the target), then type-checking can be improved even further because there will be no requirement to allow things purely due to JS compatibility.
Finally, there's an awfully large number of optimisations that can be done if JS is not the target and native-code is.
I'm not seeing any downside here.
So I'm not necessarily saying it's a bad thing, it's just that I don't see the point. And given that there's the major downside of having to go through the standards process, both now and in the future, which will likely involve breaking changes and making it harder to update, I don't see it happening. (Edit: I should add that I do think the "types as comments" proposal makes sense. I do see the advantage of being able to run TS code without a build step. It's just the part where we'd throw an error in the user's face that I don't see providing value to anyone.)
I do think TC39 is progressive enough to be OK with changes to JS if those would allow TS to have more effective type checking (as long as they're backwards compatible, of course, which would also be the case if TS got incorporated into JS), so I don't think it's necessary for that.
Performance improvements enabled by optimisations would be nice, but I believe I heard that no major gains would be expected there, especially compared to something like WASM.