何时以及如何使用服务器端 JavaScript?[已结束]

When and how do you use server side JavaScript? [closed]

提问人:Johnno Nolan 提问时间:1/20/2009 最后编辑:Peter HiltonJohnno Nolan 更新时间:6/29/2018 访问量:80225

问:


想改进这个问题吗?通过编辑这篇文章来更新问题,使其仅关注一个问题。

8年前关闭。

偶尔我会搜索一些 JavaScript 帮助,我会遇到“服务器端 JavaScript”一词。你什么时候会使用JavaScript服务器端?又是如何做到的呢?

我对 JavaScript 的体验一直在浏览器中。有JS的编译版本吗?

JavaScript 服务器端

评论

0赞 Prestaul 1/20/2009
看到这个关于 Jaxer 的问题:stackoverflow.com/questions/98915/......
0赞 Prestaul 1/20/2009
还相关:stackoverflow.com/questions/109762/...
0赞 jeff musk 11/24/2011
我认为这在这里可能会有所帮助 - 维基百科关于服务器端 javascript 解决方案的比较:en.wikipedia.org/wiki/...
0赞 Peter Krauss 2/9/2015
这个问题几乎等同于“何时以及如何在开发堆栈中统一语言?Javascript 是客户端的标准语言,用于传输的 JSON...因此,使用服务器端的 Javascript,您可以统一开发。请在此处查看答案
0赞 ToolmakerSteve 2/15/2017
@PeterKrauss - 我知道这不是讨论这个问题的地方,但在当今可用的所有语言中,javascript 已经变得很普遍了......吓坏了我。另一方面,也许这意味着 WWW 委员会下次可以就实质性的语言改进达成一致,而他们无法就 HTML5 达成一致。(根据会议记录,从字里行间看,未能达成一致,主要是因为这样做意味着帮助Adobe或Microsoft,因为这两家公司拥有实质性语言,可以用作新功能的基础。

答:

6赞 Joel Coehoorn 1/20/2009 #1

它可以指使用 javascript 将消息发布到 Web 服务器而无需重新加载页面:换句话说,AJAX。

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

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

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

评论

0赞 wootscootinboogie 10/25/2013
旧帖子,但这是我读过的最清晰、最简洁的服务器端 JavaScript 使用方式。+1
2赞 Francisco Canedo 1/20/2009 #2

您可能希望在浏览器和服务器中都具有某些功能,以便实现完全相同。

例如,wiki 语法的渲染器,您可以在所见即所得编辑器的浏览器中运行它,并在服务器上运行该渲染生成的页面。这样,您就知道在这两种情况下,两种渲染结果将完全相同。

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

1赞 yogman 1/20/2009 #3

传统上,Javascript 围绕文档对象模型运行。但是,如果您在一家 Java 商店工作,并且想要一个围绕您的自定义对象模型的脚本引擎,该怎么办?这就是服务器端 Javascript 的用武之地。

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

3赞 andynormancx 1/20/2009 #4

这真的取决于您是在谈论 ASP.NET 还是经典 ASP。如果您使用的是 ASP.NET 那么使用 Javascript 的理由并不多。

ASP Classic 是另一种情况。您可以在 ASP 中的服务器端使用 Javascript,就像使用 VBScript 一样。您可以像通过 VBScript 一样访问 Application、Server、Request 和 Response 对象。

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

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

评论

1赞 Adam Lassek 1/20/2009
OP从未提及具体技术;他可以很容易地想到像Jaxer这样的东西。
0赞 andynormancx 1/20/2009
很多人没有意识到你甚至可以在经典 ASP 中做服务器端 Javascript。因此,我认为解释术语“服务器端 Javascript”可能只是指普通的旧 ASP Classic 会有所帮助。
0赞 Prestaul 1/20/2009
使用运算符 (+) 的 JScript string concat 速度稍慢,但推送到数组并联接的速度非常快,而且难度也不大。如果你要连接足够多的字符串,那么这并不难做到:var buffer = [];buffer.push('字符串');返回buffer.join('');
27赞 Kev 1/20/2009 #5

它不是 AJAX,除非人们不恰当地使用这个术语。顾名思义,SSJS 是在服务器上运行的 JavaScript,由独立(即独立于浏览器)的 JavaScript 引擎(如 SpiderMonkey)解释。

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

评论

0赞 Kev 1/20/2009
有一天,我想以这种方式从数据库 CHECK 约束自动生成 JavaScript。(我想知道pgsql是否有JS绑定?
1赞 orip 1/20/2009
+1,从来没想过验证角度
0赞 Esteban Küber 7/14/2009
我在一些旧版 ASP 应用程序上使用这种方法。它并非没有问题(与IE vs FF vs Opera相同的问题),但是一旦您设法使其工作,它就会运行良好。
20赞 Lee Harold 1/20/2009 #6

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

在服务器上使用 JavaScript 的一个引人注目的用途是作为客户端数据验证的补充。例如,您可以在客户端和服务器上使用相同的 JavaScript 验证库。这可确保您在客户端上使用与在服务器上相同的逻辑,但(可能)通过在客户端进行预验证来避免不必要的往返。

维基百科在这里列出了许多服务器端 JavaScript 实现。

评论

0赞 Kev 1/20/2009
我更喜欢你的措辞而不是我的措辞。:) +1
0赞 Alex Mcp 3/13/2010
在我的上一家公司,我们使用了 JScript w/ ASP。这样做的好处是更少的语言(我们让前端开发人员编写一些服务器端数据调用)和代码重用,因为您将使用几乎完全相同的代码在两端进行验证。好东西,但现在我正在努力寻找将其放入 Apache 的好方法。
0赞 Utku 2/9/2021
客户端验证仅用于用户体验。它不提供任何安全性。
1赞 igorgue 1/20/2009 #7

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

我们当时使用的是Rhyno,请检查:http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty

1赞 Johnno Nolan 1/20/2009 #8

是的,我刚刚在一个名叫 John Resig 的人的博客上读到了关于 SSJS 的信息。

他描述了一个名为 Jaxer 的引擎,他说它是“想象一下,剥离 Firefox 的视觉渲染部分,并用 Apache 的钩子代替它——粗略地说,这就是 Jaxer 的本质。

对于任何了解 ASP.NET HTML 的人来说,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>

请注意 runat=“sever” 和 runat=“both”

评论

0赞 Prestaul 1/20/2009
我在上面发布了这个,但也许它属于这里......关于 Jaxer 的一些反馈:stackoverflow.com/questions/98915/......
0赞 jeff musk 11/25/2011
@John Nolan,我相信John Rseig是jQuery背后的“那个人”
1赞 Greg 1/20/2009 #9

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

了解 Steve Yegge 如何在 Rhino 中使用服务器端 JavaScript,以及原因。他有一大堆关于他如何看待 JavaScript 的东西。

评论

4赞 Johnno Nolan 1/20/2009
我没有空闲的 6 小时来发布 Yegge 帖子。
0赞 Christian Nunciato 1/20/2009
伙计,我希望我能投赞成票。:)
25赞 Will Hartung 1/20/2009 #10

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

回到过去,Netscape Web 服务器也提供了服务器端 java 脚本。

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

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

我预见到服务器上会有越来越多的JavaScript。当你在客户端上用 JavaScript 编写“厚”应用程序时,你也可以在服务器上用 JavaScript 编写你的逻辑,这样就不必从一种语言到另一种语言进行认知飞跃。环境会有所不同,但您的大部分代码和知识都是可以共享的。

最后,JavaScript 可能是目前在实现方面最赚钱的单一语言。来自Apple,Mozilla,Google甚至Microsoft的努力,以及使其成为更高级语言的努力(即基本上是具有Algol语法的Scheme,没有宏)。

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

工具是 JavaScript 最大的不足之处,尤其是在服务器端,但如果你考虑像 Phobos 这样的东西,你可以在 IDE 中调试服务器端 JavaScript,这是一个很大的进步。

就我个人而言,我在我的应用程序中折腾 JavaScript,就像白色油漆一样。它以极低的成本提供廉价的可扩展性,并且是一个很好的推动因素。

评论

0赞 oberhamsi 9/18/2009
请注意,正在努力改进服务器端JS的互操作性和可用性库 wiki.commonjs.org/wiki/CommonJS
3赞 ToolmakerSteve 2/15/2017
2016年更新:调查node.js。并阅读彼得·克劳斯(Peter Krauss)的回答
0赞 Ashok M A 5/29/2018
这个答案更像是当时对服务器端JS的预言,如Node.js等。
1赞 Esteban Küber 7/14/2009 #11

使用 ASP,您可以通过多种方式使用服务器端 JavaScript。我最常使用它的方式是在客户端和服务器上执行相同的代码进行验证

file.js

<!--//--><%

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

//%>

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以允许包含同一文件的方式开始和结束。

22赞 8 revs, 4 users 90%Peter Krauss #12

2013年新闻

Node.js(另见维基百科文章)是成功的,它的社区正在成长

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

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


“Server-Javascript”和“Client-Javascript”语言之间的主要区别在 http://www.commonJS.org/ 中进行了解释,这是 Server-Javascript 的标准库。

CommonJS 自 2009 年就存在了,今天(2013 年)是一个成熟的标准,用于 MongoDBNode.js


历史说明:最古老的活跃“客户端+服务器 Javascript”(包括使用 PostgreSQL)开放包还活着!
Whitebeam 于 2001 年发布,此后一直在不断开发,是一种成熟的 Javascript(和 DOM)技术。最后一次更新是在 2016 年 1 月。


2016年新闻

Node.js引擎继续作为基于 Chrome 的 V8 JavaScript 构建的运行时......事实上,现在是一个巩固的成功!最新版本是 v7.0v6.8 LTS

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

自 2014 年以来,(更快的)V8 引擎也是使用最多的:在最流行的客户端桌面上的 Chrome 和 Android 上的 WebView)和服务器上流行的 - Node.js作为运行时和 PostgreSQL 以及用于 SQL 和存储过程的 PL/V8

...也许 2016 年最重要的服务器端贡献是对 JSON 和 Javascript 的快速而强大的数据库支持:使用 PostgreSQL 9.1+ (2016-10),您可以通过简单的命令加载 PL/V8(以及 Coffeshop 等方言);其中 PostgreSQL 9.5+ (2016-10) 是最重要的,是一组完整的正交 JSON 和 JSONb 函数和运算符CREATE EXTENSION

因此,事实上,有一个快速、有弹性和可靠的统一 JavaScript 开发堆栈

评论

0赞 ToolmakerSteve 2/15/2017
回复“JSON ..作为原生的 Javascript 格式,它也是一个很好的语言趋势指标。不,JSON 的流行正在爆炸式增长,因为它已经证明自己在其他语言中同样有用,每当需要在设备(手机、桌面、服务器)之间传输键值对的小数据包时。它比 XML 更容易使用,满足简单的数据需求。特别是,Apple 和 Google 都使用 JSON 进行推送通知。仅此一项就足以引起使用量的爆炸式增长!
0赞 Peter Krauss 7/28/2017
关于“统一开发”,也是为了在客户端和服务器使用的 MVC 模型中保留一些客户端/服务器同构。请参阅 isomorphic-universal-javascript 文章或 git 文章
0赞 Peter Krauss 6/17/2020
...2019年专利纠纷大问题甲骨文/谷歌,见 github.com/plv8/plv8/issues/364