What makes (or why is) a language Server-Side?

Question

Since Swift 3 is boasting its new capabilities, it occurs to me that I don't actually know why Swift is server-side. I've been hunting "Full Stack" and the listings have MEAN, they have C#/ASP, some do MongoDB, Hadoop, Rest/SQL, but my main point is the interface language.

I was thinking, could it be network requests? All languages do Remote Procedure Calls. Then I was like "What about HTTP requests?", but they all do that also. I found a similar question on differences between, (posted in comments). But in nothing more than an epiphany, I realized all of them are interpreted on some level.

Are they server-side because they run "on the spot?", yet Swift is compiled and Java is a gray area (pardon my ignorance with bytecode if I'm wrong here).

Server-side javascript can take a POST request and process it now, but so can wordpress with an .htaccess modification (well, technically Apache's server, but still, the idea of a dynamic request stays the same).

So... why is Java with Grails a thing, but you never hear of C++ running a database request as "Full stack dev?"

Based on my level of ignorance, a simple "They are interpreted" if that is it, would be fine. Or "It can grab from a database" or "It processes queries fast enough to not hit the TCP/IP timeout limit of 60sec". I just, don't know why php is server-side and Objective C/C can't be.

I understand practicality on "shouldn't be, because too complex", but the solid, defining line on can/can't be server-side by taking requests and returning a database call, that is puzzling.

EDIT: Before writing this, I kept the idea that there's only one type of server. But Apache would "serve text" and while that text is processing it would "have data to process" while Swift/Express.js/Node would "be" the server and feed the data directly. I suppose my question pertained to html and "has script" vs the "is the server returning the text", but the answers are still the same. Apache I guess is more "boxed into a package" where I need to use a language that apache runs. But otherwise can make a daemon in any language to "serve" pages using 8080.

Thank you.

Answer 1

the solid, defining line on can/can't be server-side by taking requests and returning a database call, that is puzzling.

Quite puzzling, I'd imagine, given that such a line does not exist for languages.

As pointed out in the comments, "server-side" is not an aspect of a language. It's not even an aspect of a language implementation (meaning whether it's interpreted, compiled, or both is irrelevant).

"Server-side" is an aspect of individual uses. When you call some code "server-side", it just means it runs on the server, as opposed to running on the client. If there is no server/client distinction for a program, then "server-side" may very well be a meaningless term in that context.

At most, in reference to an entire language instead of a specific use of that language, "server-side" may suggest that the language is often used for server-side programming or has features or libraries available that are particularly amenable to server-side programming. But none of that makes it so the language can only be used on a server.

Answer 2

Any Turing complete language can be used for both server-side and client-side, but some language are more fit to some roles. That fitness also depends on existing implementations of the language and on it's ecosystem, since you don't usually want to re-implement everything just for your one project.

Java and C#, for example, are fit for server-side because many of their weaknesses matter very little on the server. They require a big virtual machine & runtime to be installed, and applications written in them tend to use many third part libraries - but on the server these are non-issues because you can set up the tooling and the users don't need to bother with installing these requirements. Also, the VM's(at least the JVM - .NET is not that bad) take a long time to boot and load all the libraries(this really shows in JVM based languages like Scala and Clojure), but this matters not on a server that always runs and handles requests.

They also have strong suits that are important for server-side programming. They have a good concurrency model, so your server can handle multiple requests at the same time, and they have reflection which is important for application server frameworks.

Now, let's look at languages that are more fit for client-side - like Javascript. JS has qualities that make it good for client-side - chief among them is it's wide availability, being supported nowadays by virtually any browser(OK, maybe not the textual ones...). It's also designed to disallow interference with the environment except for what the host explicitly exposes to it, allowing browsers to prevent it from messing up the user's machines(you can still use Javascript the mess up with the users themselves - like with popups - but that can also be blocked)

Javascript's weak points are less troublesome in client-side applications. It does not support concurrency, but client-side architecture is usually event-based anyways, and JS does support that(especially with ES6), and it's lack of modules is not as painful in client-side, which tends to be smaller than server-side.

As others and myself have said, any language can be used for any role - but some languages don't fit very well for some roles. Java can be used for client-side, and it was in the past, but it's weak points really show when used like that and you don't often see it used for client-side in modern projects. Javascript can be used for server-side, and NodeJS is quite popular, but they NodeJS team had to jump through several hoops to solve the fundamental JS problems and make this possible.

So, those of us who cling to the idea the any language can be used for anything are welcome to use Brainfuck for both client-side and server-side. For everyone else I suggest to try picking a language who's strong suits match the role you'll use it for while it's weaknesses are less painful in that role.

Answer 3

What makes (or why is) a language Server-Side?

Answer: The fact, that it runs on the server's side - aka: something, which serves Webpages is written in some language. Simple as that.

In contrast, the only client-side-Language in use - mean: running in a browser - today is Javascript. There is no other but a historical reason for that. It does its job. End of story.

Nevertheless there are languages which are transpiled (="translated") to Javascript: like Clojure Script, Elm, emscripten (no language, it takes LLVM-Code and makes JS from it) or others.

Perhaps when Web Assembly is in use, Javascript as a language will loose its dominance as a language for the browser.

On the other hand since 2009 when Ryan Dahl created NodeJS, Javascript became popular as a serverside language. And with the advent of Meteor, the term »isomorphic web app« was coined.

So... why is Java with Grails a thing, but you never hear of C++ running a database request as "Full stack dev?"

The same goes for: Why are so few people using Haskell for webdevelopment; though there are frameworks like Yesod? It is a mixture of what is seen as »the right tool for the rght job«, easy to work with, commonly known, has better marketing etc.

Besides: There is Kore, which is written in C. It is to some degree usefull, but has a hard position against Rails, Flask, Spring-Boot, Phoenix, NancyFX and whatnot.

Answer 4

When people speak of client-side languages, they're usually referring to languages that run inside inside client software (as opposed to being used for writing client software). JavaScript, Lua, Tcl, and Lisp are examples of these languages.

I think it's more illuminating to look at why other languages aren't used in clients:

• You want a language that can execute in a run-time environment. This allows the run-time to abstract away platform differences, and to impose security restrictions. This is harder for some languages than others. Compiled languages are problematic because of the overhead of the "start-up" cost of compilation. Languages that expect direct memory and IO access are also unsuitable.
• Many scripting languages are custom-tailored to to their clients and have only limited features. Many clients only support one scripting language.

These reasons make some languages good candidates (sometimes the only candidate) as "client-side" languages; inside their respective client programs. It doesn't necessarily make them bad server-side languages. However:

• Some interpreted languages are much slower than compiled languages. This makes them less likely candidates for performance critical applications, on servers or elsewhere.
• Sometimes you need access to hardware or OS specific features that might not be available in the run-time environment (often by design).