npmgraph VS postgres

You don't think depending on dozens or even hundreds of NPM packages with a single maintainer is an issue?

Just as an example, Express depends on 25 modules with a single maintainer.

https://npmgraph.js.org/?q=express

Obviously a router is a fraction of what's needed for any non trivial backend project.

It's not a frontend problem but a JS-ecosystem problem. Happens in the backend too.

The JS landscape is an absolute mess where dependencies have dozens if not hundreds of other dependencies. As an example, this is the dependency graph of Platformatic (a Node framework based on Fastify):

https://npmgraph.js.org/?q=platformatic#zoom=h

Each of those dependencies could be abandoned at any moment. Even huge dependencies like Axios or Express seemed to have been abandoned at one point.

And then each dependency is ruled by whatever their maintainers think is right. Just the other day a dependency I use in prod with aprox 25M downloads per week (React is aprox 26M) and used by 10M Github repos decided it was ok to drop support for Safari versions from about 3 years ago. It's just insane considering Safari has +50% mobile market share in the US.

In recent years, it's started to feel like you can't trust third-party dependencies and extensions at all anymore. I no longer install npm packages that have more than a few transitive dependencies, and I've started to refrain from installing vscode or chrome extensions altogether.

Time and time again, they either get hijacked and malicious code added, or the dev themselves suddenly decides to betray everyone's trust and inject malicious code (see: Moq), or they sell out to some company that changes the license to one where you have to pay hundreds of dollars to keep using it (e.g. the recent FluentAssertions debacle), or one of those happens to any of the packages' hundreds of dependencies.

Just take a look at eslint's dependency tree: https://npmgraph.js.org/?q=eslint

Can you really say you trust all of these?

NestJS is probably the closest thing to a Rails-like framework in JS. Also Platformatic by the creator of Fastify.

Still, the dependency entanglement in JS is just crazy. This is the dependency graph of Platformatic:

https://npmgraph.js.org/?q=platformatic#zoom=h

AFAIK there's no JS framework that solved the whole thing and doesn't depend on other packages.

I don't know why JS devs historically have an aversion to frameworks. Maybe the author of the article is right and this is caused by preventing heavy bloated JS apps in the browser.

In any case, after 10 years of Node in the backend, I'm done with it.

Lots of people taking general pot shots at different languages and ecosystems.

But OP was trying to install gatsby on a different node target. It's not some little library. These kinds of massive libraries break all the time: https://npmgraph.js.org/?q=gatsby

React and react-dom are peer dependencies (npmgraph lists them but doesn't graph them visually). The actual full installation command is: `npm install next@latest react@latest react-dom@latest`[1]. Even if you include react and react-dom, the dependency graph still looks tolerable to me: https://npmgraph.js.org/?q=next%4014.2.13%2C+react%4018.3.1%...

[1] https://nextjs.org/docs/getting-started/installation#manual-...

This looks a lot better than I expected.

One thing that bugs me about this (and Tailwind) is the number of dependencies they pull in. Panda has 152 nodes (239, if you count their dev-dependencies)[0].

Tailwind has 98 (594 if you count their dev-dependencies).

I know they're only dev-dependencies, but still... I've got all of that code running on my machine, just to process CSS. I really don't love it.

[0] https://npmgraph.js.org/?q=%40pandacss%2Fdev

This is what I came up with. I get 514. I got 496 here https://npmgraph.js.org/. I'm curious what you get using npm and/or yarn, or other tool.

> What are you missing?

Everything else needed to make a backend app.

At the very least, Node should provide fundamental pieces like database drivers. Currently the best PG driver[1] depends on a single guy.

Bun already provides its own PG driver [2] and Jarred has written they will keep investing into more built-in APIs.

[1] https://github.com/porsager/postgres

[2] https://bun.com/docs/api/sql

postgres driver

Great post!

Postgres.js actually does this implicitly through a simple API[1] mimicking the postgres way, thereby using only a single dedicated connection for listening per process.

Listen/notify is also super useful with triggers.

[1] https://github.com/porsager/postgres

I want to use this as a chance to bring attention to a GitHub issue that I think would help reduce friction for Neon:

https://github.com/neondatabase/neon/issues/4989

If the Neon driver were to allow us to easily pass in a localhost connection, the development and test experience would be easier. Perhaps Neon could swap to something like this internally: https://github.com/porsager/postgres.

Having run a local dev environment connected to Neon and tests connected to Neon got in our way of adoption. We'd prefer to develop and run tests against a regular Postgres localhost database.

To the PMs of Neon, put yourself in the shoes of a new developer thinking of giving Neon a try. What changes will I have to make to my code and my development workflow?

I'd push you to consider using postgres, slonik or similar for database queries. With these libraries, you just write SQL, but they perform input sanitization for you. So you can safely write:

Thanks Pier! Your comment saved me some frustration here :-D

https://github.com/porsager/postgres/discussions/627#discuss...

There's a core client interface here:

- https://www.postgresql.org/docs/current/client-interfaces.ht...

On what makes it postgres.js faster, from author himself:

> it seems Postgres.js is actually faster than, not only pg, but of any driver out-there

- https://github.com/porsager/postgres/discussions/627

- https://porsager.github.io/imdbench/sql.html

When viewed as a DSL for set theory, views, CTEs, set-returning functions, et al are indeed proper first-class query abstractions.

When viewed through the lens of general purpose imperative or functional programming languages, it's easy to see how it can be seen as falling short.

I'll admit much of the tooling and driver APIs leave a lot to be desired.

Some tools do make good efforts though such as nested fragments in this driver.

https://github.com/porsager/postgres#building-queries