Claim #2 is particularly egregious. If it actually has merit, and if a judge is willing to hold a large corporation accountable for breaking the law (lol), someone at Oracle needs to be charged and prosecuted for it.
Can anyone speak to whether this is likely to succeed on its merits, or point to analysis of same by competent professionals?
Obviously, it looks like a pretty egregious case of Oracle-ness, but it's the job of Deno's lawyers to make it look like that. I'd be interested to see disinterested commentary.
Didn't know about Oracle using Node as an example of them building/selling things utilizing the "JavaScript" trademark. I think the post's framing of this being fraudulent is accurate, but even if it didn't legally qualify, it is at the very least extremely dishonest and unethical.
It’s not “obscure” or “exotic;” at least, no more than Node was when it was released. Honestly this is such a lame take to those of us who are working in JS outside of Node and Deno.
And people do work at that intersection.
IMO Deno is the worst option of all new JS runtimes and taking on this fight kind of makes sense that way. If you can’t win mindshare, start a fight. I guess. (In my opinion they should have simply designed Deno to be NPM compatible, but here we are.)
Only recently... and yes, to Deno's great credit. Deno has an amazing team and this isn't commentary about their hard work; just disagreement with one of the early decisions.
Neat. But for a relevant query, try searching for "npm" instead. 0 issues listed. Further, in the `deno_npm` repo for npm resolving by the deno cli, there are two open issues. One is a feature request, and the other is not clearly an important issue.
Deno is probably not "fully" NPM compatible, arguably, because you still need to prefix imports with "npm:" in a lot of cases. I've filed PRs to that effect, is why I know -- a breaking change for many widely-deployed libraries that need to maintain older node compat. That should not be necessary for a runtime that is "fully" NPM compliant.
Aside from that, Node compliance is a much larger ball of wax than simple NPM compliance, and as far as I know Deno is not there and will not be there for some time.
My gripe with Deno is the choice to hard-fork. That is core to the idea; so, we will disagree. No big deal. As a result of Deno's choice, people now have many runtimes to choose from: Bun, LLRT, and the one I have written on top of GraalJs, Elide. Many others, too.
Most of these runtimes shoot for as full NPM / Node compat as they can muster without intolerable contortions in the code. Why? Because a ton of software out there runs on NPM, or on Node APIs. Users think of server-side JavaScript and Node as the same thing -- this is not true, Node is both the "Node APIs" and the V8-based engine underneath it.
But this is exactly what I mean: for Deno to claim that Oracle does not "use" the JavaScript trademark requires a completely ignorant stance about technologies like GraalJs. Last we benched, Elide (on top of GraalJs) outperformed Deno by a wide margin. Oracle has invested years of engineering work into it. Enough that it outperforms Node (by a long shot) and Deno, and typically ties with Bun. So why does Deno get to say what happens with the trademark? It makes no sense to me.
I might even agree that Oracle should not own it or control it the way they do. I don't know. But I do know that Deno's demands are Node-centric, and the JavaScript ecosystem is simply way bigger than that.
I think the history, causes, and goals here are getting a bit wobbly. Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno. I'm obviously not him, so I can't speak much about all of that.
Node compatibility is interesting because it's only useful until it's not. If all these other runtimes eat away enough at node's share, it won't make sense to be compatible with node anymore.
Just to finish the original discussion, as much as I love talking about the current state of js (heh) runtimes: the mention of graaljs supports deno's argument. Oracle, for whatever reason, used "js" rather than "JavaScript".
GraalJs is just a name. It was created by Oracle so they can use the trademark if they want to. I have no idea what you are talking about.
> Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno
Yes, I explained that we disagree. Clearly he also feels he was wrong about Deno’s NPM choices since he reversed course and added NPM support. So Ryan agrees with me, I guess.
> If all these runtimes eat away enough at node’s share
WinterCG and other efforts are formalizing APIs that can be shared across runtimes. Which is great. Many of these APIs are at least informed by, if not outright standardized versions of, Node APIs. They are here to stay.
Claim #2 is particularly egregious. If it actually has merit, and if a judge is willing to hold a large corporation accountable for breaking the law (lol), someone at Oracle needs to be charged and prosecuted for it.
Related:
Oracle, it's time to free JavaScript (277 points, 70 days ago, 127 comments) https://news.ycombinator.com/item?id=41557383
Deno is filing a USPTO petition to cancel Oracle's JavaScript trademark (7 points, 3 days ago) https://news.ycombinator.com/item?id=42212949
Can anyone speak to whether this is likely to succeed on its merits, or point to analysis of same by competent professionals?
Obviously, it looks like a pretty egregious case of Oracle-ness, but it's the job of Deno's lawyers to make it look like that. I'd be interested to see disinterested commentary.
Didn't know about Oracle using Node as an example of them building/selling things utilizing the "JavaScript" trademark. I think the post's framing of this being fraudulent is accurate, but even if it didn't legally qualify, it is at the very least extremely dishonest and unethical.
This is either for the greater good of the whole JavaScript community or a PR stunt to just get in the news. Or both.
even if it's a PR stunt, it's good thing if JavaScript becomes free
GraalJs, it would seem, would count.
It’s not “obscure” or “exotic;” at least, no more than Node was when it was released. Honestly this is such a lame take to those of us who are working in JS outside of Node and Deno.
And people do work at that intersection.
IMO Deno is the worst option of all new JS runtimes and taking on this fight kind of makes sense that way. If you can’t win mindshare, start a fight. I guess. (In my opinion they should have simply designed Deno to be NPM compatible, but here we are.)
Deno is NPM compatible
Only recently... and yes, to Deno's great credit. Deno has an amazing team and this isn't commentary about their hard work; just disagreement with one of the early decisions.
`is:open is:issue label:bug label:"node compat"` -> 203 issues currently open.
Neat. But for a relevant query, try searching for "npm" instead. 0 issues listed. Further, in the `deno_npm` repo for npm resolving by the deno cli, there are two open issues. One is a feature request, and the other is not clearly an important issue.
> Neat. But for a relevant query, try searching for "npm" instead
`is:issue is:open npm` 467 open
https://github.com/denoland/deno/issues?q=is%3Aissue+is%3Aop...
`is:issue is:open label:bug npm` 199 open
https://github.com/denoland/deno/issues?q=is%3Aopen+is%3Aiss...
For the record, "NPM compat" probably does include many feature requests (legitimately), not just bugs.
I did make a mistake. Thanks for pointing that out.
However, the point that deno is npm compatible is still true, contrary to what you originally said.
Deno is probably not "fully" NPM compatible, arguably, because you still need to prefix imports with "npm:" in a lot of cases. I've filed PRs to that effect, is why I know -- a breaking change for many widely-deployed libraries that need to maintain older node compat. That should not be necessary for a runtime that is "fully" NPM compliant.
Aside from that, Node compliance is a much larger ball of wax than simple NPM compliance, and as far as I know Deno is not there and will not be there for some time.
My gripe with Deno is the choice to hard-fork. That is core to the idea; so, we will disagree. No big deal. As a result of Deno's choice, people now have many runtimes to choose from: Bun, LLRT, and the one I have written on top of GraalJs, Elide. Many others, too.
Most of these runtimes shoot for as full NPM / Node compat as they can muster without intolerable contortions in the code. Why? Because a ton of software out there runs on NPM, or on Node APIs. Users think of server-side JavaScript and Node as the same thing -- this is not true, Node is both the "Node APIs" and the V8-based engine underneath it.
But this is exactly what I mean: for Deno to claim that Oracle does not "use" the JavaScript trademark requires a completely ignorant stance about technologies like GraalJs. Last we benched, Elide (on top of GraalJs) outperformed Deno by a wide margin. Oracle has invested years of engineering work into it. Enough that it outperforms Node (by a long shot) and Deno, and typically ties with Bun. So why does Deno get to say what happens with the trademark? It makes no sense to me.
I might even agree that Oracle should not own it or control it the way they do. I don't know. But I do know that Deno's demands are Node-centric, and the JavaScript ecosystem is simply way bigger than that.
I think the history, causes, and goals here are getting a bit wobbly. Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno. I'm obviously not him, so I can't speak much about all of that.
Node compatibility is interesting because it's only useful until it's not. If all these other runtimes eat away enough at node's share, it won't make sense to be compatible with node anymore.
Just to finish the original discussion, as much as I love talking about the current state of js (heh) runtimes: the mention of graaljs supports deno's argument. Oracle, for whatever reason, used "js" rather than "JavaScript".
GraalJs is just a name. It was created by Oracle so they can use the trademark if they want to. I have no idea what you are talking about.
> Ryan has been outspoken about what he thinks he did wrong with Node and why he decided to make Deno
Yes, I explained that we disagree. Clearly he also feels he was wrong about Deno’s NPM choices since he reversed course and added NPM support. So Ryan agrees with me, I guess.
> If all these runtimes eat away enough at node’s share
WinterCG and other efforts are formalizing APIs that can be shared across runtimes. Which is great. Many of these APIs are at least informed by, if not outright standardized versions of, Node APIs. They are here to stay.
Good luck