Languages bring along a culture. Sone teams buck the culture of the broader language ecosystem, most do not. IMO, the C# culture is closer to enterprise Java than it is to Typescript, for good or for ill.

More than culture, language is a statement of values.

There's reflexivity and path dependency but the culture is downstream of the values for the most part.

    > C# culture is closer to enterprise Java than it is to Typescript

I mean, this really depends on what you're looking at.

Here's a sample from the MongoDB client: https://github.com/mongodb/node-mongodb-native/blob/main/src...

Here's a sample from Storybook: https://github.com/storybookjs/storybook/blob/next/code/core...

Here's a sample from Prisma: https://github.com/prisma/prisma/blob/main/packages/client/s...

Here's a sample from Cal.com: https://github.com/calcom/cal.com/blob/main/packages/core/Ev...

These are all fairly mainstream repos so it's not a one off to see "enterprise" style coding in TypeScript.

It's rather the specific use case that determines the style of the code that's written. In the examples above, there's no need for the teams to choose JavaScript classes and inheritance to model the logic, yet it likely better fits the programming model of those modules.

Look at Nest.js as well: https://github.com/nestjs/nest/blob/master/packages/core/rou...

The whole codebase of Nest.js looks an awful lot like Spring or ASP.NET (controller syntax) probably because there's a lot of crossover in terms of what APIs need at scale and how to logically organize that logic.

It just so happens that most use cases for C# and Java favor applications at a larger scale. Another key difference being object scope and lifecycles -- something that rarely comes into play in the generally single-threaded Node runtime. This being one of the key reasons why dependency injection is a thing in C# and Java land.

Both. The language can afford that usage through the design decisions.

I kind of think the best languages would be those that make creating layers of spaghetti indirection nearly impossible. In practice, it's usually much more specious. Names like "CreatorImplementer", "FactoryAbstrator", "DeviceAccessory" and a half dozen equally amorphous things calling each other as if Thomas Pynchon was writing software.

I think I've seen it in all languages I've worked on professionally. Maybe not in Perl.

I mean, you can do the same in JavaScript and TypeScript as well as any number of other languages.

Agreed. There's plenty of obtuse indecipherable JavaScript these days.

I keep remembering this code I saw in 2014. It was in ember and used mongodb and some bizarre ember features I've long forgotten to stylize things instead of conventional stylesheets.

I had been doing JavaScript since it was called LiveScript in 1995. I knew it very well. This setup was utterly impenetrable. Charging a button color required I think 6 or so different data stores to be manually updated and placed back in alignment because things were validating and cross checking for no good reason other than being a complicated pile of tangled messes. I had to quit the job.

I know how incredible this sounds. I can prove it. He does everything like this. Here you go https://github.com/davideschiera/flame-ui/tree/master ... I'm not quite sure what these 252 files do but I'm pretty sure it could be done in about 25 lines of code in a single function.

I had worked with him previously on a C# codebase almost 20 years ago now. I remember him being just as insane but somehow the language successfully encapsulated the insanity so I never had to deal with it.

There's this fundamental clash. I think things should work, be maintainable, and have the most minimally complex implementation possible - the Ernest Hemingway approach. Some people prefer James Joyce.

It is, in fact, independent. You can create horrible monstrosities in any language, or create great code in any language.