javascript - 服务器端 JavaScript 会起飞吗？哪种实现最稳定？

Question

有人看到服务器端 JavaScript 起飞了吗？那里有几个实现，但这一切似乎有点牵强（例如，“这样做是因为我们可以”类型的态度）。

我很想知道是否有人真的为服务器端编写 JavaScript，以及他们迄今为止的经验。

另外，哪种实现通常被认为是最稳定的？

score 12 · Accepted Answer

我喜欢阅读 Google 员工 Steve Yegge 的博客，最近我看到了他的这篇文章，他认为Mozilla Rhino是服务器端 JS 的一个很好的解决方案。这是一个有点草率的成绩单，你可能更喜欢看谈话的视频。它还提供了一些关于他为什么首先认为服务器端 JS 是一个好主意的见解（或者更确切地说，为什么他认为使用动态语言编写 Java 脚本是一个好主意）。我认为他提出的观点很有说服力，所以你可能想看看。

不久前，他还发布了一些关于动态语言的一般信息（他是动态语言的忠实粉丝），以防你想知道为什么要使用 JS。

score 5 · Accepted Answer

当您可以在专为此任务设计的 PHP 或 ASP.NET 中处理某些内容时，为什么还要使用 Javascript 来处理它？

也许是因为 JavaScript 是一种比这两者更强大的编程语言？例如，它具有一流数据类型的功能并支持闭包。

Steve Yegge 曾写过一篇关于将 Ruby on Rails 移植到服务器端 JavaScript 作为 Google 内部项目（“Rhino on Rails”）的博客。他这样做是因为他喜欢 Rails，但 Google 不允许使用 Ruby。

score 3 · Accepted Answer

在被 Google 收购之前，JotSpot使用服务器端 JavaScript 让您查询他们的数据库并显示您的页面。他们用Rhino来做这件事。CouchDB 使用服务器端 JavaScript 来创建其数据库的视图。

从这些示例中可以看出，在服务器上使用 JavaScript 的一个好方法是使用插件。使用它的原因之一是您可以创建一个非常孤立的沙箱供人们在其中运行他们的代码。此外，由于 JavaScript 作为一种语言的工作方式，您可以提供专门针对用户需要的任务的用户工具去完成。如果你做对了，用户不需要学习一门新语言来完成他们的任务，快速浏览一下你的 API 和示例就足以让他们上路。将此与许多其他语言进行比较，您就会明白为什么使用服务器端 JavaScript 来提供插件架构是如此诱人。

第二种流行的解决方案，可以通过像Jaxer这样的项目看到，是进行客户端验证的 Web 应用程序的一个常见问题是，由于 JavaScript 在浏览器中很容易绕过，因此必须再次运行验证服务器。像 Jaxer 这样的系统允许您编写一些可在服务器和客户端之间重用的验证功能。

score 3 · Accepted Answer

服务端对 JS 的支持越来越强，框架的数量越来越大，速度越来越快。

就在最近serversideJS小组成立了。他们有很多聪明人多年来一直在研究服务器端 JS（其中一些超过 10 人）。

该项目的目标是创建一个标准库，最终将允许 Web 开发人员在任意数量的 Web 框架和工具中进行选择，并在对其应用程序最有意义的平台上运行该代码。

对于那些说“你为什么会选择 JS 而不是 java 或任何其他语言？”的人。- 你应该阅读Crockford的这篇Re-Introduction并忘记 DOM - DOM 是超级丑陋的，但这不是 JS 的错，而且 JS 不是 DOM。

score 1 · Accepted Answer

似乎你们中的大多数人都被这个想法推迟了，因为 Javascript 的各种客户端实现有多么令人不快。不过，我会在做出判断之前检查现有的解决方案，因为请记住，没有特定的 SS/JS 解决方案与当前在浏览器中使用的 JS 实现相关联。Javascript 基于 ECMAScript，请记住，这是一个目前处于相当成熟状态的规范。我怀疑支持最新 ECMA 规范的 SS/JS 解决方案不会比使用其他脚本语言来完成任务更麻烦。请记住，Ruby 最初也不是为了成为一种“网络语言”而编写的。

score 1 · Accepted Answer

我什至从未听说过这个，但它让我觉得使用了错误的工具来完成这项工作。由于编程语言只是旨在帮助我们解决某些问题的工具。

当您可以在专为此任务设计的 PHP 或 ASP.NET 中处理某些内容时，为什么还要使用 Javascript 来处理它？

当然你可以用螺丝刀敲钉子，但是锤子效果更好，因为它实际上是为它设计的......

所以不，我看不到它起飞。

score 1 · Accepted Answer

好吧，几年前，普通的 ASP 支持 JavaScript 服务器端，而每个人都在他们的狗上使用 VBShiate。但我必须同意其他人的观点：JS 似乎不是这里的正确工具——而且我喜欢做客户端 JS :)

score 1 · Accepted Answer

我个人使用 ASP 在服务器端 JavaScript 中做了一个完整的站点。我觉得这很有趣，因为我能够有一些很好的代码重用。这包括：

参数验证
对象建模
物体运输

再加上更高级别的建模工具和代码生成器，我对那个项目很感兴趣。

不幸的是，我没有关于 perf 的数字，因为它仅用于 Intranet。但是，我必须假设性能与 VBScript 支持的 ASP 站点相当。

score 1 · Accepted Answer

有人看到服务器端 Javascript 起飞了吗？

尝试查看http://www.appjet.com一家提供托管 JavaScript 应用程序的初创公司，以了解您可以做什么。我特别喜欢这个学习过程，它轻轻地推动用户以最小的开销构建东西 ~ http://appjet.com/learn-to-program/lessons/intro

现在，现在使用 JavaScript 似乎是一个奇怪的想法，但回想一下 PC 开始出现的时候。我认识的每个书呆子都在用他们的新Trash-80、Commodore64、Apple ][输入游戏或 BASIC 中的简单应用程序。

对于年轻的黑客来说，今天的基础在哪里？

JavaScript 可以为基于 Web 的服务器端应用程序做一些事情，就像 BASIC 为 PC 做的事情一样。

score 1 · Accepted Answer

XChat 可以运行 Javascript 插件。
我有一些完全用 Javascript 编写的会计软件。
V8 有一个有趣的 IO 库：http: //tinyclouds.org/node/
CouchDB 是一个文档数据库，其中包含用 Javascript (TraceMonkey) 编写的“查询”。

考虑到这一点，我相信服务器端 Javascript确实起飞了。

score 0 · Accepted Answer

服务器端编程比客户端编程存在的时间要长得多，并且已经有很多好的解决方案。

JavaScript 得以幸存并变得流行，纯粹是因为开发人员在这件事上几乎没有选择——它是唯一可以与 DOM 交互的语言。它在客户端的唯一竞争来自诸如 Flash 和 Silverlight 之类的产品，它们的模型非常不同。

这也是为什么 JavaScript 受到如此多的努力来对其进行智能化和添加现代特性的原因。如果整个浏览器市场有可能放弃 JavaScript 并用为该任务设计的适当的东西来代替它，我相信他们会的。就目前而言，Javascript 具有奇怪的基于原型的对象、一些简洁的函数式编程特性、有限且古怪的集合以及很少的库。

对于小型脚本来说这很好，但对于编写大型复杂系统来说，它是一种可怕的语言。像 Firefox 和 Gmail 这样的东西（部分）是用它编写的，这对他们来说是一项英勇的成就，而不是表明该语言已经为真正的应用程序开发做好了准备。

score 0 · Accepted Answer

个人而言，我已经开发和使用自己的 JavaScript 框架大约 4 年了。

服务器端 JS 的好处是在 ASP Classic 中实现，您不需要安装任何其他插件或软件，此外我还在服务器上使用我的 javascript（客户端）框架，这让我可以享受相同的功能并在客户端和服务器端环境中证明了我的功能的性能。

不仅用于数据验证，还可以说 HTML 或 CSS 动态构造可以在客户端或服务器端完成，至少在我的框架中是这样。

到目前为止，它运行得很快，我没有什么可抱怨或遗憾的，除了它在过去 4 年中我一直享受的强大的可用性和可扩展性，直到我将我的 ASP Classic 代码更改为 javascript 代码。

你可以在http://www.laferia.com.do看到它的实践

score 0 · Accepted Answer

我认为服务器端 Javascript 肯定会起飞。这只是时间问题。

Mozilla、Google 和 Adobe 对 Javascript 有着如此多的既得利益，以至于将其从浏览器世界中驱逐出去需要奇迹。下一个合乎逻辑的步骤是将其移至服务器端。

这是朝着摆脱通常包括所有这些的互联网技术大杂烩迈出的一步

HTML
CSS
Javascript
服务器端语言 J2EE/ASP/Ruby/Python/PHP
SQL

我没有听说太多关于 Javascript 服务器框架的当前状态，除了它们大多是不完整的。

score 0 · Accepted Answer

Flash Media Server 是使用服务器端动作脚本编写的，它实际上只是 javascript (ECMAScript)。所以，我经常这样做。事实上，我一天的大部分时间都在处理 SSAS。

我讨厌它。虽然公平地说，其中一堆与我继承的（不太好）代码库有关，而不是与实际语言相关。

score 0 · Accepted Answer

我看到服务器端 js 将在未来的应用程序中提供相当大的优势。为什么？可以离线的网络应用程序、客户端数据库商店、谷歌齿轮等......

随着这一趋势，越来越多的逻辑正在进入客户端。使用适用于客户端的 ORM，并在服务器端使用另一个（无论是 PHP / Ruby / 其他），用两种不同的语言编写两次同步逻辑，用两种不同的语言编写两次业务逻辑？

在客户端和服务器端使用js并编写一次代码怎么样？

有说服力吗？

score 0 · Accepted Answer

0

Node.js 已经起飞并证明服务器端 JavaScript 将继续存在 =)

于 2012-09-23T16:02:09.863 回答

score -1 · Accepted Answer

我无法看到大多数开发人员克服他们对客户端 JavaScript 编程的厌恶。在选择 JavaScript 之前，我宁愿去 Java 做服务器端的东西。

javascript - 服务器端 JavaScript 会起飞吗？哪种实现最稳定？

17 回答 17

Related

Reference