服务器端 JavaScript 会起飞吗？哪种实现最稳定？[已结束]

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

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

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

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

所以不，我不认为它会起飞。

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

我个人使用 ASP 在服务器端 JavaScript 中做了一个完整的网站。我发现它非常有趣，因为我能够重用一些好的代码。这包括：

• 参数验证
• 对象建模
• 对象传输

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

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

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

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

为什么要处理 Javascript 中的东西，如果可以的话 在PHP或 ASP.NET 中处理它 专为此任务而设计？

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

Steve Yegge 在博客中谈到了将 Ruby on Rails 移植到服务器端 JavaScript 上，作为 Google 内部的一个项目（“Rhino on Rails”）。他这样做是因为他喜欢 Rails，但 Google 不允许使用 Ruby。

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

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

这也是为什么 JavaScript 需要付出如此多的努力来使其智能化并添加现代功能的原因。如果整个浏览器市场有可能放弃 JavaScript，取而代之的是专为这项任务而设计的东西，我相信他们会的。就目前而言，Javascript 具有奇怪的基于原型的对象、一些简洁的函数式编程功能、有限且古怪的集合以及很少的库。

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

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

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

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

现在，使用 JavaScript 似乎是一个奇怪的想法，但回想一下 PC 何时开始出现。我所知道的每个书都在打字他们的新 Trash-80、Commodore64、Apple [在游戏或 BASIC 中的简单应用程序中打字。

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

JavaScript 可以像 BASIC 对 PC 所做的那样，用于基于 Web 的服务器端应用程序。

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

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

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

Flash Media Server 是使用服务器端操作脚本编写脚本的，该脚本实际上只是 javascript （ECMAScript）。所以，我经常这样做。事实上，我一天中的大部分时间都在与SSAS打交道。

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

服务器上对 JS 的支持越来越强，框架的数量越来越大，甚至越来越快。

就在最近，serversideJS 小组成立了。他们有很多聪明的人，他们已经在服务器端JS上工作了多年（其中一些超过10个）。

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

---

对于那些说“你为什么选择JS而不是Java或任何其他语言？”的人 - 你应该阅读Crockford的这篇重新介绍，忘记DOM - DOM非常丑陋，但这不是JS的错，JS也不是DOM。

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

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

我认为服务器端 Javascript 是有保证起飞的。这只是时间问题。

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

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

• [HTML全
• CSS的
• Java脚本
• 服务器端语言 J2EE/ASP/Ruby/Python/PHP
• SQL格式

我没有听说过 Javascript Server 框架的当前状态，除了它们大多不完整。

我看到服务器端js将在未来的应用程序中提供相当大的优势。为什么？可以离线的 Web 应用程序、客户端数据库存储、Google Gears 等......

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

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

有说服力的？

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

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

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

到目前为止，它运行速度很快，除了它的出色可用性之外，我没有什么可抱怨或后悔的 以及我在过去 4 年中一直享受的可扩展性，直到这一点 我正在将我的 ASP Classic 代码更改为 javascript 代码。

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

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