Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
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?
My experiences of JavaScript have been in the browser. Is there a compiled version of JS?
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.
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.
There's the project Phobos, which is a server side JavaScript framework.
Back In The Day, the Netscape web server offered server-side java script as well.
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.
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.
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.
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).
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.
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.
2013's NEWS
Node.js (see also at Wikipedia article) is a sucess, and its community is growing!
MongoDB (at server), Chrome (at client), and Node.js (at server) use
V8 JavaScript engine.
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"!
The main distinction between "Server-Javascript" and "Client-Javascript" languages, is explained at http://www.commonJS.org/ , the standard library for Server-Javascript.
CommonJS exists since 2009, and today (2013) is a mature standard, used in both, MongoDB and 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.
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.
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.
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.
...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.
So, as a fact, there is a fast, resilient and reliable unified JavaScript development stack.
Classic ASP was able to use JavaScript on the server, although most people used 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.
Wikipedia lists a number of server-side JavaScript implementations here.
It could refer to using javascript to post messages to a web server without re-loading the page: in other words, 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.
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.
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.
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 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.
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.
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).
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.
Apparently Rhino can compile JavaScript to Java classes.
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.
http://en.wikipedia.org/wiki/Server-side_JavaScript
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.
We used Rhyno by that time, please check: http://peter.michaux.ca/articles/server-side-javascript-with-rhino-and-jetty
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.
Yeah I've just read up about SSJS on a blog by some guy named John Resig.
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."
For anyone who knows ASP.NET The HTML looks familiar
<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"
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.
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 starts and ends the way it does to allow for inclusion of the same file.
Related
If I program a website in a language, say JavaScript. Then I make this website public like an usual website. Will people who use my website be able to tell what language it is programmed in?
Code running in a browser is always discoverable by a visitor. Code running on a server may not be discoverable.
If you mean using JavaScript only on the server via NodeJS or similar solution, then no, there is not anything that will inherently expose the fact that you're using JavaScript on the server. Some languages whose filenames typically end in a known extension, (e.g. .php, .asp) may reveal the server-side language. But it's also easy for you (as the developer) spoof this if you wanted to for some reason.
However, any code running client-side can easily be explored by most browsers' developer tools. They even typically offer reformatting of minified HTML and JS.
Currently, I am developing a 2-player tetris game. Originally, I was planning to implement a client-server model in a mobile environment.
However, now I change into web game, which is accessible by a browser. Since I am not used to a web development, I want to know if client-server model is necessary in a web game.
To be honest, I am a little bit skeptical writing both client and server code since a browser does a job to connect to the server.
Is it possible to build a network-based game by using only one server without a client part?
Is it possible to build a network-based game by using only one server without a client part?
Nope. You need a client.
It doesn't matter if you're in the browser or writing a native application. Yes, the browser solves a lot of client problems for you - it implements HTTP for you, and it has display (CSS), content (HTML), and evented logic (JavaScript) that you can use. But you still need to write your client using those technologies.
Even if the browser exposed a call in javascript like this:
window.startPeterHwangsTetrisGame();
You still have a client. The client is 1 line of code, and it is exactly the above script*.
Realistically, you should look for a game-oriented web development tutorial and start there.
*(aside from the necessary HTML within which that javascript exists)
Well, in one sorta correct way, no, because you're not redesigning the browser, but nobody would say it like that. Web design includes a lot of code / markup used on the client (browser), and while your server is sending the browser the data, and that data is a mix of CSS, HTML, and JavaScript (as well as media like graphics and perhaps music), the browser is the piece of software doing the lifting on those pieces once it receives them. That data is selected by the server, so the logic for that is on the server, but this is what people would think of as "client design" in the context of a web application.
There are also a number of models (ways of arranging your programming designs) which would lead to cleaner code, and a lot of these would send a grouping of information (called a model) to the client (the browser) and then the browser would do some interpretation of how to use that data (called a view). This is a simplification since I don't think you're ready for a big dive into specific theories, but you could start with a JavaScript and HTML tutorial and then learn a server language:
Python is my favorite, but PHP is big as is Java (NOT to be confused with JavaScript), and I make my living doing C#. Really there are plenty of great choices.
One commentator recommended Node.js because you'd use JavaScript on the server with Node--just like for the client part (the response data you're sending to the browser). That's double duty, but I am partial to Python (as I said). Just pick something, and as you learn, you'll get to know what you like. If you change languages, it'll be easier to learn your second one.
I looking at using Javascript server side and took a look at persevere/pintura but for a novice like me, I need more documentation and tutorials and CouchDB seems to have a lot of that but is it used as a server side js tool?
Kind Regards
Yes (seconding what #Pointy said above). The JavaScript in CouchDB does run server-side. :)
Beyond that, though, JavaScript in CouchDB can do far more than just map/reduce queries. It's also used for document validation, update handling (for processing XML POSTed to CouchDB for example), as well as HTML or other markup output from either a single JSON document (using _show) or from the results of a map/reduce query (using _list).
CouchDB does not, however, offer filesystem access or TCP/IP listeners as Node.js does. Right now, the JavaScript is focused on the "shipping and handling" for the database contents (things like validation, formatting, and querying).
If you're interested in looking into options for handling things that CouchDB doesn't do "internally" (image processing, sending e-mails, etc), you might checkout my reply about CouchApp architecture options.
CouchApp's are definitely a viable option for web apps. Coupling those with replication, it's hard to beat.
http://nodejs.org/ is a great example for server-side javascript. If you don't want to write your complete webapp on NodeJS you can trigger it via the node command.
CouchDB is a database with an interresting feature, it allows you to interact via a RestFull api making it ideally suited to access over the web, either in javascript or other client environments. If you are looking for a server-side javascript development environment, try Servoy. It allows full featured server-side application development in javascript including easy database access to all major databases.
Short Answer: Yes.
Longer Answer:
There is a Javascript Engine shipped with CouchDB, which is SpiderMonkey
(the very first engine, open source, written by Brendan Eich, creator of javascript)
CouchDB's View function is JavaScript function running server side that acts as the Map half of a map/reduce operation to construct view.
Then there is client side javascript API, which can be used to communicate with the REST layer to fetch/update documents, which is also where jQuery is used by CouchDB.
More on CouchDB's both server-side & client side javascript capability:
The default engine is capable of doing many features, while package availability is limited compared to Node.js. Kan.so can be considered "NPM for CouchDB, where some packages are server side.
For example, there are frameworks like duality that try to make use of both server side & client side javascript capability to reuse code for rendering with couchDB.
More on the engine:
(The selection of spider Monkey over v8 is because for couchDB's use case the map reduce is not v8 designed for. Also include packaging, multi-threading and also historical reason v8 did not exist that time when spiderMoney is chosen) see [the mailing list] and tweet2
There is even project to port the whole CouchDB to Node.js (i.e. instead of Erlang), Chesterfield
I am glad if someone can add how Erlang talk with the javscript engine.
Thanks for everyone's answer, this is an important thing to make clear for people like me messing up couchDB with some Node.js packages
No, CouchDB is a document-oriented database that can be queried and indexed in a MapReduce fashion using JavaScript. CouchDB also offers incremental replication with bi-directional conflict detection and resolution.
http://couchdb.apache.org/
CommonJS can be used for server side JavaScript, see here: http://www.commonjs.org/
NodeJS is another: http://nodejs.org/
I'm now thinking to establish my server-side code in JavaScript, and begin to do all on it, but I want to know about its security and flexibility compared to PHP.
I want to know too, if it can be successfully used to develop things like forum boards, full web-sites and things like this, as PHP does.
Javascript is just now starting to get some presence on the server, with things like ServerJS and nodeJS, but right now, you would probably be best off using PHP for your server side code, and javascript for client-side beautification.
The question is very, very broad. Interpreting it as "can I use Javascript on the server":
Fundamentally, sure, Javascript is a very powerful language and so you can do development in it server-side just like you can client-side (and if you do client-side scripting as well, you get some definite reuse benefits using Javascript on the server).
For Apache systems, there's the v8cgi project (a FastCGI Javascript plug-in with connectors, using Google's freaky-fast V8 engine).
On Microsoft-based systems, IIS supports Javascript (JScript) on the server out of the box (I use that all the time), which has access to all of the ActiveX stuff (e.g., for talking to databases, dealing with the file system, etc.).
If your server framework is JVM-based, there's Rhino, which is Javascript for the Java platform and has access to all (or nearly all) of the libraries available for Java — e.g., a huge ecosystem of libraries and plug-ins.
Aside from v8cgi, there are a couple of other projects built on Google's V8 engine.
There's a place that does a full stack for you called chromeserver (I don't know what their backend is; I'm not going to infer from the name).
Paul mentioned ServerJS and NodeJS.
There's the whole CommonJS project.
Etc. etc. etc. There's quite a list on Wikipedia.
Arguing against, there's a very rich ecosystem built around PHP. Unless you're using something like Rhino for the Java platform or JScript on IIS (because of the ecosystems they leverage), you may find that you don't have nearly that ecosystem available to you when developing in Javascript for the server. I mean, if you're looking for pre-built forum or wiki software (for example), let's just say you can't swing a dead cat without finding one based on PHP, and the same cannot be said of Javascript on the server.
The way they are usually used, PHP and JavaScript run in entirely different worlds, and are not really comparable. (There is a server-side version of JavaScript but it's fair to say it's not especially widespread yet, and doesn't run on standard web hosting.)
The security issues you are going to encounter in JavaScript (on the browser) side are very different from what you have to look out for in PHP.
I want to know too, if it can be sucessfully used to develop things like forum boards, full web-sites and things like this, as PHP does.
No, not with client-side Javascript. For dynamic applications, you will always need some server-side language backing it, be it PHP or some other language like ASP, Python, Ruby, Perl....
To replace PHP with Javascript, you need server-side Javascript and there is a lot happening on that front. Mozilla’s Rhino runs Javascript atop the JVM and it seems Google is also working on its own server side Javascript framework. The most popular in-production implementations are:
Helma: Several active projects are using it, runs on Jetty & Rhino and lets developers leverage the power of JVM, has its own object-oriented MVC framework
Project Phobos: runs on Glassfish & Rhino and lets developers leverage the power of JVM, includes plug-ins for NetBeans and integrates with jMaki Web UI framework
JSSP: A very simple server side framework, a lot like classic ASP, JSP and PHP
Aptana’s Jaxer showed a lot of promise, especially by bringing the DOM to the server side, but the project seems dead now. From what I understand, node.js is not a server-side Javascript framework in the same sense as Helma and Phobos. Instead it can be used for writing event-driven servers in Javascript (for example: writing your own web server).
Yes, my site is written by node.js
Using websvr, it's Java style have filter and handlers, hosting on debian OS.
This is slightly off-topic, but it may actually get to the core of your question:
if you want to use only one language for web applications, you may wanna have a look at Haxe.
It is a cross-platform language, that (among other targets) compiles to JavaScript and PHP source as well as NekoVM bytecode. For server-side JavaScript, there are NodeJS bindings.
This way you are not bound to a specific platform. The neko and PHP APIs are largely compatible, so you can deploy on both platforms, having the option to choose neko's speed and persistency or PHP's ease of deployment. Please note however, the PHP output has a little overhead although common optimizers as eaccelerator will make this barely noticeable.
Haxe is significantly less forgiving than both JavaScript and PHP. This makes it harder to learn, but a much safer, robust and in the end more productive tool.
In a word: no. Javascript is a client-side language. In order to do the things that you are describing, you need a server-side language such as PHP.
EDIT: OK, technically it is possible to implement Javascript in other areas besides the browser, but this is not very common.
5 YEAR EDIT: Well, 5 years later, this answer obviously is not accurate, with the popularity of things like node.js. Let that be a testament to how quickly things can change!
PHP and JavaScript are two different languages that do two different things. One cannot replace the other. You are most likely going to use a combination of the two. JavaScript for client-side stuff. PHP for server-side stuff.
Html can contain little bits of Javascript embedded in it (e.g. defined in onclick event handlers).
If I were writing an Html browser using a dotNet language like C#, what technologies or APIs could I use to run such Javascript fragments, given that I don't receive it until run-time (and receive it as string data, not as executable code)?
Is it any easier or harder if the code to be run were C# snippets rather than Javascript?
Is there any technique which doesn't require my code to have unusual priviledges? For example, a method like CodeCompiler.FromSource requires SecurityPermissionFlag.UnmanagedCode (which seems to me excessive: I don't see why it's so risky to compile code).
If I controlled the server-side as well as the client-side code, I could also consider compiling such script fragments on the server instead of on the client, and then sending it as precompiled code to the client side to be executed. Is there a way to send such code (a dotNet assembly, presumably) over the network to the client, have client-side code receive it from the network into client-side RAM, and invoke it on the client side without storing it as a file on a client-side disk drive?
Edit
I have answer to the first three questions: I've resigned myself to the fact that compiling takes high privileges. I don't see why; maybe (although I don't find this a very convincing reason) it's because the compiler is implemented using unmanaged code. Maybe this will change when they reimplement the compiler using managed code, in maybe the "C# version 5" timeframe. In any case, whatever the reason, that seems to be the way it is, and there are no work-arounds (other similar APIs but which require fewer privileges).
My remaining question then is how to get an Assembly instance from one machine to another. When I have time I'll find out whether untrusted code can run the Assembly.Load(byte[] rawAssembly) method.
Server side Javascript is one of the languages supported by the .NET platform. I used it many times in the scenrios when you need to insert small code snippets into existing code. Runtime it can be loaded from i.e. database and compiled, so there is no preformance penalty.
From the standpoint of making the plumbing work (retrieveing the source, compiling it, etc.) there is no difference. With strongly typed languages though it is much more difficult to assemble code snippets into a compilable compilation unit.
Permissions is certanly a challenge. I am not sure about the specific permission you mentioned, but security is a concern, after all the source you compile can be anything and if you are not careful about the source of your code it can become the backdoor into your system
The answer to this one is - yes of course. You can load an assembly from anywhere, not necessarily from a file, you can also compile in memory - that's what I do. There is no dll file in this case.
You're asking several questions, sort of, so I'll give you an idea on one of them.
There's a very good article and some code samples from:
http://www.west-wind.com/presentations/dynamicCode/DynamicCode.htm
which talks about compiling and executing C# code at runtime. I found it very useful and I am using this in a standard c# application. Seems like it would be usable for your problem as well.