why server side Javascript is not widely used? [closed]

Question

we know JavaScript is one of the most popular and widely used language in front end.i wonder it is not widely used in back end ?

Abatis

Because it's not really meant to be a server-side language? – Uprush

this is neither subjective, nor argumentative. It's a valid question with real answers. – Triplicate

the first time I saw a runat="server" attribute on a script type="text/javascript" tag I threw up in my mouth – Meson

@Meson That's just one implementation. You can't write off all back-end Javascript because Microsoft made a mistake. – Toleration

@Assaf Lavie: It most certainly is subjective, there is no one specific answer why JavaScript is not more popular for server-side. This should be on programmers: programmers.stackexchange.com – Scheer

having more than one answer doesn't mean it's subjective. If you can't think of any meaningful reasons why JS isn't used in the server side, aside from language wars and personal preferences, then you can ignore this question and not participate. I, on the other hand, do think that there are clear and objective reasons why the server side is dominated by certain languages and not others, and I certainly don't see justification in closing such a question just because it has the faintest whiff of attracting answers that are subjective and stem from personal preference. – Triplicate

There's absolutely nothing wrong with server side javascript. Just filter the evangelism out of the answers and you'll end up with javascript as a possible server side language. I programmed complete database/ajax-driven websites using server side javascript, a large and complex diagnostic research questionnaire (hta) and server administration tools (admittedly for windows servers), no problem. Programmers are a conservative species, and many will keep disregarding javascript as 'not a real language' I suppose. Use your own judgement I'd say. – Boffin

Answer 1

It's becoming more widely used thanks to Google's V8 engine. Take a look at Node.js. I think poor performance limited it's effectiveness before.

Node.js lets you write multi-threaded custom web services in the blink of an eye and in a mostly OOP manner. I think you'll see that Javascript on the back-end is just beginning it's run.

I think the only thing holding it back is — as others have said — the lack of a neatly packaged and standardized (for Linux at least) drop-in solution. This solution would then need to be picked up by the major hosting companies and added as part of their product offerings for it to really take off IMHO. If that happens then I think you'll find that it will explode into the back-end server space.

Microsoft has offered the ability to program back-end systems with "Javascript" (AKA JScript) since 1998 with it's ASP offering. You still can develop ASP.NET applications with JScript. So it's nothing new. I think the reason it isn't widely used for ASP or ASP.NET applications is because VBScript is the "default" and C# seems to be the preferred language for more experienced professionals. But there is nothing stopping you except company policies which often restrict developers to a single language for corporate development. One reason JScript might not be used much by corporate entities is that it "appears no longer to be actively developed." In fact Microsoft never really "marketed" JScript to developers. Or at least not nearly as much as they did C# & VBScript. So I think that may have held it back.

Toleration

I think poor exposure limited its use before. It was available for server-side use at a time when other server-side mechanisms also had serious performance issues, people just didn't particularly use it. +1 for the nodejs stuff, though, and the observation that it's probably just about to take off. I've been using JavaScript on servers for years, it's just so convenient to use one language throughout. – Fissirostral

Poor performance is no reason, I programmed PHP, .NET (c#), Perl and JScript, JScript not being the poorest performer. – Boffin

Added comments about what I think is holding it back, and proof that it has been around since 1998. – Toleration

Answer 2

JavaScript is popular and widely used on the front end because it has critical mass, not necessarily because it's an excellent language. Nobody makes the decision to write JavaScript for client-side code; they simply must, because every browser supports it. On the back end, other languages (Java, PHP, Python, Ruby, ...) offer advantages that JavaScript can't.

Edit: In 2022, I received reputation for this answer, which inspired me to revisit it. Twelve years later, of course, JavaScript is commonly used on the server side, although in many cases it's a compilation target rather than being used. The engine for this has been Node.js. Along with a language like TypeScript or PureScript, you can achieve good performance and reasonable developer ergonomics, as well.

Imperative

Indeed, CoffeeScript is an attempt to avoid the requirement of writing (traditional) JavaScript in the browser, either. – Andyane

Answer 3

I'm not an expert on this, but Douglas Crockford says in "Javascript: The Good Parts" that JS essentially became popular in the browser by accident, not because of merit.

"Javascript is a language with more than its share of bad parts. It went from non-existence to global adoption in an alarmingly short period of time. It never had an interval in the lab when it could be tried out and polished... when Java applets failed, Javascript became the 'Language of the Web' by default. JavasScript's popularity is almost completely independent of its qualities as a programming language."

Different browsers implement it differently, and it's harder to say what's correct than it is for languages with a standard interpreter.

It does have good features, as Crockford's book explains, and node.js may prove that it's great for server-side development. But so far, where people have had choices, they've mostly chosen other languages.

Andyane

Answer 4

Short answer: Because there are far better alternatives.

Long answer: Because it is wholly interpreted (and often not well - e.g. IE6), provides no standard I/O mechanisms other than what the environment gives, has a loose grammar that results in difficult to verify code, and many people find prototype-based OO a lot harder to deal with than class-based OO.

Recliner

"Because it is wholly interpreted..." Haven't been keeping up? "provides no I/O mechanisms other than what the environment gives" So, like every other language in the world, then. I/O isn't a language feature, it's an environment feature. "has a loose grammar that results in difficult to verify code" The grammar is not loose. I agree code verification can be challenging with rich dynamic languages. – Fissirostral

@TJ - That Google project appears to be an interpreter, not a compiler. I meant it contains no I/O in its standard implementation, unlike C, C++, C#, Java, etc. I would describe optional semicolons except when they're not optional as a loose grammar feature. – Recliner

Could not agree with you more about the idiocy of "semicolon insertion," you're quite right there. Wow I wish they'd fixed that in strict mode. V8 is basically a JIT compiler rather than an interpreter. In fact, it's an optimizing JIT compiler (most recently a two-phase with hotspot analysis and optimization). There's no reason an interim format can't be stored (Rhino does this; compiles JavaScript to Java bytecode), the language doesn't prevent it other than requiring that you allow dynamic constructs. – Fissirostral

A language is neither interpreted nor compiled. A language just is. It's a set of abstract mathematical rules. Compilation and interpretation are traits of a specific language implementation. With very few exceptions, almost all existing JavaScript implementations are compiled. V8, IronJS and DMDScript are, to use your words, "wholly compiled" (meaning they always compile, they do not even have an interpreter), Nitro (Safari), TraceMonkey/JägerMonkey (Firefox), Chakra (IE), Carakan (Opera) and Rhino are both compiled and interpreted. Only JScript (ancient IE) is "wholly interpreted". – Professional

Clearly I haven't been keeping up on that front. Thanks for the info. – Recliner

Answer 5

I'd say it's just an accident of history. Javascript was born at Netscape as a client-side language and never made the transition.

Comparing it to the prominent server-side web languages today, I think the most obvious difference is that the batteries aren't included with Javascript. There is no standard library.

Compare that to Python, PHP, ruby, etc which all have fantastic standard libraries that make web programming far more palatable.

Azurite

Nitpick: Actually, JavaScript was born as a web scripting language for both client and server. In fact, the reason why it was originally called LiveScript (and not, for example, NavigatorScript) was because it shipped as the scripting language for the Netscape LiveWire web application framework which was part of Netscape Enterprise Server 2.0 and later. I agree with your conclusion, though. It's kind of hard to use a language for serverside programming, which cannot even read a file from the file system. – Professional

Answer 6

On the server people are not obliged to use a specific language, and JavaScript is so free-form that code becomes very difficult to maintain.

That's why the largest percentage of people choose something else.

Successive

Answer 7

I think the answer might be that what's good for client-side isn't always good for server-side. For example, Javascript (ECMAScript in general.. also ActionScript) is a very lax and forgiving language, that allows you to get away with lots of stuff. In the client-side this is often not only acceptable but also preferable. You often want your UI to be as smooth and forgiving as possible, to improve user experience.

On the server side, however, it's usually a different story, and that's why, I believe, the languages that dominate that side are more strongly typed and rigid.

There's also the issue of scale. What works for the generally smaller code-base of a client-side UI application doesn't always work for the server side, which has to deal with a host of issues that aren't really a major concern in the client-side. e.g. performance, packaging, scalability - these are much more important to server code than to client code (usually) and so it's understandable why people would not choose JS for server side work.

Triplicate