何时以及如何使用服务器端JavaScript?

Occasionally I search for some JavaScript help and I come upon the term "Server-side JavaScript". When would you use JavaScript server-side? And how?

偶尔我搜索一些JavaScript帮助，发现术语“服务器端JavaScript”。什么时候使用JavaScript服务器端?以及如何?

My experiences of JavaScript have been in the browser. Is there a compiled version of JS?

我的JavaScript经验在浏览器中。有编译版的JS吗?

12 个解决方案

#1

There's the project Phobos, which is a server side JavaScript framework.

还有项目Phobos，它是一个服务器端JavaScript框架。

Back In The Day, the Netscape web server offered server-side java script as well.

过去，Netscape web服务器也提供服务器端java脚本。

In both of these cases, JavaScript is used just like you'd use any language on the server. Typically to handle HTTP requests and generate content.

在这两种情况下，使用JavaScript就像在服务器上使用任何语言一样。通常用于处理HTTP请求并生成内容。

Rhino, which is Mozilla's JavaScript system for Java, compiles JavaScript in to Java byte codes, which the JVM can choose to JIT. Other systems use other means for executing java script, even to the point that some are JIT compiling their java script internal codes.

Rhino是Mozilla的Java JavaScript系统，它将JavaScript编译成Java字节码，JVM可以选择JIT。其他系统使用其他方法执行java脚本，甚至有些系统正在JIT编译它们的java脚本内部代码。

I foresee that there will be more and more JavaScript on the server. When you're writing "thick" applications in JavaScript on the client, then you may as well be able to write your logic in JavaScript on the server in order to not have to make the cognitive leaps from one language to another. The environments will be different, but much of your code and knowledge will be shareable.

我预见服务器上将会有越来越多的JavaScript。当您在客户机上用JavaScript编写“厚”应用程序时，那么您也可以在服务器上用JavaScript编写逻辑，从而不必从一种语言跳到另一种语言。环境会有所不同，但是您的大部分代码和知识是可以共享的。

Finally, JavaScript is probably the singular language that has the most money pointing at it right now in terms of implementations. From Apple, Mozilla, Google, and even Microsoft as well as the efforts to make it an even more advanced language (i.e. basically a Scheme with Algol syntax sans macros).

最后，在实现方面，JavaScript可能是目前最赚钱的语言。苹果，Mozilla，谷歌，甚至微软都在努力使它成为一种更高级的语言(也就是说，基本上是一种没有宏的Algol语法)。

Most of those implementation are buried in the browser, but that's not to say that there's no value on the server side as well.

大多数实现都隐藏在浏览器中，但这并不是说服务器端也没有价值。

The tooling is the biggest place where JavaScript is lacking, especially on the server side, but if you consider something like Phobos, where you can debug your server side JavaScript in the IDE, that's a great advancement.

工具是JavaScript缺乏的最大的地方，特别是在服务器端，但是如果你考虑到像Phobos这样的东西，你可以在IDE中调试你的服务器端JavaScript，这是一个很大的进步。

Personally, I'm tossing JavaScript around in my applications like white paint. It offers cheap extensibility for very little cost and is a great enabler.

就我个人而言，我在我的应用程序中像白漆一样折腾JavaScript。它提供了廉价的可扩展性，成本很低，是一个很好的促进因素。

#2

It's not AJAX, unless people are using the term improperly. As its name suggests, SSJS is JavaScript that runs on the server, interpreted by a standalone (i.e., browser-independent) JavaScript engine, like SpiderMonkey.

它不是AJAX，除非人们使用不当。顾名思义，SSJS是在服务器上运行的JavaScript，由独立的(例如。JavaScript引擎，比如SpiderMonkey。

Why bother? Well, one area I currently see it underutilized in is in data validation. With SSJS you write one piece of code that then gets used on both the server and the client. Thus you get immediate user feedback from the client-side JS that will automatically match the data checking taking place on the server.

何苦呢?我目前看到的一个未被充分利用的领域是数据验证。使用SSJS，编写一段代码，然后在服务器和客户端上使用。因此，您可以从客户端JS获得即时的用户反馈，这些反馈将自动匹配服务器上正在进行的数据检查。

#3

Classic ASP was able to use JavaScript on the server, although most people used VBScript.

经典的ASP能够在服务器上使用JavaScript，尽管大多数人使用VBScript。

One compelling use of JavaScript on the server is as a complement to client-side data validation. For example, you might use the same JavaScript validation library on the client and on the server. This ensures you're using the same logic on the client as you are on the server, but (potentially) avoiding an unnecessary round-trip by pre-validating on the client side.

在服务器上使用JavaScript是对客户端数据验证的补充。例如，您可能在客户机和服务器上使用相同的JavaScript验证库。这确保您在客户机上使用与服务器上相同的逻辑，但是(潜在地)避免在客户端进行预先验证，从而避免不必要的往返。

Wikipedia lists a number of server-side JavaScript implementations here.

Wikipedia在这里列出了许多服务器端JavaScript实现。

#4

2013's NEWS

Node.js (see also at Wikipedia article) is a sucess, and its community is growing!

节点。js(参见*文章)是一个成功的例子，它的社区正在成长!

MongoDB (at server), Chrome (at client), and Node.js (at server) use V8 JavaScript engine.

MongoDB(服务器端)、Chrome(客户端)和Node。js(在服务器上)使用V8 JavaScript引擎。

PS: you can use only one language, Javascript, to all your project modules: client-APIs, client interface, "server hub", and server database (ex. stored procedures). All programmers "coding once"!

PS:您只能对所有项目模块使用一种语言Javascript:客户端api、客户端接口、“服务器集线器”和服务器数据库(例如存储过程)。所有程序员“编码一次”!

---

The main distinction between "Server-Javascript" and "Client-Javascript" languages, is explained at http://www.commonJS.org/ , the standard library for Server-Javascript.

“服务器- javascript”和“客户- javascript”语言之间的主要区别，在服务器- javascript的标准库http://www.commonJS.org/上进行了解释。

CommonJS exists since 2009, and today (2013) is a mature standard, used in both, MongoDB and Node.js.

CommonJS自2009年开始存在，今天(2013年)是一个成熟的标准，用于MongoDB和Node.js。

---

HISTORICAL NOTE: the oldest active "client+server Javascript" (including use of PostgreSQL) open package is alive!
Released in 2001 and in continuous development since then, Whitebeam is a mature Javascript (and DOM) technology. The last update was in January 2016.

历史记录:最古老的活跃的“客户端+服务器Javascript”(包括使用PostgreSQL)打开包是活的!自2001年发布以来，Whitebeam一直是一个成熟的Javascript(和DOM)技术。最近一次更新是在2016年1月。

---

2016's NEWS

Node.js engine continues as a runtime built on Chrome's V8 JavaScript... And now is, in fact, a consolidated success! The last releases are v7.0 and v6.8 LTS.

节点。js引擎继续作为一个运行时构建在Chrome的V8 JavaScript上…事实上，现在是一个巩固的成功!最后的版本是v7.0和v6.8 LTS。

JSON, as data interchange format, have continous growing interest in the last years, having surpassed in 2016 the interest in XML (see also in the Science context, where surpassed in 2011). As the native Javascript format, it is also a good language-trend indicator.

JSON作为数据交换格式，在过去的几年里一直受到越来越多的关注，在2016年超过了对XML的兴趣(参见科学上下文，在2011年超过)。作为原生的Javascript格式，它也是一个很好的语言趋势指示器。

The (faster) V8 engine is also the most used, since 2014: in the most popular client (Chrome at desktops and WebView at Android) and popular at servers — Node.js as runtime and PostgreSQL with PL/V8 for SQL and stored procedures.

自2014年以来，(速度更快的)V8引擎也得到了最广泛的应用:在最流行的客户端(桌面版的Chrome和安卓版的WebView)和服务器端——Node。js作为运行时，使用PL/V8作为SQL和存储过程的PostgreSQL。

...Perhaps the most important server-side contribution in 2016 was a fast and robust database support for JSON and Javascript: with PostgreSQL 9.1+ (2016-10) you are able to load PL/V8 (and dialects like Coffeshop) via simple CREATE EXTENSION command; with PostgreSQL 9.5+ (2016-10) the most important, a complete orthogonal set of JSON and JSONb functions and operators.

…也许2016年服务器端最重要的贡献是对JSON和Javascript的快速和健壮的数据库支持:使用PostgreSQL 9.1+(2016-10)，您可以通过简单的CREATE扩展命令加载PL/V8(以及Coffeshop等方言);其中最重要的是PostgreSQL 9.5+(2016-10)，一个完整的JSON和JSONb函数和操作符的正交集合。

So, as a fact, there is a fast, resilient and reliable unified JavaScript development stack.

因此，作为一个事实，有一个快速、有弹性和可靠的统一JavaScript开发堆栈。

#5

It could refer to using javascript to post messages to a web server without re-loading the page: in other words, AJAX.

它可以指使用javascript向web服务器发送消息，而无需重新加载页面:换句话说，AJAX。

But more likely I think it means something like Aptana/Jaxer (or, today, Node.js), which uses javascript for a server-side language. In this case, remember that javascript is just a language: the DOM used in a web browser is a sort of API. The server-side javascript engines would provide their own API objects, geared at server-side tasks like DB and file system access.

但更可能的是，我认为它的意思是Aptana/Jaxer(或者，今天的Node.js)，它使用javascript作为服务器端语言。在这种情况下，请记住javascript只是一种语言:web浏览器中使用的DOM是一种API。服务器端javascript引擎将提供它们自己的API对象，用于服务器端任务，如DB和文件系统访问。

Server-side javascript is an interesting idea because of the client-side validation problem: you want to do validation client-side to avoid sending needless requests to your server. This improves server performance and reduces latency on the client. But you must do validation server-side because you can't trust the client. This results in a lot of duplicate code between the client and server.

由于客户端验证问题，服务器端javascript是一个有趣的想法:您希望在客户端进行验证，以避免向服务器发送不必要的请求。这提高了服务器性能，减少了客户机上的延迟。但是您必须在服务器端进行验证，因为您不能信任客户端。这会导致客户端和服务器之间产生大量重复的代码。

The theory is that if your client and server languages match you'll no longer need two implementations of the same logic. In practice it doesn't work so well, because the client and server views of a page request are so different and because you don't control the javascript engine used by the client.

理论上，如果您的客户端和服务器语言匹配，您将不再需要相同逻辑的两个实现。在实践中，它并不能很好地工作，因为页面请求的客户端和服务器视图是如此不同，而且您不能控制客户端使用的javascript引擎。

#6

It really depends if you are talking about ASP.NET or Classic ASP. If you are using ASP.NET there aren't many good reasons for using Javascript.

这取决于你说的是不是ASP。净或经典ASP。如果您正在使用ASP。使用Javascript没有很多好的理由。

ASP Classic is an different case. You can use Javascript on the server side in ASP just the same way you would use VBScript. You can access the Application, Server, Request and Response objects just the same as via VBScript.

ASP经典是另一种情况。您可以在ASP中的服务器端使用Javascript，就像使用VBScript一样。您可以像通过VBScript一样访问应用程序、服务器、请求和响应对象。

There can be real benefits to using Javascript on the server side in ASP rather than VBScript. It means you can share code between the browser code and server code. It also means your developers don't need to deal with two different languages.

在服务器端使用Javascript而不是VBScript可以带来真正的好处。这意味着您可以在浏览器代码和服务器代码之间共享代码。这也意味着您的开发人员不需要处理两种不同的语言。

There are some downsides to server side Javascript in ASP though. Firstly it doesn't appear to be as fast as VBScript on the server side at string concatenation. It also isn't as good as making calls to COM objects as VBScript (you can only get data back from COM calls via the return value, rather than via out/byref parameters).

在ASP中，服务器端Javascript也有一些缺点。首先，在字符串连接时，它似乎没有服务器端VBScript那么快。它也不如VBScript那样调用COM对象(您只能通过返回值从COM调用获取数据，而不能通过out/byref参数)。

#7

You might want to have some functionality both in the browser and in the server to have the exact same implementation.

您可能希望在浏览器和服务器中都具有相同的实现。

An example would be a renderer for a wiki-syntax, that you run in the browser for the WYSIWYG editor and on the server to render the resulting page. This way you know that both the rendered results will be exactly the same in both cases.

一个例子是wiki语法的渲染器，您可以在浏览器中为WYSIWYG编辑器运行，并在服务器上呈现结果页面。通过这种方式，您知道在两种情况下，呈现的结果都是完全相同的。

Apparently Rhino can compile JavaScript to Java classes.

显然，Rhino可以将JavaScript编译为Java类。

#8

Traditionally, Javascript runs around the Document Object Model. But what if you work for a Java shop and would like a scripting engine around your custom object model? That's when Server-side Javascript comes in.

传统上，Javascript围绕文档对象模型运行。但是，如果您在Java商店工作，并且希望围绕自定义对象模型使用脚本引擎，该怎么办呢?这时服务器端Javascript就出现了。

http://en.wikipedia.org/wiki/Server-side_JavaScript

http://en.wikipedia.org/wiki/Server-side_JavaScript

#9

I remember with Cocoon (Apache's Java/XML/Javascript MVC framework) I used to use server-side Javascript since there was a something (I believe cforms) that needed to be written in Javascript and was running on the server even though I believe you could write it in Java.

我记得在Cocoon (Apache的Java/XML/Javascript MVC框架)中，我曾经使用服务器端Javascript，因为有一些东西(我相信是cforms)需要用Javascript编写，并且在服务器上运行，尽管我相信您可以用Java编写它。

We used Rhyno by that time, please check: http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty

那时我们使用了Rhyno，请检查:http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty

#10

http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html

http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html

Check out how Steve Yegge is using Server-Side JavaScript with Rhino and why. He has a bunch of stuff on how he feels JavaScript is up and coming.

查看Steve Yegge如何使用Rhino的服务器端JavaScript以及为什么。他有很多关于他如何感觉到JavaScript的东西。

#11

Yeah I've just read up about SSJS on a blog by some guy named John Resig.

是的，我刚刚在一个叫John Resig的博客上读到了关于SSJS的消息。

He describes an engine called Jaxer, which he says is "Imagine ripping off the visual rendering part of Firefox and replacing it with a hook to Apache instead - roughly speaking that's what Jaxer is."

他描述了一个叫做Jaxer的引擎，他说这个引擎是“想象一下剥离Firefox的视觉渲染部分，代之以与Apache的挂钩——粗略地说，这就是Jaxer。”

For anyone who knows ASP.NET The HTML looks familiar

对于任何了解ASP的人。NET HTML看起来很熟悉

<html>
<head>
  <script src="http://code.jquery.com/jquery.js" runat="both"></script>
  <script>
    jQuery(function($){
      $("form").submit(function(){
        save( $("textarea").val() );
        return false;
      });
    });
  </script>
 <script runat="server">
    function save( text ){
      Jaxer.File.write("tmp.txt", text);
    }
    save.proxy = true;

    function load(){
      $("textarea").val(
        Jaxer.File.exists("tmp.txt") ? Jaxer.File.read("tmp.txt") : "");
    }
  </script>
</head>
<body onserverload="load()">
   <form action="" method="post">
    <textarea></textarea>
    <input type="submit"/>
  </form>
</body>
</html>

Note the runat="sever" and runat="both"

注意runat="sever"和runat="both"

#12

With ASP you can use Server Side JavaScript in a number of ways. The way I most commonly use it is to have the same code executing on the client and on the server for validation.

有了ASP，你可以在很多方面使用服务器端JavaScript。我最常用的方法是让相同的代码在客户端和服务器上执行以进行验证。

file.js

file.js

<!--//--><%

//javascript code
function example(){return "Hello, World!";}

//%>

file.html

file.html

<%@LANGUAGE="javascript"%>
<!-- METADATA TYPE="typelib" 
FILE="C:\Archivos de programa\Archivos comunes\System\ado\msado15.dll" -->
<!--#include file="file.js"-->
<html>
<head>
  <script language="javascript" src="file.js"></script>
</head>
<body>
<%=example();%>
<script language="javascript">alert(example());</script>
</body>
</html>

file.js starts and ends the way it does to allow for inclusion of the same file.

文件。js以允许包含相同文件的方式开始和结束。