4 ms·

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

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.

tipiirai 4y ago
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.
- eyelidlessness 4y ago
  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.
  - tipiirai 4y ago
    Narrowing the scope would help
- freeqaz 4y ago
  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-difference-between-node-js-and-io-js https://stackoverflow.com/questions/27309412/what-is-the-dif...
- light24bulbs 4y ago
  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.
nwienert 4y ago
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.
light24bulbs 4y ago
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 :)
- lioeters 4y ago
  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/c3bf97002d6f0b117060dabf2aa281eedd85b7fd/test/macro/hello-fetch-macro.tsx https://github.com/oven-sh/bun/blob/c3bf97002d6f0b117060dabf...
  - light24bulbs 4y ago
    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.

tipiirai 4y ago

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.

eyelidlessness 4y ago
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.
- tipiirai 4y ago
  Narrowing the scope would help
freeqaz 4y ago
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-difference-between-node-js-and-io-js https://stackoverflow.com/questions/27309412/what-is-the-dif...
light24bulbs 4y ago
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.

nwienert 4y ago

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.

light24bulbs 4y ago

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 :)

lioeters 4y ago
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/c3bf97002d6f0b117060dabf2aa281eedd85b7fd/test/macro/hello-fetch-macro.tsx https://github.com/oven-sh/bun/blob/c3bf97002d6f0b117060dabf...
- light24bulbs 4y ago
  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.