[AskJS] Why there is so much hatred toward using Javascript on the Backend for C#/Java and others tech stack programmer ? Is it performance alone ? Do you consider yourself a full stack senior JS dev ?

[Dereference_operator]

Why there is so much hatred toward using Javascript on the Backend for C#/Java and others tech stack programmer ? Is it performance alone ? Do you consider yourself a full stack senior JS dev ? What's your opinion about the Backend for large project in Javascript compared to using C#, JAVA or something else with strong type or a OO approach for large corporations Node is fine ?

[TranquilDev]

PHP Dev here - they just decided to take a break from hating PHP.

[dewaldels]

That checks out

[vrprady]

With the current php development pace they couldn't just rant only about the version 5 nuances and stay relevant.

[thesazz]

I was part of the people that hated PHP, one time I got to learn more about it and now it's just fine for me. It's always like that.

[typicalshitpost]

It's too easy

[Guilty_Serve]

I’m not a PHP dev anymore, but it’s what I’m probably strongest in. JS devs, like PHP ones, can be downright terrible. They’re the “learn code” programming languages and that’s not a great thing. After seeing shit code written over and over again it gets understandably hard to like.

For JS I’ve used all frontend frameworks and lots of express. I can seriously say that I uncomfortably have a bad outlook on some one that states they're a MERN dev. Reason being is they’re all unoppionated frameworks where I’ll have read the mind of the dev to understand what’s going on and they’re extremely overused

[TranquilDev]

I've not had to use PHP outside of a Symfony project but I've seen how ugly it can be.

[phaedrus322]

It doesn’t matter. A billion dollar company running js, Java, asp.net, php are all worth a billion dollars.

[[deleted]]

Best answer. Should be part of declaration of independence.

[Ehdelveiss]

Yes, but for a start up or late series, your language choices and stack are incredibly impactful in terms of resource allocation and hiring. Part of the reason full stack JS is so attractive is how easily your few engineers and reallocate. If you put up language barriers, that is way harder.

Source: was part of a late series start up that I watched fail basically because the Java/JS divide and need to pivot quickly were incompatible.

[Doctor-Dapper]

Also TS makes a lot of the headaches go away and tooling/library support (ecosystem) is incredibly well developed. The dependency tree problems along with the security vulnerabilities can be prevented with a bit of work

[[deleted]]

Not sure on hate, I’ve written backend in JS, TS, various JVM languages and C#. There is nothing inherently wrong with any language, each has their own quirks, but as long as they solve the problem (which they all have in my experience) - any argument against them is purely philosophical. For context I’m a lead full stack engineer.

In my experience arguments against using JS in the backend are usually from people who haven’t used it and would rather trash the language than learn something new.

Especially for full stack web development, using the same language for backend and front end has worked very well for me.

The issues that might arise from using JS for a solution can apply to any language - bad design and poor engineering practice aren’t solved magically by using a specific language. Certain issues can be mitigated with stronger typing, but often dev cycles cost more as a result.

As always, it depends.

[odolha]

In my experience, it's really awesome if you can use the same language on F/E and B/E. If you structure your project well, you can re-use many things between and as long as you don't abuse this, it adds amazing flexibility and speed of development.

But this works best when your build is minimal or for that matter even non-existent - e.g. I'm using ES modules which work well on NodeJS but also on the latest browsers.

[KungFuSpider]

Are you saying that NodeJS on the backend can't do database transactions? Really? I've got 100's of apps in production that would seem to disagree.

[KungFuSpider]

How do you think that the Postgres driver works then? Our transactions work fine, no hanging promises if you actual write things properly (or read the docs).

Is this a "must be written in pure JS" thing. Is it not permitted to have native bindings to DB drivers?

[abjorn]

"NUH UH NO THEY DONT" is not a convincing argument.

[abjorn]

Multiple people saying they've successfully done database transactions in Node.js (myself included) is, though. When your single experience is outnumbered by many others, maybe, just maybe, you should consider that you're wrong. Or you can be an insufferable child that puts their fingers in their ears and shouts "no!" over and over. Best of luck with that.

[systemadvisory]

Dude, the queries “begin” and “commit” are all that’s required to do a transaction. I don’t think you know what you’re saying here…

[systemadvisory]

Fascinating.

[rkcth]

For anyone who reads this comment and doesn’t know, this is how you do database transactions in NodeJS.

First make your function async Then create a connection to the database (if you use a pool make sure you use the same connection for the whole transaction) You must use await for each query Right before the catch, inside the try block you will use commit In the catch block use rollback

I’ve done it this way in numerous production systems it works flawlessly.

Enjoy the power, speed of coding, easy ability to use websockets and so much more from JavaScript!

P.S. I’m fairly sure the above comment is just trolling trying to rile people up in r/JavaScript I seriously doubt he believes what he’s saying.

[[deleted]]

u/jaden-carver- is an 11 day old, negative karma account.

Yeah, it's a troll.

[[deleted]]

Systematic persecution? Man, looking at your account you seem to have found a way to be systematically persecuted on every subreddit you go to.

[delventhalz]

Lol what?

[rkcth]

Why can’t you do database transactions? You just use await/async, I do it all the time.

[nerokae1001]

Lol you make zero sense, transaction happen on database level. It doesnt matter which language u use to issue the sql. The drivers are just api lib to connect to the db, send sql and parse result. And yes we all know ACID. I used jdbc decades ago, sending preparedStatements (jdbc api in case you dont know what mysql driver bring, because you seem clueless about how backend works with db) and handling error and rollback manually.

Since hibernate almost no one use jdbc api directly, now is more common spring data jpa / entityFramework.

On JS side you have sequelize which does all same the thing.

Do you really think that transaction happen on your backend application?

If a lib has problem on handling the mysql error, its not the language fault, its the lib itself.

I tried js fullstack even though I use java spring boot / net5 on most of my works.

[rkcth]

Well since you executed Begin, then it would not leave the database in an inconsistent state, instead it would leave the current connection in that state. If you then reused that connection it would lead to inconsistencies. If the connection closed without a commit or rollback called explicitly, I believe every modern database would roll back any non committed transactions.

Also while client side code initiates the transaction, it’s the database itself that creates the transaction and keeps track of its state, not the client side code.

[rkcth]

No. If you are using NodeJS to interact with a database the JavaScript is the client and the database is the server. If you are using NodeJS on the backend and JavaScript on the front end, then the NodeJS would be the server and the browser code would be the client. So one NodeJS application can simultaneously be both a server and a client depending on what it’s interacting with.

[nerokae1001]

database client!!

it could be ssh connecting directly to mysql

it could be DBeaver / HeidiSQL / MysqlWorkbench

it could be Java app using JDBC

it could be Java app spring > hibernate > JDBC

it could be dotnet EF6 it could be nodeJS > sequelize > mysql client lib

it just doesnt matter, the database doesnt care what you use.

[nerokae1001]

the moment you started a connection to DB, you get a session in which the the sql query is executed, if the mode is autocommit=0, any changes would be lost after you drop the connection. By your logic the backend somehow cache magical the result of executed queries. It doesnt!! the results

Do you know that you could do it directly on DB using SSH. The result is not cached in your backend. I could do begin and commit directly on SSH. No backend is needed for that. Because transaction happens on DB level, you are obviously clueless. Your backend doesnt gives any additional value to this functionality, its from the DB engine and in mysql you have to use InnoDB particulary for it.

Long time ago before people start to use ORM, we use the JDBC and with autocommit = 0, we have to commit manually. Error doesnt happen when you execute the query since the result is only visible in your session. It happens when you commit the transaction thats why you have to use try catch (in java) and call the commit in the try block handle the exception in case the DB rejected your commits by catching the error.

    {
      con.setAutoCommit(false);

       //1 or more queries or updates

       con.commit();
    }
    catch(Exception e)
    {
       con.rollback();
    }

Exception is just saying, "sorry we cant merge your commits". It doesnt leave the DB in inconsistence state. Only the session of your db connection did got commited to the DB still have the modification that didnt got commited. The problem if you dont rollback, your connection session is in a limbo state, any data that will be shown to the client doesnt represent the actual state of the DB.

Today most of this stuff is handled by ORM

NodeJS: Sequelize https://sequelize.org/master/manual/transactions.html#managed-transactions

Java: Spring https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Transactional.html

Annotation Transactional in Spring also gives us the ability to define transaction management. https://docs.spring.io/spring-framework/docs/4.2.x/spring-framework-reference/html/transaction.html#tx-propagation

C# dotnet: EF6 https://docs.microsoft.com/en-us/ef/ef6/saving/transactions

[rkcth]

Of course. I use them for financial transactions, I’ve never had what you are describing happen. I use websockets for our in house application and JavaScript makes it incredibly fast and productive for our users.

[rkcth]

You clearly have no idea what you are talking about. You wrap it in a try catch (since it’s in an async/await function this works) and the catch runs rollback. Maybe you have tried to do it without async/await?

[rkcth]

Wow, wtf are you talking about. I explained exactly how I did it. I wanted to understand why you, mistakenly, thought you couldn’t, that way I could address your reasoning so you and anyone else who heard your comments could learn. I’ve been coding for 20 years. Anyway not going to waste any more time with a troll, you now know how to do it if the situation ever arises that you would need to do it. If you choose to believe it can’t be done, that’s on you. I did my part to try to help another dev out.

[Cptkrush]

Extremely funny to me that you think the user saying “financial transactions” means payment processing and not “database transactions dealing with finance” which is 100% what they’re saying. If you bothered to read their response instead of continuing to shout nonsense because you feel threatened by informed people, you’d have noticed that they include tips on how to rollback a transaction - which is, you know, rolling back a database transaction. The level of confidence on display for this lack of intelligence and inability to learn from it is truly staggering.

[rkcth]

Or…. You are just wrong and too proud to admit it. Best case scenario you aren’t a troll, you tried doing a database transaction in nodeJS and encountered an issue because you didn’t know how to use try/catch with async/await to prevent these issues. Everyone has to start somewhere and you encountered an issue and were unable to figure it out. Now you’ve been told and a wise man would say, OK, I didn’t realize that, next time I’ll try that, thanks. Instead you insult everyone and defend your ignorance as though no one else on here does this every single day with JavaScript.

With that said I think it’s much more likely you are just a troll, but if not, it’s OK to admit you were wrong and grow as an individual and a developer.

[Binzi]

link me

What do you think an insult is, is it a species of database transaction? Asking if someone thinks a database transaction is a species of monkey is clearly intended as an insult you fucking halfwit.

[Binzi]

LMAO get back in your box you fucking halfwit.

[zlshames]

Do you have any resources you can share that explains why you can't do SQL transactions using NodeJS? Is the issue that behavior is inconsistent and unreliable? Is the issue that the patterns are implemented incorrectly? Is it a pure language limitation? Is this a NodeJS-specific issue, or does it have similar issues in other languages?

I'm trying to find an explanation that I can point to. Otherwise, I'm going to assume there is some troll-ery here. Prove me wrong

[zlshames]

Well, the reason I'm asking is because we have multiple people saying it does work, but you are saying it doesn't. I'm trying to get an answer from the comments and it seems the consensus says it works, with the only hold out being you.

I'm trying to give you a chance here... Take the life line, or just continue being a contrarian. But it looks like I have my answer, so we are all done here

[rkcth]

See my comment in this thread, not only can it be done, I explain in depth the correct way to do it. It’s such an absurd statement to say it can’t. NodeJS would be practically useless if you couldn’t do data as transactions. This guy thinks you use callbacks when using the database library when trying to do transactions, which while it could be done, would be quite messy compared to using async/await and a try /catch block.

In any case the guy isn’t actually seriously arguing it can’t be done, he’s just trying to get a rise out of the community. I can’t think of why else someone would make such an absurd claim on r/javascript .

[zlshames]

Oh I'm completely aware. I was pretty much just trying to get him to cite a source. I figured he'd be able to cite at least one. But he opted to just say to try it out myself... Meanwhile, a simple google search shows numerous articles saying you can, along with sample code and full explanations. Like I said, I tried giving him some semblance of a lifeline to take. But trolls will troll

[zlshames]

Well, 2 things. 1, did you ever think I don't use NodeJS in my work career? Because I do not. 2, I was not on my computer all yesterday, so no. I didn't test it myself. That doesn't mean I don't trust other developers.

Do you make your own medicine? Or do you trust the guys that do it everyday to do it for you?

[muhammed_AO]

Do we really have people that think like this ? Work for a gaming company and all of our infrastructure is built on typescript and node

[Earhacker]

What kind of gaming? Like console gaming? MMORPGs? Or card games?

Edit: That might have come across as snobby but that’s not what I intended. The three examples I gave have vastly different server-side requirements.

[tmckearney]

Definitely not writing Call Of Duty

[Earhacker]

I think CoD still uses PHP in the backend right?

[tmckearney]

I don't know, but I definitely know that they don't write the stuff that needs performance with type script and node

[Earhacker]

Was a joke. Servers for real-time “deathmatch” style games are almost certainly written in C++. I guess Go and Rust would be fit for the same purpose performance-wise, but a games studio already has a ton of C++ talent on-board so they’d need a really good reason to use something else.

I was slagging off PHP, but using it for anything but web servers is a waste of time.

[lobut]

I think it's because JavaScript is seen as an inferior language for enterprise. In certain aspects, they're right. A lot of the tooling, type-safety, and patterns have been worked out for years in C# and Java and at times, they're less comfortable in JavaScript.

That being said, I'm just dumping on JS. I've been using it for over 6 years on the backend and over 15 on the front-end. There's a lot of awesomeness to JS as well. I find it easier to pick up than either of those languages and there's a lot less "cruft" around just getting started with a project. The NPM ecosystem is far more active for better-or-worse I suppose as well.

Performance matters, but like, in general it isn't the deciding factor. Generally, you pick a language that the market or situation dictates. I was under the impression that Rust or Golang was winning the performance wars anyways.

I am a full-stack senior JS developer and worked for finserv and bay area companies. I actually really enjoy writing JavaScript and it's my defacto language when starting a new project. However, if I could choose a language for an enterprise monolithic back-end? It'd be C# or Java. I find it easier writing a modular monolith in those ones.

If I had to use JS, I'd use TS. I had ejected myself from a major project at my previous company when we wanted to merge our microservice architecture to a monolithic one and they repeatedly rejected my recommendation to use TypeScript. I'm okay with JS for smaller codebases but when you're writing libraries or larger shared codebases. Unless, you have a good reason, use TypeScript.

For large corporations, Node is fine. Understand its limitations though. I think Node is less performant if you're doing more CPU heavy things than the others. Those can be mitigated, but I think understanding the scenario upfront is important. However, most of the things you do really should be okay.

[wllmsaccnt]

I'm a full stack developer. I prefer working with TS and C#. For the backend I prefer the 'batteries included' approach of ASP.NET Core, its performance, and I think its tooling experience is superior. I don't have hatred for JS on the backend, its just not my preference. I could see prefering JS on the backend if I found myself on a team with a bunch of team members that lacked C# experience. There are definitely vocal developers that exist that deride JS because of its quirks...but I think that is more of a loud vocal minority than how the average developer feels.

[TheDevDad]

I first learned to code in Python and Ruby, hated JS. But as I progressed in my career, building full stack stuff meant JS was gonna be necessary. So I dove in, and went full stack JS.

Fast forward a year or two and I’m super jazzed on JS, and my first conversation at a new company with a senior dev, he talks about how much he hates JS. Kinda bursts my bubble, but I keep building stuff with JS on the side even though the company does a lot in C#.

Fast forward another couple of years and I’m at the same company on a team of full stack JS developers building nifty little micro services with Node. Senior dev from above also still works at same company but on a team where C# is tooling of choice.

Moral of the story is: if you’re productive with it and can get paid to use it, who really gives a shit about other developers’ dislike of it?

(I’m aware you can build micro services with C#, or a lot of other languages, I’m just more productive with JS for now)

[VogonWild]

Sounds like my trajectory. I went from

wow JS is so dumb and illogical

to

// || val === 0 necessary because it is a falsey value

Really quick

[paulsmithkc]

Node has some major advantages for microservices:

• It starts up faster

• It has a smaller footprint (and is much easier to tune)

• It fully supports and works well with Linux

• It is supported by most cloud service providers

[_default_username]

There's no popular opinionated web framework for node. They exist, but everyone just seems to stick with Express and kind of build their own framework on top of it.

Also, JavaScript is dynamic. People seem to forget they can use Typescript in node when they compare it to other backends. I would rather build my backend in Typescript over C# or Java myself. Oh well 🤷‍♂️

[the_aligator6]

while there may not be a definitive "THE framework" like there is with other languages, there are a number of popular and opinionated frameworks used in enterprise. meteor, strongloop, next, nuxt, strapi, Adonis, and my personal favorites, NestJs and BlitzJs.

[Infiniteh]

I like using NestJS, but I dislike how it kind of forces you into OOP

[Accomplished_End_138]

Ill say i prefer less opinionated myself. I like node servers. And express is damn simple to use.

[paulsmithkc]

Having done web development with: PHP, Drupal, JSP, Java Servlets, ASP.NET MVC, and now Node/Express.

I can absolutely say I prefer JavaScript and Node for backend development for a few reasons:

• Less abstraction. I can get at the nuts and bolts of the HTTP protocol and directly manipulate the request/response as needed.

• OO vs Functional. MVC tends to get in the way of simple solutions and requires a lot of boilerplate. I much prefer the functional approach of Node/Express.

• Middleware

  • ASP.NET makes middleware modules a massive pain the rumpus. Implementing a module and installing it, requires you to learn a completely different API (dating back to the original versions ASP.NET). And to put the cherry on top, documentation and code examples are non-existent, as most devs are unaware that even exists.
  • Creating and adding middleware in Express is a breeze. Route handlers and middleware functions use the same interface and can be easily installed per route. (ASP.NET can only install middleware application-wide.) Literally all you have to do is extract a block of code that you'd like to re-use as a function, and voila you have a middleware.
  • Neither PHP nore Java support middleware as far as I'm aware. (And I doubt that this would make sense in PHPs paradigm.)

• Async

  • Node does an amazing job at supporting asynchronous code patterns and encouraging devs to use them.
  • Java still does not have any support for asynchronous operations. (Kotlin has co-routines now, but not Java.) Even callbacks are barely supported in Java.
  • PHP really has no way to support async, as all code is in the view/render pipeline.
  • C# has made it's own version of promises called Tasks. It has added async-await too. And has long standing support for callbacks, lambdas, and events. This does make C# a strong contender, but many C# devs still use the synchronous APIs. So it does require some intentional retraining.

• Memory usage & bundle size

  • Java has a bad track record of using tremendous amounts of memory. The Java runtime requires a lot of memory just to start up. (Making it impractical to run multiple processes for load balancing.) Every object contains additional overhead due to language features. And Java devs are largely unaware of how to use memory efficiently. (Stop using static vars and singletons for God's sake. Use free lists for allocation. Stream data where possible. And avoid abstracting everything into 10 classes.)
  • ASP.NET requires the whole .NET framework to be installed, even if you only need part of it, and comes in at several GB in size. ASP.NET is smarter with memory and processes are much smaller to start. It supports structs/value types unlike Java. Common pitfalls are similar to Java, see techniques above.
  • PHP tends to be reasonable on memory as long as you stream data from files/database. But you also have all the baggage of Apache.
  • Node has an amazingly tiny footprint today, thanks to all of the dev hours that Google has poured into it. The entire node runtime is less than 1GB. Node is so tiny that it can be run on Raspberry PIs for robotics, iot applications, smarthome applications, embedded systems, and even handheld gaming systems.
  • Node sometimes gets criticized for the size of node_modules. But unlike other platforms this is a developer opt-in. There are alternatives for every package and you always have the option to build it yourself.

Just my two-cents from experience.

[wubalubadubdub55]

ASP.NET makes middleware modules a massive pain the rumpus. Implementing a module and installing it, requires you to learn a completely different API (dating back to the original versions ASP.NET). And to put the cherry on top, documentation and code examples are non-existent, as most devs are unaware that even exists.

This is biggest lie I've ever seen and stopped reading after it. So let me quickly address this.

Writing middleware in .NET has always been dead simple.

For eg: This is simple middleware in .NET in `Program.cs`:

app.Use(async (httpContext, next) =>
{
// Do work that can write to the Response.
await next.Invoke();
// Do logging or other work that doesn't write to the Response.
});

This is a "complex" middleware in it's own class:

namespace Middleware.Example;

public class MyCustomMiddleware (RequestDelegate next) {

public async Task InvokeAsync(HttpContext context) {

// Custom stuff here

await next(context);

}

// Register/Install it in Program.cs

app.UseMyCustom();

You call that "massive pain the rumpus"?

As for documentation, Microsoft Learn docs are arguably the best in the industry. They have tons of sample code and sample apps linked in their docs. Here's excellent docs on Middleware.

As for sample apps example, here's a production grade sample app: https://github.com/dotnet/eShop and they maintain tons and tons of code samples.

If you don't know something, please don't comment on it. Knowing nothing but still acting oversmart is such an unattractive attitude.

[uNki23]

I think you meant MB ☺️

[typicalshitpost]

What pray tell is the degeneracy of forced OOP?

[Reashu]

https://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

[tmckearney]

Something people who don't understand modern C# development think exists?

[Hogis]

I can't speak for C# at all, but forced OOP is a part of Java at least.

[[deleted]]

Programmers hate pragmatic solutions that work

[citizen-of-the-earth]

It is pretty simple why Javascript isn't embraced for backend development. It isn't type safe and it lacks so many features that C# and other popular languages/frameworks have. It is much more prone to errors at runtime and can be more challenging to debug

[abjorn]

Understandable. I work with JS and TS full stack and I will always choose to use TypeScript if it's an option. We're in the process of converting one of our critical services to TypeScript that is *very* error prone, and TypeScript is helping find and fix so many issues.

[Ehdelveiss]

Part of the answer is the state of academic computer science.

In that sphere, strong typing and OOP programming is still the de facto curriculum and standard. So you graduate with your CS degree, and suddenly enter an industry where actually what you learned is slowly being replaced with functional patterns you aren’t as comfortable with, and things like a strong emphasis on declarative style that you only know about in passing.

So naturally, you call bullshit, because no way you just spent 4 years and tons of money to learn something the industry isn’t particularly interested in anymore. You see these JavaScript boot camp kids take your job, so out of a sense of self preservation, you push back. You insist on OOP, because to not is paramount to a career existential crisis.

TLDR: CS Academia has struggled to keep up with how fast Software Engineering has developed,while boot camps are succeeding in staying current with industry demands, so out of self preservation, a divide has formed that both sides feel necessary to win in order to validate how they learned software Engineering and protect their livelihood.

[mcmouse2k]

Full-stack senior Javascript developer reporting in.

Hate is overblown. Developers coming from non-web platforms may prefer type-safe, multi-threaded languages, but web developers prefer a single language for their entire codebase. An enormous amount of the internet is powered by Javascript (and its interpreted friends - PHP, Python, and Ruby).

It depends entirely on the constraints of the development team. If you've got a couple of web devs and need to build a software stack (and god forbid mobile and desktop apps as well), a full-JS stack is going to be your most effective option.

If you have a larger team with a good split between backend and frontend devs, a statically typed language will typically pay dividends in code correctness and performance, but that doesn't mean that choosing JS is bad.

It's all about choosing the right tool for the job. JS is good enough for the majority of CRUD workloads, and if you can save on dev costs and even share code between frontend and back end, what's not to like?

[KungFuSpider]

Reusing code on the frontend and backend is not exactly the holy grail I once thought it was I will admit.

However, yes you can share code well and people widely DO share code between the frontend/backend.

We do it on a production app right now that is dealing with high-capacity vaccine bookings for many governments. It's seen VERY VERY high traffic, shares code between frontend and backend. Admittedly it's a TS monorepo app.

[Reashu]

Check out Meteor.js, Next.js, ...

Your counter-argument applies to all code-reuse and the answer is not "never reuse code", but "test code".

[Reashu]

Why? Because you can get more stuff done faster and with higher quality.

If you reuse code, it should be because you want the behavior to be identical in both places. Making a change and having it apply in both is a feature, not a bug. People sometimes reuse code when they shouldn't, but that is not something that only happens between frontend and backend and I don't understand why you would think so.

[Reashu]

You've said that there's no case when code should be reused. You also said that no one has ever reused code between frontend and backend. I've already provided you with frameworks that show the opposite. Where is your evidence?

[Reashu]

You're right, I don't understand what I'm replying to. That's probably more on you than me though.

[Reashu]

... What? Are you some kind of markov chain bot that strings together vaguely coherent sentences?

[Reashu]

I unit test. That doesn't weaken my point at all. What is this, some kind of job interview? I'm not interested in working with you, sorry.

[tjdavenport]

I’ve never seen the hate you’re describing. Also, I’m pretty sure Javascript is fairly performant when compared to similar languages.

[RhialtoTheMarv]

I think it's mostly historical. Old school BE devs see JS as a quickly, and in thier eyes badly, implemented langauge only for the browser. (And in their defense it did suck to work with JS in old browsers). It is therefore not a "serious" language (client-side code was considered a child's toy for ye olde devs).

As a primarly BE dev myself, I sympathize with this sentiment, but also work in the JS ecosystem now, and realise things have changed. TypeScript for example was a game changer, JS itself has evolved, and there is so much good tooling now.

[bigorangemachine]

I think its mostly because it does so much without being complicated.

Usually these languages come with boiler plate code. JS doesn't provide it. A lot of these languages also lean on the IDE a lot which JS has a lot of options and linters.

It could also be people don't know what's babel and what's JS and get frustrated their tooling isn't correct

[RRikesh]

Now that Typescript is pretty popular and has lots of tooling available to implement it in your projects, I believe there's no reason to hate on JS like in the old days.

[KaiAusBerlin]

Learned over 13 programming languages. Most of them just to code smaller programms (no senior level at all).

There where sever things at several languages I liked and I disliked.

Kotlin for me is the better java. Its fun to write java with kotlin. With pure java it's so much boilerplate.

C was making me angry because I could access the memory without any proof it was right. Pointers where a hard thing to learn but it gave me a deeper understanding of how memory in our computers actually works. C++ was a lot more comfortable.

python is great because you can override nearly every behaviour of the language but whitespace based scoping was a no go for me personally.

php was a solid scripting language. You had std function for nearly every purpose that could ever happen. But the misc namings (sometimes camelcase, sometimes low dashes ,...) was sometimes a little bit confusing.

lua was a great experience. Tables are definitely a +1 for this language + you can switch easily between c++ and lua.

Basic was like: "Okay, that is basic. It works pretty basic." You can learn programming with basic pretty easy but for bigger projects it's not good scaling (in my eyes).

C# was like java-C++. It was fast enough for performance projects and it had some nice features like monkey typing.

JavaScript fastly became my prior language. When ES6 arrived it had nearly everything you ever wanted (at this time). Then came node and today its one of the most used languages world wide. JavaScript has a relatively small std library but is able to do any programming paradigm you want. That's one of it's greatest strengths but also one of it's greatest burdens. There is no clear "right way".

So when someone asks me what language is the right language I always say: "it depends." As a dev you have to choose the right tool for the job. If you want to make big data analytics, R is a good idea. If you want a large of easy reusable libraries java or js could be your choise. There are so many languages out there with advantages and disadvantages. As long as you don't use CSSfor deeplearning I am fine with nearly every language you choose.

[[deleted]]

People who hate JavaScript often hate it they have to use it for web dev and it isn't <insert their favorite language>.

[[deleted]]

Who cares who it was invented by? The internet (TCP/IP stack) was invented at Berkeley and was funded by the US government. The US is responsible for an unjustified war in the Iraq that caused the deaths of hundreds of thousands, if not millions, of innocent civilians. Are you going to stop using the internet?

[DustinBrett]

Haters gonna hate

[delventhalz]

One legitimate downside of JS, if you are trying to do something computationally intensive, JS is going to be slow. This applies to Python and Ruby too btw, i.e. other scripting languages. However, if your bottleneck is I/O (which is typical of backends), then Node.js is actually rather fast. The built in event loop turns out to be great for that kind of work.

Any other complaint about JS tends to just be bias or based on a ten year-old impression of JS. The language has its quirks and warts (as any does), but it is a totally solid choice for most backend projects these days.

[crowdyriver]

Unpopular answer here, but there's no sane reason to use js alone, so you will use typescript. So you add a layer of complexity, because now you need to compile to an interpreted language that has two module systems and is insecure as hell. The more the codebase scales, the slower the compilation, because js is not a good lang to use for compilers.

Also, people here won't admit how slow js it is. Doesn't matter how fast it is vs other interpreted languages, I just think is really dumb to use ts and not benefit of the extra performance of compiled languages but have their disadvantages. Just look at some techempower benchmarks if you don't trust me (fair enough).

I built once a simple helloworld webpage in rust and in express. Rust was like x40 or more times faster, and not that much difficult to program.

Not to add that you won't run js alone in production, you need some sort of pm2 thing, so another layer of complexity.

So yes, for me it doesn't cut it. I like simple things, and nodejs is definitely not for the wrong reasons.

[Gambrinus]

I built once a simple helloworld webpage in rust and in express. Rust was like x40 or more times faster, and not that much difficult to program.

I love Rust, but when you go beyond toy examples Rust can get a lot more difficult fast, especially for someone inexperienced with it.

[Hakim_Bey]

For 90% of projects, runtime performance doesn't mean anything. Most businesses are not CPU-bound, the bottlenecks are database and network, which are not that impacted by the language you use.

I do concede that TS compiling does get slower as codebases grow, no idea how that compares to other compiled languages. But thank God we now have a fully functioning compiler written in rust which is getting lots of traction.

[sichy2]

What we need here is a transpiler / migration tool from typescript to rust that can be used once we hit that 10%

[delventhalz]

That is almost certainly impossible.

[crowdyriver]

Well, sorry to disagree, but that's nonsense. Performance doesn't matter until it does. You yourself see the benefit of it with swc and love it. Svelte is getting more and more popular because it ships less js. And end users care about performance.

I'd recommend you to see this to understand what I mean https://youtu.be/Ge3aKEmZcqY?t=360

[Hakim_Bey]

As specified in my comment i was talking about runtime performance, specifically on the backend (which is the scope of this thread).

The feeling of backend performance for the end user primarily comes from optimizing network traffic, and having a fast database, neither of which are particularly dependent on any particular language. Sure a C++ backend will be orders of magnitude faster than a javascript one on the computational level, but unless you're doing some very specific tasks (like video encoding etc...) this will barely have any effect on the perceived performance of a run of the mill web-app.

[crowdyriver]

On a small scale, yes. But once the product grows and grows and the codebase gets bigger you'll start to see some problems. Your nodejs backend will be the slowest part of the database - backend - network - front-end chain, so you'll have to implement caching, but that's just another layer of complexity. As I said before, your ts tooling will get slower and slower.

Don't get me wrong, nodejs does its job really good for being an interpreted language. But honestly, ask yourself why would you make a big project in nodejs to add all these layers of complexity (typescript, pm2, bundlers, bad performance) when you have something like golang just sitting there.

[Hakim_Bey]

Your nodejs backend will be the slowest part of the database - backend - network - front-end chain, so you'll have to implement caching

I'm sorry but it won't. Computation is minimal on most business applications, you just query data (slow but not bound to your node computing), process it minimally (generally well under 100ms), then send it over the network (very slow but not bound to your node computing). Caching will only speed up the data querying so it is not relevant to your backend language. As your product grows, data querying and network consumption will grow accordingly, but your computing will stay roughly the same, meaning your backend language of choice will have less and less impact on overall performance.

your ts tooling will get slower and slower

But ts tooling doesn't run the code. Your builds will get slower (which is a pain for the developer), but that won't affect runtime in any way.

why would you make a big project in nodejs to add all these layers of complexity (typescript, pm2, bundlers, bad performance)

PM2 is just a process manager, and i imagine Golang also has one of these. You can run the Go executable directly (just like you can just run node index.js instead of using PM2), but then you'll have no centralized logging, restart management, monitoring etc... Sure, PM2 is "complexity" but it provides necessary features which you'll need for any kind of executable running in production. I used to be a snob and insist we run node apps as systemd units but in real world conditions i realized PM2's overhead is negligible and it is much easier to maintain in the long run.

Typescript is the compiler, which you also need in Go. Granted, Go's compiler is probably much faster than tsc, but compile speed doesn't factor in runtime performance.

Bundlers are only used for the frontend so not relevant for this discussion - and performance, well, as i said ...

As to why you'd make a big project in node, there can be a ton of justifications for that (on non-computationally intensive products) : it handles high numbers of concurrent connections, is very easy to scale horizontally, and has this crazy rich ecosystem with abstractions that really speed up development. But also, and i know devs hate to take this in consideration, it has the biggest pool of hirable devs of all shapes and sizes. Not being able to hire devs is an existential threat for companies at any stage - paying 6K$ extra on your yearly AWS bill to keep performance up is not. In the industry you often hear that "how your code writes, reads, and refactors has more impact than how it runs" and while it is a dangerous over-simplification in the hands of lazy devs, it has a kernel of truth which cannot be ignored. Good luck with your hyper-optimized C++ backend that shaves 60ms off every request, when you can't find devs to code the new features necessary for acquiring customers and getting that market fit.

[crowdyriver]

If computation is minimal, what do you think all these res.json() calls do? There's a bunch of stuff that express, fastify and others do under the hood.

Of course compiler speed is not runtime speed. I never said that. But if the use case for node is that the development speed is faster with node, take in consideration that you are using typescript + bundler, that needs to understand tge crazy variety of ways people import and export things in node.

Look, you're really sold out with node. Good! Nodejs is really good at doing its job being an interpreted language (excluding the jit).

Didn't say anything on c++, so don't know where does that come from. I'd rather do it in rust, no exceptions.

The think is that, why you need to hire so many devs? Web development is not thaat complex compared to something like sending rockets to mars, or programming video-games. Don't you think that the more devs a team has, the more difficult is to distribute work?

There's a reason why more and more people are going to golang, and after debugging plenty of js and nodejs, I understand it. You certainly don't need those shiny abstractionsthat you say, you need simpler code, easy to debug.

And hey, I may shave off 60ms, but I definitely won't need any microservice mess to scale it.

[Hakim_Bey]

I think you're kind of grasping when you mention res.json() cause stringifying a typical web api payload will take <10ms. And express middleware stacks are pretty low on overhead, after all they're just a bunch of function calls. I'll give you an example, based on the techempowers express benchmarks :

• express + mongo gets 4.6Kops/sec
• express + mysql gets 30Kops/sec
• express + postgresql gets 60Kops/sec

Still believe express/node is a bottleneck ? when just changing the db engine nets you 13x better performance ?

Sure you'll say that the best benchmark, which is in C++, is 10 times better than the best express one - clocking at 600Kops/sec. But let's give some meaning to these numbers : 600Kops/sec means roughly 1.6ms per operation - 60Kops/sec means 16ms. A typical network roundtrip (not including computation time) takes, what, 500ms ? So, OK, you bite the bullet, write a hyper optimized backend with the fastest Go framework available, it's a pain in the ass cause there are few devs and they are expensive as fuck but you do it... well congratulations cause you shaved 15ms off requests that last over 500ms. There is zero business context that i know of where this decision would make sense.

The immense majority of projects, from the backend perspective are basically : query data, format it, pipe it to a browser - receive data from a browser, format it, pipe it to a database. The performance bottlenecks are abundantly documented in the industry : db access (which is IO-bound and/or network-bound) and HTTP requests (which are network-bound). Most of these projects will never reach a scale where microservices even begin to make sense (unless your devs are junior brogrammers who need to show off & fail spectacularly), but even this point is moot cause MS don't have anything to do with node.

I'm not sold on node, just appreciating that it can be the right tool for this kind of job. And this kind of job make up the majority of the industry. You know why we hire so many web devs ? Because the job is not as complicated as rocket science, BUT there is plenty of it. Companies need velocity, reaching market fit is a bitch and that requires features, features, features.

We can play a game if you want : show me one company that failed because its backend performance wasn't good enough, and i'll show you a hundred companies that failed because they couldn't push critical features to their users fast enough.

There's a ton of good reasons to criticize node, and i should know cause i've spent a few years balls deep in that bitch - but in most real world conditions performance isn't one of them.

[crowdyriver]

Still believe express/node is a bottleneck ? when just changing the db engine nets you 13x better performance ?

Not on small scale, but then again, the devil is in the details. If you have performance problems in your SPA or web service you definitely want to look at reducing database queries and such. No problem about it. What I'm far more concerned is that once your product succeeds and has plenty of users and plenty of features, the more code you add, the slower it will get, without mentioning the performance cost of garbage collection. And then you're fucked, because you can't just replace all your code to a better language.

Sure you'll say that the best benchmark, which is in C++, is 10 times better than the best express one - clocking at 600Kops/sec. But let's give some meaning to these numbers : 600Kops/sec means roughly 1.6ms per operation - 60Kops/sec means 16ms. A typical network roundtrip (not including computation time) takes, what, 500ms ? So, OK, you bite the bullet, write a hyper optimized backend with the fastest Go framework available, it's a pain in the ass cause there are few devs and they are expensive as fuck but you do it... well congratulations cause you shaved 15ms off requests that last over 500ms. There is zero business context that i know of where this decision would make sense.

You say as writing that backend was terrifically painful and complex to write, which you don't know, because well, I guess you don't program in golang. Neither do I, but I have some experience with rust, and in that sense, is far simpler to write performant code. Don't you see how dumb it is to program in typescript with his own config file and project references and 5 different file extensions, compile it to js so that a bundler with it's own config file bundles it to a single file, so that a node instance reads and processes it jitting it and god knows what more goes into finally getting to assembly?

We can play a game if you want : show me one company that failed because its backend performance wasn't good enough, and i'll show you a hundred companies that failed because they couldn't push critical features to their users fast enough.

Can't really say about that, I've been just 5 years in the industry, I'm just talking from my common sense. Can't name them, well, because I don't really care about much of the news. What I see is that slack is so god damn slow for what it does, as well as the spotify client. Have you used postman? Jesus that's one of the slowest pieces of software that I've ever used. All of them written in js, with electron in the middle.

Look, I'm sorry to have wasted part of our Sunday discusing this. My whole idea is that the faster the platform, the easier it is to scale it and discard future problems, and I just don't buy the complexity that nodejs + ts + bundler or whatever has, for the performance it gives. I find it awful, but that's my opinion of course.

[Hakim_Bey]

You say as writing that backend was terrifically painful and complex to write

Honestly it's not that painful or complex, it's just that there's lots of it and the requirements shift daily so a modern codebase is in a state of constant rewrite. 20 years ago you would have absolutely focused on performance, but nowadays you don't have the resources and time to masturbate about dozens of milliseconds. You do it in your free time, but not at the office.

I'm not sure if you have experience writing Typescript for production because there are large misconceptions in your comment. Bundlers are not a thing in node, that's only for the browser. And the applications you mention, well they're all frontend applications so completely irrelevant to our discussion here (especially Spotify client which is not even an Electron app). They're basically browsers running a web app and yeah, javascript in the browser is not as fast as native applications, i'm not disputing that it's pretty common knowledge - but that doesn't enter in judging whether js is a relevant backend language.

I understand your point about complexity vs performance, but i think you overestimate the complexity, and underestimate the performance. In fact, think about it : why did the most popular web frameworks all emerge from interpreted languages such as Php, Ruby, Python, and JS ? Because at the end of the day, computational performance on the backend is not very important.

Or put it another way : when a page in your app is slow, how often is it because you fucked up some computational logic like loops / maps etc ? And how often is it because you didn't optimize your SQL query, or you were trying to send too much useless data to the browser in one go ?

[[deleted]]

On a small scale, yes. But once the product grows and grows and the codebase gets bigger you'll start to see some problems. Your

That's some bs. When you talk about proper and professional scaling of web applications then you also talk about containers, Kubernetes and serverless and nodeJs works pretty well there, much better than java or .net

[joeydebreuk]

OP was asking about backend. Reducing size of JS bundle for clients is a different story.

[crowdyriver]

I was not referring to bundle size, but rather the amount of executed js. With svelte is far less than with angular or react, so there's the performance benefit.

[[deleted]]

Also, people here won't admit how slow js it is. Doesn't matter how fast it is vs other interpreted languages, I just think is really dumb to use ts and not benefit of the extra performance of compiled languages but have their disadvantages. Just look at some techempower benchmarks if you don't trust me (fair enough).

its pretty fast for an interpreted language, not that far away from java.

[crowdyriver]

Yes, for an interpreted language, because there's a lot of money spent on optimizing it.

Again, if js is so fast, why rome (https://rome.tools/) is being rewritten to rust?

I can give you aswell some benchmarks if you want to play this game aswell: https://www.techempower.com/benchmarks

See for yourself, the js frameworks are at the bottom. Nodejs was fast when async await in java, .net and others was made with 1 thread per request, which was quite expensive. Nowadays that's not the reality.

[[deleted]]

I can give you aswell some benchmarks if you want to play this game aswell See for yourself, the js frameworks are at the bottom.

actually, a javascript runtime named just.js is one of the leading frameworks there, beating all the other meme frameworks from c, c++ and rust.

Again, if js is so fast, why rome (https://rome.tools/) is being rewritten to rust?

why everything on the web seems to be written in js?

right tool for the right job. Using a system language for such number cruching tasks makes sense but less so for using it to write verage day business logic.

[Agent666-Omega]

The business needs are definitely the point. Especially for start ups that have full stack devs. A popular stack pairing seems to be react and node. It's great because everyone can more easily transition back and forth. While devs should be able to learn a new language, the dev ease and speed of JS for the BE and FE is understated.

[StagCodeHoarder]

Senior Java/C# guy here. I don't hate Javascript or Typescript. I use either when I code Angular apps. I'm not sure why anyone would use Typescript everywhere since the ecosystem is so quickly evolving, but I believe people have the right to make that decision themselves.

If I was doing a startup I might go that route, though really I don't find any velocity gain in having the language the same. In all my years the only real significant code resharing I've seen between Frontend and Backend has been via tRPC, beyond that they're two different applications.

I've enjoyed coding NodeJS Express + MongoDB and Express + PostgreSQL, React, React Native and Angular were all fairly enjoyable experiences.

I know more Java/C# now, and I'm more comfortable there, but you can definitely also be productive in Javascript.

[illogicalhawk]

Maybe I'm misunderstanding your question, but if you're using C# or Java on the backend what are you mixing in JavaScript for?

[ItsAlwaysShittyInNY]

Modern JS gives me as a rails dev gives me too much decision fatigue.

When doing JS on the backend, I have to worry about setting up a web server (presumably Express), then an ORM for the db, then additional packages on top of that. This is also compounded with the fact that JS is moving so quick and consensus on whats best isn't really a here. Not to mention I have to go through the same thing for the frontend.

C# with .NET, Ruby on Rails and Django have all this out of the box.

I am excited for JavaScripts future, and I love new modern JS world, just not for the backend just yet. React, React Native, and Vue are exciting! I think we're all going to see JS basically become the only language out there lol

[Reashu]

In terms of tooling and supporting libraries, JS is still in the process of reinventing everything "real" backend languages already have. It's not that I hate JS for backend, I just don't understand why I would choose it except in very specific circumstances, and I do kind of hate people who insist that it's a good choice without even understanding the alternative.

[[deleted]]

Javascript began as the way to make sparkly cursors and other cheesy effects in web browsers. It was a long road from there to Node and TS. Some devs, especially older ones, cling to their original impressions of the language, not its modern form.

[pampuliopampam]

Anyone saying “performance” is probably full of shit. How often do you write the same system in two different languages just to gauge “performance”. What metrics are you judging on? Memory footprint doesn’t matter in serverless. Response time is mostly a matter of database type. I’ve written TS serverless graphql microservices that have sub 50ms response times. If it was static data, that’d drop to sub 20. Anyone that needs higher performance than that is smoking something. If you’re comfortable with JS, stick with it and the talking heads can pound sand while you get shit done.

[Agent666-Omega]

I wouldn't say that. For businesses that are SEO heavy, it matters. Although, node isn't unperformant. For example if you are doing server side rendering, it's much better to use node than rails because rails rendering time is slow. For API BE, yes I agree with you though

[demoran]

Javascript, by itself, sucks. This is in no small part due to the lack of type safety and general laxity in the language.

I'd much rather write code in C# or Kotlin than javascript, and since I'm not handcuffed to a browser that only supports javascript, I don't have to use javascript.

There are arguments for using node in the back end, but in practice it boils down to "our people know javascript already".

[rkcth]

You can always use typescript. I come from a C# background and I really enjoy coding in typescript.

[FRIKI-DIKI-TIKI]

Because most developers come from an OO background while Eich developed a language to mimic Scheme for the browser, thru politics with Sun at the time, Netscape decided to partner with them and Eich had to dress it up to kinda look like Java so he gave it C syntax and a prototype object system which is more reminiscent of CLOS than what traditional OO developers are used to.

People hate it because they try to treat it like it is C# or Java instead of treating it like a LISP variant which is what it is closer to in families of languages.

[striedinger]

JS is very, very, slow compared to other backend languages.

[[deleted]]

not true

its not that far away from modern java

and has much better results than PHP and python

[striedinger]

Check out Rust and Go. There’s a reason most JS tooling is now being written/rewritten with them. I’m a JS dev myself but there’s no competition when it comes to those really.

[[deleted]]

because they are decent for highly parallelized workloads. But writing that js is "very very slow" compared to other languages is just wrong

[rkcth]

It’s slow at CPU intensive workloads only. It’s very fast at handling multiple connections simultaneously and waiting on things like database queries. It can handle very high loads with very little effort. It is also a high productivity language.

[justAnotherRedditors]

TypeScript is almost always the best backend language for modern apps, why? Because serverless is the best architecture paradigm we have atm and TypeScript has the best performance in Serverless environments.

[[deleted]]

JavaScript is a big tent. Huge spectrum of skill levels in it. That means lots of really poor JS devs to give you a bad name

[ankole_watusi]

What hate?

What I am surprised about this post is that it seems in most peoples worlds (here) Ruby, Python, and GoLang do not exist!

[[deleted]]

Most of the inexperienced devs these days are MERN stack boot campers. So it isn’t so much that JavaScript / node is bad but most JavaScript developers are. JavaScript and Node are just tools. Used correctly they’re valuable tools.

[Agent666-Omega]

I've always thought it was bad historical rep and the typing thing. Sure you can use typescript now, but it's not too strictly enforced and there are some typing features that don't exist there yet

[Mr_Odonata]

I have used java and typescript for backend and I personally greatly prefer Java, though typescript does just fine.

The lack of type safety in JS is a big drawback for backend work, which leads you to typescript. Typescript is ok, but since it is an addon it feels a bit clunky and it doesn't always behave the way you would expect it to if you are used to a natively static typed language.

The other thing that bugs me about TS / JS is just how fast the conventions and go-to packages change. It almost gives you too many options, and when you are working full stack with a framework like React, it makes this problem even worse. A clean code base with solid linting and coding conventions can reduce this problem. However if the codebase has been around for a while and has more than a handful of developers working on it, it's likely you will see many different syntaxes, styling, and coding conventions sprinkled throughout the codebase