本文适合关注Web技术历史脉络的开发者与爱好者阅读。
上世纪90年代的浏览器大战广为人知，微软的Internet Explorer与网景的Netscape Navigator在客户端市场激烈交锋。但鲜少被提及的是，两者在Web服务器端的竞争同样激烈。微软的武器是IIS及其ASP脚本，而网景的利器则是Netscape Enterprise Server（简称NES）及其独有的动态脚本技术——LiveWire，也就是我们今天要探讨的早期服务器端JavaScript（SSJS）。
（兼具浏览器和网页编辑发布功能的Netscape Communicator套件安装程序）
（NES 3.x服务器安装界面）
（NES 3.x服务器集群管理界面）
很多人知道，1995年5月，Brendan Eich花了十天时间创造了JavaScript的原型“Mocha”。但少有人知的是，据《JavaScript二十年》记载，他加入网景的第一个月其实是在服务器团队工作。因此，“Mocha”原型的设计也受到了服务器端需求的影响，例如采用字节码指令解析器、支持无限制的对象属性动态添加，这些特性都为后来在服务器上运行JavaScript埋下了伏笔。
（官方LiveWire示例代码中充满了动态属性赋值的风格，注意其使用的是早期的CR换行符）
（这种风格的代码甚至允许直接通过对象属性来更新数据库记录）
在网景与Sun公司联合发布JavaScript新闻稿的4个月后，1996年3月，网景推出了正式支持JavaScript 1.0的软件。除了面向消费者的Netscape Navigator 2.0浏览器，另一个重量级产品便是面向企业市场的Netscape Enterprise Server 2.0（NES 2.0）。
网景宣称NES 2.0是世界上第一个支持Java和JavaScript的工业级Web服务器。它分为两个版本发售：基础版（含LiveWire和Navigator Gold）售价995美元；专业版（含LiveWire Pro及Informix数据库运行时）售价高达1495美元。对比当年中国5569元的人均GDP，其价格之昂贵可见一斑。
（1995年12月4日的新闻稿，标题强调了28家行业巨头支持JavaScript作为Java的补充）
（1996年3月5日，网景发布NES 2.0的新闻稿）
30年前的“服务端渲染”技术
在NES服务器中，负责执行服务端JavaScript的组件被称为LiveWire技术，其对应的编程语言则以“Server-Side JavaScript”（SSJS）之名进行推广。该功能默认关闭，需要管理员手动开启。
（在服务器配置中手动开启SSJS支持）
LiveWire的语法并不复杂。在HTML文件中，只需嵌入 <SERVER> 标签，该标签内的JavaScript代码就会被服务器执行，并将运算结果动态输出到HTML中。这种模式，用现在的眼光看，不就是服务端渲染（SSR）的雏形吗？
（有趣的是，早期相关文档的封面上还出现了JavaScript的前身名称“LiveScript”）
<html>
<head>
<title> Hello World </title>
</head>
<body>
<h1> Hello World </h1>
<p>Your IP address is <server>write(request.ip);</server>
</body>
</html>
（一个典型的Hello World应用，在HTML中嵌入SSJS代码获取客户端IP）
为了适应服务器环境，NES 2.0的LiveWire增加了客户端JavaScript 1.0所不具备的专属接口：
- 文件操作对象（
File）
- 数据库连接与读写对象（
database），支持Informix、Oracle、Sybase、ODBC等多种数据库
- FFI（外部函数接口）：通过
registerCfunction注册外部库函数，并用callC调用
- LiveConnect技术：允许JavaScript代码直接调用Java包（JavaScript 1.1引入）
- 请求重定向功能
到了1997年的NES 3.0，LiveWire升级到JavaScript 1.2，并增加了更多服务器端功能：
- 数据库连接池（
DbPool）
- 邮件发送服务（
SendMail）
- 锁对象（
Lock），用于处理并发
- 直接操作HTTP响应头
2000年，网景与Sun合作期间发布了iPlanet Web Server 4.1，其JavaScript引擎升级为Mozilla.org的引擎，并支持了try/catch、in和instanceof等更现代的语法特性。
因“太像Java”而导致的失败
如此超前的构思，为何最终没有流行起来？
首先，LiveWire技术对开发者要求颇高，属于“易懂难精”。开发者需要手动管理锁（加锁/释放锁），极易引发竞态条件和数据库阻塞；当时的JavaScript在服务器端功能仍有缺失，常需借助Java进行桥接；Cookie和Session概念混淆，存在安全隐患；调试过程也异常繁琐，只能通过浏览器查看服务器端的执行结果。
（手动管理锁和数据库连接，增加了开发复杂度和出错风险）
（实现复杂功能时，不得不借助Java和CORBA等技术）
（原始的调试界面，体验并不友好）
其次，也是最致命的一点，是其独特的、模仿Java的发布流程。一个LiveWire应用必须先编译：开发者需要将HTML和JS文件通过专门的jsac编译器，打包成一个平台无关的字节码文件（扩展名为.web）。然后，才能将这个.web文件（连同可能需要的Java Class文件或动态库）部署到NES服务器上运行。
（使用jsac编译器将源代码编译成.web字节码文件）
（在管理界面中添加已编译的.web应用）
（管理已部署的LiveWire应用状态）
（帮助文档中明确指出NES服务器采用单进程、多线程模型）
熟悉Java的开发者立刻就能看出，这种“一次编写，到处运行”的编译部署模式，与Java的WAR包部署何其相似。这恰恰揭示了LiveWire团队当年的初衷：希望通过字节码来提升服务器端应用的加载与执行效率。
然而，正是以上种种设计，使得JavaScript原本应有的快速开发、灵活部署的优势，在NES服务器上因为这套过于“Java化”的托管方式而消失殆尽。
（Java圈内流传的经典调侃，讽刺跨平台运行中的各种调试难题）
随着网景公司的动荡，LiveWire技术也逐渐走向没落。最终，在2001年发布的iPlanet Web Server 6.0 / Netscape Enterprise Server 6.0中，官方正式放弃了对LiveWire/SSJS的支持，并建议现有用户将应用迁移至Java技术栈。
一个本想借助Java生态力量的服务器端JavaScript，最终因为过于模仿Java的形态，反而被Java所取代。网景的首次服务器端JavaScript尝试就此宣告失败，直到2009年Node.js的出现，才真正复兴了这一理念。
（iWS 6.0/NES 6.0的官方安装文档明确将SSJS/LiveWire列为不再支持的功能）
（迁移指南中提供的SSJS对象到Java类的映射关系，数据库部分需转为JDBC）
*（迁移指南详细说明了将SSJS应用重写为JSP的步骤，包括替换标签和语法）**
这段尘封的技术往事，不仅是一次失败的产品尝试，更是Web技术演进中一个值得深思的节点。它揭示了技术选型、生态定位与开发者体验之间的复杂关系。在云栈社区，我们持续关注技术背后的历史与逻辑，因为理解过去，方能更好地构建未来。
（未完待续）
发表于 2026-2-14 08:24:30
|
查看: 35|
回复: 0
