Thinking about doing server sided development, what tools should I use?

[Memory]

I've been thinking about trying server sided development for a while which is mainly related to the web but also other areas too like game development!

Some languages I've considered are: TypeScript (with Node.js or Bun), Rust (Rocket), and Ruby (on Rails).

Reasons why I considered them:

Rust: I don't really have the best hardware for hosting and thought about choosing a fast language to prevent having to pay for better hardware Rust fits that criteria while also providing other advantages like memory safety. I'm not sure if it's logical to have that mindset towards servers but better safe than sorry.

Ruby (On Rails): This is the "simplest" language for web development, since I don't have much experience with servers I thought it would be reasonable to learn it that way. This also happens to be the language Neocities was programmed in.

TypeScript: I feel that this a middle ground between the easy to use and performant languages, I don't really have much else to say about this language other than I heard that it's better than JavaScript and Node.js allows you to do it on the server but Bun is faster but experimental.

For others like PHP, I don't know what to say about them.

[Melooon]

I use Node.js for most of my server stuff these days; I used to use Java Servlets but those were hell! I find Node.js very fun to work with, but only because I know JavaScript really well. The HUGE number of npm packages for Node.js are also really handy.

PHP was one of my first languages and I didn't touch it for many years before getting into working on this forum, it's not as bad as I remember but debugging is a pain because its harder to dig up the logs 

I used to use TypeScript at my last job; it's just a wrapper language; e.g. so you write in TypeScript and then a program converts your typescript to JavaScript. It's handy if you have VERY large projects and a big team because it stops people messing up types on variables; but for individual projects, it's not really necessary unless you want the experience for your CV.

I've only done a tiny bit of Ruby, it's a nice language, so I'm not sure why it's fallen out of popularity.

I think they are all good choices for basic server-side features; it depends on which one you enjoy using the most! 

[Memory]

Probably a very unpopular opinion for hobby dev but I use C# 

You can use it for anything server side and games since its the language of Unity. To date I havent find something that compares to the ultimate dream experience that is using C# on Visual Studio but I know that my preference for the language is an acquired taste so no need to attack me for that 

.net (the framework of C#) now allows to compile C# to javascript or use them together which is a dream come true.

I have been working profissionaly with typescript for some years now but I dont like to use it for personal stuff, I really dislike the way the server code interacts with the frontend and how everything has to be an external library but on the other hand I find it very beginers friendly and cheap to get started, I consider it the modern equivalent of php for ease of access and use.

[Memory]

So use javascript instead of typescript? What are senarios where typescript is better or not?

[lime360]

there is cgi, which appears to be the first server-side technology ever

[Memory]

Are you suuuuure you don't want to use PHP? :P
It's actually pretty great and very accessible. It just has a bad reputation, partly due to how prolific it once was.

Probably a very unpopular opinion for hobby dev but I use C# 

I actually love C#, but I've never used it as a server langue. I just did a bit of app development years ago. I fully expected it to take over the world with how easy Microsoft made it to port apps to UWP, but it somehow never caught on.

there is cgi, which appears to be the first server-side technology ever

I only ever used cgi to install a news feed on my early sites. Way back before I could even comprehend Javascript. It was basically magic to me.

[Memory]

Are you suuuuure you don't want to use PHP? :P
It's actually pretty great and very accessible. It just has a bad reputation, partly due to how prolific it once was.

A while ago I saw a lot of negativity around the language so I didn't consider it when making this topic. Now seeing people say that it's better now while considering that there are a lot of pre-made tools (Wordpress, phpbb, etc) and there exist alot of cheap + cheap php hosters I might consider learning it as my first "server sided language". I'm still open to what you have to say about other languages (or just talk about PHP).

[Memory]

huh, what am I reading...

did you tried XAMPP? https://www.apachefriends.org/download.html it has linux versions on there
in case you don't want to use that and you're using a debian-based distro just do a sudo apt-get install php7.4 php7.4-fpm nginx (if php7.4 isn't listed in your distro then use sudo apt search php7) and then go to the nginx configuration (/etc/nginx/sites-enabled/default) and add this code for enable php on your webserver

Code

       location ~ \.php$ {
                include snippets/fastcgi-php.conf;
                fastcgi_pass unix:/run/php/php7.4-fpm.sock;
                default_type  application/octet-stream;
        }

[Dan Q]

there is cgi

CGI isn't a server-side programming language but a standard for how webservers can talk to programs. Many CGI programs were often written in Perl or C, because those languages were commonplace on the kinds of webservers people were using back in the day, but early versions of PHP were run using CGI, too! It's absolutely possible to use CGI with any programming language: I've used Ruby and Go over CGI, for example!

CGI basically describes:

• the format of the data that a webserver should send to a program (giving the program information like the URL the user requested, any request headers, cookies, etc.), and
• the format in which the program should return information to the webserver, giving it information like the response headers, the content of the resulting web page, etc.

The biggest problem (there are others!) with CGI is that it runs a separate copy of the program every time, which means it doesn't scale well. It gets pretty slow when you're serving to lots of users at once!

There are a few ways to fix this problem. One is to embed the programming language directly into the webserver software itself: this is what mod_perl and mod_php did for Apache, lua-native does for Nginx, and FrankenPHP does for Caddy, for example. This gives great performance but ties your programming language to your webserver, so upgrading your programming language requires reconfiguring or sometimes even recompiling your webserver.

A more-popular approach is FastCGI. FastCGI is a standard that allows the program itself to be responsible for threading the incoming requests: so instead of e.g. running the PHP interpreter for every single request that comes in, you run just one copy of the PHP interpreter and it handles each of many successive requests that come in. It's more-complicated for language developers to make languages FastCGI-compliant, but it's much better for performance.

Another modern approach is to reverse-proxy to a specialised webserver provided by the programming language (or its frameworks) itself. In this case, the webserver (Apache, Nginx, Caddy, or whatever) just passes-on most requests wholesale to a separate "webserver" running behind the scenes (this might be Express for NodeJS, or Passenger for Ruby, for example). This is very popular nowadays because it's very modular and fits well into "microservices"-thinking: you can have separate systems doing separate things and your webserver just acts as a load balancer. But it does mean that you have to do extra work to make sure the main webserver gets to do the thing that webservers are best at: serving static files! (You don't want every request for an image to have to be processed by your programming language if you can avoid it!)

So yeah, that's the state of play now. tl;dr:

• CGI isn't a programming language, it's a way for webservers to talk to programs
• traditionally those programs were written in Perl or C, but PHP started out this way and you can still use CGI today
• the most-popular modern approaches are FastCGI (similar to CGI, but more work gets outsourced from the webserver to the program) and reverse-proxying (even more work gets outsourced to the program; the webserver mostly just acts as a firewall and/or load balancer)

which appears to be the first server-side technology ever

I'm not certain that's true: I imagine that somebody wrote some server-side interactive code directly into their webserver software before CGI was standardised. I think NCSA HTTPd supported SSI, for example, which could be described as a server-side technology and might have appeared before CGI. Hard to be sure without better nailing-down what you mean by a "server-side technology".

But anyway: there's the history lesson!