Hacker Newsnew | past | comments | ask | show | jobs | submit | andyfleming's commentslogin

There’s a project Nub that is meant to bring the benefits of bun to node, which you might appreciate. It also may articulate that gap as to why people like using bun.

https://nubjs.com


What are the benefits, though?


With Bun, I have a single dependency which gives me: bundling, runtime, package management, test runner, SQLite, Postgres connectivity, S3 utilities, sane APIs (compare Bun.serve to whatever the heck I had to do in Node), routing…

Basically, Bun is giving us something between Rails and the .Net framework for Typescript. It’s become an (almost) standalone runtime for running low-dependency apps.


This:

    node + npm + vitest + vite
Turns into:

    bun
That's the benefit


Throwing out a couple more benefits: bun is faster than node, dramatically so in some specific cases (websockets). Bun also has been doing a great job at building out core libs that probably don't make sense for node, such as the native inbuilt sqlite module, thereby reducing your dependency graph.

People shit on the node/npm ecosystem relentlessly for the typical inauditable deep dependency graph, and bun makes substantial improvements to that situation.

Edit: bun recently added an inbuilt api for manipulating images (resize, change formats, etc). Another good example of them adding native/faster functionality that replaces significant dependencies (in this case, likely sharp: https://www.npmjs.com/package/sharp?activeTab=versions)


I rather replace bun with deno, given that now both bun and deno are written in Rust, and Deno have even more node compatibility than bun. Deno and Node both runs on V8, while Bun runs on JSC, and Deno has a killer feature that you don't have to even run npm install to use package, you can just top-level import or await import an URL (given that you allowed it with a command prompt or bypass it competely with -A but discouraged).

I've used Deno, CucumberJS and Playwright to write E2E test suites. Zero npm install and not even deno.json or package.json


To say nothing of `bun install` being about 50 times faster than npm, and disabling most post-install hooks by default.


I like Zellij, but one point of friction I ran into was it not loading profile configurations like .zprofile. https://github.com/zellij-org/zellij/issues/1434


Is that similar to the functionality they're targeting with Mojo?


> Two deaths occurred — one caused by cryptococcal meningitis and one by severe dementia with agitation owing to the progression of preexisting neurocognitive impairment.


If the islet cells persist then it's effectively cured. If new cells have to be injected regularly it's still likely to be a very effective treatment.


Perhaps, but generally we hope the cure to be better than the affliction. Type 1 is fairly easily managed with insulin pumps and CGM for a closed loop system that almost approximates a functional pancreas.

Taking immuno-suppressants, which often have painful or nauseous side-effects, as well as the elevated health risks of reducing your immune system doesn’t sound like it’s an actual improvement - at least IMHO.


I haven't had any issues with lock-ups.

The LEDs and screens can be adjusted (or turned off) on a schedule with the latest firmware.


I'm personally wait for the JetBrains equivalent to cursor: https://www.jetbrains.com/junie/


JSON5 is a more reasonable format for config files, in my opinion.


I prefer YAML on my Markdown front matter. It's more readable because of no brackets, quotes, or commas.


Seconding the sibling, YAML may look nice but it's absolutely full of awful confusing behavior. If you don't like JSON for human-written stuff, see TOML or the like. I think JSON is great for serialization, it's so simple, but I agree we need something more readable like TOML for human-written data.

https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...


Do you convert your Markdown front matter to TOML? Also for your clients?


> I prefer YAML on my Markdown front matter. It's more readable because of no brackets, quotes, or commas.

YAML is full of pitfalls. I think the brackets/braces and quotes are worth giving up a small amount readability to eliminate the ambiguity.


I'm not sure whether or not there's an issue of entitlement, but there's certainly incentives to develop a popular package (even if superficially). One big one is career development. For people early in their career, it's something they can proactively invest in, as where they can't magically materialize years of experience overnight.


I use prettier for this reason. There’s very few config options on purpose. If I use eslint it’s for additional issue detection, not formatting.


+1 for prettier, I plop the same minimal config in every project and off I go.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: