Hacker News Reader

Agreed with everything, except this:

> I really wish the Node, Typescript, Deno/Bun, and maybe some bundler people would come together and figure out how to make this easier for people.

Bun has solved this. Bun is straight-up magic; they've implemented tons of hacks and heuristics so everything just works. Bun can even handle ridiculous or otherwise invalid code, like having import and require in the same file.

My point here is that Bun should go teach Node how to be pragmatic and build a good developer experience

Oh, yeah, totally agreed then.

> tons of hacks and heuristics

So, business as usual in the Javascript space. That's how the ecosystem got here, and why nothing works reliably.

Like I said in my comment, Bun works just fine. You seem to have taken 5 words I said out of context to justify something that I didn't say. It's not true that "nothing works reliably". Bun works reliably.

I’ve never heard of bun before today. Why is it so low key and what’s it main selling point?

What are your main sources of tech news? Bun has been quite a darling here for a while..

My own primary news source these days is HN and I’ve missed anything about it, your comment isn’t really helpful.

let me HN it for you - https://hn.algolia.com/?dateRange=pastYear&page=0&prefix=tru...

It's a pretty recent development in the frontend landscape. Its main selling point is a fabulous developer experience. That and, like I said, combing over the ESM mess and basically Just Working (TM).

How hard would it be to migrate a node project to Bun though? I want to move, but I'm not sure.

Should be a drop-in replacement.

TL;DR: It is too buggy.

I tried it and ran into many issues. For example:

- Incompatibility of transpiled artifacts with the Node runtime (many bugs were fixed, but I haven't tried again). I don't trust bun as a runtime.

- Broken monorepo support.

- No direct react support; you still need react-scripts/webpack/whatever. They have documentation on transpiling react, but it isn't the same.

- No type checking, as with many other tools.

Also, filter their issue tracker for bugs: https://github.com/oven-sh/bun/issues?q=is%3Aissue+is%3Aopen...

Bun has solved this, unless you have developers on Windows.

Unfortunately, bun is unusable due to a myriad of bugs. I closely monitor every bun release, hoping it will function well beyond simple node use cases. The idea is amazing, and I would love to switch to bun, but looking at the issues - no, not yet. How can I trust bun to be a secure runtime with all these bugs?

Which bugs are you referring to? Every runtime has bugs in the issue tracker; you'll have to be more specific than that.

I ran into all types of bugs, including segfaults and incompatibilities with node. After encountering bundler bugs like https://github.com/oven-sh/bun/issues/6168 and https://github.com/oven-sh/bun/issues/4216, I stopped finding workarounds to get bun working.

Totally agree.

It's doubly frustrating because a standard for authoring modules across browser and server platforms such as ESM is a good thing. But it's a bit arrogant to expect module authors across TS and JS ecosystems to ship overnight. Beginners may just turn to Deno or Bun simply because hundreds of coding tutorials and snippets no longer work.

Or, when you finally get a TS config that works but then you import @aws-sdk/* or prisma seeds and then you really rip your hair out.

I am finding whatever NextJS does “just works” and I hit issues when I roll my own stuff. But I have’t dug deeply into how they do it yet.

> I roll my eyes whenever the HN-types complain about CSS or frontend development being a hellhole. Mostly the comments I see seem ignorant or impatient ("Why doesn't this thing work without be bothering to learn it?")

I’d also argue that outsiders looking into all the complexity are ignoring the complexity within their own specialization: https://bower.sh/front-end-complexity

It’s hypocritical thinking.

Couldn't agree more. Love the frontend-space, love the ecosystem, but hate the whole ESM vs. CJS fiasco with a passion.

To some degree, I think the typescript-team itself also has to take some blame here. I understand their point that they do not want to do any rewrites, and to some degree it makes sense, but if the ecosystem as a whole really wants to move forward to a common understanding of how it should work, someone needs to do the heavy lifting for dev-experience, and right now they're best-equipped to actually solve the problem, or at the very least help us a lot in doing so.

Their dogmatic approach makes sense for the scope they set out with when starting with typescript but in my eyes refuses a bit the reality the ecosystem currently finds itself in. And I'm saying this as an absolute ts-fanboy; it's one of the very few things about typescript that I take an issue with.

I’m curious what it is you think TypeScript could do, or could do differently, to address the situation. Or what you think they’ve been dogmatic about, and what reality they’ve refused [to see? to accept? to fix? unclear what you mean]?

Hard agree, especially with your first two paragraphs :)

The biggest tip I would add is to bin jest and start using vitest.

For projects where I can, I've moved to Deno and never looked back. It's blissful over there

Except when you need libraries from npm, and then you have a choice 1) use npm: imports and watch things not work 2) use esm.sh imports and watch supposedly-immutable URLs change their contents all the time, and be ready to pile on kludges to get transitive dependencies to behave.

Bartek from the Deno team here. You can also use `package.json` and bare specifiers with Deno. We also recently added `--unstable-byonm` flag (Bring Your Own Node Modules) that allows you to manage `node_modules/` be the package manager of your choice. In other words, you should be able to drop Deno into an existing Node project.

I have had mixed results when using NPM libraries, but I also haven't run into any cases yet where I absolutely needed them

Some stuff you might reach out to NPM for is built into Deno's standard library. Other stuff has become built-in JS language features over the years. And the ecosystem, while nowhere near as big as NPM's, seems to have all the most important stuff at this point, at least for back-end work

And if I have to fill gaps by reinventing some small wheels here and there, or by interning and converting an NPM library, that's still worth it to me to avoid all the tooling headaches

Relieved to hear I’m not the only one. I always blamed myself for not understanding it deeply enough. But admittedly, it is a shit snow and the most frustrating part of development.

How about not using Jest?

Once Bun is feature complete I’m jumping ship

So much this.