9 ms·
I think this + node:test makes Node.js a pretty compelling sensible default for most things now. Running things with `tsx` was such a QoL improvement when it ha
by lunarcave 1y ago
I think this + node:test makes Node.js a pretty compelling sensible default for most things now. Running things with `tsx` was such a QoL improvement when it happened, but it didn't solve everything.
Runtime type assertion at the edges is mostly solved through `zod` and tools like `ts-rest` and `trpc` makes it so much easier to do full-stack Typescript these days.
- madeofpalk 1y agoThis. 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.
- thrown-0825 1y agodoes it have a go fmt / lint command yet?
- sisve 1y agoNope
- thrown-0825 1y agoshame, I remember having a lot of issues getting ts-lint to work with test runners a few years back.
- pjmlp 1y agojslint/tslint are an install away.
- beart 1y agotslint has been deprecated for quite a long time now - from 2019: https://github.com/palantir/tslint/issues/4534 https://github.com/palantir/tslint/issues/4534
- thrown-0825 1y agowerent one of the js linters part of a supply chain attack recently?
- pjmlp 1y agoMaybe, are you sure Go dependencies are immune to similar attacks?
- fabioborellini 1y agoYes, with the difference that Google would have to be compromised in order to poison the go distributable containing fmt tool. With js, it’s enough to poison any single one of the 1400 dependencies of the linter
- homebrewer 1y agoUse biome, it doesn't have any external dependencies. eslint should have been put to rest a long time ago.
- prmph 1y agoGood advice. That was my conclusion as well after years of fighting with eslint.
- thrown-0825 1y agosomeone else recommended this too, I'll give it a shot next time I'm in js land.
- 1y ago
- Sammi 1y agonpx prettier
- thrown-0825 1y agodoes that require a config?
- coldtea 1y agodepends, will you keep finding pendatic faults after any answer?
- ohmahjong 1y agoHaving a typo in "pendantic" is a masterstroke
- thrown-0825 1y agoI come from go where this stuff is default
- akarlsten 1y agoNo, it has good defaults. See also: https://prettier.io/docs/option-philosophy https://prettier.io/docs/option-philosophy
- d357r0y3r 1y agoWhat'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, which actually means using something other than tsc.
- WorldMaker 1y agoWith "type": "module" there's very few reasons to do dual compilation unless you have very conservative downstreams that hate promises and async/await, and even then there's mitigations now (sync `require()` of async ESM). It's been a while since I've had a trouble importing an upstream CommonJS library. Often it is easy enough in the rare cases where upstream is particularly old/gnarly you can vendorize an ESM build with rollup or esbuild. That said, CommonJS is also now a strong maintenance signal for me and if a library doesn't have recent ESM builds I start to wonder if it is at all well maintained and not just a pile of tech debt to avoid. JSR has started becoming my first place to search for a library I need, ahead of NPM, because of JSR's focus (and scoring systems) on ESM first and good Typescript types.
- ItsHarper 1y agoIt's possible, but it can be weird and difficult: https://nodejs.org/docs/latest-v17.x/api/esm.html#esm_commonjs_namespaces 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-modules-using-require https://nodejs.org/api/modules.html#loading-ecmascript-modul... The next version of Babel (currently in beta) is even going ESM-only.
- deleted 1y ago[deleted]
- 1y ago
- hliyan 1y agoThis 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 felt like what Node.js would be, if it had strong typing built-in, and had a good standard library that eliminated a lot of the module management and churn. I'm now finding it hard to return to Node.js.
- ninetyninenine 1y agoEh the focus on OOP is my main issue with it. It’s not my style in that sense.
- WorldMaker 1y agoF# is a great FP language that runs on .NET and there's a growing field of FP proponents working in C#, sort of a Trojan Horse situation trying for a best of both worlds (easy onboarding for C# junior devs, but deep FP options thanks to things like C#'s clever LINQ syntax). LanguageExt is a big part of some of those ecosystems: https://github.com/louthy/language-ext https://github.com/louthy/language-ext
- deleted 1y ago[deleted]
- throwanem 1y agoInteresting. I haven't looked hard at .Net despite some advocacy from past colleagues. Perhaps I should.
- pimbrouwers 1y agoI can second this experience. I arrived roughly 10 years ago, right in time to see netcore1.0 emerge. Been onboard even since. You should absolutely check it out. The compilation story (native aot) is what I'm currently most excited about it.
- firloop 1y agoIt's still probably better to use Bun.
- chrisweekly 1y agoDeno 2 is (arguably) just as compelling.
- nailer 1y agoYou're being downmodded for not providing any supporting arguments, but there's some compelling protection for malicious modules in these other JS implementations.
- chrisweekly 1y agoAm I? My comment was 7 words suggesting consideration for Deno 2, responding to a 7-word comment suggesting to use Bun.
- nailer 1y agoIt was a collective you, applying to the parent post as well.
- chrisweekly 1y agoThat's... weird. And kind of hypocritical, given the quality of your own comment which (a) mentioned downvotes and (b) used a few more words that boil down to "module protection". At this point I'm not exactly elevating the conversation either, for which I apologize. But I do think brief comments like mine and the one I replied to are perfectly fine.
- balamatom 1y agoYou mean TypeScript. TypeScript is finally usable by default.
- madeofpalk 1y agoI mean Node. I find writing Node in JS intolerable. ESM, --watch, and TS syntax support is the combo that makes it all good!
- balamatom 1y agoWell, only goes to show how different everyone's experiences are. I guess I've had the opposite one: Node+CommonJS was something I was extremely comfortable with. The slow adoption of ESM by Node, with many compatibility missteps, the thousand papercuts around TS, the way frontend-centric toolchains kinda-sorta paper over the whole thing, letting it fester, and the way people have been acting like things are ready for primetime for over a decade while diligently testing them in production, all of that came later. To the point of having me wondering how did people work with TypeScript before ~5.4 - though evidently they did, and had few if any of the same complaints! Baffling but IIWII. Anyway, only this year I discovered a pure `tsx` + ESM workflow had become viable OOTB, to no little surprise. I perceive that as the toolchain becoming unfucked just as randomly as it became fucked when Node 16 did what it did. Not that it didn't take a couple years for TS to "invent" the right compiler flags that it took to tell it to stay out of the runtime's way, too. So a good year overall. Hope they don't break it again because when they do it's an uphill struggle to convince them that they have.
- edem 1y agonah. it is still eons behind literally everything else
- pseudosavant 1y agoI can’t help but think that none of these would have happened without Deno doing it first. It was basically the pragmatic Node before Node started to get reasonable.
- benoau 1y agoWatching NodeJS fill in these gaps the last 5 years or so has been great, I strongly prefer using built-in stuff as much as possible now to avoid bloating the modules and becoming dependent on a thousand random people being good-stewards of their packages.
- ZYbCRq22HbJ2y7 1y agoThe standard library could use some more work.
- throwmeaway222 1y agoYou did the "this" thing AND the "it's $CUR_YEAR"
- socalgal2 1y agoDoes this run tsx? Even with the types stripped you still need the JSX transformed to JavaScript
- wartijn_ 1y agoIt doesn’t. The comment you’re replying to is referring to tsx, the package that lets you execute ts files, not to running files with the tsx extension. https://github.com/privatenumber/tsx https://github.com/privatenumber/tsx
- rs186 1y agoLet's see if Sveltr converts their codebase back to TypeScript
- _heimdall 1y agoI'm very much in favor of TS support directly in node. vitest has made it easier these days, but I've lost too much time over the years getting the balance just right when configuring test environments for .ts files. trpc and ts-rest are a different animal in my opinion. I'm happy to use either one but won't deal with them in production. For trpc that's mainly due to the lack of owning API URLs and being able to more clearly manage deprecating old URLs gracefully. For ts-rest I just tend to prefer owning that setup myself, usually with zod and shared typings for API request/response pairs. It also does irk me every time I import what is clearly an RPC tool named "-rest"
- port11 1y agovitest is incredible; it makes one wonder how/why jest, with its larger user base and community, couldn't get its TS support sorted.
- edem 1y agoi switched to python a while ago. it has batteries included. i feel so much better now that i dont have to debug all the quirks of a half-baked system.
- wredcoll 1y agoJust wait, you'll find the python pain points at some point. Two types of languages...
- edem 1y agoWhat are the main pain points?
- kaffekaka 1y agoPackage and environment management are both pretty commonly brought up.
- ccanassa 1y agoI work with Node every day, and the library ecosystem is a nightmare. Just keeping a project from falling apart takes a huge amount of effort. Libraries are either abandoned when the author moves on, or they push major releases almost every month. And there’s a new CVE practically every week. Python libraries are much more stable and reliable.
- nake89 1y ago> the library ecosystem is a nightmare I agree. > Just keeping a project from falling apart takes a huge amount of effort I think the culture of importing libraries with lots of dependencies is a big contributor. > Libraries are either abandoned when the author moves on This applies to any OSS project. Generally speaking popular abandoned libraries get forked. > or they push major releases almost every month This sounds like a very bad library to use. I would not recommend having this type of library as a dependency in Node or even in Python for that matter. > Python libraries are much more stable and reliable. Not sure what would make python libraries magically more stable and more reliable. Maybe libraries with minimal dependencies would could be the reason. That is why I recommend 0 or minimal dependecy libraries for node.