What's the WORST commonly used language to use for server side web development? By this, I mean which is LEAST fit for the job, not which one do you hate the most.

I vote Java. It's lack of creature comforts like operator overloading and it's verbose and strict nature are in direct contrast with the free-form nature of the web. At least C# lets you do some crazy stuff.

They all spray gobs of traffic and eat resources while creating applications that users hate, so, all of them?

I'm voting js though, because the level of abstraction abuse is too damn high.

What does lack of creature means?

Java is fine for web development, I have seldom found a language that just wasn't fit for web development, C# is amazing for it as well.

If anything I would say CGI scripting was most definitely not fit for it. Which is why we had php invented.

At this point I am so fed up with web development that I consider basic php with composer to be the best tool available for it. Simply because we can just throw it at any server and it will work. JavaScript as well, making a full application with iy granted you know what you are doing will work for damn near all possible cases.

So cgi script it is, also cpp, very powerful, very prone to fucking shit up for the average developer.

When did you need overloading for a webapp?

As for the worst, maybe pure fp languages? A server has too many side effects to be modeled as pure fp, imo.

ASP.NET is the hackiest shit I've ever seen.
Okay, maybe classic ASP is even worse, but still.

Its very hard to say, I have used quite a few, and while I did dislike some, all did work to some extent.

So any list or choice will be very opinionated.

But my vote would be TSQL, yes there was a solution that used templates in sql server to directly build html for the web. All run directly inside the db server. That felt wrong even the first time I heard about it, even before I learned about SQL injections.

@kescherRant classic ASP damn near made me rich. Shit sucks but I still love it.

@AleCx04 "Should I really try to work with classic ASP in order to get money" is the same question to me as "Can I really spend $20 on a semen cookbook and continue my life as normal?"

@kescherRant ASP was quite capable and while lacking some things you had in PHP it was still good enough :)

We built a service in ASP that generated a couple of millions in profit and, while moved to AP.Net, it still going strong some 17 years later :)

You cannot really compare it to modern platforms.

@Voxera that sounds awful but really interesting (the tsql thing), what should i search for if i wanna learn about it?

@Voxera

ASP.NET just need some “love” for older technos.
Now that the whole world knows how “bad” are viewstates are and how you shouldn’t have inProc sessions, it’s fairly easy to disable all of it in WebForms for example. You can even disable Id generation.
Then nothing forces you to use WebForms controls. Just a p[lain HTML page with SOME back end functionality (Let’s say localizations).
The plug a JS framework of your choice and you are good to go.
Efficient ? Maybe not as last things in asp.core 3, but still stable, easy to use and production ready.

Frankly I find Java the most suitable for the job. JMX, javaagent (for transaction tracing and metrics), memory tuning, *strictness*, cleanliness and verbosity -- that's what I missed in C# and others. I'm not against C# - no - I just find JVM more... capable.

IMO javascript (and derivates) are least suitable for BackEnd. Lack of strict typing and single-threaded model is hell of a drawback if you asked me.

I only had very little to deal with server-side js (node) -- to maintain some mocks used in out client's system. They can't handle load... They only have a very simple job to do: to match a request method and URL and return a static response. And at that they suck hard :/

I can't imagine a js-based webapp serving tens of thousands of requests per second :/

@netikras did you find out why the load was such a problem? I think JS (node runtime) is actually quite fast. Of course you need multiple workers due to lack of multithreading... Though i DID once have a situation where a service could nit handle more than 20 requests per second, but that was due to a bad encryption implementation in node-soap (i think that was the package name) with client certificates. Still unfixed though... But i think that's not really nodes fault (i think the slow code is in a native module even)

@NoToJavaScript I have never been a fan of webforms and if you ever looked on any “webforms page” i built you would not see any view state or similar ;)

I used web methods a lot though :D

Knowing what web forms really was behind the scenes I did mot like it, to verbose and heavy for any complex page.

@eval
Nodejs, especially when used with server frameworks like express, have been shown to be on average 2.5x slower than comparable .net and java frameworks. Even with comparable pm2 configurations (20 worker processes) it doesn't compare on request volume at load.

The only thing node truly excels at by the perf numbers is regex.

For comp: we handle bursts of up to 1M r/s on meter transactions. And we're nowhere near what some in the game industry are doing:
https://ageofascent.com/2019/02/...
Node struggles at 20k/s.

@SortOfTested ok, interesting. Well my apps are nowhere near that. Also, i'd always be willing to accept 2.5 server cost for avoiding java :P

@eval
Its whatever your customers will tolerate. Just remember if you're paying for server time, your hosting cost is at least 2.5x what it has to be.

@SortOfTested one reason nodejs got a rep for being fast is that the only way to build using it it to enforce async as much as possible.

Therefore any site that handles at least a moderate load can often grow quite good.

You can do the same with java or c# but you are not forced to, which can make it easy to build something that works for a moderate load but tanks fast once it grows.

An pure async often survive longer before tanking.

But if you build right both the c# clr and jvm are much faster and have more features than node.

@SortOfTested interested on what you think Go as a server side stack

@Voxera
I'm not sure what the takeaway from that is.

@AleCx04
It's a newer stack, I'm watching to see where it goes. It's reasonably performant but still seems to be teething and feeling out it's sweet spot.

@netikras @SortOfTested as much as i dont like backend js, i have to admit its pretty good for pumping out an app asap

@SortOfTested that as in so many cases, its very rarely the language setting the limits but the developers.

Facebook was primarily built on php and mysql. Then they started to switch out parts as they needed better performance, using other databases, optimized versions of php.

Nodejs, due to being single threaded (unless workers are used) has a single main loop and requires you to do async or even a modest number of requests will block and tank the site.

C# and java with multithreading, can split up the work before your code gets involved, allowing for a larger number of requests before they start to block each other, and its most often db locking causing problems, not the webserver.

But if you use async with c#, you get all the benefits of async plus the performance if compiled code AND multithreading.

@Voxera except if you're successful and your load grows way above moderate levels you're in trouble with js, as concurrency will only get you this far when compared to multithreading. Now you either have to scale beyond levels you've never imagined your app at or you have to rewrite it all in a multithreaded technology.

Yes, concurrency is more effective than multithreading. But multithreading is SO much cheaper when concurrency hits its limits!

@netikras i dont quite understand why that is. Is it because when using multithreading you don't have your entire app copied and this is more efficient?

Because my expectation would be that as requests are generally independent it shouldn't matter weather you have 2 copies of service X or Service X can use 2 threads.

Writing correct multithreaded code is also not free in terms of developer time of course...

@eval how is this taxing developers in any way?
|
V

@yellow-dog this way it doesn't. But i don't see how this is (much) more efficient than just running multiple instances.

It might be a bit more memory efficient because some stuff can be shared nut that's about it. What am i missing?

Edit: well that was a fail :D

@Voxera
We're obviously talking about runtimes, not languages.

ITC is way faster, because it's generally in-memory and stack-driven. That's basic OS-level architecture and message considerations.

https://xunhuanfengliuxiang.gitbooks.io/...

Re: "writing multithreaded code is not free"

True, but you're rarely writing multithreading code in any platform. Erik Meijer introduced async await to .Net on top of the already existent Task async abstraction and it exploded onto a number of other runtimes, including node, where it builds upon Promise. Java on the other hand uses primarily futures, however neither of these is writing multithreaded code; different pattern, but still essentially a "callback". You choose a scheduler, a scheduler interacts with/manages a thread pool. It takes little to no time, but gets all the benefits of in-memory ITC. As a bonus, there's no need to handle cluster configuration.

@eval sure, running multiple instances works. But it also adds another layer of complexity as you need some sort of load balancer between them.

And that is quite a step up in complexity ;)

@SortOfTested sort of yes. The language only takes you so far.

If you have an abundance of performance the runtime is not a bottleneck and language has more of an impact, but once you start straining the hardware the runtime becomes more important.

On the other hand, by that time you should probably have started to scale horizontal instead of vertical and language and runtime looses out to load balancing and architecture ;)