Server Side Javascript: Why?

Question

Is the use of server side javascript prevalent? Why would one use it as opposed the any other server side scripting? Is there a specific use case(s) that makes it better than other server side languages?

Also, confused on how to get started experimenting with it, I'm on freeBSD, what would I need installed in order to run server side javascript?

Sogdian

Answer 1

It goes like this:

Servers are expensive, but users will give you processing time in their browsers for free. Therefore, server-side code is relatively expensive compared to client-side code on any site big enough to need to run more than one server. However, there are some things you can't leave to the client, like data validation and retrieval. You'd like to do them on the client, because it means faster response times for the users and less server infrastructure for yourself, but security and accessibility concerns mean server-side code is required.

What typically happens is you do both. You write server-side logic because you have to, but you also write the same logic in javascript in hopes of providing faster responses to the user and saving your servers a little extra work in some situations. This is especially effective for validation code; a failed validation check in a browser can save an entire http request/response pair on the server.

Since we're all (mostly) programmers here we should immediately spot the new problem. There's not only the extra work involved in developing two sets of the same logic, but also the work involved in maintaining it, the inevitable bugs resulting from platforms don't match up well, and the bugs introduced as the implementations drift apart over time.

Enter server-side javascript. The idea is you can write code once, so the same code runs on both server and client. This would appear to solve most of the issue: you get the full set of both server and client logic done all at once, there's no drifting, and no double maintenance. It's also nice when your developers only need to know one language for both server and client work.

Unfortunately, in the real world it doesn't work out so well. The problem is four-fold:

1. The server view of a page is still very different from the client view of a page. The server needs to be able to do things like talk directly to a database that just shouldn't be done from the browser. The browser needs to do things like manipulate a DOM that doesn't match up with the server.
2. You don't control the javascript engine of the client, meaning there will still be important language differences between your server code and your client code.
3. The database is normally a bigger bottleneck than the web server, so savings and performance benefit ends up less than expected.
4. While just about everyone knows a little javascript, not many developers really know and understand javascript well.

These aren't completely unassailable technical problems: you constrain the server-supported language to a sub-set of javascript that's well supported across most browsers, provide an IDE that knows this subset and the server-side extensions, make some rules about page structure to minimize DOM issues, and provide some boiler-plate javascript for inclusion on the client to make the platform a little nicer to use. The result is something like Aptana Studio/Jaxer, or more recently Node.js, which can be pretty nice.

But not perfect. In my opinion, there are just too many pitfalls and little compatibility issues to make this really shine. Ultimately, additional servers are still cheap compared to developer time, and most programmers are able to be much more productive using something other than javascript.

What I'd really like to see is partial server-side javascript. When a page is requested or a form submitted the server platform does request validation in javascript, perhaps as a plugin to the web server that's completely independent from the rest of it, but the response is built using the platform of your choice.

Thermomotor

There is no way you just typed that... :p – Purusha

:) The last time someone asked a question like this it was closed just before I could hit submit. I had enough work in the post I decided to save it. – Thermomotor

Is there something wrong with this question? why was a similar one closed? – Sogdian

Dupe. Why else? I'm a little surprised this stayed open, given the first answer linked to both previous questions. – Thermomotor

Plus: 4. Most web programmers use JavaScript not because they like it, but because nothing else is available! Doing the whole app in that accursed language would be painful. – Forevermore

Definetly JavaScript is miles better than VBScript with ASP. At least you can use objects. – Respectable

Also what's wrong with this question, is that it is "too broad" for stackoverflow. Yet, like many such "too broad" questions, I find the answers quite informative! – Consultation

I find it very interesting reading this question and answer a decade later as a javascript developer. One other answer is some environments are fixed (i.e. you can't install anything). We used node in 2010-ish to solve this problem in a distributed environment where we had thousands of devices. We could run node with the exe without installing or turning on anything. – Velma

well explained.. and interesting. – Faefaeces

Answer 2

I think a really cool use of server-side Javascript that isn't used nearly often enough is for data validation. With it, you can write one javascript file to validate a form, check it on the client side, then check it again on the server side because we shouldn't trust anything on the client side. It lets you keep your validation rules DRY. Quite handy.

Also see:

• Will server-side Javascript take off? Which implementation is most stable?
• When and how do you use server side JavaScript?

Purusha

+1: You know, I never thought I would ever vote up anything in favour of server-side javascript, but your answer is good food for thought! – Busily

Answer 3

Javascript is a perfectly good language with a self / scheme prototype style base and a C style syntax. There are some problems, see Javascript the Good Parts, but in general it's a first rate language. The problem is that most javascript programmers are terrible programmers because it's very accessible to get started.

One team at google built out Rhino on Rails, which is an MVC framework like Ruby on Rails which is written in javascript and runs on Rhino a javascript interpreter for the Java VM. In this case they had a requirement to use the Java VM, but wanted to get a language which was fast (javascript is fast), supported duck typing, and was flexible.

Another example is something like CouchDB, a document oriented database which uses json as it's transport format and javascript as it's query & index language. They wanted the database to be as web native as possible.

Javascript is good at string and dom (xml) manipulation, being sandboxed, networking, extending itself, etc... Those kind of features are the thing you often do when developing web applications.

All that said, i don't actually develop server side javascript. It's not a bad idea, but definitely less common.

Stauder

Answer 4

Javascript is just a language. Because it is just a language, you can use it anywhere you want... in your browser, on the server, embedded in other applications, stand-alone applications, etc.

That being said, I don't know that there is a lot of new development happening with "Server-Side Javascript"

Cambogia

Answer 5

We use javascript on the client because it is there, not because from a list of languages it was our choice. I wouldn't choose it for any chore on the server.

You can run any language you like on the server, in fact, as many as you like.

javascript is reliable and easy to use, but it is just too labor intensive for common tasks on the server.

Malo

Answer 6

I have used both Javascript (NodeJS) and compiled languages (such as Java or C#.NET). There are huge discussions on the internet about which is preferable. This question is very old (2009). Since then the Javascript world has changed considerably, whereas honestly the Java world has not changed much (relatively).

There have been huge advancements in the Javascript world with Typescript, amazing frameworks (such as Next.JS), reactive programming, functional programming, GraphQL, SSR etc.

When I look at compiled code, especially Java code it all still seems to be the same old tools - Spring (maybe SpringBoot) and Jackson. .NET has advanced server side, but not to the extent of the JS world.

Sure my list there can be used with several languages, but I believe Javascript has improved the software engineering world considerably.

Server side development with Javascript, Typescript and NodeJs is engaging, fun and productive. Use it and enjoy it. Like millions are today.

Tangleberry

so it wouldn't be wrong to say Ryan dahl single handedly changed the face of software engineering when he created NodeJs on a very popular but disregarded language, JavaScript – Giavani