Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
I've always considered JavaScript as a great addition (or rather, for the last couple of years, as a must have) to the client side of any web application. Even when I started to use Mootools, which takes a big step away from DOM manipulation, and aims toward a general purpose, OO framework, I still didn't think that I would consider using JavaScript for server-side development. JavaScript belongs to the front, period - that's what I thought.
Well, it seems like according to some damn smart people, I was wrong. For the first time ever, the web development platform contest called Plat_Form accepted a team that used pure JavaScript both on the server and the client side. What's more, here is what the contest organizers had to say about this:
"We had a single application of a team, Upstream Agile, that will work with JavaScript on both the server and the client side. Since this might become a major trend in coming years, we consider their participation a glimpse of the future and accept this team even though no others with this platform have applied."
So my question is: is this really a viable concept, to build multi-tier web applications purely on JavaScript? If so, what would be the advantages of using JavaScript for both the front- and the backend?
EDIT: The link in Vanwaril's answer (Why node.js is totally awesome) reveals an interesting discussion in the comments section that worth reading through. I, for one, have decided that though using Javascript on the server side is a viable concept and might have its benefits, I would definitely not start building an enterprise application with that architecture. At least for now. This question might need to be asked again in a year, I can imagine that the answer will dramatically change in the near future.
First off, have you taken a look at node.js? JavaScript is one of the languages that, over the last few years, has seen leaps and bounds of development, and its likely to keep growing.
In terms of functionality, it is less mature when compared to other server-side technology, but the active community is making it not far behind.
Finally, since its a language that runs on both the front and back-end, its implications for code-reuse and data-exchange formats make application development a whole lot faster.
I'm not sure its quite ready for production yet (unless you yourself are willing to contribute to the code-base) but server-side JavaScript is a good option to experiment with.
Unhosted is a "project" that is fully about javascript-only applications that run in the web browser only and use server just as storage for (encrypted) data. You will find some examples there.
To actually answer the question - yes, it is perfectly viable to build client-server web applications entirely in JavaScript, and frameworks that got traction in the intervening two years since the question was asked -- notably Meteor -- make this much easier than it used to be:
One Language. Write both the client and the server parts of your interface in JavaScript.
-- http://docs.meteor.com
We are building our CMS & frontends using http://Helma.at, currently serving ~ 250 mio pages / month. This is JavaScript through & through.
Note that this is not bleeding edge technology, as you seem to assume: Helma is in development since 1998 and we use it in production since 1999.
So my question is: is this really a viable concept, to build multi-tier web applications purely on JavaScript?
Yes, although the tools are relatively immature when compared to many other languages.
If so, what would be the advantages of using JavaScript for both the front- and the backend?
- No switching between languages for developers
- Code reuse (e.g. Want to check that data is sane? The same code can be used on the client and the server).
Server side code has to be particularly robust and well engineered, as it manages more than one client in a multi threaded environment. The complexity of business tier processes and the need for accurate code re-use has always lead me to write server side code in Java. I would not consider using Java script because it is aimed at a different usage.
That being said I do use Java script at the server for replicating client side validation scripts for example. That way you can use the one piece of validation code at both ends. The user gets responsive browser validation but the back end re-validates in case someone bypasses the front end validation.
This is not a new idea. In fact its so old to have been in fashion then gone out and is now coming back again.
Clasic ASP on windows server IIS can use javascript as the server side scripting language. it can talk to local filesystem and SQL sever etc. very very simple stuff.
You could easily write some ASP code that returns JSON to be consumed by your client side script ajax.
The problem is that MS have ignored classic asp and moved to asp.net (c# or VB.net) so we have to wait for the community to re-invent server side javascript to get back to where we where in 2001.
