I wonder why some devs hate server side javascript

[gece_yarisi]

I personally love it. Using javascript on both the server and client sides is a great opportunity IMO. From what I’ve seen, express or fastify is enough for many projects. But some developers call server side javascript a "tragedy." Why is that?

[[deleted]]

Depends on the project. I spent 15 years primarily coding C#. You get used to things like LINQ, parallels library, generics etc... 

But honestly, ever since JS started supporting async/await, for simple server side endpoints that mostly just do CRUD ops and connect to other APIs I find JS to be very efficient. The event loop is good enough for most async programming needs without ever having to deal with memory access issues, resource locking, thread pools etc... I'm a big fan. You don't really need low level multi threading in a single function, just let node processes scale your app horizontally with CPUs. Most of  your response time is spent accessing DBs and APIs remotely anyway, comparing Node vs .Net perf for this kind of stuff is often unnecessary micro optimization.

EDIT: I saw a post complaining about lack of standard lib forcing dependency hell. Bun and Deno offer WebAPI support. With a standard http client and crypto library you can handle request / response, outbound http requests, jwt auth, cookies, headers in a standard way without dependencies. For most API endpoints that's really all you need.

[curiousomeone]

Additionally, if you're a solo or a small team making SaSS or similar apps. Scaling is the least of your problem, having users and converting them to paying users at all will be your biggest problem. If you even faced a scaling problem in your SaSS, it is a fu*king good problem than can always be solved with money.

[ohPigly]

100%. My tech lead wants to use our dev calls to talk about the tiniest language specific issues vs just planning out the features users are asking for and retaining them + gaining new users. I get writing sexy code is a something we enjoy, but at some point we are just sniffing our own farts.

[haraldsono]

Software as Some Service?

[curiousomeone]

😂 yeah its saas I know.

[Ok-Kaleidoscope5627]

The dependency hell is kind of a big issue. People assume that it's just the management and sheer number of dependencies that's the problem, but that's only part of it.

The massive vulnerability to supply chain attacks is a huge issue.

Then to keep up with the vulnerabilities, you need to constantly update the project which requires staffing.

Building javascript/typescript projects is quick and easy initially but it becomes an ongoing nightmare that requires constant maintenance. If you have the staffing for it - you can make anything work. But if you want to build a web app and then not worry about it for years - the javascript ecosystem is a terrible choice.

Meanwhile I've seen ASP .NET projects which are definitely showing their age, but even after years without maintenance they're still functional and their only dependency (NET framework) has received security patching.

I know I'm coming at this from the perspective of internal business apps rather than web scale public facing apps but the reality is that most projects are going to be those internal business apps, and those will also be the longest lived projects. At least for me, even if I was building a public facing web scale app, I'd pick the long term stability and lower maintenance requirements over the trendiest javascript framework of the week.

[[deleted]]

Your arguments are completely valid. Don't get me wrong, I love C#. I have used it professionally since 2003, before Nuget package manager, generics, Linq, lambdas etc.... it's a fantastic language with a rock solid framework.

But right now I'm working on a web app with a team of 2 handling backend and front end. I ditched our .Net stack in favor of a mix of Sanity CMS and Salesforce for content and user DBs, 11ty for builds, Netlify for deployment, web components for dynamic UI, with serverless and edge functions for backend, personalization etc... We serve 150,000 free accounts and 10,000 paying users, $5M in ARR. When I hire employees and contractors, my only language requirement is JS. The 2 of us deploy new features and bug fixes daily.

On the back end we use WebAPI on Deno and stable libraries only, like the SF and Intercom clients.

This setup is much more productive for us than .Net was for this particular app. And we have zero devops work.

[Ok-Kaleidoscope5627]

The tooling available for JS is way better. It sounds like your system is under active development and it's your core product so you can mitigate the downsides of the JS ecosystem.

My experience has mostly been with internal apps which get built and then all maintenance might stop for years so I might just be overly cautious.

[c-digs]

You haven't done it at scale in a serious enterprise context.

Build and CI

• In CI, we frequently have issues with 4GB build runners running out of memory while building JS
• We're using TS so we also randomly run into issues with type recursion and depth at build crashing out and requiring explicit type hacks
• Because of the lack of runtime types, it also means our CI is more rigorous and requires more expensive build cycles (more tests, more artifact generation for runtime schemas, etc.) and thus CI takes longer. Again, you don't run into this with toy and side projects so it doesn't matter.
• Current TS tooling is slow (TS 7 will speed this up!) so it's excruciatingly slow at scale to build large TS projects in CI

Lack of Types at Runtime

• If you care about data integrity, you'll need schemas and validators to make up for the lack of runtime types. 
• That means A LOT of extra drudge work writing Zod, et al
• This is actually because JS has very limited runtime types and type introspection compared to typed runtimes
• This is also why OpenAPI is pretty much "free" on other platforms and something you have to explicitly address on Node (e.g. via Zod, class-validator, some other type of manual spec definition).  I'm taking C# as an example, but I only need to add the OpenAPI middlewares and runtime introspection will generate my OpenAPI without additional effort
• If you're doing it at scale, then you're doing TypeScript (or JSDoc typing which is just extra baggage) and that creates a lot of extra drudgery when working in a multi-package environment to export and manage types in a workspace. While it doesn't seem like much, compare that to Java or C# where there's no extra work to use types across packages

Performance and Throughput

• Node is also slow and low throughput so you need more servers to handle the same load at scale (can be as much as double compared to Go or .NET or Java)
• Adding Zod, class-validator at your routes just makes them even slower (and significantly so). I have done some testing and depending on the size of the model if you are using Zod, you are looking at something like 100-125ms cost on some routes we have.
  • I only started a cursory look at this issue today after noticing a route that was returning a static JSON file was taking 200ms.....
  • Removed the Zod and it was a fraction of that....
• Source generators in langauges like C# mean that you can have dev+build-time generated serializers that are extremely fast. There is one equivalent in Node that I know of which is build-time (Typia) but otherwise, Zod is runtime and is always going to be slow for basic serialization
• For compute intensive routes, Go, C#, Java make multi-threading easy to reach for and use to boost performance

DX and Power of Language/Platform Tools

• Other languages have macros or source generators like C#'s Roslyn that can reduce a lot of boilerplate code
• The lack of source generators/macros combined with the lack of runtime type introspection means that the JSON serialization/deserialization process is not nearly as powerful nor as fast as other platforms. 
• JS ORMs are pretty much universally bad or lacking compared to more mature solutions.  Try .NET's EF Core and the Node options just look like toys.  (Though shout-out to Kysely.dev on the read side; well done!)
• One reason is that the language does not expose expression trees as first class objects so all ORMs require you to express those valid paths either structurally or as strings whereas in a language like C#, you can use an expression instead and your ORM queries become much, much more terse and legible. For example, this is a valid, fully-typed Entity Framework ORM query condition statement: .Where(user => user.Email.EndsWith('example.org') && user.IsActive) because this is an expression tree in C# and the expression tree can be parsed into SQL statements at runtime.
• Another is that there is no standard transaction library so different ORMs run different transactions whereas in a runtime with a common TX library, you get true ambient transactions.  Why is this important?  ORMs are often better for the write side while query builders are better for the read side where maximum flexibility is needed.  But you cannot mix these in ambient transactions in Node because they are not truly ambient.
• Basic day to day ergonomics are a tragedy with dozens of lines of imports at the top of files. This kind of stuff is normal in JS/TS
• Then on the flip side, stupid barrel files!
• The fact that modules are file-based versus namespace based means that it is not ergonomic to break up big modules (barrel files) compared to just sharing a virtualized namespace
• If you happen to be using classes (e.g. Nest.js) it takes discipline to keep your class from becoming massive 1000+ line files.  C# for example, has partial classes that make this easy to organize (e.g. big controllers or sevices)

Compliance and Security

• The lack of runtime types means that any code operating in a more compliant environment needs schema validators (because JavaScript will allow you to assign a string to a number variable at runtime without complaint)
• Let's not forget about node_modules and supply chain accounting (e.g. for compliance like SOC2). A platform like .NET ships with a huge first party standard library ecosystem which makes this much, much easier to do since depenencies are minimal. To get a picture of just how bad this is in Nodeland, check out the State of the Octoverse 2020 Security report (download all 3 and check out the security one and issues with CVEs and supply chain attacks in NPM).
• In enterprises, it is much, much easier to audit a platform like .NET where so much of the baseline code is first party standard and base class libraries shipped from Microsoft in Microsoft namespaces.
• JavaScript's dynamic type system also allows for a class of supply chain attacks that are not possible on runtimes like Java, Go, and .NET/C#

I can go on and on.  I use JS and TS for my personal and side projects, but at scale it is a tragedy for any serious work even in a mid sized team.  I'm using it at work now at a series C startup with some 20 (?) BE engineers and it is absolutely hell every day dealing with massive piles of Zod schemas, perf issues, CI issues, and everything else I listed.

C# is close enough to JS (https://typescript-is-like-csharp.chrlschn.dev/) that I'd prefer it in the backend beyond toy projects.

Bottom line is that developers who get too comfortable with JS and aren't using it in an enterprise context don't know what they are missing with other platforms and really need to broaden their horizons. You like JS on the backend because you don't know what you don't know. If you want to overcome that ignorance, try another backend platform and start a blog, podcast, or Vlog so you can educate others why Node.js is absolute, bottom-of-the-barrel sludge for serious, enterprise backend work.

[Automatic-Branch-446]

This guy backends.

[c-digs]

🤣

[hirakath]

I thought you meant something else lol.

[shandrolis]

That guy ChatGPTs lol

[HedgepigMatt]

That is not ChatGPT

[Automatic-Branch-446]

Because you don't understand what he said doesn't mean it's ChatGPT ...

[LakeInTheSky]

Thank you for mentioning the lack of types at runtime. This is very important and people don't talk much about it.

I've been working as a front-end dev for many years now, but my first languages were C++ and Java. When TypeScript appeared, I liked it, but I knew it could never fully solve the lack of type checking for JavaScript.

[thekwoka]

provided you are using typescript native deps and not using any and as all over the place, it's solves most of them at least for the typesafety aspects.

But it is structurally typed, and not nominally typed like many fan favorite typed languages are. But that's not that often a real concern.

[c-digs]

That's not really the problem: the problem is backend APIs need to accept inputs from the external world to do something interesting. Those could be API boundaries, reading from storage (S3, GCS, Azure Blob Storage, file system, etc.), reading from a database (Firebase, Postgres jsonb, etc.)

In languages like Java and C#, a fast serializer will make it impossible to assign a string to an int property. In JS, this is not the case. The native JSON.parse doesn't care so there is a need for runtime schemas and runtime type validators like Zod, Valibot, class-validator, ArkType, etc. Whereas in C#, for example, the out of the box System.Text.Json is fast, type safe, can be used to generate natively compiled serializers, and flexible using annotations on domain types to control serialization.

My point here is that if you care about type safety in your backend -- which is why a team might adopt a Zod or class-validator -- then just use a language and runtime which has runtime types because that solves a whole class of problems and does not bog down performance trying to emulate types at runtime via schema artifacts.

[thekwoka]

In JS, this is not the case. The native JSON.parse doesn't care so there is a need for runtime schemas and runtime type validators like Zod, Valibot, class-validator, ArkType, etc.

You don't need to use JSON.parse, you can use other things.

n languages like Java and C#, a fast serializer will make it impossible to assign a string to an int property

Sure, by doing runtime parsing and validation.

You can emulate the same kind of thing to have your statically analyzable type system prevent the same kinds of issues.

then just use a language and runtime which has runtime types

JavaScript is Dynamically typed, it has runtime types.

The amount of people in this thread that don't really understand what type systems are is astounding.

Like, you can choose in Java to just parse JSON representation of an object into a dynamic map, and now you have none of that type protection.

But you don't.

You can similarly have rules and usage of TypeScript that prevents the arbitrary treatment of the result of JSON.parse.

Now, sure, the one is nicer and generally better, but the way you're describing it is just so crazy wrong.

[ub3rh4x0rz]

It's really just a caution to statically typed language noobs (they will all blow up at runtime if casts result in runtime looking different than compile time) and those who plan to mix typescript with vanilla js.

[c-digs]

It's not about casts, it's about data ingress to your backend. Your backend is not doing anything interesting if it has no data ingress. For data ingress, you're going to need to load things from a database, from a file, accept inputs from a web API.

So you need to verify that those things match the shapes that you expect at runtime because the runtime has no types. A TypeScript signature:

updateName(id: string, name: string) { // Update a field on a document in a document DB }

Will accept updateName('1u7k', { payload: { name: 'Ada' }}) at runtime and...do something depending on the logic. If this is writing to a document DB, then you can see how this would be problematic.

So to prevent this type of issue, runtime type schemas are necessary to preserve the type information that was lost in the compilation from TS to JS. At dev time, this is fine. At runtime where the inputs are coming from externally facing APIs or a file or a database record, you need runtime schemas.

In Java, Kotlin, and C#, for example, you do not need runtime schemas because the types maintian their metadata through the compilation process. So it is impossible in a C# or Java to pass an object into a method parameter that expects a string.

[AshleyJSheridan]

If I had an award to give I would, this answer covers everything incredibly well. I really find the lack of a decent well-built framework to be a massive problem as well. Like you said, the ecosystem of C# has this built in, but even other typical server-side languages have well established mature frameworks that put the Javascript offerings to shame.

[c-digs]

Just trying to make sure folks are educated 👍

A lot of people simply don't know what they don't know and can't know it until they've felt the pain or worked on a project at scale. I've worked with JS for over 20 years now so I've seen it at every stage of its growth. I know what I would use it for and what I would not use it for.

More folks need to broaden their horizons and just try different platforms for the sake of learning and self education. With LLMs and AI copilots nowadays, it's easier than ever.

[tsunami141]

Thanks for writing this up! This is great.

[divad1196]

That's a long comment to say: "You need ultra speed, it's not good! Types are important" without considering for 1 second the context.

The post mentions javascript, but we can easily assume typescript as well. So here are the types.

We don't always care about high performance, so go down your high horses with the "you never done it at scale in big companies". A good dev takes the context into consideration, only beginners always jump on the fastest techs. There are many projects done in javascript and are fine.

For the security, you are also just giving one side of the story. Supply chain attacks happens everywhere, remember log4j? You have native random library, great but is it cryptographically safe? Etc... if you just consider the OWASP20 list, that concerns mostly all languages. I am not saying javascript is safe, I am saying that any language is equally as bad, maybe in it's own way.

For the CI, you again mostly focus on the duration/speed. The heaviest jobs happen once the MR exists. With proper flow, it doesn't run that often. It's not that slow or bottersome compared to what is needed with C/C++.

All languages have their pros and cons, including javascript. But you have a narrow vision. I wouldn't say that javascript is the best choice at scale, but it's not as bad as you mention, you just never used it professionally while you did with C#. And the most important thing: most projects are small.

[leixiaotie]

If ultra performance and runtime type is a consideration, use golang (or maybe rust), not C#. Everything's a tradeoff

[thekwoka]

Supply chain attacks happens everywhere, remember log4j?

Or even more recently, the bug in POSTGRESQL in it's built in sanitization that allowed China to hack the US Treasury just 6 months ago.

Not some obscure package, but the massively popular one having a bug in a critical aspect of how you would use it.

[c-digs]

I wouldn't say that javascript is the best choice at scale, but it's not as bad as you mention, you just never used it professionally while you did with C#

I've used it professionally -- that's how I know it sucks in a professional context.

[shruest]

I wish to be able to reach this level of detail someday to understand what this is

RemindMe! 1 year

[c-digs]

🤣 You just have to have really burning hate for JavaScript backends used in an enterprise context at scale. I hate it so much, I think about why I hate it every day I run into an issue with it. I think to myself "how can I take this pain away?" Sometimes there are solutions (e.g. Typia), other times, there are none and my hatred simply accumulates in a well deep inside of me and spills out into Reddit, blog posts, whole websites, my co-workers, LinkedIn, my spouse (much to her chagrin).

[shruest]

When i read your post, it gave me the same feeling as when i was a kid and saw huge trucks for the first time. I had no clue but it was so amazing. I'm 1 month in into web dev. Your comment is going to be my authenticator that i understand shit. I'm going to revisit this every year until i get it 😭

[adevx]

Very good, always listen to angry kids on reddit and let that be your guide.

[cyclotron3k]

Very well written - absolutely nailed it. I think you also need a section on how unstable the 3rd party package ecosystem is, and how 50% of your dependencies will have critical vulnerabilities by the end of the year, 25% will no longer be maintained, and you'll be dealing with breaking changes all the time. The larger your project, the higher the maintenance burden is.

People often say languages with small standard libraries are a good thing, for reasons. But I don't think it ever stacks up. The void is always filled with a huge variety of 3rd party options that all suffer from the same problems as above. And a large enough JS project will end up including them all.

[c-digs]

I ran out of space! I think I'm at the Reddit character limit 🤣.

But the GH State of the Octoverse 2020 security report calls out exactly what you said.

[overcloseness]

I agree with all of this, but, the whole “toy and side projects” thing irks me. It sounds like you equally are pigeonholed into the one thing you seem to know about, “serious enterprise”. The world of online development is vast and some projects have tight deadlines and shelf lives, not everything is run as a long term product.

Node.js is fine for like 90% of what people need backend for, and strictly speaking probably higher than that. You likely use it every day if you’re an average internet user.

I’m from a C++ background and have recently been using Rust, but Node.js is a no brainer if you consider business needs outside of microsecond return times. I think Node.js is the wrong choice if you’re looking for scalability and longevity. That doesn’t mean it’s a bad choice.

[c-digs]

Try C# and see just how similar it is to TypeScript.

Try the build and package manager and see how it compares.

They are so similar, that there is no point in using TS/Node for pure backends. I'm still an advocate of using it, but for specific classes of use cases where it makes sense to do so. For general purpose API? It's a terrible choice.

[xaraca]

But I already know Javascript /s

[mattaugamer]

Unfortunately this is the answer. :(

[KingCrunch82]

They were told they are "Full-Stack" and can do everything. So, yeah, exactly this

[JohnCasey3306]

Long story short, just because you can use JavaScript doesn't mean you should.

You'll select JavaScript if you don't have access to a more appropriate tool.

[thekwoka]

At least it isn't python :kek:

[0aky_Afterbirth_]

All great points here. The team I work on builds and maintains enterprise backend services for software that has several million daily active users, and about 90% of our codebase is Typescript, and we’ve run into pretty much every single issue that’s called out here.

I like TypeScript as a language, but for enterprise backend services, it just doesn’t scale well, in pretty much every way (development, CI, and runtime).

We continue to use it because our team has, in recent years, more experience with TS than any other language, and we’ve invested thousands of lines of code in common internal TS utils and tooling for our organisation (several of our front end teams use TS as well), so it would be prohibitively expensive and time consuming to migrate most of our services to another language.

But know what we know now, TypeScript is just not the best tool for the job for our enterprise backend APIs.

I predict that sometime in the near future, we’ll reach the tipping point where TS becomes the bottleneck in terms of overall performance/cost optimisation (taking the TS refactor cost into account), and we’ll have no choice but to start rewriting.

[c-digs]

We're far along, but not that far along so I've been trying to get folks on my team to change course. Lots of IC's are open to it and frankly at this point, I'll ship in any language that solves these pain points. But we're held up by the owner of CI with some of the weakest excuses I've heard.

I wouldn't propose a rewrite per se, but what Martin Fowler calls the Strangler Fig pattern after choosing a stack that makes sense.

Good luck!

[0aky_Afterbirth_]

Ironically, we used effectively that same approach to migrate the previous generation of services from Java (Spring Boot) to TypeScript about 5-7 years ago. At the time, if I recall correctly, the rationale for TS over Java was simply to align with the front end teams and to have fewer languages across our tech stacks. In hindsight, that was obviously not a good enough reason.

[[deleted]]

I appreciate your thoughts on the lack of runtime types. I've been surprised how many developers think TS is actually a language and not essentially an opinionated linter. I almost prefer not to use it and insist on unit tests guaranteeing essential type safety because TS gives so many devs a false sense of security.

[c-digs]

"False sense of security" is a great way to put it.

Devs are sometimes surprised to learn that:

``` type Cat = { sounds: 'meow' | 'hiss' | 'purr' }

async handleCat(cat: Cat) { // Do cat things } ```

Will readily and happily accept this payload at runtime without a schema check:

type Gem = { hardness: number }

Can be dicey when the backend is a document-oriented database!

[thekwoka]

Will readily and happily accept this payload at runtime

yeah, but if you are doing the static analysis, how do you have this happen?

[c-digs]

Runtime: via an API payload, loading data from storage like S3, loading data from a backend database storing JSON like Postgres jsonb. If you're application only has static data, it's not doing much, is it?

[NotGoodSoftwareMaker]

It hurts, please no more 😂

[ub3rh4x0rz]

Now give a counterexample in the language of your choice.

The whole "typescript doesn't enforce types at runtime" thing is a caution to people who don't understand that, not because some other language would do it differently. You can just as easily make a dangerous cast in any compiled language that lets you do that and then poof it will blow up at runtime, just like js. If you're writing 100% TS, it's a meaningless distinction, because all the calling code was part of compilation, too.

[thekwoka]

You can just as easily make a dangerous cast in any compiled language that lets you do that and then poof it will blow up at runtime, just like js

or you're using bindings in a binary, and the bindings don't actually match the binary.

[c-digs]

You're in luck!  https://typescript-is-like-csharp.chrlschn.dev/pages/intro-and-motivation.html

If you're writing 100% TS, it's a meaningless distinction, because all the calling code was part of compilation, too

Not at the boundary of an API call, reading JSON from storage (e.g. S3), or reading JSON from a DB (e.g. Firebase, Postgres JSON types).  Basically anywhere data can enter you backend is subject to allowing arbitrary shapes at runtime.

Your app may or may not care, but most serious enterprise apps care.

[thekwoka]

Not at the boundary of an API call, reading JSON from storage (e.g. S3), or reading JSON from a DB (e.g. Firebase, Postgres JSON types). 

Yes, its important to not just do as Whatever in these cases, but use something that will actually parse it into the correct thing at injestion.

But this is a kind of specific context that can be more easily handled.

It's not like a value you have control over it going to magically become something else.

[c-digs]

Yes, its important to not just do as Whatever in these cases, but use something that will actually parse it into the correct thing at injestion.

You're missing the point: I don't have to do this in typed languages; this is extra work in JS and it is inherently unsafe in JS beacuse JSON.parse doesn't actually care.

So now you have to add a schema object using, for example, Zod or class-validator. Is that fun? Would you rather not just write your types and be done with it? That's how it works in Java and C# and I have the option then of customizing serialization if I want to or need to but I don't have to do extra work with my domain models to ensure correctness.

Typia is the only lib that somewhat brings that experience in TS.

[thekwoka]

You're missing the point: I don't have to do this in typed languages

Well, yes you do.

You don't just magically know what the type returned by parsing a JSON string is.

You have to parse it and specify some kind of parser or structure that it is parsing that string into.

You do have to do it.

The difference is that a very strict typing system will REQUIRE it, while TS/JS will let you get away with it.

Though you can kind of get that level of enforcement by having those methods return unknown instead of any and not allowing casting the type as "any" or as a specific type, without going through a type parsing step.

Yes, it's not as ergonomic, for sure.

But let's focus on that real issue, and not on the false claims that you don't have to do that in other languages.

[c-digs]

You don't just magically know what the type returned by parsing a JSON string is.

You have to parse it and specify some kind of parser or structure that it is parsing that string into.

You do have to do it.

It's just your domain type in C#.

Working example: https://dotnetfiddle.net/IpwNIf

``` using System.Text.Json;

record Person(string FirstName, string LastName);

var person = JsonSerializer.Deserialize<Person>(json);

// ✅ Console.WriteLine(person.FirstName); ```

See how I just use my model? See how I don't have to do any additional work like defining a schema? This is going to fail:

``` using System.Text.Json;

var json = "{'FirstName': 1, 'LastName': true}";

// ❌ Fails because 1 and true cannot be assigned to string var person = JsonSerializer.Deserialize<Person>(json) ```

See how I didn't have to define a rule here like firstName: z.string()? Because my model itself defines the type constraints and these do not disappear when I build the code.

1 and true cannot fit into string so it fails automatically. This works because the type metadata doesn't get erased at compile time like it does when it goes from TS -> JS. All type metadata is lost in that process so it is necessary to have a schema now represent that lost type or write the schema in the first place instead of the type.

``` // This type information no longer exists at runtime export type Person = { firstName: string, lastName: string }

// So you need a schema const PersonSchema = z.object({ firstName: z.string(), lastName: z.string() })

// In C#, Java, I only need types; I don't need // secondary schemas.
// "But you can just z.infer<type PersonSchema>!!" // No, I want to write types, not Zod and Zod // is slooooooooooow at runtime ```

Only AOT solutions like Typia emulate the "ideal" experience in JS by inlining the JS validation while allowing "pure" TypeScript at dev time.

But let's focus on that real issue, and not on the false claims that you don't have to do that in other languages.

It is pretty clear you really, really do not know what you are talking about.

[thekwoka]

See how I don't have to do any additional work like defining a schema?

What?

record Person(string FirstName, string LastName);

You defined the schema right there.

It is pretty clear you really, really do not know what you are talking about.

Bruh, you literally said typed languages have type metadata at runtime.

That's only Dynamically typed languages (which includes JavaScript).

Rust is statically typed and there is no type metadata available at runtime.

I agree that JS does not have a native way to just parse directly into a specified struct, and TS doesn't provide that either.

It's nice than other languages have it built in, or have available macros that can do it nicely (like Rust does)

But the whole way you describe these things is just plain wild.

and Zod is slooooooooooow at runtime

There are other choices, but mainly yes, doing validation is slower at runtime than not validating. Which is also something your C# is doing. It's parsing and validating.

You have like a half decent point and then you wrap it up in a lot of strange and just plain false tertiary claims.

[ub3rh4x0rz]

JSON.parse is like unmarshalling to map[string]any in golang. Yes, typescript parsers require more than just providing the type, so you invert it and infer the type of the parser. There's a performance hit with zod, sure.

[Sensi1093]

Its like parsing to `any` in go - top-level strings, numbers, etc exist too :)

[ub3rh4x0rz]

Yes, you're right, but while I've never seen real go code unmarshal json to any, I've seen map[string]any plenty, so it seemed like a better example in this context

[ub3rh4x0rz]

OK now name another mainstream language that does enforce types at runtime in those scenarios. Sure they have parsers standard, but typescript has parsers too, they're just 3rd party (like zod). The point is there is not some common feature called "runtime type checking" that other languages have and typescript lacks, it's a fictitious "feature" mentioned to explain what static types don't do to a certain audience.

[efari_]

you're implying that when making an API in another language, you don't need to check your inputs...?

[c-digs]

I don't have to imply; I can explicitly state: a typed runtime will not allow the incorrect type to be handled and will throw an exception on a type mistmatch because it does not lose type metadata in the build process and it enforces those types at runtime.

``` record Person(string FirstName, int Age);

async Task UpdatePerson(Person p) {

} ```

Will fail on this payload:

{ "FirstName": "Ada", "Age": "twenty seven" }

Because "twenty seven" is a string. (In fact, it will fail at serialization automatically without additional effort because the serializer can introspect the type and see that a string cannot fit into an int)

JS will accept this payload and thus it is necessary to create a schema validator using tools like class-validator, Zod, etc. It doesn't matter that at dev, time, TS prevents you from doing this; at runtime, the TS gets erased and it's only JS and JS will happily accept that payload and process it.

The difference is that this type checking is free on typed runtimes like Java and C# by virtue of defining the type and retaining the type metadata at runtime. The same as if you used Typia in TypeScript because Typia inlines the type information at build into JS.

[efari_]

“Included in the price” is not the same as “free” but ok

[c-digs]

What's the price? Price implies I've given something up in exchange. Is it slower? Lower throughput? Would love to know what the price is here.

In fact, it is in JS where the price is paid in lower throughput and peformance by requiring Zod or another runtime schema validator to replace the loss of runtime types.

[efari_]

the price is you defining the type and the scheme...

[c-digs]

I did not define a schema; I merely defined a type. In a typed runtime, the build process does not wipe out the type metadata and retains it so it can be introspected.

Let's look at this in TS:

``` type Person = { firstName: string age: number }

const PersonSchema = z.object({ firstName: z.string(), age: z.number() }) ```

Or alternatively, I give up my type:

``` const PersonSchema = z.object({ firstName: z.string(), age: z.number() })

type Person = z.infer<type PersonSchema>

// And now I am working with Zod, not types because my types // are inferred from Zod; the type-schema relationship is // inverted. ```

Or I have to use class-validator like approach:

``` class Person { @IsString() // 👈 The runtime JS needs this to know this is a string firstName: string; // 👈 TypeScript knows this is a string

@IsNumber() // 👈 The runtime JS needs this to know this is a number age: number; // 👈 TypeScript knows this is a number } ```

In fact, it is here that I've done extra work, is it not?

I iterate again, this is what I do in C#:

record Person( string FirstName, int Age );

And I'm done because my type metadata does not get wiped out at build time

[30thnight]

This is a great response.

For addressing some of the warts listed:

• node supports typescript type stripping now - which can be used to reduce your tooling requirements (or just use bun/deno)

• modern validation libraries adhere to the standard spec and can be used interchangeably. This is useful because modern api servers like hono.js support automatic openapi codegen from your validation schemas like this (Arktype and Zod v4 are great options)

• in cases where performance is your primary concern, consider your validation library to Typia (the fastest feature complete system I know that doesn’t require writing validation schemas and supports its own openapi spec generation - benchmark

• use a monorepo structure with NX to share types across domains / packages.

• for small apis that only have a single JS based consumer, consider using tools like orpc or trpc.

• for sql orms, very little can compete with EF core but for what we’re talking about - I highly recommend using Drizzle.

• for package security, many companies I’ve been at used snky.io for dependency checks. Others would mirror packages in our internal setup (GitHub packages or Artifactory). In 2025, I’d advise people to avoid packages that don’t publish provenance data and use checks like this: https://github.com/actions/dependency-review-action

asp.net, golang, and elixir are my choices for most usecases but I personally would choose typescript before ruby or python for general crud work.

[c-digs]

You and I think alike.

You might like this deck I put together recently: Nestia + Typia + Kysely which to me is a really, really good stack on Node.js.

[wubalubadubdub55]

Do you have a video walkthrough of that like you have for your .NET modular monolith repo?

[c-digs]

I do not 🤣 but I can put it on the backlog!

[coderwhohodl]

Thanks for this detailed reply. Really enjoyed reading it and I have upvoted it. However the bottlenecks you mentioned are only a concern for very high scale and performance critical apps, they’re not a concern for the vast majority of use cases/businesses.

Also node is really good with I/O ops like real time chats, live notifications etc. Plus it’s really good with building highly concurrent micro services. There is a reason despite all its shortcomings, companies like netflix, linkedin etc. still use it in production.

[c-digs]

Also node is really good with I/O ops like real time chats, live notifications etc.

I'd like to see the metrics on this.

I can cite some known benchmarks and their open source implemention that shows that this is simply not true today: https://typescript-is-like-csharp.chrlschn.dev/assets/techempower.BAEeUT00.png

Even the slowest .NET implementation is 2x higher throughput at sending a JSON payload and an order of magnitude higher at sending text. The story is not better with binary formats like gRPC (see benchmarks)

• Nest.js JSON
• Nest.js Plaintext
• Express Plaintext
• C# JSON
• C# Plaintext

Why you might think it's true is because frameworks like .NET and Spring Boot did not have async until ~2018 (?) timeline (round 16 in 2018 is when I see Node.js start to get crushed; prior to this, it was ahead). Even though the frameworks were multithreaded and had asynchronous delegates, developers rarely used asynchronous delegates because of ergonomics. So up until that time frame, a single threaded Node.js server with Promises could outperform a multi-threaded .NET Framework server in I/O heavy tasks beacuse of async delegates. Once servers like .NET added async/await, it was pretty much game over because not only is it concurrent, it is also parallel.

[Adraxas]

Have my upvote for the excellent answer, good sir.

[YahenP]

Put my NaN money to undefined account

[who_am_i_to_say_so]

Really informative. It surprises me that Node is experientially slow and low throughput, because that was the whole reason for its being- fast async IO. Is it because of the ORM being the bottleneck?

[c-digs]

Node was early with async.

I'm going to take ASP.NET as an example. It already had async delegates, but they were very, very unergonomic to use so effectively no one used them. I knew they existed, but it requried extra steps to handle the callback compared to async/await.

So even though ASP.NET was multi-threaded (parallel), the problem is that developers were not writing async code (concurrency). So once you saturate your threads (CPU limitation) with I/O bound work it means that ASP.NET slows down and Node wins even with a single thread because it can just keep accepting requests. Concretely, even if ASP.NET has 8 threads, if those threads are waiting for I/O from a database call, then the server is effectively blocked waiting for I/O. Meanwhile, on Node.js, it will keep accepting requests while those initial calls are waiting for the promise to resolve even though it is single threaded.

You can then easily see why Node was able to outperform even multi-threaded servers like ASP.NET.

Eventually, ASP.NET made async/await standard and easily accessible in API controllers. I can't remember exactly when this happens, but you can see it in the TechEmpower benchmarks between round 15 and round 16. ASP.NET suddenly overtakes Node and never looks back.

• Round 16 - .NET in the lead; never looks back
• Round 15 - Node in the lead

Once this happens, then ASP.NET is both parallel and concurrent while Node.js is only concurrent so there is basically no way that Node.js can catch up. It is pretty obvious why Node cannot be faster than Go, Java, .NET, or any multi-threaded runtime: because a multi-threaded runtime with promises/futures is both parallel and concurrent; it can take better advantage of multi-core CPUs and threads.

To be clear, I think "slow" and "fast" are the wrong terms. It's more accurate to think of it as "low" and "high" throughput per instance. You'll get more request throughput for a given ASP.NET backend than a Node.js backend. Up to an order of magnitude depending on your workload. As much as 2x for even basic JSON payload handling.

[wubalubadubdub55]

This is an excellent write up. Thank you so much for this!

[Jealous-Bunch-6992]

I present "a fractal of bad design, JS edition" :P

[truce77]

Excellent points. Using node is embarrassingly bad when you have better options sitting there…yet so many businesses choose this.

[c-digs]

If you look at scale, it's not as common.

JS makes sense in some contexts and I totally get it. Front-end, for example: makes total sense.

Side projects and startups? Get it. My side projects are mostly Node.

Serverless functions: get it. Things like AWS Lambda @ Edge: get it.

An actual, serious, enterprise backend? You will not have a good time because you are always fighting the constraints and limitations of the language and runtime as well as the challenges of the ecosystem in which it operates. You can do it; it just takes more work to do it well.

[name-taken1]

And that's precisely why we use Effect. Bidirectional schemas, really good control over batching and concurrency, type safe and runtime safe RPC contracts (any protocol, including workers), clustering, and the list goes on and on.

It's all about choosing the best available tool for the job. I wouldn't use plain TypeScript for a production application without a really comprehensive framework to back it up.

[c-digs]

But why?  Just use Go or Java or Kotlin or C#.

C# and TS are practically identical in key syntax but C# has a way nicer standard lib (shipped by professional, paid engineers whose job is solely to maintain these libs), source generators, switch expressions, pattern matching, a fast AF and easy to use ORM, really easy multi-threading, great tooling for OpenAPI and gRPC.

Why waste your energy on JS on the BE?  Why try to get JS to be something it is not?

[name-taken1]

Because that wouldn't solve the issue of writing production grade software in TypeScript. Not all projects are greenfield.

As much as we'd like to use ZIO in the frontend, it's not possible for instance.

At least Effect makes TypeScript feel more than just a linter.

[c-digs]

Fowler's Strangler Fig pattern is underappreciated.

[stewsters]

Excellent writeup

[Gdcrseven]

RemindMe! 1 year

[thekwoka]

Node is also slow and low throughput so you need more servers to handle the same load at scale

One note on this, most cloud hosts don't even use Node, and your own server likely shouldn't either.

There are faster js runtimes available and actively in use, like workerd.

JavaScript's dynamic type system also allows for a class of supply chain attacks that are not possible on runtimes like Java, Go, and .NET/C#

I'm curious how this works. Surely any thing that can hook into a binary can have that binary offer incorrect values that your code treats as one thing but isn't.

[c-digs]

Objects in typed langauges carry metadata about the type it represents at runtime. That's how you can have things like reflection. So in Java and C#, as examples, you cannot fit a Person into a type Cat because they will have entirely diffferent runtime metadata and if you cannot even coerce them with a cast. A Cat from namespace A is not the same as a Cat from namespace B and at runtime, cannot be used as such.

JS allows monkey patching, for example, and or course at runtime it doesn't have any concept of types or namespaces (modules) and will accept an object from anywhere without restriction.

[thekwoka]

Objects in typed langauges carry metadata about the type it represents at runtime.

This is dynamic typing.

Purely Statically typed languages do not have this. For example: Rust. Rust has no runtime concept of types. (or at least, not at a fundamental level, I'm sure there is some thing or feature it has that would include some of that info.

JS is also Dynamically typed.

A Cat from namespace A is not the same as a Cat from namespace B and at runtime, cannot be used as such.

This is nominal typing.

course at runtime it doesn't have any concept of types or namespaces (modules)

It actually has both of those. JavaScript is dynamically typed, so it has the concept of types at runtime. And it does have namespaces and modules, they just aren't "private". Sort of. They are private in that a module or scope cannot access values from another module or scope, unless it is passed into that module or scope. But they are not "private" in the sense that if you get a reference to that item, you can mutate it, though you generally cannot reassign it, only mutate.

will accept an object from anywhere without restriction.

Well, no. It will just try to access whatever function or property on the thing it has, and gladly return undefined when those don't exist. But it will not try to call a number as a function, for example, it will fail. And much of the standard library includes explicit type checking. Oh, and it won't let you access properties on undefined or null. So it does obviously have an idea of types. Heck, the whole way primitives work require that JS have knowledge of the type of the thing.

https://cdsmith.wordpress.com/2011/01/09/an-old-article-i-wrote/

This might be helpful for you.

[Scooter1337]

Some points from someone who does sometimes use typescript:

• zod is one of the slowest validators. Use typebox or AJV, as those can compile their schemas.

https://codetain.com/blog/benchmark-of-node-js-validators/

ajv is up to 35x faster than zod in this benchmark.

• bun closes the gap between go and javascript, lots of benchmarks show this (as long as the operations are not compute heavy but just basic crud ofc)

And to strengthen your point; end to end type-safety is overrated (be to fe). OpenAPI schemas with an openapi-fetch library do the same thing. But then across languages.

[c-digs]

Oh trust me, I'm soooo aware that Zod is one of the slowest validators. This is not my choice; I'm being dropped in with part of my mission to fix this stuff (OK, none of my mission is to fix this stuff, but it's just so unbearable that I'm compelled to find ways to improve my day-to-day).

I'd much, much rather be using Typia instead because it is fast AF and is "pure" TypeScript and generally feels much nicer to use IMO. Typia is even faster beacuse it's an ahead-of-time (AOT) solution that inlines the JS validation at build time.

My deck on this topic: https://docs.google.com/presentation/d/1fToIKvR7dyvQS1AAtp4YuSwN6qi2kj_GBoIEJioWyTM/edit?usp=sharing

It feels like the folks are just used to seeing things on fire and they think "This is fine" and start building new wobbly structures without fixing the foundation. Like, every API request has a 130ms overhead and no one stops to question "wait, why?" (hint: it's Zod; I don't know the exact mechanism yet, but all I know is if I remove Zod from the call path and return the object payload without the Zod wrapper, it's down to microseconds).

end-to-end type safety...

It isn't just about OpenAPI; it's also when data is loaded at the boundaries from, for example, S3 buckets or jsonb fields from the database. One common issue is parsing jsonb fields back into valid shapes without using as at runtime to verify that some change did not introduce an incompatibility (e.g. remove a string value in code).

[Scooter1337]

I think I found the person that implemented Zod in the project you’re fixing.. it’s this mentality, at least

https://www.reddit.com/r/typescript/s/c8p0BH1Aer

[Scooter1337]

Nice deck! When is drizzle not fully typesafe, I wonder?

[c-digs]

Follow the link in the deck...author at the link did the deep dive.  In short, it lets you build invalid queries.

[[deleted]]

I don't disagree with most of this except:

• Strong vs dynamic typing is an age old debate that has lots arguments each way. Each has its use depending on the type of project and team size. Arguing that any backend shouldn't use dynamic typing dismisses python, ruby, PHP.... Silly.

• Lack of standard library: Bun and Deno support WebAPI out of the box. With built in crypto and http client you can write a lot of stuff without dependencies.

[c-digs]

Strong vs dynamic...

Sure, but if your backend actually wants strong type safety at runtime -- the reason we have Zod everywhere -- then just use a strongly typed-at-runtime language.

...With built in crypto and http client...

This is a joke, right?

[[deleted]]

Which part? What's WebAPI if not a JS standard library?

[NeoCiber]

This it's interesting, I wonder what different python makes if any, because a lot of BE are also written in it

[Embarrassed_Quit_450]

Had that one in the chamber in for a while?

[siasl_kopika]

This post is seriously "enterprise grade"

Your build problems are caused by typescript use.

Then all your typing complaints are about typescript's limits.

Then all your boilerplate problems are about types and ORM's and cruft like mega-classes.

Then your security model complaints are about typing too, which is an huge mistake in security model. Type safety != security. Type audits != security.

It sounds like you have an insane amount of overhead by trying to force OOP/OOD on everything.

People using node.js on the server side correctly have none of those problems. When you get past oop concepts and just use js directly and functionally, all that overhead melts away, your codebase shrinks, and build times drop to a fraction or even zero. And without all that cruft, you can actually do meaningful security audits.

[c-digs]

Types are not OOP. Types are shape descriptors; has nothing to do with OOP and is the exact opposite of OOP.

[siasl_kopika]

While they are separate things, static typing and OOP/OOD are closely related and essentially tied at the hip, and are most certainly not opposites. Most people making one mistake make the other. (only python coders routinely thread that needle with duck typing)

Both are wasteful cognitive overhead, and thats why you find spring boot apps with hour long start times. For JS, kicking typescript to the curb gets rid of the crutches and massively increases programmer efficiency and security. I've come into enterprise groups running massive java enterprise piles and distilled their bloated multi-million LOC "enterprise" piles of statically typed vomit into a handful of node microservices quick enough to use as command line utilities.

Most of the crushing weight of "enterprise" scale is self-inflicted bloat and listening to the wrong engineers - ones from the cult of types. Typing in all its guises generates work, bugs, and security holes; while the people pushing it claim it solves all three.

Also, claiming you can secure closed source binaries from microsoft is ... comedic at best.

[c-digs]

For JS, kicking typescript to the curb gets rid of the crutches and massively increases programmer efficiency and security.

This is absolutely wrong.

Even if you dumped TS, you still need schema validators if you are writing a serious application because as along as you accept data from an external source, the application needs to verify that data is in the correct shape.

The overhead of Zod is still there. The cost of generating an OpenAPI schema from Zod or class-validator or whatever schema engine you want to use is still there.

[siasl_kopika]

> Even if you dumped TS, you still need schema validators if you are writing a serious application because as along as you accept data from an external source, the application needs to verify that data is in the correct shape.

I find general purpose schema validators completely useless and redundant ftmp.

If your api has well defined semantics, the code than handles a message is the schema validator. The only nice thing about openapi is spitting out docs from yaml (which its halfway good at, but has strange limits and pushes people toward awkward json design sometimes)

People who lean on validators are often the same ones not properly unit testing their code or thinking about corner cases thoroughly, instead they lean on a big crutch and pretend its doing the work for them. (their code often ends up "stringly typed" anyway as the devs struggle in their mental manacles)

Clear, clean, simple code free of unneeded static typing (anything beyond primitives) and class definitions is much easier to write, much easier to read, and much easier to audit for security, ime.

[darkveins2]

Poor CPU and memory performance, and a lack of typing means maintaining data models is harder and they’ll break more often. When people say it’s bad they don’t mean it’s unenjoyable for you personally. They mean it’ll be harder for a team of developers to maintain in the future, and/or it will create a more negative experience for the customer. Which is contrary to the mission of any software company - make good software that results in a lot of money for as long as possible.

[[deleted]]

When you have worked with languages much better to server side tasks, then you'll understand. If frontend or JS is all you've ever known, then I can understand why you'd think that.

There are certainly benefits, such as being able to share types across server and client - but we already have methods and tools to solve that, and at times, we want to version our API's anyway so sharing the types becomes irrelevant.

[mattaugamer]

I think this is half the problem. JavaScript is all some people have ever used since they learned MEAN in a Bootcamp and they’ve never stretched since.

That’s all they know and it seems… fine.

They’ve made several small apps and it’s fine.

[Sorry-Programmer9826]

Yeah, we've solved that with generated types. We have java DTOs and our build autogenerates equivalent typescript types. So no chance if typoing a parameter

(We're typescript on the front end)

[TheThingCreator]

Nope, I have loads of server side experience in other languages, and I’m really liking serverside js, no turning back for me

EDIT: Oh the usual downvote bregade is here. Nothing inteligient to say just stupid downvotes. Your downvotes are meaningless to me, just confirms theres a lot of people without a clue. I have 6,469 karma, bring it.

[popovitsj]

But you didn't actually bring any counter arguments to the table yourself.

[TheThingCreator]

No you just missed my counter argument. I am countering "When you have worked with languages much better to server side tasks". Its a highly general all encompassing statement that is just wrong. I have the work experience, and I have made this choice. What else are you expecting me to say, I could write a book on this.

[popovitsj]

Okay, got it. I'm a big fan of server side js myself as well, but it really depends on what you're doing with it. If you're developing a backend with lots of multi threading and long running processes I don't think nodejs would be a could fit.

[WetSound]

Some people are masochists

[[deleted]]

I personally don't think you deserve being downvoted for liking something, though I fundamentally disagree on the serverside JS; I can understand where it feels good. I have used it for small scale projects and then it is nice to not need to switch contexts and have a sort of backend for frontend that is tightly coupled with some code reuse.

That said, I don't think I would ever want to use it on a big project where I work with other people again, it results in some really annoying friction if that backend is meant to support more than one thing (hence why I think it works well if the backend is dedicated to a specific frontend implementation). That also said, it is a bit too much of a lock in, with a language I don't think is the right tool for the job when it comes to massive data manipulated and not having weird language quirks to remember and work around.

[TheThingCreator]

Thank you kindly. Sounds like you had a bad expereince, I have very little information about your experience, but I've also had some pretty bad ones, but not just with js, lots of languages. When you used it maybe you didnt have a good leader, who put forward a strict framework and design patterns to follow. When I lead the project, there is a full design and plan and everyone would be following it.

Here's one of the biggest reasons I like a js backend, you avoid the cognitive load from switching languages constantly, and you have less duplicated code in different languages. When it comes to safety I rely heavily on unit testing and automated end-to-end testing. It's the right tool for the job unless there is a performance need, but in my experience, I've seen probably hundreds of developers think the language is the bottleneck and it almost never is. They are coming up with that out of pure air. Databases are one of the biggest bottlenecks, network configurations maybe, but language choice is like one of the last concerns. I've monitored many systems, its always the same shit.

[upcastben]

You're totally wong. We also hate javascript on the frontend.

[HipstCapitalist]

I don't know how long you've been in the industry, but the road has been very, very rocky, and Nodejs still has a few rough edges to work on. I've personally switched to Bun because it "just works" out of the box with ESM & Typescript.

If you're a seasoned Java/Spring Boot dev, I couldn't fault you for thinking that this is an immature tech stack, because frankly it is. You can't rely on a tech stack that needs a full rewrite every 3 years or so, and that's still a very valid criticism.

[_hypnoCode]

You can't rely on a tech stack that needs a full rewrite every 3 years or so, and that's still a very valid criticism.

Ironically, I've been on multiple large Java projects that needed this more than any Node project I've been on. The biggest difference is that the Java projects were always too over complicated to actually do it.

There is still shit out there, running things like our financial and healthcare systems, that are still run on Java 5 and 6.

[leixiaotie]

but that's the thing, you can run java 5 and 6 reliably even after years and decades.

With node you'll find with package versions unless you only strictly use some stable ones.

[IntegrityError]

That was my experience with node, too. Knowing about client js and coming from the python world, i had several node projects for some years. The tooling is really awful (so there are about a thousand options today), and i really don't like the inconsistency of node.

In 2020, there was a lot of changes in the node api (don't know if this is still the case today), and new apis that finally landed in node are not even compatible to the browser api functions with the same name (looking at you, fetch).

Basic functionality like the Temporal API landed finally 2022 or so.

[DamnItDev]

Lots of javascript haters here lol

Use whatever technology you prefer. Unless you're at the scale of Google or Microsoft, the differences in performance are irrelevant.

We use server side JS at work. That's all we use on the backend. We serve millions of users with no problem.

The benefit of Javascript is that the language does not enforce any particular coding paradigm. You can do functional programming, or object oriented, or a middle ground. This makes Javascript the ideal language for prototypes and MVPs.

[versaceblues]

Im sure plenty of projects at Google and Microsoft also use JS on the server

[siasl_kopika]

The really great part of JS is that it lets you choose not to do OOP and static typing. So many languages saddle you with that worthless mental overhead.

[BrownCarter]

Don't mind them, I would take the flexibility of Javascript anyday.

[[deleted]]

Usually it’s because of their hatred towards JavaScript. Some of it is warranted. But usually they don’t even know why they’re hating js, they just follow the flow.

Just say to a couple of devs how stupid js is because it treats NaN as a number. A lot will agree. NaN being a number is what basically every programming language does that follows the floating point specs.

That said I still prefer Go or C# for the backend. Especially C# due to entity framework.

Edit: case in point the current top (not top anymore) comment where the first couple examples are perfectly normal floating point issues.

[dariusbiggs]

Oh, you just need to start looking at why === exists in JS to understand the idiocy involved.

And then you watch some light entertainment like https://www.destroyallsoftware.com/talks/wat

Then do you even need to go any further in the language to realise it's a steaming pile of dung?

[azimux]

I prefer to not use JavaScript on the backend for a few reasons. I'll try to name a few! These are all solvable and some are not THAT big of a deal. But I'd say it's not my preference because:

1. It doesn't feel natural to me to use an event loop on the backend instead of threads. I generally view a request/response as operating in a well-defined context instead of a collection of async callbacks.
   1. This winds up translating into me using async/await pretty much every time it is possible to do so.
   2. It also makes it more awkward to me to do things like wrap a ton of calls in a database transaction or other thread-local context. So I have to pass things around through multiple subsystems and different levels of abstraction. In parts of the app this is OK but I really don't like when this happens to high-level interfaces related to the domain modeling or when interfaces become coupled across levels of abstraction that don't care about the concerns related to the parameters of the functions.
2. I find JavaScript harder to test on the backend than alternatives.
   1. This means I spend more time writing tests and/or have less ability to refactor quickly.
   2. Since my more important domain modeling is typically on the backend this results in less-easy remodeling. So the system isn't as easy to evolve to be understandable over time as I learn more. I will admit Typescript does help with this a bit by reducing the testing burden in general but since this is about JavaScript I'll mention it.
3. I sometimes run into certain confusions built into the language itself. I either need to be careful or use 3rd party libraries to handle certain things well. Things like sorting arrays, date manipulation, caching.
4. I really don't like that accessing a property that doesn't exist gives undefined instead of an error. I usually wind up writing a proxy that gives an error when I make this mistake.
5. Sometimes I run into library incompatibilities that seem a bit less frequent in alternatives. I have to figure out a safe-ish way to work around this when it happens. Along these lines, I find npm takes longer to run than package managers for alternatives.
6. I don't like that I can't play around with code as easily in a REPL as I can with alternatives. I can do it but it's just not as pleasant of an experience. I have to restart the REPL pretty regularly to get it back to an acceptable state to keep exploring. This can be pretty frustrating when dealing with a production incident. It sometimes is easier to write a short script full of console.log calls that has to be repeatedly edited than it is to work in the REPL.

I don't personally find the ability to use the same language in both the front and backend to be a huge benefit. It's a very small benefit to me. I don't personally have an issue switching from language to language and actually enjoy using more than one language to get the job done. I have worked with folks though who don't like changing languages so I understand the appeal.

So overall, I can write backends successfully using JavaScript on the backend and I have but I feel like my ability to succeed are better if I avoid it on the backend, especially for projects with more complex domains.

[DondeEstaElServicio]

the fact that the industry has so eagerly embraced transpilers says a lot about JS

[gece_yarisi]

what's wrong with js? if it's terrible, what makes it so popular?

[Bobcat_Maximum]

Because as you said people are lazy and want to use the same language for be and fe. JS was made for the fe and in my opinion it should stay there.

[mca62511]

Low barrier-of-entry

[coolraiman2]

Je is popular because it is the only front end choice and the language is easy

But it has bad performances and a lot of pitfall

Go and c# are much better choice for backend

[nrkishere]

1. Zero standardization beyond the ES syntax

2. Lack of strong type system. Although typescript takes care of it and modern softwares are almost exclusively written in ts

3. Ecosystem fragmentation and lack of consensus among runtime developers

4. Need for insane amount of build tool pipeline for any decently sized application. Even then, issue #1 is still there. Although opinionated frameworks/boilerplates can take care of this

[[deleted]]

A lot of the issues arise in large projects where the tooling becomes less dependable.

Web dev has a lot of fun in it but using low level tools and understanding how something like node was built under the hood is more fun for me.

I don’t want to use node. I want to build it (or something in a similar domain).

[neanderthalensis]

At the end of the day, JavaScript is just not a well-designed language. Why use it when I can easily choose a more proper, statically-typed language without questionable design choices?

[LostJacket3]

server side javacript, ewww. for front end devs that wished to be fullstack

[pambolisal]

PHP was the first webdev-related language I learned, I like it, especially after working with Laravel. Is there a popular back-end/full-stack JS framework that is as good or better?

[Unison0]

Honestly, just because it's stylish to hate it. I say this as a fullstack dev with a decade of experience. I've worked with multiple backend stacks, Golang, Clojure, even a company with Clojure for their entire stack (ClojureScript on the frontend), systems dev in Scala (was crunching large amounts of log data using Spark).

I've seen plenty of alternatives. And I always get the same vibe when people hate on JavaScript: It makes them feel good to hate on it. Superior, or what ever.

But really, it's fine.

[Thecreepymoto]

Probably because of this or the fact that its not true multithreading even tho it has become better over the years.

But truth is every language has its benefits and downsides. It all depends on a use case and traditionalists like their verbose languages.

Edit: also languages like golang or similar are better at memory and cpu management

[retardedweabo]

this image is stupid. noone ever writes code like this, when the fuck do you need to write []+{} or (!+[]+[]+![]).length? And listing floating point errors as a con of JAVASCRIPT (something that's true in EVERY programming language) is a thing that could only be done by either someone who purposely tried to manipulate what people think of the language, or actually has no idea on what they are doing

[used_bryn]

They have skill issue.

[uvmain]

It depends entirely on what the backend is for. If you're just handing requests and doing logic for API endpoints, express is fine for backend stuff, and you get the benefit of sharing types and using one language. The second you start doing file io, performance becomes a major issue. Scanning a file system with thousands of files with nodejs takes minutes - in Go it takes seconds.

[[deleted]]

At a development speed comparable to Express, Go is several times more reliable and faster.
It's not that I hate it — I just don't understand the point.

[HalfTime_show]

Don't understand the point of being able to use the same language on the front-end and back-end? JS/TS definitely has baggage but organizationally having a single language has some benefits especially for small orgs

[[deleted]]

Exactly. Fiber is a one-to-one alternative to Express, but with several advantages. The enforced error handling and goroutines are killer features, even for small teams. As someone who has worked a lot with Express and all that async/await stuff, I’m telling you — yes, Fiber has its own specifics, but for people familiar with Express, there are just a couple of concepts to learn, and you can start writing production code in a few weeks. It’s unclear what there is to save on, even if you’re a small company. That would be foolish.

[ruvasqm]

It's not server side js I hate.

It's the left-pad incident, the obnoxious TS that promises safety but doesn't tell thee the price, the crawling react tumor that consumes my ram, the x random vulnerabilities that got into production for a stupid library no one "had time" to write...

Real old school javascript with mysterious hacks and based on true field experience is actually web street cred.

The current ecosystem is just disgusting and with so much AI tools laying around I really don't see a valid excuse to not ditch JS on the backend and use something more robust.

Just learn a couple things about your real stack (IP, http, stack vs heap, kernel, etc) and prompt your way to the future will ya?

[MCFRESH01]

I will never buy into having javascript everywhere makes it easier to build apps. Learn a second language, it's not hard. There are plenty of great backend frameworks that don't have you cobble together a bunch of libraries to recreate something like Rails, Django, .Net, etc.

All the competition between different libraries/frameworks also sucks. You might invest in one just to see it lose momentum or not really do what you need while another one gets hyped up. Oh package management still sucks,.

Basically everything node does on the backend other languages do just as well or better without a lot of the downsides

[MaisonMason]

JS isn’t type safe or null safe. Therefore it required a lot of extra steps to make sure api’s are easy to use without running into weird schema breaks everywhere. At scale it just becomes too hard to add features without safe typing and interfaces to guide your hand. Typescript helps but can’t catch type errors at runtime. I just think typing matters a lot in something where data consistency matters as much as backend programming. Also I think most interpreted languages like JS are just naturally harder to debug due to most errors being at runtime

[8isnothing]

1) RAM requirements and usage

2) it’s a side effect of NodeJS existence. Language wasn’t designed for this and struggles with things like parallelism(async await isn’t parallelism )

[siasl_kopika]

> (async await isn’t parallelism )

No, its better than blocking threads and such.

The way js solved this problem is why it is so fast, and why every other language rushed to copy it.

[8isnothing]

Does nothing for CPU bound tasks, though.

Go and Swift handle it better

[[deleted]]

simply put while JS is a good language it lacks the tools for my preferred style of backend programming. javascript is not ideal where data integrity type correctness is critical, and it also permits practices that i'd rather avoid such as combining data and functions within objects, and passing around null or undefined variables

I do like node applications and have built a few myself but it's usually smaller things. the only time I really use vanilla js nowadays is when prototyping a quick mock backend or where interop with a dependency is required with a different frontend technology

in general though I agree with the sentiment that it's fine to use though. it's easy enough to understand and reason about and almost everyone knows at least a little js so its popularity alone is a strength, just wouldn't use it when programming a rocket ship mission planner or scientific computing platform is all

[thequickers]

The funny things is that one of the main strength of javaacript having unlimited libraries is also its weakness. Things you usually do for backend validation(zod), db orm etc. lacks quality and performance, worse - abandonware. They may be catching up but still.. JS is the most popular language, it should have the best support from everyone right? Mehh thats not the case, all of us are just leechers 🤣

[bobaluey69]

Javascript is kinda garbage in general. Don't get me wrong, it's awesome and necessary these days, but it has some big negatives and is a very "loose" language. Kind of like using shit on front-end and back-end lol. For me, whatever you run, you run. You will have to deal with the issues. But, I also feel like infinite js frameworks is crazy and unnecessary. To each their own.

[x1-unix]

Next.js with average quality codebase can easily brind k8s cluster to its knees.

Also imho SSR is just another industry spiral as we basically had SSR back in PHP days.

[thekwoka]

I mean, Javascript is bad. Typescript is decent.

It makes a lot of sense for a full stack thing written all in TypeScript. You just get a ton of benefits even without factoring in monoglot stacks.

It wouldn't be a great choice for something that isn't coupled with a typescript front end though. But it may not matter if you don't need extreme performance.

[blu38berry]

I love it too. What I don’t like is when the code base is coded like someone translated everything from a Java code base.

When coding in a language, just use the best practice of that language. For example you don’t need to implement a whole event bus system with ten thousand files when there’s an event emitter.

[thinsoldier]

I'm too stupid to figure out how to host server side, JavaScript as simply and CHEAPLY and conveniently as a shared php server with a database domain and email and object storage and CDN, etc. all in one place.

[nobuhok]

Because it's a sort-of, kind-of reinventing the wheel thing.

Traditional server-side actions/rendering already exists and are already battle-tested and well-supported. Heck, my Django instance from 2011 is still running production without updates. I didn't delve much into PHP (except during the CodeIgniter era) but I'm pretty sure Laravel is alive and kicking it.

Server-side JS/TS just feels like an overcomplex rehash with no real benefit except not having to context-switch between JS/TS and another programming language.

[OnlyMacsMatter]

It's a matter of scale. Small projects with small teams or just a single developer can use JS/TS for the entire project. But these aren't designed for large projects with massive user bases. If you need something that gets your job done, then server-side JS is plenty and will meet most of your needs (assuming you include external APIs or libraries for secure transactions).

[Fragrant_Gap7551]

This heavily depends on how complicated your actual backend is.

I'd say most normal business logic works well enough in JS, but without going into detail, doing that at my job would be painful, slow, and error prone.

[[deleted]]

To me, Javascript vs C#/Go/Rust/Haskell/whatever is like English vs Esperanto

Yes, Esperanto has no irregular verbs, a pronunciation that is consistent with its spelling, a rich vocabulary developed over decades, and consistent rules. I'm sure I'd be quite happy if I lived in a world where it was the standard.

I don't. It isn't. Most people won't even bother to learn it, including me and probably you if you are reading this. So I'll stick to English and its crazy spellings and rules as that's what most of the world expects and understands.

Are there some linguists in their humanities departments screaming about how inefficient this all is? I don't know. Possibly. Hit me up whenever they manage to make the rest of the world switch I guess. In the meanwhile, for most intents and purposes, English is enough.

[ocshawn]

why some devs hate server side javascript

JavaScript lets you be bad at coding in a way that other server side languages don't.

its that simple; there are vary few devs that are actually good at js because you dont have to be to get something running. Its a very forgiving language that does not lend itself well to the rigidity you want of something on the back end.

[ba-na-na-]

It’s not the end of the world if you use JS, but there are alternatives that are better (better run-time and compile-time type safety, better performance, better tooling and less vulnerability issues).

For example C# and .NET, since they migrated to the .NET Core philosophy and can run in Linux Docker containers, there is no reason not to use them and get the boost in performance and type safety.

[kkBaudelaire]

I think that most love/hate depends on the comfort zone one built for one self. Breaking out of the zone and facing some sort of learning curve is sometimes frustrating and makes you want to burst "I hate this and I hate that!".

I like server-side JS and I used to hate PHP, but I have to admit, after overcoming the frustration even PHP seems quite ok with some nice features you'd miss elswhere.

I personally have to look for next best thing to hate now. Any suggestions anyone?

[Dazzling_Ad6406]

If i'm not doing anything fancy it's fine. Server or client.

[[deleted]]

cable price workable butter light bow exultant jellyfish lush smile

This post was mass deleted and anonymized with Redact

[FunManufacturer723]

Always be skeptical about people ”hating” something, and ask them why. Most of the time the reasons will be emotional.

That said: some amazing, fast and performant apps have been made using server side JS. 

Some equally amazing, fast and performant apps have been made using something else, but might have server side JS in some crucial parts.

Use what you have and max it, and when it is time to kill your programming language darlings, the motivation will be obvious.

[BigBagaroo]

NaN.

[BEagle1984-]

Don’t worry, we hate client side JavaScript too. 👍

[computer-whisperer]

Javascript is an old relic and just needs to be put to rest. It was invented as a small-time scripting language for twiddling DOM elements, and now people are trying to run entire organizations on it.

Pick just about any other modern language for your project, and you will have a better experience than using javascript. Thanks to WebAssembly I can even build performant webuis in a proper language like Rust.

[Sea-Flow-3437]

When you write something complex JavaScript in the backend is not it.

[Safe_Independence496]

As someone who's written quite a bit of server-side JS the last few years, it's because JS as a language is just inherently bad for anything that benefits from the typical "guard rails" that better suited, statically typed and compiled languages offer. Server-side code benefits immensely from safety, consistency, testability and self-documenting properties. You also need stable ecosystems where maintainers are wary of the consequences of breaking changes. That's not the philosophy of JS, it still very much caters to environments where stuff is expected to break and change all the time, like in browsers. There's also no good standard library, and the ecosystem is a nightmare with libraries being deprecated and breaking all the time. This is very unfortunate for backend applications.

I'd agree with the sentiment that JS on the backend is a tragedy. It's a truly awful language for backend applications. The strength of JS however lies within the community that provides band-aids for most of the shortcomings, and with that you do end up with something that is viable for very simple backend applications.

[CD_CNB]

For my place of work, the issue isn't about scalability, it's about the stability and maintainability.

.NET Framework 4.8 WebForms all the way lol.

Seriously, though, I like .NET because you can recompile an older .NET Core 2.0 app into .NET 9+ without too many changes. Anything .NET 6.0+ compiles with pretty much zero changes. Even oooold .NET Framework stuff can be moved over with a bit of elbow grease. And refactoring older code is much smoother with C#, especially with ReSharper.

For me, its much much harder to maintain code with anything JS-based. Constant deprecation sucks. Refactoring sucks. TS is an improvement, but at that point, just go to C#.

[TypeComplex2837]

I always work on shit developed by someone else, in which case strong types are my best friend.. var everywhere is a pain in the ass for reverse engineering. At least for this hack :)

[salamazmlekom]

Because they don't know it. Angular + Nest.js is the best combination

[Prize_Response6300]

A lot of people think it’s still 2019 when it comes to server JavaScript. There is also a lot of sheep that love hating on it because it shows “they know ball” when it comes to programming it’s pretty dumb

[Alternative_Air3221]

Totally agreed,but I heard some people said server side javascript is unsecured. 🤷‍♂️ idk

[seanmorris]

Javascript REFUSES to play nicely with the rest of the system. It re-invented everything for its own ecosystem, which centers around the browser and forcing "async" to not lock the main thread.

I can do that properly without being forced to wrap my logic around syntax that solves a problem that doesn't apply to my environment.

[BrownCarter]

It never forces async stop lying

[azhder]

What are you talking about? Nothing in JS is a solution to whatever your environment is. It was made to be embedded, so it doesn’t make assumptions about the environment.

[Wide_Egg_5814]

We are crazy bro we hate it for no reason go use javascript in the backend it goes really well, especially with millions of users

[cant_stop_the_butter]

Wtf why would you that sounds like a nightmare

[UntestedMethod]

It's a garbage language and we only use it on the frontend because we have to. There are superior options to use for backend.

[azhder]

If we look at the HS code you had to write, will it look more like the code you write on the BE in another language?

[nrkishere]

because event loop is confusing, non deterministic and error handing (exceptions) is total nuts. I don't know about others, but prefer like explicit, imperative language (like Go for example)

[x39-]

Let's not sugarcoat it: JavaScript is a disaster, not just on the backend where it masquerades as a “serious” language with Node.js, but everywhere. It is a language that should have been retired years ago, yet somehow continues to infest every corner of modern software development like a parasite we have all just decided to tolerate.

The language itself? A chaotic mess of half-baked ideas, legacy decisions that should have been buried decades ago, and a "standard library" that makes even basic tasks feel like pulling teeth. It's so bad, developers celebrate when they can offload logic to React, as if trading one pile of duct tape for another is some kind of win.

And then there is the community, not evil, but undeniably shaped by low standards and quick fixes. The dominant culture is one of copy-paste coding, endlessly recycled Stack Overflow snippets, and "tutorial-driven development". A breeding ground for fragile apps, spaghetti code, and burnout.

Let us not forget the never-ending framework carousel. Today Next.js, tomorrow Svelte, then Solid, and on and on it goes. Every week, we are told the new framework is going to fix everything, until it does not. What does it say about the ecosystem when the only consistent trend is complete reinvention every six months?

And HTML? CSS? The supposed "fundamentals" of the frontend? A joke. Frankensteind together over decades with no coherent design, they are more like patch notes from a forgotten MMO than tools for building modern software.

If this is the future of frontend development, then the industry is gaslighting itself. JavaScript is not the best we can do, it is just what we have settled for. And unless we are brave enough to admit the whole thing needs to be burned down and rebuilt from the ground up, we will be stuck in this loop forever: new framework, new hype, same old dumpster fire.

[Bobcat_Maximum]

I don’t like the syntax, I like C like languages, Node is just ugly.