Develop Reference

Programming language of a website

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.

JavaScript basics/instructional

I have just begun giving JavaScript a try on a programmer friend's suggestion (though I have used it to some extent before with websites using jQuery without fully understanding the intricacies of the language itself) and was wondering how certain features work.
Question:
What other uses of JavaScript are there aside from websites (by itself and/or with jQuery framework)? Is there a difference between making a site interactive and an actual "web app"? I've heard the term and don't know the difference.
To add to my main question:
I've read and done some tutorials on prototyping and am not sure on its actual application (since what little I've dabbled in, by making a website more interactive, I've never seen them used). Can someone link a website with extensive deep/heavy JavaScript use so I can check it out?
Gist:
In essence, what I'm trying to understand is where heavy use of JavaScript comes into play because so far, all JavaScript I've experienced is superficial.
Appreciate in advance any advice/help in this matter!

What other uses of Javascript are there aside from websites (by itself and/or with jQuery framework)?
Check out node.js. It runs JavaScript programs not intended for web use. Node offers a bunch of imports for things like file system IO, socket IO and a bunch of others. I personally use it for a WebSocket server because I don't like my alternatives.
Further, JavaScript has native support in many operating systems, including all Windows versions after and including XP (not sure about before). Windows Script Host runs .js files as JScript and these can be used to achieve things like those node can. It's a convenient way to do things batch can't.

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

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.

GWT or DOJO or something else?

I come from the Microsoft world (and I come in peace). I want to rapidly prototype a web app and if it works out, take it live - and I don't want to use ASP.Net.
I am not sure which web application toolkit to use though. Should I use GWT, DOJO...other recommendations? I am open to any server-side language but am looking at RoR, Php or even Java (J2EE to be precise). I am not much of a Javascript/CSS guy so a toolkit that might make it relatively easy on me on those fronts would be preferable.
Also, I am a mac user at home. What IDEs go along with the framework you would recommend?
Any recommendations guys?

If you're open to doing Java, GWT is the way to go. It allows you to have a relatively uniform codebase across client-server, and to only use one language on both.
There are some limitations to doing very off-the-beaten-path AJAXy things (which GWT makes difficult, but not impossible), but it doesn't sound like that's your use case anyway.
GWT will allow you to scale up by using more of its features as your app gets more complex - and your prototype won't be throwaway code.

If you want to write the front and back end in JAVA, and want to do complex ajax type thing, then GWT is a great way to go.
The easiest way to think about it is that building a GWT app is kind of like building a JAVA swing application that hooks into a server. Just like a swing app that uses a server you can make it fat or thin. When you're done it all compiles down into HTML and javascript, and has very good modern browser support (ie6+ ff, opera, safari).
It does abstract all the javascript and HTML away, but if you want it to look good you'll still need to understand CSS.
I think anyone who says that that it ruins MVC or that it's a muddying of client vs server doesn't understand GWT. GWT is a CLIENT side framework. And it is only used on the CLIENT. GWT does provide an RPC mechanism to hook it into JAVA (and other) back ends, but that's just a communication protocol, it doesn't mean that your server code magically becomes your client code. Sure you can write a whole bunch of business rules into your UI if you really wanted to, but you can do this with any framework, so it would be silly to say that GWT is somehow different in that respect.

GWT is a good choice, while if you choose more powerful JavaScript framework based on GWT (e.g. SmartGWT), the compiled stuff is too heavyweight.
Choose direct JavaScript if you need a compact project.

I am a fan of GWT, however I am very familiar with Java. I found it to be intuitive, and surprisingly easy to get good results quickly. If you are to use GWT, then you'll definitely want to use the free, and immensely powerful Eclipse IDE.
One disadvantage of GWT is that it requires Javascript to be supported by the browser, there is no "graceful degradation".

We have evaluate a large list of frameworks and have decide us for Echo2.
You need only to code in Java. Javascript you need only if you want write your own components.
There are no startup performance problems with large projects like GWT.
You can use the full range of Java in your client code because it run on the server. In GWT you can use only very small set of Java classes.
The IDE for Java is Eclipse. This is independent of the used framework.

I'm a fan of jQuery, the chainability of actions, traversals, and commands is really powerful. A good friend of mine is crazy about Mootools, he works at a Java shop FWIW. He mentioned a cool feature of Mootools is that you can specify the functionality you want the framework to include and it will generate the entire library on a single line in a file that you can include on your page to minimize the weight of the framework (pretty cool feature). Really it just depends on what you are most comfortable with. jQuery has great tutorials, is super fast, and can be used along with other javascript frameworks.

Not related to GWT, but have you considered other backends that GWT could work nicely with?
Grails is one backend that ties quite nicely with GWT.

Personally, I would avoid server-side frameworks that try to embed or hide the client-side framework. I'm sure that GWT is great for getting something going quickly, and is probably fine for certain kinds of applications, but you'll probably run into lots of problems "on the edges" for more complex applications. Decoupling the client framework from the server-side framework avoids those problems.

Will server-side JavaScript take off? Which implementation is most stable? [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone see server-side JavaScript taking off? There are a couple of implementations out there, but it all seems to be a bit of a stretch (as in, "doing it BECAUSE WE CAN" type of attitude).
I'm curious to know if anyone actually writes JavaScript for the server-side and what their experiences with it have been to date.
Also, which implementation is generally seen as the most stable?

I like to read Googler Steve Yegge's blog, and recently I came across this article of his where he argues that Mozilla Rhino is a good solution for server-side JS. It's a somewhat sloppy transcript, you might prefer to watch the video of the talk. It also offers a little bit of insight on why he thinks server-side JS is a good idea in the first place (or rather, why he thinks that it's a good idea to use a dynamic language to script Java). I thought the points he makes were convincing, so you might want to check it out.
A while earlier, he also posted something about dynamic languages in general (he's a big fan of them), just in case you were wondering why to use JS at all.

Why would you want to process
something in Javascript when you can
process it in PHP or ASP.NET which are
designed specifically for this task?
Perhaps because JavaScript is a more powerful programming language than those two? For example, it has functions as first-class data types and support for closures.
Steve Yegge has blogged about porting Ruby on Rails to server-side JavaScript as an internal project within Google ("Rhino on Rails"). He did it because he likes Rails but using Ruby isn't allowed within Google.

Before it was acquired by Google, JotSpot used server-side JavaScript to let you query their database and display your pages. They used Rhino to do it. CouchDB uses server-side JavaScript to create views of their database.
As you can see from these examples, a great way to use JavaScript on the server is for plugins. One of the reasons it's used is that you can create a very isolated sandbox for people to run their code in. Also, because of the way that JavaScript as a language works, you can provide a user tooling specifically honed to the tasks your users need to complete. If you do this right, users don't need to learn a new language to complete their tasks, a quick glance at your API and examples is enough to get them on their way. Compare this to many of the other languages and you can see why using server-side JavaScript to provide a plugin architecture is so enticing.
A secondary popular solution, one which can be seen through a project like Jaxer, is that a common problem of web applications that do client-side validation is that, since JavaScript is easily bypassed in the browser, validation has to be run once again on the server. A system like Jaxer allows you to write some validation functionality that is reusable between both server and client.

Support for JS on the server has been getting stronger and the number of frameworks is getting bigger even faster.
Just recently the serversideJS group was founded. They have a lot of smart people that have been working on serverside JS for years (some of them more then 10).
The goal for this project is to create
a standard library that will
ultimately allow web developers to
choose among any number of web
frameworks and tools and run that code
on the platform that makes the most
sense for their application.
to the people who say "why would you choose JS over java or any other language?" - you should read this Re-Introduction by Crockford and forget about the DOM - the DOM is superugly, but that's not JS fault and JS is not the DOM.

I've never even heard of this, but it strikes me as using the wrong tool for the job. Since programming languages are just tools designed to help us solve some problem.
Why would you want to process something in Javascript when you can process it in PHP or ASP.NET which are designed specifically for this task?
Sure you can pound a nail in with a screw driver, but a hammer works much better because it was actually designed for it...
So no, I don't see it taking off.

Well, plain ol' ASP supported JavaScript server-side years ago and everyone onad their dog used VBShiate instead. But I have to agree with the others: JS does not seem to be the right tool here - and I love to do client-side JS :)

I personally did a whole site in server side JavaScript using ASP. I found it quite enjoyable because I was able to have some good code reuse. This included:
validation of parameters
object modeling
object transport
Coupled with a higher-level modeling tool and code gen, I had fun with that project.
I have no numbers on perf unfortunately, since it is used only on an intranet. However, I have to assume performance is on par with VBScript backed ASP sites.

It seems like most of you are put off by this idea because of how unpleasant the various client-side implementations of Javascript have been. I would check out existing solutions before passing judgment, though, because remember that no particular SS/JS solution is tied to the JS implementations currently being used in browsers. Javascript is based on ECMAScript, remember, a spec that is currently in a fairly mature state. I suspect that a SS/JS solution that supports more recent ECMA specs would be no more cumbersome than using other scripting languages for the task. Remember, Ruby wasn't written to be a "web language" originally, either.

Does anyone see Server-side Javascript
taking off?
Try looking at http://www.appjet.com a startup doing hosted JavaScript applications to get a feel for what you can do. I especially like the learning process which gently nudges the user to build things with a minimal overhead ~ http://appjet.com/learn-to-program/lessons/intro
Now it might seem a weird idea at the moment to use JavaScript but think back when PC's started coming out. Every nerd I knew of was typing away at their new Trash-80's, Commodore64's, Apple ]['s typing in games or simple apps in BASIC.
Where is todays basic for the younger hacker?
It is just possible that JavaScript could do for Web based server side apps as BASIC did for the PC.

XChat can run Javascript plugins.
I've some accounting software completely written in Javascript.
There's this interesting IO library for V8: http://tinyclouds.org/node/
CouchDB is a document database with 'queries' written in Javascript (TraceMonkey).
Considering this, i believe, server-side Javascript did take off.

Server-side programming has been around for a lot longer than client side, and has lots of good solutions already.
JavaScript has survived and become popular purely because developers have very little choice in the matter - it's the only language that can interact with a DOM. Its only competition on the client side is from things like Flash and Silverlight which have a very different model.
This is also why JavaScript has received so much effort to smart it up and add modern features. If it were possible for the whole browser market to drop JavaScript and replace it with something designed properly for the task, I'm sure they would. As it stands Javascript has strange prototype-based objects, a few neat functional programming features, limited and quirky collections and very few libraries.
For small scripts it's fine, but it's a horrible language for writing large complicated systems. That things like Firefox and Gmail are (partly) written in it is a heroic accomplishment on their part, not a sign that the language is ready for real application development.

Flash Media Server is scripted by using Server Side Action Script, which is really just javascript (ECMAScript). So, I do it a lot. In fact, most of my day was dealing with SSAS.
And I hate it. Though to be fair, a bunch of that is more related to the (not so great) codebase I inherited than the actual language.

I think server-side Javascript is guarenteed to take off. Its only a matter of time.
Mozilla, Google, and Adobe have so much vested interest for Javascript that it would take a miracle to dislodge it from the browser world. The next logical step is to move this into the server-side.
This is a step towards moving away from the hodge podge of Internet technology that usually includes all of these
HTML
CSS
Javascript
Serverside Language J2EE/ASP/Ruby/Python/PHP
SQL
I haven't heard much about the current state of Javascript Server frameworks, except that they are mostly incomplete.

I see server-side js will offer considerable advantages in future applications. Why? Web apps that can go offline, client-side db store, google gears, etc...
Following this trend, more and more logic are moving into the client-side. Use an ORM that works for client-side, and use another on server-side (be it PHP / Ruby / whatever), write your synchronization logic twice in two different languages, write your business logic twice in two different languages?
How about use js on the client AND the server side and write the code once?
Convincing?

Personaly i've been developing and using my own JavaScript framework for about 4 years
now.
The good thing about JS on serverside is that implemented in ASP Classic you don't need
any other plugin or software installed, besides i'm also using my javascript (client)
framework on my server, that allows me to enjoy of the same functionality and proven
performance of my functions at both environments client and serverside.
Not only for data validation, but also lets say HTML or CSS dynamic constructions
can be done client or serverside, at least with my framework.
So far it works fast, i have nothing to complain or regret except its great usability
and scalability that i have been enjoying during this past 4 years, until the point
that i'm changing my ASP Classic code to javascript code.
You can see it in pratice at http://www.laferia.com.do

Node.js has taken off and proven that server-side JavaScript is here to stay =)

I can't see most developers getting over their distaste for client-side JavaScript programming. I'd rather go to Java for server-side stuff before choosing JavaScript.