Bun: A Complete Overhaul of the JavaScript Ecosystem | Hacker News Reader

Bun: A Complete Overhaul of the JavaScript Ecosystem

lunasec.io

69 pointsfreeqaz25 comments

Open articleView on HN

That was a fun read, and I'm really interested to see where Bun goes. That said:

> No more calling util.promisify(fs.writefile) just to get a function you can await

I'm sorry to say you've been missing out on `fs.promises.writeFile()` (or `require('fs/promises')`) for quite a while!

Hey, author here. Thank you so much for pointing this out, youre not the first. I'm updating the post.

I was waiting for a writeFilePromise to show up, should have guessed they'd be name spaced.

I remember feeling like they snuck that feature in without a lot of fanfare. Seems like it was easy to miss!

> I'm not sure if Bun is also a complete rewrite of the TypeScript compiler, but it appears to be.

I thought it used ESBuild for that part.

Looking in Bun's Git repo, I see under Credits:

> While written in Zig instead of Go, bun’s JS transpiler, CSS lexer, and node module resolver source code is based on @evanw’s esbuild project.

https://github.com/oven-sh/bun#credits

Reading it this time, I understand ESBuild was only used as a reference, and Bun's transpiler is indeed a fresh rewrite.

Same as ESBuild, it does no typechecking.

> Bun doesn't actually typecheck the TypeScript code. It only transpiles it to javascript. Typechecking should be handled either by your IDE or other tools like tsc.

I’ve been following Bun’s development earnestly for quite a while—not since the start, but long enough to help clear up some stuff.

A thing that’s not clear in the article, or indeed obvious in Bun’s launch material, is that it was originally (or at least as close to its origin as I can trace in personal memory) scoped as a TypeScript/JS/JSX compiler and generally as a bundler. This is where it got its name, as I recall. In any case, as you say it was a greenfield compiler with ESBuild as a reference.

Jarred can correct me if he’s here and I’m wrong (about this or anything), but I believe the runtime scope grew organically out of:

1. Bun’s nascent macro system (which last I checked is novel and quite clever, using JSX as the abstract macro it is). Macros need a runtime to macro anything, after all.

2. Prioritizing development before production, and ecosystem compatibility (e.g. Next.js is frequently used in example benchmarks), again where a runtime is expected.

Of very few nits I’d pick, I think “based on” should very probably be reworded to reflect the inspiration. It’s easy to misinterpret in a software context. The only nits remaining to pick, I’ve already picked them on Twitter and they’re generally about not introducing API inconsistencies for performance wins (and AFAICT that’s always been persuasive).

If Bun’s future is primarily as a runtime rather than a build tool, it’s probably fine that its roots as a transpiler/bundler is left to curious esoteria. Maybe even for the best, because that category of software has such a poor reputation. Even if the cute name references a hopefully not distant future where so much churn and worry about JS build tooling might become an afterthought.

This explains a lot. I'm personally much more interested about the runtime and replacing my Node with a more performant alternative. Not so interested about the other stuff. Feels like the scope of the project is way too large and I'm slightly worried about the timeline.

The creator says it should be 1.0 in 6 months. I’m much more worried about him getting sleep than any other details at all.

Narrowing the scope would help

This is how io.js got adoption back in the day, iirc. It was then mainlined back into Node.

https://stackoverflow.com/questions/27309412/what-is-the-dif...

I think it's one of those things that if you haven't hit the wall with the JS ecosystem yet, you don't know the wall is there.

One thing I really don’t understand (and probably should ask in the discord) is: why the JSX like syntax for macros? It doesn’t seem to have any advantage over function calls, and in fact is a bit disorienting as you’re not constructing a tree-like structure using it. Felt very fancy-for-fanciness-sake to me, but maybe I’m missing something.

I'd REALLY like to hear more about the macro system. I've been yelling about wanting that to become part of typescript for a long time, but I don't think they quite have the vision.

In Zig, code can run at compile time, and thats amazing. That's one of the main things I want in TypeScript. Once you have that, everything from type reflection to native graphql types without codegen is just a library away.

Yeah, I'd really, really like to hear more about that if you can point me at anything. Overall, all of the decisions Bun is making, in just about every part of the ecosystem it touches, are things that I have been really excited about. I've got a good feeling about this and I'm trying to scrape some time together to help out.

As for esbuild, I don't think you're correcting the article because it said that the parser is a `port` of esbuild, not "based on". You're probably just replying to the other comment :)

Searching Bun's documentation (currently the long README on GitHub) for "macro", I only see a brief usage example as part of the build configuration, like:

  [macros]
  # Remap any import like this:
  #     import {graphql} from 'react-relay';
  # To:
  #     import {graphql} from 'macro:bun-macro-relay';
  react-relay = { "graphql" = "bun-macro-relay" }

..Or as a transpiler option:

  const transpiler = new Bun.Transpiler({
    loader: "tsx",
    define: {
      "process.env.NODE_ENV": JSON.stringify("development"),
      user_undefined: "undefined",
    },
    platform: "bun",
    macro: {
      inline: {
        whatDidIPass: `${import.meta.dir}/inline.macro.js`,
      },
      react: {
        bacon: `${import.meta.dir}/macro-check.js`,
      },
    },
  });

..But not within the transpiled code itself.

Ooh, hold on - there's more in /test/macro. Here's hello-fetch-macro.tsx.

  import { fetchSync } from "macro:./fetchSync.tsx";

  const synchronousFetch = fetchSync(`https://example.com`);

  console.log(synchronousFetch);

Looks like the special import syntax converts the function to run at build time.

https://github.com/oven-sh/bun/blob/c3bf97002d6f0b117060dabf...

I actually found out a bit more about it and added it to the blog post. I found links to the macro examples and so on, added it. It uses jsx/tsx with special tags like <string> and <array>. Honestly, that strikes me as completely genius. I really hope it can emit types before the typescript compilation step, not sure. Tried to read the zig but...it's deep.

My colleague was super excited about Bun and wrote this post based on his gripes with the JavaScript ecosystem + why he's excited for Bun to disrupt the current web tool chain. I figure maybe there are a few Node.js haters on HN (just a hunch) that share that enthusiasm. :P

There was another thread about Bun on HN a few weeks ago when it launched and that's where we first became aware of it: https://news.ycombinator.com/item?id=31993429

nice article, I agree Deno is probably not going to win, especially after watching this pretentious talk [0]. I personally expect WASM based solutions to take market share from JS/TS by enabling any language to be used. Still a bit out in time I suspect, but the interest is definitely there on the user end.

[0] https://www.youtube.com/watch?v=3NR9Spj0DmQ

I agree is early, but the same thought around WASM crossed my mind. Interesting approach though

Is it pretentious because he said he wrote the talk the night before? (It is Ryan Dahl giving the talk and he's pretty famous for writing Node.js originally.)

It's interesting the goals that he outlines at 3:30. They feel like the same goals as what Bun has for the project. I'll paste them below (thank you iOS image OCR)

> My Dream Stack

> - Reduces boilerplate

> - ideally very small apps can be defined in a single file

> - Uses JavaScript, the universal scripting language

> - Async I/0 and optimal HTTP server performance

> - Built-in, uniform dev tools - code formatter, linter, doc generation, etc

None of those describe the goal of what my understanding of Dyno has previously led me to believe: Security around 3rd party dependencies. (They've forked the entire NPM ecosystem to make this possible, and this is the key differentiator between Bun and Dyno in my mind.)

It's pretentious because he sounds like he knows what is better for everyone, while he "fixes" his previous mess up by fracturing the ecosystem and introducing more tooling. Beyond N browser support, we are now going to see a host of tools to support Node <-> Deno translation. So it seems he has added a dimension of complexity while claiming to reduce it.

The part about unix being wrong was notably wrong itself

I don't know why deno is veered off hard from package.json and node ecosystem rather than supporting it and enhancing from it. It makes adapting deno a hassle and hard than transitioning nicely from node.

It's going to be a hard case to make to management, while bun is a drop in replacement, for npm, that does make a small part of JS better

I wonder if Deno as a word is a premonition for what it will do to node, split in the middle and rearranged to look shinny again

Turns out bun is not a drop in replacement and has decided to make its equivalent of package.json a binary file... smh

My understanding (which I’m sympathetic but not married to) is because Deno’s module system, along with those of the web APIs it embraces, provide a sufficient abstraction layer for `npm` (the client, not the business) to be built on. Various approximations of this are good enough that people are using Node and Deno almost interchangeably. The extent to which they don’t work mostly boil down to packages expecting a fully complete Node environment or a fully complete browser environment.

Agreed. I started using blazor webassembly and I love it. It enables logic sharing between backend and frontend.

https://dayssincelastjavascriptframework.com/

Reply on news.ycombinator.com