Gelegentlich suche ich nach JavaScript-Hilfe und stoße auf den Begriff "Serverseitiges JavaScript". Wann würden Sie JavaScript serverseitig verwenden? Und wie?
Meine Erfahrungen mit JavaScript wurden im Browser gemacht. Gibt es eine kompilierte Version von JS?
Antworten:
Es gibt das Projekt Phobos , ein serverseitiges JavaScript-Framework.
Damals bot der Netscape-Webserver auch serverseitiges Java-Skript an.
In beiden Fällen wird JavaScript genauso verwendet wie jede andere Sprache auf dem Server. In der Regel zum Behandeln von HTTP-Anforderungen und zum Generieren von Inhalten.
Rhino , Mozillas JavaScript-System für Java, kompiliert JavaScript in Java-Bytecodes, die die JVM für JIT auswählen kann. Andere Systeme verwenden andere Mittel zum Ausführen von Java-Skripten, sogar bis zu dem Punkt, dass einige JIT ihre internen Codes für Java-Skripte kompilieren.
Ich gehe davon aus, dass auf dem Server immer mehr JavaScript verfügbar sein wird. Wenn Sie "dicke" Anwendungen in JavaScript auf dem Client schreiben, können Sie möglicherweise auch Ihre Logik in JavaScript auf dem Server schreiben, um nicht die kognitiven Sprünge von einer Sprache in eine andere machen zu müssen. Die Umgebungen werden unterschiedlich sein, aber ein Großteil Ihres Codes und Wissens kann gemeinsam genutzt werden.
Schließlich ist JavaScript wahrscheinlich die einzige Sprache, auf die derzeit in Bezug auf Implementierungen am meisten Geld zu verweisen ist. Von Apple, Mozilla, Google und sogar Microsoft sowie den Bemühungen, es zu einer noch fortgeschritteneren Sprache zu machen (dh im Grunde ein Schema mit Algol-Syntax ohne Makros).
Die meisten dieser Implementierungen sind im Browser vergraben, aber das heißt nicht, dass es auch auf der Serverseite keinen Wert gibt.
Das Tooling ist der größte Ort, an dem JavaScript fehlt, insbesondere auf der Serverseite. Wenn Sie jedoch etwas wie Phobos in Betracht ziehen, bei dem Sie Ihr serverseitiges JavaScript in der IDE debuggen können, ist dies ein großer Fortschritt.
Persönlich werfe ich JavaScript in meinen Anwendungen wie weiße Farbe herum. Es bietet günstige Erweiterbarkeit für sehr geringe Kosten und ist ein großartiger Wegbereiter.
Es ist nicht AJAX, es sei denn, die Leute verwenden den Begriff falsch. Wie der Name schon sagt, handelt es sich bei SSJS um JavaScript, das auf dem Server ausgeführt wird und von einer eigenständigen (dh browserunabhängigen) JavaScript-Engine wie SpiderMonkey interpretiert wird.
Warum die Mühe? Ein Bereich, in dem es derzeit nicht ausreichend genutzt wird, ist die Datenvalidierung. Mit SSJS schreiben Sie einen Code, der dann sowohl auf dem Server als auch auf dem Client verwendet wird. Auf diese Weise erhalten Sie vom clientseitigen JS sofort ein Benutzerfeedback, das automatisch mit der auf dem Server stattfindenden Datenprüfung übereinstimmt.
Node.js (siehe auch Wikipedia-Artikel ) ist ein Erfolg und seine Community wächst !
MongoDB (am Server), Chrome (am Client) und Node.js (am Server) verwenden die V8-JavaScript-Engine .
PS: Sie können nur eine Sprache, Javascript, für alle Ihre Projektmodule verwenden: Client-APIs, Client-Schnittstelle, "Server-Hub" und Server-Datenbank (z. B. gespeicherte Prozeduren). Alle Programmierer "einmal codieren"!
Die Hauptunterscheidung zwischen den Sprachen "Server-Javascript" und "Client-Javascript" wird unter http://www.commonJS.org/ , der Standardbibliothek für Server-Javascript , erläutert .
CommonJS existiert seit 2009 und heute (2013) ist ein ausgereifter Standard , der sowohl in MongoDB als auch in Node.js verwendet wird .
HISTORISCHER HINWEIS: Das älteste aktive offene Paket "Client + Server Javascript" (einschließlich der Verwendung von PostgreSQL) ist aktiv! Whitebeam wurde
2001 veröffentlicht und seitdem kontinuierlich weiterentwickelt. Es handelt sich um eine ausgereifte Javascript- (und DOM-) Technologie. Das letzte Update war im Januar 2016.
Die Node.js- Engine wird als Laufzeit fortgesetzt, die auf dem V8-JavaScript von Chrome basiert... Und jetzt ist sie tatsächlich ein konsolidierter Erfolg! Die letzten Versionen sind v7.0 und v6.8 LTS .
JSON als Datenaustauschformat hat in den letzten Jahren ein stetig wachsendes Interesse, nachdem es 2016 das Interesse an XML übertroffen hat (siehe auch im wissenschaftlichen Kontext, wo es 2011 übertroffen wurde ). Als natives Javascript-Format ist es auch ein guter Indikator für Sprachtrends.
Die (schnellere) V8-Engine wird seit 2014 auch am häufigsten verwendet: im beliebtesten Client ( Chrome auf Desktops und WebView unter Android) und auf Servern - Node.js als Laufzeit und PostgreSQL mit PL / V8 für SQL und gespeicherte Prozeduren .
... Der vielleicht wichtigste serverseitige Beitrag im Jahr 2016 war eine schnelle und robuste Datenbankunterstützung für JSON und Javascript: Mit PostgreSQL 9.1+ (2016-10) können Sie PL / V8 (und Dialekte wie Coffeshop) einfach laden CREATE EXTENSIONBefehl; mit PostgreSQL 9.5+ (2016-10) das wichtigste, ein vollständiger orthogonaler Satz von JSON- und JSONb-Funktionen und -Operatoren .
Tatsächlich gibt es also einen schnellen, belastbaren und zuverlässigen einheitlichen JavaScript-Entwicklungsstapel .
Classic ASP konnte JavaScript auf dem Server verwenden, obwohl die meisten Benutzer VBScript verwendeten.
Eine überzeugende Verwendung von JavaScript auf dem Server ist die Ergänzung zur clientseitigen Datenvalidierung. Beispielsweise können Sie auf dem Client und auf dem Server dieselbe JavaScript-Validierungsbibliothek verwenden. Dies stellt sicher, dass Sie auf dem Client dieselbe Logik verwenden wie auf dem Server, aber (möglicherweise) einen unnötigen Roundtrip vermeiden, indem Sie auf der Clientseite vorab validieren.
Wikipedia listet hier eine Reihe von serverseitigen JavaScript-Implementierungen auf .
Es könnte sich auf die Verwendung von Javascript beziehen, um Nachrichten auf einem Webserver zu veröffentlichen, ohne die Seite neu zu laden: mit anderen Worten, AJAX.
Aber wahrscheinlicher denke ich, dass es so etwas wie Aptana / Jaxer bedeutet (oder heute Node.js) bedeutet, das Javascript für eine serverseitige Sprache verwendet. Denken Sie in diesem Fall daran, dass Javascript nur eine Sprache ist: Das in einem Webbrowser verwendete DOM ist eine Art API. Die serverseitigen Javascript-Engines stellen ihre eigenen API-Objekte bereit, die auf serverseitige Aufgaben wie DB- und Dateisystemzugriff ausgerichtet sind.
Serverseitiges Javascript ist aufgrund des clientseitigen Validierungsproblems eine interessante Idee: Sie möchten die clientseitige Validierung durchführen, um zu vermeiden, dass unnötige Anforderungen an Ihren Server gesendet werden. Dies verbessert die Serverleistung und verringert die Latenz auf dem Client. Sie müssen die Validierung jedoch serverseitig durchführen, da Sie dem Client nicht vertrauen können. Dies führt zu viel doppeltem Code zwischen Client und Server.
Die Theorie besagt, dass Sie, wenn Ihre Client- und Server-Sprachen übereinstimmen, nicht mehr zwei Implementierungen derselben Logik benötigen. In der Praxis funktioniert dies nicht so gut, weil die Client- und Serveransichten einer Seitenanforderung so unterschiedlich sind und Sie die vom Client verwendete Javascript-Engine nicht steuern.
Es hängt wirklich davon ab, ob Sie über ASP.NET oder Classic ASP sprechen. Wenn Sie ASP.NET verwenden, gibt es nicht viele gute Gründe für die Verwendung von Javascript.
ASP Classic ist ein anderer Fall. Sie können Javascript auf der Serverseite in ASP genauso verwenden wie VBScript. Sie können genauso wie über VBScript auf die Objekte Application, Server, Request und Response zugreifen.
Die Verwendung von Javascript auf der Serverseite in ASP anstelle von VBScript kann echte Vorteile haben. Dies bedeutet, dass Sie Code zwischen dem Browsercode und dem Servercode freigeben können. Dies bedeutet auch, dass Ihre Entwickler nicht mit zwei verschiedenen Sprachen umgehen müssen.
Das serverseitige Javascript in ASP hat jedoch einige Nachteile. Erstens scheint es bei der Verkettung von Zeichenfolgen auf der Serverseite nicht so schnell wie VBScript zu sein. Es ist auch nicht so gut wie das Aufrufen von COM-Objekten wie VBScript (Sie können Daten von COM-Aufrufen nur über den Rückgabewert und nicht über die Parameter out / byref zurückerhalten).
Möglicherweise möchten Sie einige Funktionen sowohl im Browser als auch auf dem Server haben, um genau dieselbe Implementierung zu erzielen.
Ein Beispiel wäre ein Renderer für eine Wiki-Syntax, den Sie im Browser für den WYSIWYG-Editor und auf dem Server ausführen, um die resultierende Seite zu rendern. Auf diese Weise wissen Sie, dass beide gerenderten Ergebnisse in beiden Fällen genau gleich sind.
Anscheinend kann Rhino JavaScript in Java-Klassen kompilieren.
Traditionell läuft Javascript um das Dokumentobjektmodell herum. Aber was ist, wenn Sie für einen Java-Shop arbeiten und eine Skript-Engine für Ihr benutzerdefiniertes Objektmodell wünschen? Dann kommt serverseitiges Javascript ins Spiel.
Ich erinnere mich, dass ich mit Cocoon (Apaches Java / XML / Javascript MVC-Framework) serverseitiges Javascript verwendet habe, da etwas (ich glaube cforms) in Javascript geschrieben werden musste und auf dem Server ausgeführt wurde, obwohl ich Ihnen glaube könnte es in Java schreiben.
Zu diesem Zeitpunkt haben wir Rhyno verwendet. Bitte überprüfen Sie: http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty
http://steve-yegge.blogspot.com/2007/06/rhino-on-rails.html
Erfahren Sie, wie Steve Yegge serverseitiges JavaScript mit Rhino verwendet und warum. Er hat eine Menge Zeug darüber, wie er glaubt, dass JavaScript auf dem Vormarsch ist.
Ja, ich habe gerade in einem Blog von John Resig über SSJS gelesen .
Er beschreibt eine Engine namens Jaxer, die er als "Stellen Sie sich vor, Sie rippen den visuellen Rendering-Teil von Firefox ab und ersetzen ihn stattdessen durch einen Hook für Apache - grob gesagt ist das Jaxer."
Für alle, die ASP.NET kennen Der HTML-Code kommt Ihnen bekannt vor
<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>
Beachten Sie die runat = "Server" und runat = "beide"
Mit ASP können Sie serverseitiges JavaScript auf verschiedene Arten verwenden. Die Art und Weise, wie ich es am häufigsten verwende, besteht darin, dass derselbe Code zur Validierung auf dem Client und auf dem Server ausgeführt wird .
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 beginnt und endet so, wie es möglich ist, dieselbe Datei aufzunehmen.