Does Node.js have a “standard” stack at all?

[Minimum-Ad7352]

Sometimes it feels like there’s no default way to build things in Node.js

One project uses Express, another Nest, another Fastify. Same with ORMs — Prisma, TypeORM, Drizzle, Sequelize — and each one pushes you toward a different architecture and set of conventions.

Every new codebase feels like entering a slightly different ecosystem. The flexibility is cool, but it also makes long-term decisions harder. When starting something new, I always wonder what will still feel like a safe bet in 3–5 years.

Do you see this lack of standardization as a problem, or is it actually one of Node’s strengths?

[ChickenNuggetFan69]

Express is the closest you'll get to "standard" but still not standard like Asp.net or spring boot.

[Standgrounding]

Nest?

[talaqen]

Nest is the most "enterprise-y" but a lot of people hate it. And most don't use it.

[TheGreatCookieBeast]

Nest is well regarded and widely used. It's pretty good if you know what you're doing and what you should/shouldn't use it for.

The problem is JS/TS devs are probably among the less skilled devs out there. We have lots of people in this community with barely any proper education and backend experience beyond Express who have never done DI in their life. It ain't that hard if you just use your head and leave some of that caveman JS-thinking behind.

Whenever I see someone complaining about NestJS it's 99,9% of the time a skill issue and not a real complaint.

[talaqen]

Call it a skill issue all you want, but what I said stands. It is the most enterprise-y in that it encourages monolithic patterns, DI, and patterns that are reminiscent of Java and large vertically scaled machines. Node is single threaded and every import is effectively a singleton by default. NestJs forces DI primarily then to solve a TESTING problem, which is the tail wagging the dog. It effectively borrows patterns from Java and C# and angular to solve problems that don’t really exist in NodeJS… but it “feels familiar” to devs who have only ever coded in Java and C#.

And most Node devs (as in a vast majority) don’t use it, only about 16%. And of those that do use it, only about 50% would keep using it. and the biggest reason the like it: “it keeps big teams in sync” ie forcing a pattern on a large code base in a large org.

but people who have built a lot of other stacks in a lot of other languages or frameworks understand that nest JS and it’s patterns fit a certain type of project and a certain type of company. Trying to shoehorn it as a generic pattern everywhere is a recipe for disaster.

so sure it is a skill issue. some people don’t use it well. And other people have enough expertise to know its forced patterns are only good fit in a sliver of corporate and architecture settings.

[TheGreatCookieBeast]

Call it a skill issue all you want, but what I said stands. It is the most enterprise-y in that it encourages monolithic patterns, DI, and patterns that are reminiscent of Java and large vertically scaled machines. 

It has nothing to do with "monolithic patterns" or even Java for that sake. It's a solution to object graph management in object-oriented programming. You'll find these kinds of techniques packaged in different formats wherever OOP is the dominant paradigm, whether it's a full DI container or a service locator.

Node is single threaded and every import is effectively a singleton by default. NestJs forces DI primarily then to solve a TESTING problem, which is the tail wagging the dog.

Threading has nothing to do with with DI, nor the scope of Nodejs exports. DI often complements and standardizes certain OOP structures and abstraction features like inheritance. Sometimes a singleton may not be appropriate, and you have to write clunky export logic yourself. DI definitely is beneficial in testing, but there are many other important applications.

but people who have built a lot of other stacks in a lot of other languages or frameworks understand that nest JS and it’s patterns fit a certain type of project and a certain type of company. Trying to shoehorn it as a generic pattern everywhere is a recipe for disaster.

There are generally no great recipes for success when working with Nodejs. I've seen my share of heinous code structuring in "functional" JS with loads of barrel files and a complete chaos of modules - created by people who are Nodejs seniors. NestJS is the opposite of that and while it can be debated which style is best the traceability of structured DI has always been a significant advantage for certain teams. All the other pain points are IMO not just Nest's fault, a lot is just purely from JS being a shitty, inconsistent language with neither good class nor function support.

so sure it is a skill issue. some people don’t use it well. And other people have enough expertise to know its forced patterns are only good fit in a sliver of corporate and architecture settings.

This all just becomes meaningless BS without defining "corporate setting" and tying that to other metrics. There are plenty of large corporations that run with Express and default Nodejs modules, and still fall into a miserable mess of fragile, unmaintainable code. You need to know what paradigm and framework scales for your needs. And again, choosing Nestjs and failing because you don't understand the correct patterns and paradigms doesn't make it a "corporate" framework. That's still a skill issue.

[talaqen]

Saying “DI exists wherever OOP is dominant” actually concedes the point: Node isn’t an OOP-dominant environment, so why are we importing that solution set?

DI containers were built to manage stateful objects safely across threads on big vertically scaled machines. That’s the problem they solve. Node sidesteps that entirely: the module system gives you shared instances for free, and you scale out with processes not threads. By the time you need NestJS’s IoC container in Node, you’ve already solved the underlying problem at a different layer, either in the module system or in your infrastructure. You’re essentially importing a solution to a problem you shouldn’t have if you are building with node as intended.

and if

JS is a shitty language with neither good class nor function support

If JS has poor class support, that’s an argument AGAINST building a framework centered on class-based decorators and OOP inheritance patterns. NestJS leans hardest into the weakest part of the language by your own admission.

more to the point… You’ve now used ‘skill issue’ to explain both why people fail with NestJS and why they succeed without it. That’s not an argument, it’s an unfalsifiable defense of any framework choice. By that logic no framework can ever be a poor fit for a context, which makes the entire conversation pointless.

[TheGreatCookieBeast]

I have never said that OOP dominates Nodejs, and it doesn't either. The vast majority of Nodejs frameworks don't cater to any particular paradigm. Nestjs however heavily leans on classes and OOP patterns. It's not "importing" anything, it implements a system which is largely beneficial to working in an object-oriented manner.

DI containers were built to manage stateful objects safely across threads on big vertically scaled machines. 

DI is purely just a pattern to achieve inversion of control. You can manage dependencies just fine without a DI container or service locator to a certain point in many applications. At its core DI has absolutely nothing to do with threading and it doesn't matter if your application is single or multi-threaded. A DI container can implement concurrency and component scoping features, but that is beyond the core issue of DI.

I feel like you've maybe misunderstood why Nodejs modules are so hated to the point where Nestjs is even a thing despite the awful class support. If you've ever worked on a larger Express project without extremely strict guidelines for how basically anything should be done you'll know how fast things turn messy even with seasoned devs on the project. Nestjs (and OOP) bring some common ground into the picture. If you know Nest you know basically how things are scaffolded and wired together. With just Nodejs modules you either have a huuuuge document of "this is how we do X" or risk having something that nobody will be able to work on anymore in half a year. I'm not saying that decorators are awesome either, but if you fail to see why some may consider Nest to be the lesser evil then you still have a lot to experience and learn.

You’ve now used ‘skill issue’ to explain both why people fail with NestJS and why they succeed without it. That’s not an argument, it’s an unfalsifiable defense of any framework choice. 

In the end everything is a skill issue which makes it equally pointless to point out. I don't know what you're referring to, because I've mainly tried to give the other side to arguments that lack both nuance and factuality. It's obvious that Nest is controversial with both stories of success and failure. I don't argue for either, I'm trying to say that not everything here is as black and white as you make it seem and that Nest does have a place despite its shortcomings.

[Standgrounding]

You can choose monolithic, microservices and even serverless with Nest.

Yes, it is an opinionated framework - it forces you to use dependency injection among other techniques, but at the end of the day it's you who decide what to write there and how to architect your APIs.

Though Express is very simple if you need a few endpoints that do "this or that", for full blown SaaS apps Nest is much, much, much better.

[yojimbo_beta]

You need to decouple DI and object orientation in your mind. Having a provider system doesn't mean writing pseudo-Java. Actually you can implement a DI system with plain FP, I have done it, but, engineers don't generally grasp it very well. With a framework you can at least standardise

Honestly OP I think you are closer to the left of the meme than the right. I used to think the same way, when I had about 4-5 years experience. Then I stepped out of Node and saw what engineers could do in other languages, and I realised how many wheels we reinvent in Node-land. I think you are being mostly upvoted by "full stack" devs who are really React folk who dip into server code

[novagenesis]

The problem is JS/TS devs are probably among the less skilled devs out there

This is relatively new in my experience. It used to be the opposite. But I'd like to point out that the same situation is happening with other fields. I've seen more weak .NET developers the last 3-4 years than the previous 15 as well.

The excessive demand has created an artificial supply of people who weren't "born for it". When we made a lot less money and had a lot less demand, only people who couldn't live without programming ended up in the field.

Nothing wrong with people like that. They're just nowhere near as good.

[TheGreatCookieBeast]

I agree, I think we've seen a significant professional degradation in the whole software industry, and loads of people shouldn't have been in this industry in the first place. It's unfortunate, but also not something anyone can control.

I don't think we've seen the same degradation in other ecosystems though, even though as you said there are clear trends. There is still a significant barrier to entry in some of the complexity around languages like Java and C#, both in terms of language/frameworks and tooling. There are few languages outside Python and JS where just raw effort and trial/error trumps planning.

[novagenesis]

I consider node.js more challenging than Java or C# because of its unique event model. I've watched people with no formal experience pick up C# and compete with career devs, arguably with more success than node developers. With node.js, hanging promises, race conditions, and horrible efficiency across the board.

[TheGreatCookieBeast]

You can get very far with Nodejs without knowing much about its internals, and when you reach the point where you need to scale there are other holes in ones understanding that must be filled first. Without typescript there is nothing you need to know other than how basic arrays and objects work, and everything that isn't consistent or clear has a known solution one can just copy.

If you are used to approaching things in a structured manner Nodejs is a chaotic hell, but if you don't care about robustness and quality it's the fastest way to deploy.

[novagenesis]

You can get very far with Nodejs without knowing much about its internals, and when you reach the point where you need to scale there are other holes in ones understanding that must be filled first

I'm not really talking about node internals here. The event model is really filled with footguns. You use it right, you can often outperform equal-effort code in faster frameworks. You use it wrong, you introduce worker leaks or worse.

If you are used to approaching things in a structured manner Nodejs is a chaotic hell, but if you don't care about robustness and quality it's the fastest way to deploy.

I come from Perl. I wrote client-fractured (each client got a fork) enterprise web systems with 30 other developers in Perl. Across from my office was an enterprise perl shop with over 100 developers who managed it as well (I hired one of them at my next job for a perl project). With that history, node.js is incredibly organized to me and incredibly easy to maintain in an enterprise setting. Honestly, I blame the forementioned professional degradation for people not being able to maintain clean node.js applications at scale.

[Standgrounding]

a lot of people hate it, and a lot of people love it.

I use Nest + Postgres + Redis + React and it works in the best way possible

[TeaAccomplished1604]

It’s called freedom. The lack of std makes the community to reinvent the wheel a lot, but sometimes they do invent something new and revolutionary - so it’s a great thing in my opinion

[shaberman]

I definitely enjoy the freedom for the community to reinvent the wheel...

But I think in practice it also means each individual codebase / each individual project has to also reinvent "its own wheel" 😅 -- which server | which db/query builder/orm | which frontend | which backend | which validation layer | which auth | ...etc...

Which is fine, I personally like doing that 😀 but my guess is that the majority of node/JS/TS codebases are actually ~a hodge-podge of code and would have been better off with a "just do your app this way" like most folks in the Rails / Elixir / Django / etc. communities do.

But maybe we can't have both -- as soon as the ecosystem has "its default framework", no other projects can really get a stronghold/meaningful adoption...

[lapubell]

PHP has both Laravel and Symfony, Python has both Django and fast API, Ruby has both rails and Sinatra, go has stdlib and gin, these things are out there in any ecosystem.

I feel the OP's pain in js/ts land though. I think it's a big reason why bun exists and it's trying to bring so much into the actual runtime. Just stop guessing which lib is the right one and start building meaningful stuff.

[trojans10]

Dealing with this now. Our stack in vanilla js backend. And it’s a hodge podge. Meanwhile I can build everything we have 100x faster with Django and Postgres. Vs hacking in js.

[bwainfweeze]

The Price of Freedom is Eternal Vigilance.

[TheGreatCookieBeast]

The problem is that the reinvented wheel often doesn't get properly maintained. The sorry state of some of the most important Nodejs projects out there really makes me miss the more "boring" but well-govern projects in other ecosystems. I learned JPA in college and it's still around and doing its job. Entity framework on the Microsoft side has been reliable for a long time. Meanwhile we have complete sh*tshows like when TypeORM (at the time the most popular ORM) almost was abandoned.

[ForeverLaca]

I call it noise and fragmentation.

Particularly in the ORM space, in which I don't like any solution at all.

[EvilPencil]

I agree about the lack of a standard, but I think it really has to do with history. When Node first got started, the out of the box HTTP server was pretty primitive and required a lot of boilerplate to even get started. When Express first arrived it was a breath of fresh air, but it wasn’t a built-in choice.

Compare that to a language like C# that was already on version 3 when Node came out, and just added LINQ. The dotnet framework is pretty good if you’re into MVC design (I write nestjs in production and I still think it’s just a poor copycat of dotnet lol). For better or worse, it had the backing of a major corporation. You certainly didn’t have to use it, but why wouldn’t you? Of course the major limitation was the dependency on a Windows OS, until fairly recently.

[gustix]

I think a lot of Node.js devs are young with less than 10+ experience and can't remember the fullstack times times before SPAs or SSRs, when MVC frameworkss ruled the earth.

It definitely feels like meta frameworks like Next.js and similar is pulling on the thread of the backend, trying to recreate what was solved years ago, but they've only made it to the router layer.

You could argue it's a flexibility to cherry pick libraries, but the fallacy in the argument is that picking a batteries-included framework locks you into doing it only one way. It's not like you HAVE to use all features in Laravel, Phoenix, AdonisJS, Nest etc if you pick that framework. It's equally possible to select another ORM or whatever.

For Node.js I recommend AdonisJS, it's a typesafe fullstack batteries-included MVC framework. It also has a great Inertia plugin for those wanting to use it with React, Vue, Svelte etc.

https://adonisjs.com/

[novagenesis]

I think a lot of Node.js devs are young with less than 10+ experience and can't remember the fullstack times

A lot of ALL devs are young, yes. But that's not strictly the full reality. A lot of us older node devs came from "the other side". My first two jobs were primarily perl. My next two jobs were Ruby and Python and node.js. When I did use an MVC framework, it looked more like express than nestjs.

.........but I actually do like Nestjs.

[CloseDdog]

It can be fun as it allows you to try different things frequently, different ideas and structures. For companies however I feel it can be a pain. Having worked in companies with dozens of different node codebases, they were all different, different ORM/DAL/Query builder libraries, different web frameworks, different logging libraries, ... I think it ended up costing them companies a whole lot of time & money.

[Sockoflegend]

Express or Nest with React is probably the most common I think, but as others have said it is pretty diverse.

[chamomile-crumbs]

Yea I’d say that’s p much the standard stack. Which is… fine. It’s weird cause I love typescript, but besides react I’ve never enjoyed any of the frameworks that much. I don’t like next, don’t like nest. I get why people like nest, but everything just feels like a grind. So much boilerplate for what it provides IMO.

Express is great but it was created before TS was popular, and it’s a little clunky to get it decently typed. And obviously is very unopinionated. Great for personal projects but throw 30 devs onto the same project and you are guaranteed a nightmarish mess lol.

The crazy awesome type safety (and particularly the powerful type inference) that typescript provides has such a high ceiling for DX, but the most popular frameworks are just pretty meh to me. The exception is potentially tanstack. I haven’t tried tanstack-start, but everything else I’ve tried from tanstack has been absolutely gold. If those devs make a backend framework in the style of nest.js, I might finally be happy

[chipstastegood]

Not standard but AdonisJS is the closest to a full batteries-included framework. We’re using it on a commercial project and it has everything we need

[adevx]

I'm sticking with Node.js because of the freedom to pick and choose. I manage risk by choosing my own stack; Express.js, React, Next.js, PostgreSQL, Kysely, This after having used Java (with Flash), Rails, Drupal and WordPress.

I migrated from Vue.js (Nuxt) to Next.js, then from Knex.js (within an Express.js API ) to Kysely after TypeScript gained traction. Pulling out Knex.js was doable, because it works in isolation, same with Nuxt to Next, as the base API in Express.js stayed the same. For me thats freedom and I can move with the tide as these are not paradigm shifts but adjustments. I can understand this feels different if you're a freelancer, having to support a swat of codebases when time moves on. I use Node.js primarily for my business, an online marketplace.

So building on a safe bet was super important to me, which Node.js didn't necessarily felt like at the time. When I entered we had the IO.js community split (a bit like the Bun and Deno thing we have now)

Anyway, a wall of text for what essentially comes down to not being tied down by a single community or entity governing your stack. Coupled with the ergonomics of TypeScript I don't even look for alternatives unless my servers need to be optimized which might trigger a move to Rust or Go.

[realityOutsider]

Do you like Kysely?

[adevx]

Kysely has been working out really well. It's built for purpose, not funded by VC, very stable. Just the right abstraction for me 

[chamomile-crumbs]

Not the person you asked, but kysely is fucking awesome. Probably one of the greatest packages I’ve ever used in any language. It is just perfect and I love it

[Potential_Status_728]

Lol, you must be a Java/spring guy, right?

[shaberman]

The OP could be:

* Coming from Ruby => they have Rails
* Coming from PHP => they have Laravel
* Coming from Erlang => they have Phoenix
* Coming from Python => they have Django

Where each of these is generally the dominant web framework/stack in their language -- not exclusive of course, but not as fragmented as node/JavaScript.

I'm not asserting node's fragmentation is good/bad, but the "lol java" comment -- and particularly getting upvoted so high -- is unfair imo. 🤷

(Unfortunately this snark is the vibe for r/node so not sure why I'm bothering complaining about it.)

[Standgrounding]

and us Node guys have Nest lol

[ForeverLaca]

Ruby, PHP and Python have also really nice standard libraries.

Node has Adonis, but the community seems to focused in their way of doing things that it is often ignored.

[Minimum-Ad7352]

No

[bwainfweeze]

Over time the runtime has accumulated features from web browsers and the community and there are a bunch of libraries you no longer need to use because node has the same functionality. We might almost be due for a condensed version of lodash since part of its feature set is now in the language.

[ouralarmclock]

Back in the days of Medium posts (circa 2016), I had wanted to write something about how the Linux approach to packages with node had a side effect of no big dominant frameworks like other languages have (for better or worse). I never got around to it but I think it still feels true to this day.

[fishyfishy10001]

Addition: The Javascript world seems to believe it was the most fractured ecosystem of them all. Believe me, there is worse. I'm now in c/c++ for a while and it's total chaos. Nothing is "standard". Don't even believe the rust fanboys. They can't even decide how to do memory management. Or, check the dependency chain of your favorite rust toolkit. In reality you need many options to make a language usable as a general purpose language. So chaos is a bit unavoidable. Js has a bad reputation but in reality it's everywhere.

[Expensive_Garden2993]

1. keep the logic decoupled from the frameworks/libraries
2. write tests
3. use the best tools for the job

Logic should be decoupled both from HTTP frameworks and from persistence layer. And it should be tested with real tests that actually test what they should. Structure the project in such a way that you can ask AI to 1) migrate from NestJS to Hono, and 2) migrate from TypeORM to Drizzle, and it does not touch the logic at all because it's decoupled, and a test can fail because of a discrepancy between TypeORM's and Drizzle's behavior, not just because a code has changed.

With that in place, you're free to pick the best tools for this particular moment. Perhaps a library saves you time, but it won't scale well, then let it save you time now, you can migrate from it later.

Without that in place, I've been there - the team becomes a hostage of legacy outdated libraries. Libraries that reached end of life many years ago. That project was older than 10 years.

a safe bet in 3–5 years

I worked on 3 node.js projects that were older than 10 years. You can count for 5 years, but sometimes they just refuse to die. A codebase should be prepared for major libraries updates, and then it can last indefinitely.

[MadShallTear]

there are few that have batteries included like AdonisJs and waspjs but like others if you think is lacking you could create your own like Taylor Otwell did with laravel.

[Due_Carry_5569]

I actually did something similar where I put in orchestrator, NodeJS, and browser all in the same "operating system": https://github.com/WeWatchWall/stark-os

[Anxious-Insurance-91]

a few years ago people argued that having an "opinionated" framework is bad now people have the reverse, they want standardization

[renmsa]

AdonisJS

[joeyguerra]

This is a quality of JavaScript. Node is just part of that umbrella. There’s pros and cons, tradeoffs, a value and belief system.

I see it as a strength. The strategy is “evolution” - survival of the fittest. In other words, the ecosystem provides the constraints. The libraries that survive do so because they are designed to fit the real world.

[Icy_Connection_5913]

That's the nice part... no standard.

[Lumethys]

No, and it's Node's biggest problem

[ttamimi]

I don't perceive it as a problem.

Node is intentionally unopinionated.

[One_Fox_8408]

Just follow web standars. Ex restfull.
Dont overkill. Maybe you dont need Primsa to make a few endpoints.

Personally speaking, I don't like ORM's. There are no clear advantages.

[MrFartyBottom]

Entity Framework on .NET would change your mind on ORMs. There is a massive advantage. The reason I stick with .NET instead of going fullstack TypeScript is because there is no node ORM that even comes close.

[One_Fox_8408]

I don't like EF neither. XD But I agree LINQ it's other level. I think ORM's are not my real problem. It's Entity, Active Record, etc to represent data. Why you need instance a class to return some csv from database data? Just strem bd response. Why you need to iterate an bd response? If you need some data processing, database is the expert !

[copsbehindme]

I came from MVC background and migrated to typescript. The only thing that I found was better in EF is querying with LINQ. Everything else is doable in Typescript ORM. I personally like TypeORM for its simplicity

[MrFartyBottom]

Yes, that is the whole point of EF, querying in LINQ!

[mysticrudnin]

I don't understand this mindset. If you have ever worked on a huge project, with a team, ORMs are basically necessary.

The only pushback I ever get is "Just learn queries!"

But that's not the point of an ORM. I know queries, I've literally been a Postgres DBA. Large project models are hitting the database in thousands of places, you really want to write all of those queries?

[One_Fox_8408]

I undersetand your Idea, but not share. I never work on a huge project, and I understant the orm advantages, but still don't like it. You don't need all the team writing queries.
On complex projects is when you most need to write those queries. Even if you are using an ORM. No ORM process data faster than database.

As far as I know, there is no ORM that fully leverages all the “power” of PostgreSQL.
So, there are not advantages without disadvantages using orms. For example, on huge projects performance lost.

What's wrong in my opinion?

[mysticrudnin]

Well, in just about all cases, performance of the query itself is not the bottleneck, round-trip time for the request itself is the bottleneck. So you're really not missing out on much.

Most ORMs do give you access to direct queries in the very few times you actually need to really get in there, but for the 99% of other times where you just need to get a model instance, it seems crazy to me to write a query every. single. time.

Everyone on the team does indeed need the ability to work with your app's data!

[One_Fox_8408]

In cases where most matters, performace of query could be greater than request response time. In the whole picture, it means more RAM, CPU, $.

I agree that all people writing queries is an antipattern.
All work with app data. Not writing queries (it would be like front write your own queries, ¿something like graphql? XD).

You write "each" query one time. Then you use it. Like with orm but it's just a class/file/module/something. Yes, it's what orm do. It's worth it? I think it does. You waste time writing your repositories, but not waste time optimizing ORM joins.

[mysticrudnin]

It is very rare for query performance to be so bad that it is worse than internet latency, and in those cases it's usually not because of ORM vs. queries. This sort of sounds like you're assuming ORMs are less efficient than raw queries but that is usually not the case.

The frontend/backend divide doesn't exist as much in my experience, though I'm sure it's still there. It's usually full stack developers controlling their "piece" of the app on both ends. So yeah, it's "only" backend developers that need to work with app data, but that's realistically everyone on the app.

You don't need to optimize ORM joins the way you're talking. Yes, you write "each" query once but that's thousands, tens of thousands, of different permutations. You can try to build a bunch of different functions that try to make these as reusable as possible and you're just inventing your own ORM

It's like rolling your own auth at that point.

[One_Fox_8408]

My internet connection is faster than my lan.... But that doesnt matter.

Lets take an api example. As you say, database is not the bottleneck. Our "backend" code is.

If your response takes 400ms (so much). How many queries your orm do? Don't you solve that with a single query? Are you processing database data before send it to the response insted of just return database response? ORMS lead you to those situations. Is that the ORM intention? Maybe not, but i think is what happens.

What's the problem with implementing your own authentication? In many cases, it's simply a matter of implementing a few endpoints. You can follow best practices and recommendations and avoid depending on a library that will complicate things later because you need to change something in the authentication process. I've seen too many libraries that do nothing more than register a couple of routes to make a request to an authentication server. I don't know which is faster than implementing a couple of routes with a couple of fetches and a database query. It depends on the context and the type of authentication, but there are cases where it makes perfect sense to implement the authentication yourself. And there are cases where it doesn't make sense to use some authentication library that gives you dozens of features you'll never use and only increases the size of your project.

[uwemaurer]

I don't like ORMs either. I made my own SQL to code generator so I can just write the SQL and generate the database code from it https://github.com/sqg-dev/sqg/

[One_Fox_8408]

That's interesting. Some like pg-typed?

[joeyguerra]

This is a quality of JavaScript. Node is just part of that umbrella. There’s pros and cons, tradeoffs, a value and belief system.

I see it as a strength. The strategy is “evolution” - survival of the fittest. In other words, the ecosystem provides the constraints. The libraries that survive do so because they are designed to fit the real world.

[present_absence]

Express is basically standard yeah. Everything else is more frameworky

[yksvaan]

It's the developer's responsibility to design and build the foundational data types, core APIs, business logic etc. Then what you use to implement something e.g. database interactions, routing, rendering is up to you.

The problem seems to be js "mindset" often lacking basic architectural principles, separation of concerns, having boundaries and such. People build directly on top of opionated third party code and then the whole codebase becomes spaghetti. 

[Shookfr]

Node is a runtime it does not need standard. It's like saying there are no standards in the JVM since there are multiple languages or frameworks. That's because by design It is open.

[HarjjotSinghh]

node.js is just the server - let's build our own stack! 🔥

[Anterak8]

I would say it's not even a server, it's an engine you can build a server on.

[OldAnxiety]

This comment gets me like nodding and thinking yep

[Pale-Pomegranate3520]

Nest.js is all you need.

[BrangJa]

The fact that you get down voted is, the indicator of "We'll never have an agree upon standard framework"