Oracle，是时候解放JavaScript了
尊敬的Oracle公司：
您早已放弃了JavaScript商标权，这正导致广泛且不必要的混淆与混乱。
JavaScript作为全球最流行的编程语言，支撑着无数网站的运行。然而，数百万使用该语言的开发者中，鲜有人意识到JavaScript实为甲骨文公司持有的商标。这种脱节现象显而易见：JavaScript早已成为通用术语，被无数个人和企业广泛使用，与甲骨文的任何产品均无关联。
甲骨文对JavaScript商标的持有显然符合法律定义的商标弃置。此前一篇博客文章曾就此问题呼吁贵公司释放该商标。不出所料，该请求未获回应。因此，现在是采取积极行动将JavaScript商标归还公共领域的时机。
商标弃置
《美国法典》第15编第1127条规定：
若出现下列任一情形，商标 出现以下任一情形时，应视为“放弃”：
对于JavaScript而言，上述两项标准均适用。
Netscape、Sun、Oracle
JavaScript商标目前由甲骨文美国公司持有(美国申请号：75026640，美国注册号：2416017)。这究竟是如何发生的？
1995年，网景公司与太阳微系统公司合作开发交互式网站。布伦丹·艾克仅用10天就创建了JavaScript的首个版本——这种动态编程语言的语法体系大致源自太阳公司的Java语言。基于此合作关系，太阳公司持有JavaScript商标权。2009年甲骨文收购太阳微系统公司，从而获得了JavaScript商标权。
该商标实为收购遗留的产物。无论是Sun还是甲骨文，从未以该商标开发过任何产品。法律团队年复一年地续展商标权，从未质疑其价值。甲骨文内部恐怕只有极少数人知晓公司持有JavaScript商标，即便知晓，他们也未必理解这给开发者社区带来的困扰。
用之则存，弃之则亡
甲骨文因长期未使用而丧失了JavaScript商标权。
甲骨文从未真正推出过名为JavaScript的产品。20世纪90年代至21世纪初，支持JavaScript浏览器功能的网景导航器曾占据主导地位。但到2003年，网景的影响力已逐渐式微，其浏览器最终版本于2008年发布。与此同时，JavaScript已演变为广泛应用的独立编程语言，嵌入多款浏览器中，与甲骨文毫无关联。
最新提交至美国专利商标局的专利申请于2019年完成，其中引用了nodejs.org(该项目由本文作者Ryan Dahl创建)以及Oracle的JavaScript扩展工具包(JET)。(http://nodejs.org/)(本函作者Ryan Dahl创建的项目)及甲骨文的JavaScript扩展工具包(JET)。但Node.js并非甲骨文产品，JET仅是为甲骨文服务(尤其是甲骨文云)开发的JavaScript库集合。JavaScript库数以百万计，JET并无特殊之处。
(甲骨文甚至不是OpenJS基金会成员——该基金会现为Node.js项目的管理机构。甲骨文也从未参与Node.js的开发工作。)
甲骨文还提供GraalVM，这是一款可执行JavaScript等多语言的JVM。但GraalVM远非标准JavaScript实现，该角色由V8、JavaScriptCore和SpiderMonkey等引擎承担。GraalVM的产品页面甚至未提及“JavaScript”，需深入文档才能发现其支持功能。
甲骨文在GraalVM和JET中使用JavaScript的行为，并不构成对该商标的实质性使用。这些松散关联无法满足商标在商业领域中持续实际使用的要件。
通用术语化
当商标演变为通用术语时，亦可视为放弃使用。
1996年，网景公司宣布将召开ECMA国际标准组织会议以规范JavaScript编程语言。但Sun公司(现甲骨文)拒绝放弃“JavaScript”商标权，最终该语言被命名为“ECMAScript”。(微软欣然提出“JScript”方案，但无人采纳。)JavaScript创始人兼本函联署人布伦丹·艾奇于2006年撰文指出：“ ECMAScript始终是个令人不快的商标名，听起来像皮肤病 。”
Ecma国际组织成立了技术指导委员会TC39，该委员会负责发布JavaScript规范ECMA-262。该委员会成员涵盖所有主流浏览器厂商，如谷歌Chrome、苹果Safari、Mozilla Firefox，同时包含Node.js和Deno等服务器端JavaScript运行环境的代表。
甲骨文对JavaScript商标的所有权只会造成混乱。全球数百万开发者、企业和组织自由使用“JavaScript”这一术语，从未受到甲骨文的干涉。甲骨文从未采取任何措施主张对JavaScript名称的权利，很可能因为他们认为该商标主张在法庭上站不住脚。与通过收取许可费或强制使用限制来保护商标的典型商标持有者不同，甲骨文允许任何人使用JavaScript名称。这种不作为进一步佐证了该商标已失去意义并成为通用名称的论点。
从事JavaScript开发的程序员们组建了无数社区组织。这些组织如同标准制定机构般，被迫在命名时极尽周折——例如JSConf大会便无法直接使用其核心语言名称。令人遗憾的是，若不愿冒着被甲骨文商标诉讼的风险，世上既不可能存在“JavaScript大会”，也不可能有“JavaScript规范”。全球最流行的编程语言，竟连以自身命名的会议都无法举办。
商标所有权与该词汇普遍的通用化使用之间存在巨大错位。
释放商标
根据法律，商标若长期未使用或成为通用术语即视为放弃。这两点都适用于JavaScript。
美国专利商标局(USPTO)是时候终止JavaScript商标注册，承认其作为全球最流行编程语言的通用名称——该语言在业界拥有多种实现形式。
甲骨文公司，您对该商标可能并无实质商业利益。其续展仅因法律团队必须履行所有商标续展义务，无论其相关性或使用情况如何。
我们敦促您将该商标归入公共领域。然而，此前善意请求已遭尝试，却未获任何回应。若贵司拒绝行动，我们将向美国专利商标局提交撤销申请以挑战其所有权。
此致
Ryan Dahl – Node.js 创建者
Brendan Eich – JavaScript 创建者
Michael Ficarra – JavaScript规范编辑者
Rich Harris – Svelte创建者
Isaac Z. Schlueter – npm创建者
费罗斯·阿布卡迪耶 – Socket首席执行官
詹姆斯·M·斯内尔 – Node.js技术标准委员会成员
韦斯·博斯 – Syntax.fm主持人
Scott Tolinski – Syntax.fm主持人
Shu-yu Guo – JavaScript规范编辑
Jordan Harband – JavaScript规范名誉编辑
Matt Pocock – 《Total Typescript》课程作者
以及 JavaScript 社区的另外 28,489 位成员
本文文字及图片出自 Oracle, it’s time to free JavaScript.
随机极客笔记：历史记载略有偏差。当Sun公司开始宣传Java时，网景其实早已拥有自己的“交互式脚本”语言，并在1995年3月发布时意外登上了《水星新闻》头版。在德国达姆施塔特举行的第三届国际万维网大会上，所有人都在热议此事。我被临时拉去午休时做专题演讲(后来不得不中断，因为没人去听SGI的主题报告:-))。现场所有人都激动不已，高呼“忘掉过去吧，这就是未来”。当时网景公司希望将其整合到Netscape Navigator浏览器中，但面临一个小问题：这与他们自有的脚本语言存在竞争关系。他们想借Java热潮之势将其命名为JavaScript，而太阳公司的法律部门仅同意在网景承诺于Java 1.0版本(同年9月发布)时将其集成到浏览器中才允许使用该名称。
最终网景为其语言赢得了曝光度，太阳公司则让顶级浏览器搭载了他们的语言，并借此向微软施压，以高昂价格授权其在IE浏览器中使用。Java团队内部曾争论这是否“好事”——对太阳公司当然是，但“Java”概念的混淆却并非如此。政治博弈最终占上风，当标准组织被拒用“JavaScript”之名时，ECMAScript便应运而生。
事情就是这样。但我们如何走到今天这一步，与“我们都该统一称谓”的论点其实无关紧要。
那个“交互式脚本”是LiveScript还是其他什么？
—
编辑：上述表述似暗示存在另一种脚本语言：
> 他们遇到的小麻烦在于，这某种程度上成了自家脚本语言的竞争对手。
没错，LiveScript后来更名为JavaScript。
他们现在通过GoFundMe发起募捐，用于启动一项
<strike>专利</strike>商标撤销请求的调查阶段。目前仅筹得5万美元，目标金额为20万美元。(不知是否合理；从外部看这笔钱似乎不少，但他们对抗的是资金无限的甲骨文公司，所以…)
页面本身未提供链接。
https://www.gofundme.com/f/help-us-challenge-oracles-javascr…
https://deno.com/blog/javascript-tm-gofundme
并非吹毛求疵，但这是商标撤销案——并非专利。混淆可能源于案件提交至美国专利商标局的事实。
有人该去申请
<blink>的专利。甲骨文使用Java商标的行为，在商标撤销申请中难道不构成问题吗？我们讨论的是针对完全相同产品类型(即编程语言)的高度相似名称。事实上这种相似性最初正是为了暗示关联性。若甲骨文对该商标的唯一兴趣源于其相似度和历史渊源，我丝毫不感到意外。
甲骨文的唯一目的就是通过最有效的手段榨取资产价值，根本不在乎技术价值(不过这似乎不特指JavaScript)。
我认为这很准确。他们不可能放弃JavaScript而不冒着放弃Java的风险。
附带问题：公司/小企业/非营利组织的CEO或个体经营者能否代表企业自行出庭应诉？个人身份时可以这样做，但若企业穷得请不起律师，能否作为最后手段“临时应战”？还是说此时已成死局？
若可行，我希望这些正义一方能战斗到底，尽可能拖延诉讼进程，耗尽资金雄厚对手的财力。
若你依法有权代表企业签署文件，即可代为签署法庭文书。
[已删除]
> 市政厅是打不倒的
本节目由“美好事物不可能实现党”为您呈现
毕竟历史上政治领域里，挑战不可能的尝试向来成效斐然。
我常举的例子是英国工党。数百年来英国始终是两党制国家，先是辉格党与托利党，后为自由党与保守党。
二十世纪之交，工人阶级与工会运动创立了自己的政党——工党。当时肯定有许多人断言挑战现存双头垄断绝无可能，甚至认为尝试本身就是浪费时间等等。
到1929年，他们已成为下议院中最大的政党。1945年，他们赢得了多数席位。这并非一夕之功，而是许多人倾注心血的成果——他们坚信更美好的未来触手可及，而他们的努力终获回报。
… 你以为人类历史上一直存在着温顺无害的投票制度，只允许对温吞话题进行表决吗？
“历史与政治”本质上是人们试图完成不可能任务的领域——按己意重塑社会。若声称这种尝试从未成功，要么是无知，要么是虚伪。
别散播失败主义了。要么将这股能量转化为更有价值的事物，要么就让开道路。
所谓“失败主义”不过是拒绝接受现实者的又一遮羞布。当你本可将金钱投入能改变之事，却执意挥霍在无力改变之事上——这才是真正的“失败主义”，因为它毫无建树。
> “失败主义”不过是那些拒绝接受现实之人的又一遮羞布。
有时你说的没错，确实有人以此为盾，肆意做些天真的事，建造沙堡。但我不认为此处如此。社会需要一定程度的潜在无用努力，否则那些勉强可行的事情永远不会被尝试，只因它们离成功线太近。
世间尚有无数值得人们投身的事业，我们不必都去追逐那些十拿九稳的成功。
你不懂。他们正在叫经理。只要叫经理，一切都能解决。
[已删除]
我对多数荒谬的“斗争”毫无兴趣，更别说这场了。我直白地说：若真想“赢得斗争”，有更值得花钱的地方。批评事物无需提供解决方案，尤其当你对议题本身并不热衷时。
顺带一提，关于你指责我缺乏务实精神，我建议你查阅定义：“基于实际而非理论考量，以明智现实的方式处理事务”——这恰恰是我评论的核心。想战胜一家靠政府偏袒才成功的公司，根本不现实。
> 既然如此：或许该听从你自己的建议，放弃改变他人想法？
我在HN发帖是因为这是公共论坛，我只想分享观点，而非改变他人想法。
[已删除]
毕竟众所周知，数量胜于质量。
强势组织必然招致强敌。许多人渴望看到甲骨文退出舞台，但他们绝非比整个行业更强大。
我认为人们应该使用EcmaScript这个名称而非JavaScript，因为它更合理(毕竟这门语言与Java毫无关联，这样命名也更少混淆)。真希望甲骨文能通过诉讼强制所有人采用更优名称。
> 因为这个名称更合理(避免混淆，毕竟这门语言与Java毫无关联)。
若在21世纪初，这场战役或许值得一搏。但2025年的今天，即便在企业领域深耕者中，了解JavaScript的人数恐怕已远超Java用户——此时再推行新命名恐怕反而更易引发混淆。
总之，这场讨论你晚了整整二十年 :/
追溯往昔…
从JavaScript代码调用Applet方法 – https://docs.oracle.com/javase/tutorial/deployment/applet/in…
以及
从Applet调用JavaScript代码 – https://docs.oracle.com/javase/tutorial/deployment/applet/in…
除了早期那种“Java很酷，凡事都冠上Java名号”的风潮外——浏览器与小程序之间确实存在一种名为JavaScript的脚本语言进行交互。
我当年确实用过这个技术：大学时用过一次，后来第一份工作做电信项目时又用过。
但这并不意味着两种语言存在太多共通点——除了表面上类似C语言的语法——更不用说它们的“标准库”(JavaScript中即浏览器API)了。
呃，JavaScript其实不是最初选定的名称，Eich给它起的名字是LiveScript。我从未见过任何知情人士对这个命名给出合理解释，除了Eich曾提到网景公司想要追求“酷炫”感。正是这种“酷炫”追求，导致最初将Scheme语言嵌入浏览器的任务，最终演变成了更接近C/Java风格的方案。
> Java小程序可调用同页面的JavaScript函数。《LiveConnect规范》详细描述了JavaScript代码与Java代码的交互机制。
https://docs.oracle.com/javase/tutorial/deployment/applet/in…
> LiveConnect是网页浏览器的一项功能，允许Java小程序与浏览器中的JavaScript引擎通信，同时使网页上的JavaScript能够与小程序交互。该概念最初由Netscape浏览器提出，至今Mozilla和Firefox浏览器对LiveConnect功能的支持最为完善。不过多年来，所有网页浏览器都已具备某种形式的JavaScript与Java互调能力。
https://www.oracle.com/java/technologies/javase/liveconnect-…
—
命名似乎存在混淆。
https://web.archive.org/web/20101115234856/http://www.oracle…
> 增强Java/JavaScript通信能力。浏览器JavaScript引擎与Java编程语言间的桥梁已完全重构。新实现兼容旧版功能，同时提升了可靠性、性能及跨浏览器移植性，无论Java调用JavaScript还是JavaScript调用Java均适用。此前仅限Mozilla的“LiveConnect”功能(如调用静态Java方法、实例化新Java对象及从JavaScript引用第三方包)现已全面支持所有浏览器。
这里的“LiveConnect”是否指原始的LiveScript？而LiveConnect本是Netscape/Mozilla主导的技术。
我的核心观点在于：“在JavaScript语言发展初期，它正是连接小程序与HTML页面本身的粘合剂。”
当时将LiveScript更名为JavaScript并推广LiveConnect功能，实属合理之举。
天啊，要是浏览器能直接解释Scheme(或类似语言)而非JavaScript，世界该多美好
<script>标签的原始设计本应具备可扩展性，而IE浏览器竟允许使用任何“活动脚本”引擎，因此曾短暂出现过Perl和Tcl等脚本语言，不过仅限于Windows平台。最终我们或许能通过wasm重现这种局面，只是这个过程实在太漫长了。
Sun公司曾力推它作为Java小程序的脚本语言。若非LiveConnect(Java与JS之间的接口层)如此漏洞百出，说不定真能成功。
更何况Java本身就是个庞然大物。运行时的启动时间和内存占用过高，导致大多数用户设备无法获得良好体验。
确实如此。记得1999年我就对这个命名感到恼火——正如你所说，JavaScript与Java除了表面都像C语言外几乎毫无关联…但只要花点时间读完两门语言的入门教程，这种混淆感很快就会消除。
还有更重要的战场需要我们去拼搏。
> 如今知道JavaScript的人可能比知道Java的还多
尽管如此，我接到Java岗位招聘电话的频率和JS岗位差不多。我从未用过前者，解释起来总是很尴尬！
我会告诉他们，不提供匹配岗位就是在浪费你的时间。他们有责任明确招聘需求，而非转嫁给你
坦白说这是对你的服务。任何值得加入的公司，其招聘人员都应理解技术差异(全AI招聘比这种体验更理想)。
对普通人而言，Java只是JavaScript的简称。
有时我们会犯愚蠢的错误长达数年甚至数十年，却无人察觉。如果你一直抱怨讨厌Java的臃肿/框架/等等，而实际指的是讨厌JavaScript的臃肿/框架/等等，人们很可能同时认同这两点。没人会察觉其中的矛盾。
我从未听闻有人这样混淆。普通人会讨论JavaScript吗？
我认为普通人其实清楚JS和HTML是什么。多数人的技术认知远超我们的想象——甚至超出他们自认的水平。
我认为普通人根本分不清谷歌和网页浏览器的区别。即便曾经明白差异的人，在主要设备变成封闭式手机后不久也渐渐遗忘了。
完全同意。我老婆(非常普通的人)前几天用必应搜索，我提醒她时她反问我在说什么，还指着任务栏里的Chrome图标。这种认知混乱程度简直超乎想象。
非开发者群体里大概万分之一的人知道吧。
我父母都不懂这些，他们不是开发者——甚至没有电脑或笔记本，只有手机。
但他们确实上班族，每天用网页浏览器工作8小时。
我这辈子大概没见过这种人。
这话听起来可能很疯狂，但如果微软开放TypeScript，所有浏览器都为JavaScript添加原生TypeScript功能…然后我们干脆都叫它TypeScript？或许？那样你就能看到原生ts文件了。甲骨文永远不会放弃JS。有趣的是，混淆Java和JS的人数多得惊人。
多年来我们呼吁为浏览器引入合理方案，而非徒劳挽救JavaScript。但眼下何不直接在WebAssembly中实现DOM绑定，让互联网一夜之间变得更好？
TypeScript确实是相当优秀的语言，比起用Fortran之类的语言，我更乐于使用它且效率更高。它的类型系统极其强大——这才是避免 bug 的关键所在。借助构造即正确的数据，编写函数式代码变得轻而易举。若需极致优化代码，WASM固然是理想选择，但多数网页应用的问题根源在于设计缺陷，此时语言选择也无济于事。TypeScript确实继承了JavaScript的某些烦人遗留特性，但每种语言都有冗余代码，通过严格的代码检查就能消除这些问题。
统一的生态系统也优于碎片化的多语言环境——后者需要为每个想用的组件编写绑定层。
由于必须兼容JavaScript(作为其超集)，TypeScript的类型系统同样存在诸多漏洞。
> 其类型系统实际上非常强大，这才是避免错误的关键
相较于JavaScript它确实强大，甚至比多数常用语言更强大。但若与具备“完整”类型系统的语言相比则逊色不少。TypeScript仍依赖开发者为所有操作编写测试。
当然，类型系统极大提升了开发体验。它支持自动重构等功能，让开发过程更愉快(尽管大型语言模型正逐步弥补动态类型语言的这一缺憾)。但它并不能像你必须编写的测试那样，真正帮你规避错误。而这些测试同样能捕获JavaScript中的相同错误，因此从这个角度看，两种语言的处境并无二致。
我热爱WASM，它正以稳健步伐向最终形态迈进，这点值得肯定。
根据经验，企业通常不会将商标名称开放给公众使用。我认为TypeScript目前是注册商标，且微软绝不会放弃这项权益。因此在此问题上，企业的行为模式如出一辙——自私自利。
原文提到微软曾提议用JScript商标替代JavaScript，这表明其存在放弃商标的意愿。
若浏览器厂商承诺在名称解禁后将其纳入浏览器，我敢说微软会同意。当前主要问题在于缺乏将TS纳入浏览器的强力推动。
我提议的技术方案是让JS和TS趋于同质化，但并非完全统一——正如他人所言，TS的核心目标仍是让用户(开发者)在代码运行前识别问题。不过若设计得当，TS文件仍可像普通JS那样被解释执行。技术上虽需编译处理而非直接以“原始”形式放入浏览器，但仍可称之为TS。
若能在YouTube找到他亲口说这话的片段，效果会更搞笑。可惜这确实是事实。
https://simonwillison.net
> 有趣的是混淆Java和JS的人数之多。
是吗？我这十年的经验是：嘲讽混淆两者的梗比实际混淆的人还多。
嘿嘿——这得看你合作的“项目破坏者”是什么货色…
ECMAScript原生类型注解曾是一项严肃的提案，一度获得广泛关注，但如今似乎已逐渐淡出视野。
https://github.com/tc39/proposal-type-annotations
除非将TypeScript改造为真正具备类型安全性的语言，并能实现良好性能——而非让你为本就不该编写的代码构造极其复杂的类型。
换言之，我接受TypeScript的语法(且因别无选择而使用它)，但其语义设计并非长久之计。
TypeScript的重要特性在于能在用户运行代码前(即浏览器介入前)识别问题。
运行时类型安全缺失常以意想不到的方式伤人。这本该成为标准规范。
没错，但这是个正交问题。这更像是呼吁标准化Zod。
那又怎样？若浏览器原生支持，它就能在下载时编译代码。
这样既能获得强类型优势，又无需等待运行时检查。
例如，在极少使用的分支中出现错误时，该分支甚至不会被执行就触发错误。
那用户会直接看到类型错误提示，而不是页面加载？这似乎并不比开发者编写代码时收到错误提示更好——而TypeScript正是采用后者机制。
> 也就是说用户会直接看到类型错误提示，而不是页面加载？
替代方案并非“用户看不到错误”，而是“用户在运行时看到错误”。
这种情况下，让用户看到类型错误确实远优于看到运行时JS错误。
更不用说每次文件未从缓存加载时，浏览器必须重新执行类型检查的性能开销。
我觉得这完全合理。Node环境已能运行TypeScript，Playwright脚本也能直接用TypeScript编写。浏览器直接运行TypeScript就是下一个合乎逻辑的步骤。
正想说同样的事。我完全接受禁用类型检查的TypeScript(这与不指定类型的TS不同)
EcmaScript真是个糟糕的名字。听起来太像湿疹(eczema)或灵质(ectoplasm)了。丑陋至极。
说得太对了。我脑子里总把它听成湿疹脚本，这联想实在不妙。
我倒觉得EctoScript这个名字挺有意思。不过换作是我，干脆改成WebScript算了。
还以为只有我注意到这个相似性(还有flegma)
赞同。WebScript更合适。
这一直是我最喜欢的提案。WebScript简洁明了。
必备链接：https://james-iry.blogspot.com/2009/05/brief-incomplete-and-…
> 1995年 – 布伦丹·艾克研究了编程语言设计史上所有错误，又发明了几项新错误，最终创造了LiveScript。后来为借势Java热潮，该语言更名为JavaScript。再后来为借势皮肤病热潮，该语言又更名为ECMAScript。
念起来别扭正是它的致命伤
文件扩展名是.js，MIME类型是text/javascript，但数百万用户都称它为javascript。短期内这不会改变
题外话：JavaScript的大小写写法实在古怪
当年似乎所有命名都采用Pascal大小写规范。
讽刺的是，JavaScript创造者本想借Java的声势而命名，如今Java和JavaScript都归Oracle所有——他们既想保留名称又不愿改用ECMAScript(其官方名称)。
若阅读原始JavaScript新闻稿(https://web.archive.org/web/20020808041248/http://wp.netscap…)，会发现它主要定位为粘合代码语言，用于让Java小程序(承载实际应用逻辑)与网页实现交互：
借助JavaScript，HTML页面可包含智能表单，根据用户输入在客户端直接执行贷款还款或货币兑换计算。用Java编写的多媒体天气预报小程序可通过JavaScript脚本，根据区域实时气象数据动态显示对应图像和声音。服务器端的JavaScript脚本能即时从关系数据库提取数据并格式化为HTML内容。页面可能同时包含客户端和服务器端的JavaScript脚本。在服务器端，脚本可根据存储在关系数据库中的用户偏好动态生成并格式化HTML内容；在客户端，脚本则将各类Java小程序与HTML表单元素整合为实时交互界面，用于指定全网信息检索。
> “程序员对Java的热情如此高涨，是因为它从底层设计就面向互联网。JavaScript同样天生契合互联网与基于Unicode的全球化应用，”Sun公司联合创始人兼研究副总裁Bill Joy表示，“JavaScript将成为连接HTML内容与Java小程序的最有效方式。”
这些功能曾实际实现过。JavaScript函数可调用Java小程序方法，反之亦然(详见https://docs.oracle.com/javase/8/docs/technotes/guides/deplo…)。当然随着时间推移，由于各种安全问题，所有人都放弃了小程序，而JavaScript也发展成足以直接编写应用逻辑的语言。不过这个名称背后蕴含的意义，远不止是冷嘲热讽的营销手段。
巧合的是，你链接的新闻稿日期是1995年12月4日——恰好是30年前的今天！
若“JavaScript”之名未被占用，如今的Groovy语言本应以此命名。
哈哈完全同意，这正是仿照Java打造的“脚本语言”！顺带一提，它确实是门优秀的语言！
还记得BeanShell吗？虽然它从未像Groovy那样成熟普及，但使用起来也很有趣。
Groovy真的在广泛领域被“采用”了吗？感觉99%的普通人只通过Gradle和Jenkins的DSL接触过它。
实在难以想象用Groovy写出有分量的东西。
Rackspace用过(还在用？)它。
Rundeck用它开发插件。这就像人们用Lua实现主程序动态脚本，只不过他们懂Java所以改用Groovy。
>我无法想象用Groovy作为主要语言编写任何有分量的东西。
这纯粹是想象力匮乏，并非尝试过…
同意前一位的观点。从未见过用Groovy开发的实质性项目。即便Beanshell我也只在其他项目中用于基础脚本/应用定制，但Groovy？十五年来从未见过。
我认为嵌入式应用、测试/插件/领域特定语言才是主要用例。若需等待JVM启动，它根本不适合命令行工具——尤其在人们已习惯Rust或Go这类即时启动二进制文件的时代。
> 当然随着时间推移，所有人都因安全问题放弃了小程序，
哈哈，或者因为加载时会让整个浏览器卡死几秒钟。顺便说一句，Macromedia Flash可不会这样。
2005年左右，我曾遇到过一个Flash广告占用100% CPU的情况。它甚至没有恶意，只是个制作拙劣的广告。那天起我就不再为任何网站设置广告拦截例外了。
当然，现在任何现代机器上100%的CPU占用可能只相当于单核处理器的十分之一，所以普通且未崩溃的广告页面如今常消耗数倍于此的周期。进步啊！
网站同样能占用你100%的CPU资源。
你或许不知，这其实是件轻而易举的事。
事情远比这复杂得多，难以简单概括，因为涉及多个动机各异的实体。简而言之，新闻稿之所以大谈特谈这个，是因为那是Java强制推广时代的巅峰时期，是企业版网景在发声。那些未曾经历过那段岁月的人无法体会Java当时的营销力度——毕竟此后再无任何编程语言能获得如此庞大的营销预算支持，无论你是否愿意，Java都像被硬塞进喉咙般铺天盖地。这与当今人工智能的处境颇为相似，只不过程序员群体被锁定得更为精准——考虑到目标人群远小于人工智能“全球全民普及”的定位，人均投入的实际金额(按通胀调整后)可能更高。
这种强推完全不考虑Java是否适合解决特定问题，甚至不考虑那个时代的Java 能否解决问题 。这些都不重要。Java就是好的。好的就是Java。Java就是未来。Java就是全部的未来。要么跟上，要么被淘汰。更令人恼火的是，当时的Java其实糟糕透顶： 启动缓慢、性能糟糕、对如今理所当然的功能(如图形界面或基础数据结构库)支持极其拙劣，更将垃圾API匆匆塞出以尽快勾选“Java实现了这个功能”的清单——比如对C++流处理的拙劣模仿(如今这些流处理本身已被公认为糟糕设计和反模式！)。
我这么说并非出于情绪化或对Java的憎恨——如今的Java仅在语法上与90年代相似，其他方面几乎判若两物。尽管言辞间带着情感色彩，但这纯粹是 客观描述 。当时的产品确实是在最低限度设计和毫无实战测试的情况下仓促出炉的——只为让那些耗费巨资营销的Java能宣称：看！它能连接数据库！看！它支持XML！看！它拥有跨平台GUI！这些功能只要不遇上强风就能勉强运转，但关键卖点总算打勾了！
最初的计划是让Java直接成为浏览器语言，因为这是管理层想要的——说到底，他们被雇佣就是为了满足这种需求。如今谁都看得出这根本不适合浏览器语言，尤其在早期阶段，脚本语言才是更理想的选择。但管理层毫不在意。
工程师们却在意，他们巧妙地将脚本语言植入浏览器——仅凭在名称中冠以“Java”二字就足以蒙蔽高层。若我先前充满激情的论述仍未能让你领会当时的本质，不妨从后现代分析视角审视其深意。看看Java，看看JavaScript，观察它们的差异。试着找出它们除却作为计算机语言的基本属性之外的任何相似之处——这简直难如登天。然而仅仅给语言冠上“Java”之名，就足以让高层们不再追问，直到多年之后。这正是当年Java推广运动的疯狂程度…在铺天盖地的Java宣传攻势掩护下，竟能悄然塞入 完全不同的脚本语言 。
因此尽管新闻稿宣称它是为粘合Java小程序而生——毕竟那是当时管理层需要听到的说辞——实情却截然不同。坦白说，它在这方面也从未真正出色过。事实证明，在Java和JavaScript之间架设桥梁相当困难；到了2025年，我们支付必要的内存和CPU成本时连眼皮都不眨一下，但在32或64兆字节内存配置的时代，这绝非易事。现实是：JavaScript的真正创造者们当初将其偷偷塞进浏览器时设想的定位，恰恰就是它今日的形态——浏览器脚本语言。当时还存在类似今日WASM的难题：在不同环境间传输大型数据时遭遇阻碍，只不过当时的困境要严峻得多。
我们都希望它能有超过一周的酝酿时间再被匆匆推出，但它取得的成功仍远超Java所能企及。
(最后声明：尽管我反复使用“西装革履的家伙们”这个贬义词，但我并非激进反商业的嬉皮士黑客。我清楚自己的薪水从何而来，也并非天生反对“商界人士”。即便如此我仍用贬义。互联网泡沫时期充斥着胡扯，他们完全配得上这个贬称。)
顺便问下，你最爱的三门语言是什么？
哇。你有博客吗？你完全可以写本书。文风绝佳又行云流水。
其实开发者原本想命名为Livescript。但创建公司(网景)希望与Java建立关联。
> 而如今Java和JavaScript都归属于
“如今”的表述让人误以为JavaScript商标是近期才被收购的。其实甲骨文早在2009年收购Sun时就获得了该商标，据我所知Sun最初是在90年代获得的商标权。
对我们大多数人而言，甲骨文收购太阳公司不过是几年前的事。那可是标志性事件，至今仍令人津津乐道呢
建议您仔细阅读原文。
请在评论中完整阐述观点，而非仅抛出空洞指责。
那艘船早就在好几年前就开走了。甲骨文根本没资格把JavaScript注册为商标。
要不让甲骨文起诉所有JavaScript开发者，看他们有多少处理器？
甲骨文就是靠庞大的法务部门欺负人的。
这点大家都心知肚明。
> Oracle根本无权将JavaScript注册为商标。
你这么认为也罢。但最终还是要由法官裁决，对吧？
我支持EcmaScript方案。干脆抛弃那个蠢名字，让所有请愿者达成共识后继续前进。去他妈的Oracle。去他妈的JavaScript(反正和Java根本不是一回事)。
> 但最终还是要由法官裁决。对吧？
我认为我们正经历一场残酷的觉醒——法律允许与道德正确并非总是等同。这里存在极其恶劣的现象，法律亟待修订，而非简单推诿“此事交由法官裁决，我们无能为力”。
我同意放弃JavaScript这个名称，明白这能彻底解决问题。但其他问题却没这么容易绕过。
我们需要大幅缩短著作权保护期限，彻底废除《计算机欺诈与滥用法》且不作任何替代，废除软件专利制度。这些任务恐怕需要百年才能完成，这估计还是过于乐观的预估。
我们不能把一切交给法官裁决，因为即便今天获得有利判决，先例也可能被另一支笔轻易推翻。
> 我认为我们正在经历一场残酷的觉醒——法律允许之事与真正正确之事往往背道而驰。
虽不确定此处“我们”指代何人(或许是美国人？)，但全人类早已洞悉此理并据此行事。诸如某些国家总统拥有赦免权便是显例。美国作为国家至今存在亦是明证——建国之初其行为显然违法，但胜者书写历史，此举终成“正义”之举。
法律并非百分百明确严苛，这同样说明存在解释空间——某些行为可能“符合字面法律”，但因其恶劣动机和“违背法律精神”而本质上非法。当然，这高度取决于具体国家，且存在大量反例。
完全赞同。但这属于普遍性议题，而非当前具体事件。
法官制已是现有最佳方案。美国采用陪审团制度，尚不确定其优劣。
更重要的是，我们必须将游说活动定为犯罪，才能重新掌控“我们的民主制度”(无论这个概念在当今仍意味着什么)。
所谓“民众”指谁？这一切该如何启动？
就标准规范而言，官方文档早已采用“ECMAScript”称谓，甚至未提及JavaScript(https://github.com/tc39/ecma262/)，尽管TC39官网仍频繁使用后者。我猜他们或许会正式建议停止使用“JavaScript”，但恐怕他们根本不在乎。
况且，此处的请愿者Deno在生态系统中仅属边缘角色，几乎毫无话语权(实际上除了TC39之外无人能掌控大局，这反而是好事)。他们(或任何人)不可能仅凭高喊“别再提JavaScript！”就指望众人遵从。
更何况相较于ECMAScript这个沉甸甸的名称，JavaScript本身简洁易读——这大概正是当初选择它的初衷。
即便“JavaScript”名称被正式废弃，只要它存在于世，人们就会继续使用这个称谓。
因此Deno的请愿直指问题根源，既解决实际困扰又具备法律可行性。这才是“正确的做法”。回避名称本身无法解决问题——这种做法从来都不管用。
但大家都已经习惯称它为JS了。如果官方名称以“J”开头，过渡过程本可以轻松得多。
直接改名为“JS”(发音为jay-ess)吧，别再纠结字母代表什么了。
要是微软没抢注JScript就好了
微软自己都提议过，如果社区愿意接手JScript这个名称，他们愿意将商标权转让给社区团体。
或者干脆用“J”，就像“C”前面加“B”那样。
已被占用 https://en.wikipedia.org/wiki/J_(programming_language)
JECMAScript
JabbaScript
我对JS持中立态度，但听过别人称它为垃圾脚本。
JarJarScript。
JSONScript
JuicyScript
像JunoScript或JangoScript？JavaScript不过是过时的ECMAScript。
灵魂贾博伊脚本
它怎么过时了？
我猜论点是技术上JavaScript仍停留在1.0版或更低版本。真正进化的语言是ECMAScript。
我们现在用的其实是ECMAScript而非JavaScript。只是习惯称其为JavaScript。
只要足够多人称其为JavaScript，它就是JavaScript。真的。从法律意义上说也是如此(Deno团队正据此主张)。
我们这行给编程语言起糟糕名字的传统根深蒂固。这些名字全都不靠谱。整个Ekmuhscrip.js分歧事件简直完美契合。没错，这是我们的马戏团，这些就是我们的猴子。
> 是的，这是我们的马戏团，这些是我们的猴子。
但这次是甲骨文的马戏团，而我们才是猴子。
不过在我们这个马戏团里，有些人能当上漂亮企鹅。
但这与现存所有.js文件并不向后兼容。
一种方案是采用元音派生法，这符合语言自发演变的规律，如元音交替现象[1]。遵循此法并保留舞蹈意象， jive [2]可作为备选。若追求与java(/ˈd͡ʒɑː.və/)的发音接近度，则可选用 jovial (/ˈd͡ʒəʊ.vɪ.əl/ 或 /ˈd͡ʒoʊ.vɪ.əl/ 或 /ˈd͡ʒoʊ.vəl/)[3]。
愿我们的欢愉脚本(jovial·script)为生活增添喜悦。
[1] https://en.wikipedia.org/wiki/Indo-European_ablaut
[2] https://en.wiktionary.org/wiki/jive
[3] https://en.wiktionary.org/wiki/jovial
.js，即jecmascript的缩写，意为“简易脚本”
JabbaScript
这将为生态系统描绘出极具描述性的状态图景。
另可选用jiva(/ˈd͡ʒiːvə/)作为替代方案。
https://en.wiktionary.org/wiki/jiva
https://www.youtube.com/watch?v=UmO4zvq9HtE
为何不用Jayscript？
我注意到已有类似JavaScript的命名，但——拼写高度相似，“.js”仍可兼容，还能避免与Java混淆等等。
> 人们应当使用EcmaScript而非JavaScript
或者干脆改回“LiveScript”
我才不会去改所有文件的扩展名呢 🙂
顺应潮流——叫它js就行。
这根本不是更好的名字。要是真好早就流行起来了。
没人会叫它EcmaScript。干脆叫Jay Es算了。“JavaScript”本身也是个难听的名字。
EcmaScript听起来就别扭。
每次看到这个词，我脑海里立刻浮现“湿疹”的缩写。
没错！我在另一条评论里也说过同样的话！这简直像在念“湿疹脚本”。
现在我们大多数人直接叫它JS了。反正实际编写的也基本都是TS。
这很具文化/行业特异性。我个人确实称它为javascript。
没错绝对是文化差异。我经验里只有聊天时才用JS作为缩写。现实中人们都说“javascript”
直接把所有东西都切换成原生TypeScript。
这是“拥抱、扩展、淘汰”战略的最后阶段吧？
https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis…
拜托。JavaScript这个名字让我浑身不自在。如今我们已有更优雅的名字和更强大的功能，干脆让JS退场吧。
EcmaScript简直是糟糕透顶的名字，没人会这么称呼JS。这词怎么念？什么意思？到底是什么玩意儿？
更糟的是它听起来像某种皮肤病。
更别提ECMAScript这个词太拗口了！Eeh-cee-emm-ay-script。整整五个音节。
大多数人不都念成“埃克马”吗？
本该叫AcmeScript才对。这样就能和 Wiley E. Coyote 产生关联了。
这名字简直完美！
既然该组织在1994年更名为“Ecma International”，我觉得直接称它为“埃克玛脚本”就行。
听起来像皮肤病呢。
压力下就出问题？结果惹人烦？没它网站反而更顺眼？
这名字倒挺贴切。
这名字实在糟糕透顶。
或许该读作“埃克玛脚本”，这样音节数就和“JavaScript”一致了。
通常确实这么发音
我只听过“EcmaScript”这种发音，没听过“E-C-M-A Script”
去推特讨论吧
啊对，“欧洲计算机制造商协会”脚本
我来自Java世界，它本质上就是Java。虽然功能更强大，但大多数Java开发者都能轻松上手——除了缺少强健的静态类型系统，IDE在检测语法错误方面也不如Java出色。绝无贬低JavaScript开发者的意思，只是你们习惯了更完善的开发环境。
愚蠢的问题：JavaScript商标究竟如何造成负面影响？
毕竟实际使用中，这不就像“Kleenex”吗——大家都心知肚明指的是“纸巾”(即ECMAScript)。
问题不在于JS商标归属本身，而在于持有者竟是甲骨文(他们收购Sun时获得该商标)。
甲骨文是极具诉讼倾向的企业。其恶劣的诉讼声誉意味着JS生态圈永远无法确保他们不会突然杀来索要“租金”。更糟的是他们雇佣的律师军团；即便他们完全理亏，被盯上的项目也往往无力承担诉讼费用。
> 甲骨文是家极其好打官司的公司。他们在诉讼领域的恶名昭彰，使得JS生态圈永远无法确定他们何时会突然杀来索要“租金”。更糟的是他们雇佣的律师大军；即便他们完全理亏，被他们盯上的项目也往往无力承担辩护费用。
正因如此，这份请愿书在某种程度上令我惊讶。他们面对的是个超级诉讼怪兽，却向它发出“亲爱的甲骨文……我们敦促您将该商标释放至公共领域”的请求。你可知道诉讼狂魔会如何应对？他们会找人工智能在亚马逊写本《Javascript: as She Is Spoke》垃圾书，只为死守商标权。此前他们毫不在意，但既然有人指出漏洞，他们定会不遗余力地证明自己仍在使用该商标。
不过话说回来，或许公司内部有人在意企业形象，乐意借此改善科技圈的观感…
> 他们会让AI在亚马逊写本《Javascript: as She Is Spoke》垃圾书，只为死守商标权。
我虽非法律专家，但这恐怕不足以维持商标权。
请愿书本质是“我们先礼貌请求，避免法律程序的麻烦和开销”。目前商标无效程序正在推进，但甲骨文公司正进行不合逻辑却也意料之中的抗辩。
我只是拿这个举例说明最低限度要求。他们完全可以花点功夫写个简陋的JavaScript调试器之类的东西。
不过我也不是律师，只是猜测。我知道甲骨文手段不光彩，一旦法律挑战就会动用影响力。不确定用新“产品”回应挑战是否足以重置时效。希望法官能识破他们的伎俩。
正因如此法院不受理假设性案件。必须有人实际受损才能证明真实危害。
甲骨文是否曾用JavaScript商标起诉过他人？若有先例，这份请愿才具价值。
除非Demo就是案例，否则这更像是营销项目。而且效果显著，值得称赞。
商标法本质上就是处理假设性问题的。商标存在的意义正是防止潜在混淆引发的理论损害——这两者都不需要证明其真实性。
本案中，甲骨文持有的商标反而造成了比无商标状态更大的混淆，因此删除商标在道德上是正确的。而鉴于甲骨文并未实际行使该商标权，从法律角度看也是正当的。
依我之见，这不过是争取更好舆论的前奏。“我们提交了删除JavaScript商标的请愿书”听起来远不如“我们收集了10万签名致函甲骨文却只得到沉默，现在正式向美国专利商标局提交请愿”有分量。这也是寻找公益法律顾问或资助请愿者的绝佳机会。
问题在于诉讼的阴影始终存在。
另一关键点在于普遍认知(需引用来源)表明：若企业未积极维护商标权，一旦遭遇诉讼挑战往往难以为继。当然，这种普遍认知也可能有误。
现阶段我将假定：在商标名称后添加“-Script”即可自由使用该名称。
JavaScriptScript？
JavaScript-Script
Kleenex-Script
除非这种后缀版本本身已是注册商标，比如AppleScript。
iPhoneScript应该没问题吧？
Oracl3Script？
没错，这就是我要给基于LLM的律所起的名字。
反过来念：Scriptacle。
假设甲骨文真要走这条路，他们能告谁？除了苹果随Webkit发布的“JavaScriptCore”，官方场合根本没人用JavaScript这个名称。
据我所知他们已起诉Deno：https://deno.com/blog/deno-v-oracle2
编辑：看来我搞错了，详见下文
完全不知道这事！惊讶于它竟未引发更多关注。
我的失误，深入了解后发现Deno其实是试图撤销甲骨文的商标权，但后来得知“Rust for Javascript”开发者已收到甲骨文关于JS商标的停止使用通知，这可能促使Deno转向起诉甲骨文。
> 他们会起诉谁
随心所欲。割草机照常工作。
真正好诉讼的公司是Deno。他们一时兴起提起诉讼，发现准备严重不足后，竟向公众募资开展法律行动——而这场诉讼最终将使这家营利性、风险投资支持的公司受益。
这场私人恩怨很可能导致社区无法使用JavaScript名称。无人应支持此举。
你的评论显得极其混乱。
1. 甲骨文才是真正的诉讼狂魔。我最经典的例子是他们曾起诉一位教授，只因对方发布了对其数据库不太光彩的基准测试报告：https://danluu.com/anon-benchmark/ 谁能阻止他们起诉任何未经授权使用JavaScript名称的行为？这正是Deno试图防范的风险。
2. Deno提交的是商标撤销申请，而非主张自身权利。此举将使该名称回归公共领域。
从这两点事实不难看出，任何使用JavaScript的公众成员都应支持此举——无论他们对Deno公司持何种看法。
> 这场私人恩怨很可能导致社区彻底丧失使用JavaScript术语的权利。无人应当支持此举。
若非甲骨文的诉讼狂热，为何会演变至此？
嗨，拉里·埃里森！要帮我修剪草坪吗？
你拼错单词的事实简直滑稽至极。
JavaScript本就是更优的命名，而营销决定一切。这让我想起Java的POJO概念——原本是无人问津的简单模式，直到有人给它冠上花哨名称才流行起来。
ECMAScript是个糟糕透顶的技术名称。与其叫这个，不如干脆叫ACMEScript——毕竟用它开发的感觉就像威利·E·科约特在追兔子…
ACME其实更合适，因为你能在5个工作日内说出来或读出来。
我听过有人戏称它为“湿疹脚本”。
ECMAScript这个名字糟透了，比谷歌Bard还难听。
听起来像湿疹——用皮肤病命名编程语言实在不是明智之举
当然我对湿疹患者并无恶意
POJO是我最爱的缩写之一。POTS和COTS也是。
POTS = 普通老式电话系统 COTS = 现成商用产品
> POTS = 普通老式电话系统 我80年代在纽约电话公司工作多年，当时都称它为“普通老式电话服务”而非系统。不过现在纠正也没什么意义了！
我的理解基本正确！
我认为服务是由系统提供的。
我90年代末在中大西洋地区以电信技术员身份入行，可以证实当时确实如此
> 开发体验简直像威利·E·鼬鼠在追逐灰狼，干脆叫它ACMEScript算了…
就算换个名字，体验也一样糟糕。
这不过是个名字，谁在乎呢？
> 这不过是个名字，谁在乎呢？
这实在极具讽刺意味——JavaScript之所以得名，恰恰是因为人们确实重视名称。Netscape/Sun公司正是借势Java的成功来推广JS，因此尽管它与Java毫无关联，仍将其命名为JavaScript。
干脆叫“杰斯”吧。反正大家都这么叫。
EMCA -> ECMA
确实。说实话这也正是“Javascript”更人性化的原因之一。
但它不够友好的原因之一，是很多人误以为它和Java有关。
欧洲-加拿大-墨西哥协定？
“轻松取消”？扯淡！
> 因为实际使用中，这不就跟“Kleenex”(纸巾品牌名)一样吗
或许吧。这正是挑战要探究的问题。
> 人人都知道
并非人人皆知。学习JavaScript的人并不了解。事实上他们必须掌握这个概念。而根据我的经验，多数学习资源根本不提及，更别说系统讲解了。我花了很长时间才理解ECMAScript是什么，以及它与JavaScript的关系。而我为此付出的努力…真希望当初不必如此。
所以不，并非人人都知晓。
ECMAScript:JavaScript :: 某位大人物:伏地魔
对大多数人而言，这可能确实无关紧要
不如都叫它ECMAScript吧。
上次讨论时曾提出“WebScript”作为替代名称。(类似WebAssembly、WebSockets、WebRTC等)
https://news.ycombinator.com/item?id=45297066
我非常喜欢“WebScript”这个名称，但人们会将其缩写为“ws”，这会让我每次看到它时都联想到NPM的WebSocket包[0]！
[0] https://www.npmjs.com/package/ws
虽然这个概念很棒，但必须向后兼容JS缩写，这样“node.js”或“react.js”这类项目名称才合理。
说实话WebScript听起来挺不错
绝妙创意。远胜于“ECMAScript”
我个人最爱“JayScript”这个名字。
难道不是JScript[0]？或是用J[1]编写的脚本？
—
[0]: https://en.wikipedia.org/wiki/JScript
[1]: https://en.wikipedia.org/wiki/J_(programming_language)
我推荐这个
DoobieScript
WebScript就挺好！
WebScript似乎确实可行。尤其若能与ECMAScript规范重大更新同步推出
别把割草机拟人化。
背景说明：
> 切勿陷入将拉里·埃里森拟人化的陷阱。你该像看待割草机那样看待拉里·埃里森。你不会把割草机拟人化，它只是割草而已——把手伸进去就会被切掉，仅此而已。你不会想“哦，割草机讨厌我”——割草机根本不在乎你，它不可能恨你。别把割草机拟人化。别在甲骨文问题上重蹈覆辙。——布莱恩·坎特里尔 (https://youtu.be/-zRN7XLCRhc?t=33m1s)
专程为这个而来。不负所望。
问题解决，其实没那么难。
TS商标归微软所有。
这无异于从火坑跳进油锅，实非良策。
正式命名为ES2026，任由他人贬损微软商标——毕竟他们仍会将该版本及后续称为TS。
…届时我们将重演Java时代的API战争^H^H^H^H诉讼风波。
那不是版权问题吗？我以为争议焦点在于谷歌重写Android版Java时涉嫌抄袭甲骨文的API设计。
如果有人抄袭微软语言并命名为“TypedWebBrowserScriptbutFree”，微软不也会这么做吗？
https://github.com/microsoft/TypeScript/blob/main/LICENSE.tx…
该许可采用Apache 2.0协议。凭借商标权，他们可以禁止他人将产品命名为TypeScript，但根据许可条款，他们无权阻止他人复制、修改并分发新版本(前提是新分发者符合许可条件)。
那和谷歌的情况一样了。开源语言的名称/标识商标所有权真的有那么重要吗？
这正是问题的核心：JavaScript是开源语言，而他们不喜欢甲骨文持有其商标权。
哎呀。暴露自己没读原文了。
有效的JS代码往往在TS中无效。将非微量JS代码复制到TS时，通常需要修改才能运行。当人们说TS是JS的超集时，这只是语法超集的学术定义，实际并不成立。
非穷举示例：
我见过太多试图保留JS编码风格却又想让编译器别发火的怪异TS代码。明明直接声明类型就能解决的问题，却要写上百行类型推断代码。
感觉多数人使用 TypeScript 并非出于个人选择，而是被他人决定的
即使从语法层面看，TypeScript 也不是 JavaScript 的超集：https://anemato.de/blog/js-to-ts
所以这是“氯化钠”问题啊。噢我也遇到过这种情况，连这篇文章都眼熟，大概是因为我谷歌过错误提示
或者干脆两者都删了，改用Dart。
啊对，退化式解决方案
题外话：今年我为了给游戏写模组才学了 Lua，或许因为很久没用动态语言了，但 Lua 确实感觉就是 JavaScript 当初想实现的样子。两者都采用类似映射的数据结构处理几乎所有内容：整数键使其像数组，函数值使其像对象。但Lua通过
for ... in循环中的显式函数调用，避免了后期需要额外构造来按顺序遍历数组(或被迫手动遍历数字而非数组本身)。Lua的模块系统让我联想到Node的exports机制(尽管如今JavaScript已存在其他导入导出方式)，而JavaScript在ES6之前采用的面向对象模型中，原型机制的强大功能是否值得增加模块系统带来的额外复杂性，对我而言并不明显。我认为Lua基本上已经解决了JS近年来需要添加大量新特性才能实现的大部分功能。我想很多人早就意识到这一点，但至少就我个人而言，即使清楚JavaScript试图修复的缺陷，也未曾意识到已有成熟语言的设计能解决其中大部分问题，且其功能范围并未超出JavaScript的目标(例如 Python具备完整的基于类的面向对象特性)，或至少在表面上差异显著(例如某种Lisp变体——我记得早期网络时代曾讨论过这种方案，但推广可能面临更大阻力)。这应该很容易实现，毕竟世上根本不存在用JS编写的遗留代码。
没错，这才是务实可行的解决方案。
不如彻底停用JavaScript或大幅限制其使用。是时候回归现代硬件上能瞬间加载、不泄露用户信息的简洁网页了。JavaScript让网络追踪变得过于容易。
这有何必要？现状有何不妥？作者并未举例说明甲骨文公司曾因他人使用JavaScript(tm)名称而采取威胁手段。
他们引用了某篇博客文章的示例：https://www.reddit.com/r/programming/comments/14vnipl/rust_f…
这个示例确实已有两年历史。我同样未能在文章中找到任何说明此举价值的论点。
但这不就是个有效的示例吗？
有人只是想分享自己的Rust+JavaScript知识，却收到了停止令。这显然不理想。
既然他们未更改名称，说明法律诉讼已失败。那我们为何在意？
法律风险本身就令人却步。不过我其实无所谓。
我认为这主要是Deno的营销手段。
没错，我也认同这个解释。
问题在于FUD(恐惧、不确定性与怀疑)。某公司员工被告知必须等待法务部门批准某个开源项目或计划——仅仅因为项目名称中包含JS字样，而他的上司听说存在商标问题。于是热情消退，创意被搁置。类似的FUD事件可能已发生数千起，我们无从知晓，却导致许多优秀创意未能落地。
我们确知的一个典型FUD案例是：规范文档本身未采用其所定义语言的名称作为标题。这不仅让初学者在学习Web平台时陷入困惑，也使资深开发者难以解释概念，更普遍地造成了困扰。复杂性、混乱、疑虑、停滞——由此而生。
消除法律层面的FUD是值得推崇的事业。若此举同时能为Deno带来营销效益，我亦乐见其成。
深有同感！多数人未意识到有多少企业会因此妥协。实际进入诉讼程序的案例寥寥无几——诉讼风险巨大且耗资惊人。企业利润驱动的逻辑决定了这场斗争几乎毫无价值，放弃抗争转而采用竞争对手的技术才是更轻松的选择。
日期应为[2024]。“邮戳”显示为2024年9月16日。
顶部的更新列表显示：他们已提交撤销商标的申请，而甲骨文则申请驳回该撤销请求。
我认为是因为2025年12月2日的更新才被发布，当时甲骨文提交了驳回请求。
编辑：我竟把日期看错了，他们的回应其实是2025年2月，所以这内容相当陈旧。
该申请被部分驳回，Deno获准修改申请书(但据我所知尚未提交修改版)。初期有过毫无价值的证据开示，现已颁布保护令允许甲骨文提交不愿公开的信息(如商业机密)。此举发生于2025年11月初，案件仍在审理中。
https://ttabvue.uspto.gov/ttabvue/v?pno=92086835&pty=CAN&eno…
真希望JavaScript别再当个被遗弃的商标了。
猴爪的手指开始蜷曲
他们居然妄想能对 Oracle 提出法律抗辩，真是天真得可爱。
“若不采取行动，我们将向美国专利商标局提交撤销申请以挑战贵方所有权。”
那你们就尽管去告啊。你们这封可爱的信根本改变不了什么。
他们早就在一年前这么做了：
https://deno.com/blog/deno-v-oracle
这帖子都过期一年多了。
这毫无意义。甲骨文不是民主机构，而是台割草机。
这不取决于甲骨文，而是美国政府(USPTO)的决定。
你完全可以论证美国政府同样不是民主机构，而是台割草机…不过我扯远了。
“我死了”，草
这让我笑得比该笑得多。谢谢。
干脆别再叫它“JavaScript”了。“JS”明明就在眼前。
说得对。你上次听到HTML被称作“超文本标记语言”是什么时候？上次听到CSS被称作“层叠样式表”又是什么时候？我们该停止说“JavaScript”，彻底改用JS。
YavaScript
是时候 重命名 JavaScript了。
他们能放弃JavaScript商标而不威胁Java商标吗？
这恐怕才是核心问题。许多开源项目因在名称中使用相关商标而陷入困境。命名如OpenFastFirefox或iPhoneScript会引发大量商标纠纷。
这封信非常软弱。甲骨文正在商业中使用该商标，且2019年的商标样本在未被积极推翻前应视为有效。甲骨文不收取名称使用许可费的事实无关紧要。将JavaScript命名为“JavaScript”属于命名性使用，甲骨文若试图针对此类真实描述性使用采取法律行动，将因命名公平使用原则而失败。
想问问甲骨文、谷歌和微软这类分别持有JavaScript、Go和TypeScript商标的公司：拥有这些商标对你们究竟有什么价值？
我唯一能想到的情况是有人另创语言却命名为JavaScript、TypeScript或Go，并盗用相同标识——但这种情况下开发者社群无需律师介入就能有效解决问题。
瞧瞧微软在90年代如何试图劫持JVM。我认为最大的担忧在于：有人会开发出“基本兼容”的产品——实际上并非100%兼容——却试图将其包装成原版产品，而它本质上并非原版。
根据其他评论中提及的甲骨文起诉Deno的案例，至少对甲骨文而言，答案显然是“能够起诉他人并从中获利”。
即便情况并非如此，我认为问题的一部分在于：即使商标本身从未创造任何价值，企业维持其有效性也几乎无需成本(除非有人试图使其失效，届时才需要投入资源进行维权)。可以说，最初建立商标的成本本身就足够低，以至于这类规模的企业根本没有理由不建立商标；他们本就有律师团队，申请商标对他们而言并非异常之事，因此多申请一项的边际成本并不高。
值得思考的是，你所提到的“他人复制名称的风险微乎其微”这一观点，是否对非开发者而言同样显而易见。开发者认为显而易见的事，律师未必能看透。归根结底，这类决策往往由企业法务团队主导。若缺乏具备足够影响力推动此事的决策者(比如高管层)，即便担忧具有现实可能性，只要理论上存在合理性，也可能被忽视。
谈及JavaScript的演进——我正在开发音乐播放器(muz11.com)，其进步之大令人惊叹。Web Audio API、用于锁屏控制的MediaSession、通过requestAnimationFrame实现的流畅动画…全部在客户端运行，无需框架，仅凭原生JS即可实现。三十年前这需要桌面应用程序，甚至可能需要唱片公司签约。
讽刺的是，比起摆脱JavaScript商标束缚，我们更该挣脱框架更迭的桎梏。如今平台本身已具备惊人的能力。
> 三十年前这需要桌面应用程序，可能还得签唱片合约。
那也挺好的。
直到你得把预付款还给唱片公司。
或许也该找个比“湿疹脚本”更合适的非商标名称了。
真希望我们能彻底抛弃JS，转投更理性的技术。
那会是什么？
设计成可编译的目标语言，这样大家就能随心所欲使用任何编程语言。
说真的，JS在常见应用场景里确实是最佳选择
Lua
赞同(虽然永远不可能实现)。
就叫JoyScript吧，这样缩写还是JS。至少名字能带来些许欢乐，哪怕语言本身不尽如人意。
当初指定可注册商标的名称本身就是个错误。
他们早有预见，才将规范命名为ECMAScript。
这让我想起甲骨文在JRE(Java运行时环境)安装程序中故意植入间谍软件(Ask工具栏)的恐怖岁月——无数企业管理员和开发/测试人员不知情地将其安装到数百万台电脑上。
若我没记错，甲骨文从未就这次突然劫持(篡改了数百万IT从业者信赖的可执行文件)及恶意行为(事前未作任何说明)道歉。
这场灾难无疑唤醒了众多开发者和企业，促使他们摆脱对Java的依赖。
虽然我完全认同这种观点，但存在无数理由表明这种情况永远不会发生。与甲骨文打交道二十余载，我深知他们与客户之间掠夺性的关系。他们会死守这个商标权，企图从中牟利。
迟早他们会找上门——目标很可能是那些产品或服务无法脱离“JavaScript”一词描述的科技公司。届时他们将提供“便利”的商标授权协议：每年5万美元的使用费。
当年他们对Java也玩过这套把戏，当时更容易得手，毕竟Java比商标更有分量，但套路永远如出一辙。https://www.reddit.com/r/sysadmin/comments/165kzxg/oraclejav…
随着甲骨文公司债务问题日益严峻，该公司似乎越来越可能将该商标作为武器来对付其他公司——尽管此前对该词汇几乎不感兴趣。https://economictimes.indiatimes.com/news/international/us/w…
我宁愿为浏览器创建一种全新且更优秀的语言。
就像Dart和Dartium浏览器那样
Dart看起来不错，但看到像{foo: 1}这样的JavaScript示例在Dart中的对应写法，我还是更倾向用JavaScript
每天都为Dart未能获得更大普及而惋惜。这确实是门优秀的语言，还能编译为AOT。
😮 有人早想到这点了吗？/s
原始语言本该命名为CoffeeScript。这样我们宇宙里的CoffeeScript就能叫JavaScript了——直到主流浏览器完善工具链并改进CoffeeScript规范。
试想若将这番精力用于解决更紧迫的问题——比如近期又爆出的安全风波，或是那些人人依赖却总在关键时刻掉链子的超负荷维护者。
干脆叫JS好了，大家都懂这名字，所有标识都用它因为够简短。我们早就有个名字极简却广受欢迎的语言(Go，虽然拼写容易出错，但照样活得好好的)。
JS社区能否组织起来解决这些问题，实际上可能取决于这场看似辅助的运动所能影响的真实社会资本。
> Go——这个名字不篡改就很难搜索
别提TypeScript了。直到最近我搜索时还得用全称
说得对，不过就是一群无所事事的喷子罢了。
>想象若这股精力用于解决更紧迫的问题
你是暗示Ryan Dahl至今的贡献不够理想吗？
真有人觉得他们会收到信件？哪种渠道更可能被专业人士阅读？纸质信函还是网页？
Deno在营销方面做得相当出色：他们还专门制作了精彩的JS发展史专题页。
但就像这次JS商标事件一样，他们总把自己塑造成整个JS社区的代言人与先锋，这种姿态既误导人又显得夸大其词。
下文提及的时间线网站(链接见后)也存在同样问题：它逐渐将焦点从JS首个版本、XMLHttpRequest创建等事件，转向Deno里程碑，仿佛这些事件具有同等影响力：
https://deno.com/blog/history-of-javascript
这种做法显得不够诚实，似乎刻意引导外界认为Deno已成为默认服务器运行时——这显然与事实不符。
读到这里不禁想起Manu Cornet绘制的甲骨文组织结构图：https://www.globalnerdy.com/2011/07/03/org-charts-of-the-big…
实际标题应为：“甲骨文，是时候解放JavaScript了”
干脆直接叫JS，让商标权见鬼去吧。
我看Deno团队是没法继续做生意了，干脆转移视线，而不是向我们推销为什么该用Deno而非Node.js。
任何理性之人都会认同，甲骨文持有该商标对自身产品毫无裨益。除了偶尔施压外，他们根本得不到任何好处。
别低估施压手段的威力。看看当前美国政府就知道了。
20万美元中的4.3万美元。
在我看来这很合理，甲骨文似乎并未使用该商标。
但同时，甲骨文持有商标会带来什么后果？为何这成为问题？
官方名称是ECMAScript。或许该放弃“JavaScript”了。
为何到了2025年，我们仍无法为浏览器交付静态类型的高性能语言？
因为每次有人提出这个想法，紧接着就会出现“用哪种语言？”的争论，直到大家精疲力竭放弃。
这正是WebAssembly成为正确答案的原因。
我虽是静态类型语言的拥趸，但将静态类型代码作为独立产物交付，似乎会丧失所有优势。
对用户而言，开发工具控制台里显示的是运行时错误还是“编译时”错误有何区别？对他们来说，页面就是无法正常工作。
静态语言在开发阶段进行编译时具有优势，因为开发者能及时响应诊断结果。因此，使用静态类型语言开发、预先编译代码再交付给用户的做法更为理想——这正是当前WebAssembly的实践模式。
如今Rust通过WebAssembly运行效果相当出色。持续优化Web API/WebAssembly/语言运行时的互操作性，似乎是条明智路径——它能让开发者在共享Web API基础上自由选用偏好的语言。
Dart是专为浏览器设计的高性能静态类型语言。曾短暂支持在Chrome浏览器中运行Dart作为JavaScript替代方案，但后来转而选择转译为JS… JavaScript本身已是严格类型且安全的语言，但动态特性使其难以优化。因此转译为JS的决策颇为奇怪。
因为各方对标准缺乏共识，而厂商缺乏动力，最终将大部分浏览器开发外包给了谷歌。
> 为何到了2025年我们仍无法为浏览器交付静态类型的高性能语言？
具体是哪种语言？
开发者总是高高在上，若历经多年尝试各种方案仍未实现，或许说明这并非世界所需？
我不想要网页语言采用静态类型。这是从Java和C++转过来的开发者想要的。JS和Python没有它照样流行起来。
而且如果你真想要，还有TS可用
是时候让浏览器直接支持TypeScript了
改名叫“Jotascript”(读作Jot-a-script)。
或者干脆叫JotScript。
javascripts这个名字太蠢了
行吧那就改名。你好，CliffRichardScript
又来了
切记甲骨文是最邪恶的科技公司之一，拉里·埃里森就是典型反派。甲骨文CEO卡茨近期宣称：“我们对使命毫不妥协，对以色列的承诺无人能及”，并表示“若对方不认同我们支持以色列国的主张，或许我们并非合适的合作伙伴”。
我曾多次强调：我们应当彻底摒弃JavaScript这个名称。这个命名从诞生之初就是错误的选择。
多年来它引发的混淆已让人们错误地将其与Java关联。我推测这种关联性正是甲骨文不愿放弃该名称的根本原因。
我本想建议回归网景拉拢太阳公司前的原始名称LiveScript，但该名称已被挪用。
另取一个含J的名称或许最不痛苦。JScript已永久与微软糟糕的IE实现绑定。我提议“JaScript”——发音近似JavaScript，但带拖腔且保留“JS”。
天啊，必要时我甚至愿意称它为ECMAScript。虽然不情愿，但总比“JavaScript”强。
我认为这将在未来四年给LLM带来诸多意想不到的后果。
“JavaScript”会分解为2个标记(BPE)。“ECMAScript”则分解为3个令牌。这倒无伤大雅。
但真正的代价不在训练阶段——而在推理环节。每次LLM需要协调“ES6”与“JavaScript”的差异、解释命名规则，或处理“用户说JavaScript但文档称ECMAScript”的矛盾时——都会产生隐性的思维链开销。这些都需要额外的澄清令牌。
粗略估算：全球每日约3.76亿次与JS相关的LLM查询。约30%会触发澄清开销。这意味着每日额外消耗约50亿令牌，每年约1.85万亿令牌。
按每令牌推断成本约0.000025千瓦时计算，年耗电量约46吉瓦时。
每年约2.3万吨二氧化碳。基于LLM使用量粗略增长及术语在四年内持续存在，四年累计约20万吨——此处估计可能有误。
数据来源
令牌计数：OpenAI tiktoken cl100k_base编码器 25亿ChatGPT日查询量： Sam Altman, 2025年7月[1] 每日大型语言模型交互总量约47亿次：综合ChatGPT+Gemini(月活跃AI概览用户2亿)+Copilot+Claude+其他[2][3] JS开发者占比62%： Stack Overflow 2024年调查[4] 8%查询与JS相关：基于语言普及率的个人估算30%澄清率：个人估算——可能偏差较大能量/令牌：约0.000025千瓦时(综合Luccioni等与Patterson等推断估算[5])
二氧化碳排放：0.5千克/千瓦时(全球电网平均值)
[1] techcrunch.com/2025/07/21/chatgpt-users-send-2-5-billion-prompts-a-day [2] demandsage.com/chatgpt-statistics [3] sqmagazine.co.uk/chatgpt-vs-google-gemini-statistics [4] survey. [5] arxiv.org/pdf/2211.02001 (BLOOM碳足迹论文)