为什么服务器端JavaScript并不被广泛使用?

13

我们知道JavaScript是前端中最流行和广泛使用的语言之一。我想知道为什么它在后端中没有被广泛使用?


8
这不是主观的,也不是争论性的。这是一个有着真实答案的有效问题。 - Assaf Lavie
3
第一次看到<script type="text/javascript" runat="server">标签上的runat="server"属性,我简直想吐。 - hunter
2
@Assaf Lavie:毫无疑问,这是主观的,没有一个具体的答案可以解释为什么JavaScript在服务器端不太流行。这个问题应该在程序员社区讨论:http://programmers.stackexchange.com/ - Orbling
2
拥有多个答案并不意味着它是主观的。如果你除了语言之争和个人偏好之外想不出任何有意义的理由来解释为什么JS没有用于服务器端,那么你可以忽略这个问题,不参与讨论。然而,我认为在服务器端某些语言占主导地位而其他语言没有得到广泛应用的原因是明确且客观的,我并不认为关闭这样一个问题是合理的,只因为它可能会吸引一些主观的、源自个人偏好的回答。 - Assaf Lavie
1
服务器端 JavaScript 没有任何问题。只需过滤掉答案中的狂热主义,你就会得到 JavaScript 作为可能的服务器端语言。我使用服务器端 JavaScript 编写了完整的数据库 / Ajax 驱动的网站、一个庞大而复杂的诊断研究问卷(hta)和服务器管理工具(诚然,用于 Windows 服务器),没有遇到任何问题。程序员是一种保守的物种,许多人将继续将 JavaScript 视为“不是真正的语言”。我想说的是,请凭自己的判断力来决定。 - KooiInc
显示剩余2条评论
7个回答

12

由于谷歌的V8引擎,它变得越来越广泛使用。看看Node.js。我认为以前效能不佳限制了它的效力。

Node.js让你以大多是面向对象编程的方式在眨眼之间编写多线程自定义 Web 服务。我想你会发现,在后端上使用JavaScript只是刚刚开始。

我认为唯一阻止它发展的是 - 正如其他人所说的那样 - 缺少一个整洁打包和标准化(至少对于Linux)的即插即用解决方案。这个解决方案需要被主要托管公司采纳,并作为其产品提供的一部分。如果这发生了,我认为你会发现它将在后端服务器领域迅速发展。

自1998年以来,Microsoft就提供了使用“JavaScript”(也称JScript)编写后端系统的功能,使用它的ASP提供。您仍然可以使用JScript开发ASP.NET应用程序。所以这并不新鲜。我认为它没有被广泛用于ASP或ASP.NET应用程序的原因是VBScript是“默认”的,而C#似乎是更有经验的专业人士首选的语言。但除了公司政策限制开发人员使用单一语言进行企业开发外,没有任何阻止你使用JScript的东西。JScript之所以不被公司实体广泛使用的原因之一是因为它“似乎不再积极开发”。事实上,Microsoft从来没有真正面向开发者“推销”JScript,或者至少不像他们对C#和VBScript那样。所以我想这可能会拖慢它的发展。


2
我认为之前的糟糕曝光限制了它的使用。在其他服务器端机制也有严重性能问题的时候,它可用于服务器端使用,但人们并不特别使用它。Node.js 真是太棒了,而且观察到它可能会很快起飞。我已经多年在服务器上使用 JavaScript,只需使用一种语言就非常方便。 - T.J. Crowder
性能差不是理由,我编写过PHP、.NET(C#)、Perl和JScript,其中JScript的表现并不是最差的。 - KooiInc
添加了关于我认为阻碍它发展的评论,并证明它自1998年以来一直存在。 - sholsinger

6
JavaScript因为有大量的用户,而不是因为它是一种优秀的语言,在前端很受欢迎且被广泛使用。没有人会选择用JavaScript编写客户端代码,他们只是不得不这样做,因为每个浏览器都支持它。在后端,其他语言(如Java、PHP、Python、Ruby等)提供了JavaScript无法比拟的优势。
编辑:2022年,我因为这个答案获得了声望,这激励我重新审视它。十二年后,JavaScript在服务器端通常被使用,尽管在许多情况下它是一个编译目标而不是实际使用。Node.js引擎是实现这一点的关键。结合像TypeScriptPureScript这样的语言,你可以获得良好的性能和合理的开发者人体工程学。

1
事实上,CoffeeScript 是一种尝试避免在浏览器中编写(传统的)JavaScript 的要求。 - Nathan Long

5
我不是这方面的专家,但道格拉斯·克罗克福德在《JavaScript语言精粹》中说,JS之所以在浏览器中变得流行,实际上是偶然事件,而不是因为它的优点。
“JavaScript是一种有着更多糟糕部分的语言。它在极短的时间内从不存在到全球范围内被采用。它从未在实验室里经过试验和完善...当Java小程序失败时,JavaScript成为了默认的“Web语言”。JavaScript的流行几乎完全独立于其作为编程语言的特性。”
不同的浏览器对其实现方式不同,与具有标准解释器的语言相比,很难确定哪个是正确的。
正如克罗克福德的书所解释的那样,它确实具有良好的特性,而node.js可能会证明它非常适合服务器端开发。但到目前为止,在人们有选择的情况下,他们大多选择其他语言。

4

简短回答:因为有更好的替代品。

详细回答:因为它完全是解释性的(而且通常不太好 - 例如IE6),除了环境提供的内容之外,没有标准的I/O机制,语法松散导致代码难以验证,许多人发现基于原型的面向对象编程比基于类的面向对象编程更难处理。


1
因为它完全是解释性的... 没有一直跟上进展吗?"除了环境提供的机制之外,没有提供任何I/O机制"。那么,就像世界上其他所有语言一样。I/O不是语言特性,而是环境特性。"具有松散的语法,导致难以验证的代码"。语法并不松散。我同意使用富动态语言进行代码验证可能具有挑战性。 - T.J. Crowder
@TJ - 那个 Google 项目似乎是一个解释器,而不是编译器。我指的是它的标准实现中不包含 I/O,不像 C、C++、C#、Java 等语言。除非分号是必需的,否则我会将可选分号描述为一种宽松的语法特性。 - OrangeDog
我非常同意你对“分号插入”的愚蠢看法,你说得很对。,我希望他们在严格模式下修复了这个问题。V8基本上是一个JIT编译器,而不是解释器。事实上,它是一个优化的JIT编译器(最近是一个两阶段的热点分析和优化)。没有理由不能存储中间格式(Rhino就是这样做的;将JavaScript编译为Java字节码),语言除了要求允许动态构造之外并没有阻止它。 - T.J. Crowder
2
一种语言既不是解释型也不是编译型。它只是存在的。它是一组抽象的数学规则。编译和解释是特定语言实现的特征。除了极少数例外,几乎所有现有的JavaScript实现都是编译的。V8、IronJS和DMDScript是“完全编译”的(意味着它们总是编译,甚至没有解释器),Nitro(Safari)、TraceMonkey/JägerMonkey(Firefox)、Chakra(IE)、Carakan(Opera)和Rhino既可以编译又可以解释。只有JScript(古老的IE)是“完全解释”的。 - Jörg W Mittag
显然我在这方面没有跟上。谢谢你提供的信息。 - OrangeDog

2

我认为这只是历史的偶然。Javascript诞生于Netscape作为一种客户端语言,从未发生过转变。

与今天流行的服务器端Web语言相比,我认为最明显的区别是Javascript没有内置电池。它没有标准库。

将其与Python、PHP、Ruby等语言进行比较,这些语言都拥有出色的标准库,使Web编程更加可接受。


吹毛求疵: 实际上,JavaScript 是作为一种既能在客户端又能在服务器端运行的网络脚本语言而诞生的。事实上,它最初被称为 LiveScript(而不是 NavigatorScript),是因为它作为 Netscape LiveWire 网络应用程序框架的脚本语言与 Netscape Enterprise Server 2.0 及以后的版本一起发布。尽管如此,我同意你的结论。使用一种连文件系统都无法读取的语言进行服务器端编程还是有些困难的。 - Jörg W Mittag

1
在服务器上,人们并不必须使用特定的语言,而JavaScript非常自由形式,因此代码变得难以维护。
这就是为什么最大比例的人选择其他东西。

0

我认为答案可能是,对于客户端来说好的并不总是对于服务器端来说好的。例如,JavaScript(通常指ECMAScript,也包括ActionScript)是一种非常宽松和宽容的语言,允许你做很多事情。在客户端,这通常不仅可以接受,而且也是首选。你经常希望你的用户界面尽可能平滑和宽容,以提高用户体验。

然而,在服务器端,情况通常是不同的,这就是为什么我认为主导那一侧的语言更加强类型和严格的原因。

还有规模的问题。适用于客户端UI应用程序通常较小的代码库的东西并不总是适用于服务器端,后者必须处理一系列在客户端中并不是主要关注的问题。例如性能、打包、可扩展性——这些对于服务器代码比客户端代码(通常)更重要,因此人们选择不使用JS进行服务器端工作是可以理解的。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接