| ▲ | madeofpalk 5 days ago |
| 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. |
|
| ▲ | hliyan 4 days ago | parent | next [-] |
| 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 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. |
| |
| ▲ | throwanem 4 days ago | parent | next [-] | | Interesting. I haven't looked hard at .Net despite some advocacy from past colleagues. Perhaps I should. | | |
| ▲ | pimbrouwers 4 days ago | parent [-] | | I 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. |
| |
| ▲ | 3 days ago | parent | prev | next [-] | | [deleted] | |
| ▲ | ninetyninenine 3 days ago | parent | prev [-] | | Eh the focus on OOP is my main issue with it. It’s not my style in that sense. | | |
| ▲ | WorldMaker 2 days ago | parent [-] | | F# 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 |
|
|
|
| ▲ | d357r0y3r 4 days ago | parent | prev | next [-] |
| 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, which actually means using something other than tsc. |
| |
| ▲ | ItsHarper 4 days ago | parent | next [-] | | 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 version of Babel (currently in beta) is even going ESM-only. | | | |
| ▲ | WorldMaker 2 days ago | parent | prev | next [-] | | With "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. | |
| ▲ | miohtama 4 days ago | parent | prev [-] | | It's almost like Python 2 to Python 3 upgrade. Took a decade but everyone is finally happy. |
|
|
| ▲ | pseudosavant 4 days ago | parent | prev | next [-] |
| I 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 4 days ago | parent | next [-] | | That's kind of the whole history of NodeJS, dragged-forward kicking and screaming right from the 0.x and IO days! | |
| ▲ | bapak 4 days ago | parent | prev [-] | | Deno first and then Bun. Node should just pass the flag at this point, they just do things to catch up. |
|
|
| ▲ | benoau 4 days ago | parent | prev | next [-] |
| Watching 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. |
|
| ▲ | balamatom 4 days ago | parent | prev | next [-] |
| You mean TypeScript. TypeScript is finally usable by default. |
| |
| ▲ | madeofpalk 4 days ago | parent [-] | | I mean Node. I find writing Node in JS intolerable. ESM, --watch, and TS syntax support is the combo that makes it all good! | | |
| ▲ | balamatom 3 days ago | parent [-] | | Well, 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. |
|
|
|
| ▲ | ZYbCRq22HbJ2y7 4 days ago | parent | prev | next [-] |
| The standard library could use some more work. |
|
| ▲ | edem 4 days ago | parent | prev | next [-] |
| nah. it is still eons behind literally everything else |
|
| ▲ | firloop 4 days ago | parent | prev | next [-] |
| It's still probably better to use Bun. |
| |
| ▲ | chrisweekly 4 days ago | parent [-] | | Deno 2 is (arguably) just as compelling. | | |
| ▲ | nailer 3 days ago | parent [-] | | You're being downmodded for not providing any supporting arguments, but there's some compelling protection for malicious modules in these other JS implementations. | | |
| ▲ | chrisweekly 3 days ago | parent [-] | | Am I? My comment was 7 words suggesting consideration for Deno 2, responding to a 7-word comment suggesting to use Bun. | | |
| ▲ | nailer 3 days ago | parent [-] | | It was a collective you, applying to the parent post as well. | | |
| ▲ | chrisweekly 3 days ago | parent [-] | | That'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. |
|
|
|
|
|
|
| ▲ | thrown-0825 5 days ago | parent | prev | next [-] |
| does it have a go fmt / lint command yet? |
| |
| ▲ | Sammi 5 days ago | parent | next [-] | | npx prettier
| | |
| ▲ | moogly 4 days ago | parent | next [-] | | I moved on to Biome (which replaces both ESLint and Prettier) and while the IDE extensions have been a bit buggy, it's much faster and has fewer dependencies. It was always a pain to set up ESLint + Prettier. | | |
| ▲ | MrJohz 4 days ago | parent | next [-] | | ESLint these days doesn't have any styling related lints (unless you opt into them) which means that it works out-of-the-box with Prettier (or Biome's formatter, presumably). My fear with Biome is missing out on type-aware lints, but I know Oxlint has had some success integrating the new Go typescript compiler, so maybe that will work out for Biome as well. | |
| ▲ | latchkey 4 days ago | parent | prev [-] | | Replacing something hard to setup with something buggy is a win? | | |
| |
| ▲ | thrown-0825 5 days ago | parent | prev [-] | | does that require a config? | | |
| ▲ | coldtea 5 days ago | parent | next [-] | | depends, will you keep finding pendatic faults after any answer? | | | |
| ▲ | akarlsten 4 days ago | parent | prev [-] | | No, it has good defaults. See also: https://prettier.io/docs/option-philosophy | | |
| ▲ | 3 days ago | parent | next [-] | | [deleted] | |
| ▲ | ZYbCRq22HbJ2y7 4 days ago | parent | prev [-] | | 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 code, as it just makes the code "prettier". | | |
| ▲ | nake89 4 days ago | parent [-] | | 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 | | |
| ▲ | ZYbCRq22HbJ2y7 3 days ago | parent [-] | | > Using it as a precommit hook in OSS projects makes it so that people can write code however they want. 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. | | |
| ▲ | nake89 3 days ago | parent [-] | | > 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). No arguments here. You are free to choose the formatter you want. > Not really, and I have written prettier plugins to get around that constraint. Or you could simply use those better formatters you were talking about. |
|
|
|
|
|
| |
| ▲ | pjmlp 5 days ago | parent | prev | next [-] | | jslint/tslint are an install away. | | |
| ▲ | beart 2 days ago | parent | next [-] | | tslint has been deprecated for quite a long time now - from 2019: https://github.com/palantir/tslint/issues/4534 | |
| ▲ | thrown-0825 5 days ago | parent | prev [-] | | werent one of the js linters part of a supply chain attack recently? | | |
| ▲ | pjmlp 5 days ago | parent [-] | | Maybe, are you sure Go dependencies are immune to similar attacks? | | |
| ▲ | fabioborellini 4 days ago | parent | next [-] | | Yes, 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 | | |
| ▲ | pjmlp 4 days ago | parent | next [-] | | I forgot that even though fmt will never suffer from middle man attacks downloading the Go toolchain, the standard library already covers 100% of the uses cases someone cares about using Go for, and no one is using CGO. | | |
| ▲ | DanielHB 4 days ago | parent [-] | | I used to use CGO quite a lot in linux-embedded environment. And we had huge dependency chains as well to non-standard library stuff, nowhere near as bad as an average nodejs project but still not free from the problem. |
| |
| ▲ | homebrewer 4 days ago | parent | prev [-] | | Use biome, it doesn't have any external dependencies. eslint should have been put to rest a long time ago. | | |
| ▲ | prmph 4 days ago | parent | next [-] | | Good advice. That was my conclusion as well after years of fighting with eslint. | |
| ▲ | thrown-0825 4 days ago | parent | prev [-] | | someone else recommended this too, I'll give it a shot next time I'm in js land. | | |
| ▲ | DanielHB 4 days ago | parent [-] | | We added biome to our project, now we have eslint, prettier and biome in the project. Seriously though it is nice, but migrating away from your existing tooling is painful and underappreciated. |
|
|
| |
| ▲ | thrown-0825 4 days ago | parent | prev [-] | | go std lib being compromised would be a pretty major achievement |
|
|
| |
| ▲ | sisve 5 days ago | parent | prev [-] | | Nope | | |
| ▲ | thrown-0825 4 days ago | parent [-] | | shame, I remember having a lot of issues getting ts-lint to work with test runners a few years back. |
|
|
|
| ▲ | throwmeaway222 4 days ago | parent | prev [-] |
| You did the "this" thing AND the "it's $CUR_YEAR" |
