251–260 of 275 posts
Earlier quoted context omitted.
What are the main pain points?
Package and environment management are both pretty commonly brought up.
Python libraries are much more stable and reliable.
Earlier quoted context omitted.
I’d argue that JS/TS is more popular than ‘some language’ would suggest. If there’s a problem that affects 19% of customers it should be fixed. I am not saying this problem exists and 19% is a made up number, the grandparent post seems to think there is some kind of problem.
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.
People were cuddling and pasting code from random people on the Internet they didn't understand for many years before package managers where there were zero maintainers. Many people that don't properly understand supply chain issues still are.
Earlier quoted context omitted.
You're being downmodded for not providing any supporting arguments, but there's some compelling protection for malicious modules in these other JS implementations.
Am I? My comment was 7 words suggesting consideration for Deno 2, responding to a 7-word comment suggesting to use Bun.
Earlier quoted context omitted.
Them is fine. It's short for "Have them [Node bozos improved it], though?" Or, equally likely it, refers to deno and bun ("deno and bun has really made Node focus and improve", "Have them (deno and bun) really made Node focus and improve, though?")
Your expanded version is also incorrect.
(Also the expansion was meant as a joke in case it went woooosh - I don't mind-read to know what the OP meant)
Earlier quoted context omitted.
Good to someone, somewhere, telling everyone else what good is. Arguably, code formatters should be configurable, to get a format for your code that you want. Unfortunately, prettier isn't one, and it is a form of regression in many communities at the cost of choice pruning. It might be great for a CI pipeline for constraining how code should look (use prettier, dumbass!), but it isn't great for actually formatting c…
Using it as a precommit hook in OSS projects makes it so that people can write code however they want. But it ends up in the repo following the guidelines of the repo. Minimizing unnecessary back-and-forth with PRs. Extremely useful in my opinion. Even though prettier has defaults, but they can be modified to quite some extent to suit your projects needs: https://prettier.io/docs/options
That is the point of a formatter, so any formatter would do that (and there were many more active projects to allow formatting before prettier came around).
> quite some extent
Not really, and I have written prettier plugins to get around that constraint.
IMO, its not great, which is kind of how things work out when you try to do everything in one project.
Earlier quoted context omitted.
This. It's 2025 and the node ecosystem is finally usable by default! ESM modules just work with both Node and Typescript, Node can run .ts files, and there's the a good enough test runner built in. --watch. The better built in packages - `node:fs/promises` - are nice with top-level await for easier async loops. It took a while to convince everyone involved to just be pragmatic, but it's nice now.
This is great to hear, but perhaps comes too late for people like myself. Node.js has been by go-to platform from around 2014 until last year. But around September last year, I found myself thrust into the .NET ecosystem (due to a client project). Within a few months, I realized that it too, had finally become usable by default (unlike the last time I tried it, when it was too tightly coupled to Windows). In fact, it…
Earlier quoted context omitted.
What's the story with supporting CommonJS libraries? I've tried to update many projects to ESM multiple times over the years, and every time, I ended up backing out because it turned out that there was some important upstream library that was still CommonJS - or even if we fixed those issues, our downstream NPM consumers wouldn't be able to consume EJS. So then you have to go down this rabbit hole of dual compilation…
It's possible, but it can be weird and difficult: https://nodejs.org/docs/latest-v17.x/api/esm.html#esm_common... Thankfully, actively-maintained CommonJS-only packages are quite rare by this point (in my experience). > our downstream NPM consumers wouldn't be able to consume EJS Node.js 20.17 and later supports loading ESM using `require()`: https://nodejs.org/api/modules.html#loading-ecmascript-modul... The next ve…
What backend framework is the go to these days? Still Express?