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.

  • Similar Q, but not quite the same: programmers.stackexchange.com/questions/171203/…
    – Stephen J
    Commented Oct 13, 2016 at 5:49
  • 13
    Any language that can run on a server and can handle HTTP requests can be used for a backend. It's just that some languages are more popular than others. I've done a bit of “full-stack” web development with a C++ backend. There's no inherent reason why you couldn't use Objective-C as well, provided it has appropriate networking libraries. Of course, more popular backend languages will have more and better frameworks available which significantly reduces the programming effort. The language category “server-side” doesn't really exist.
    – amon
    Commented Oct 13, 2016 at 6:01
  • @amon: I second that. Regarding your comment about Objective-C: I have never used it, by I heard people say that WebObjects (especially the original Objective-C version by NeXT, not the Java clone by Apple) is still to this day one of the best web frameworks ever created. The Apple Web Shop and the iTunes Music Store are some examples of large websites that use (used?) it. Commented Oct 13, 2016 at 7:15
  • 1
    I agree with @amon but I would like to add something to it. server-side programming with regards to web technologies such as Asp.NET, php, Jsp means that the dynamic content you set on your html pages are resolved and populated on the server using those languages I listed above. Once the server has generated the page it is then sent to the client to be rendered into a web page. Client side programming would rather resolve the dynamic data received from the server and generate the page itself an example would be Angular and Single Page Applications Its a matter of where the data was processed.
    – SpaceApple
    Commented Oct 13, 2016 at 12:41
  • 1
    Also, in the context of Swift, the new feature is that it is being shipped in a configuration that will run headless on a server. Before this Swift was a desktop/iThingy language that was tied to all the libraries associated with a user-centric interface. You could not conveniently use it in a server environment, you had to have the whole GUI stack present.
    – Ukko
    Commented Oct 13, 2016 at 14:34

4 Answers 4


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.

  • This. And in many discussions, the only language that can be used in the client is JavaScript (because that's what runs in Web browsers), making all other languages "server-side languages" by virtue of not being JavaScript. Commented Oct 13, 2016 at 14:08
  • 5
    @RemcoGerlich If you're talking about web apps. There are plenty of other programs that have a client-server distinction, with clients often written in other languages. Web browsers themselves, multiplayer games, email clients. Even with web apps, there's options like Dart, TypeScript, CoffeeScript, and C or C++. Sure, they're compiled to JavaScript before actually running in the browser, but we generally prefer to talk more about the source language than the execution language when discussing what something is written in.
    – 8bittree
    Commented Oct 13, 2016 at 14:18
  • I suppose I should've kept my question in the context of database requests that are typically populated during an http request. Even then, what you said may still apply, but I am aware of multiplayer game programming via sockets, it just seems like this answer goes beyond the scope of my intent. I am not saying it is inaccurate, but my original confusion remains.
    – Stephen J
    Commented Oct 13, 2016 at 20:15
  • 2
    @StephenJ I don't think that context changes much (or possibly I'm just not understanding your confusion). "Server-side" is simply not a property of the language, it's a property of the executing code.
    – 8bittree
    Commented Oct 13, 2016 at 21:06
  • I've added another comment that might explain, where I am aware of "has a" vs "is a" servers, and previously kept trying to conceptualize both as one. That's impossible to do, so I kept hitting a gray line that would never fit. I suppose we get to choose "when" it runs on the server, either as the whole request, or inside another request. The rest, like you said, is the same as network programming.
    – Stephen J
    Commented Oct 19, 2016 at 0:00

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.

  • That was a good answer as an architect and decider-of-which to use. I believe my original confusion comes from there being 2 types of servers, and I explain it above in other posts' comments. I will upvote your answer, although I think your scope expanded.
    – Stephen J
    Commented Oct 19, 2016 at 0:02

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.

  • 1
    Javascript was used on the server before 2009. Classic ASP supported javascript and I maintained an application in 2007 in javascript and that application was old at the time. Commented Oct 13, 2016 at 20:02
  • 3
    I think the statement " the only client-side-Language in use today ." is overly broad. Taken literally, there are many client-side programming languages. I presume that you mean javascript is the only in-browser language. Commented Oct 13, 2016 at 21:00
  • 2
    @EsbenSkovPedersen: In fact, I believe Netscape's LiveWire Web Framework (part of Enterprise Server) shipped a couple of weeks before Navigator 2.0, which would mean that JavaScript (sorry, LiveScript back then) was a server-side language first and only became client-side later, but I might be wrong about the exact timeline. At any rate, Netscape developed and shipped LiveScript/JavaScript as a server-side language from the very beginning. Even if my timeline is wrong, it couldn't have been more than a couple of weeks, months at most. Commented Oct 13, 2016 at 23:29

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).
  • Right, the need to run "on the fly" eg embedded php kinda made me think they had to be interpreted at first, but then I stared at Swift router code, direct non-interpreted, so that's what caused me to to rethink my question (again). I forgot in my comments that security is definitely a factor, and permissions. Although if you needed hardware to respond, I would bet on an RPC or some other direct network calls. Perf is interesting because C++ is faster but booting up C++ is slower. Yet php has its limitations and must be run "by" something. Basically summarizing what you said, sans details.
    – Stephen J
    Commented Oct 19, 2016 at 20:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.