3 ms·

> 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 G

> 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 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.

eyelidlessness 4y ago
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 :)

eyelidlessness 4y ago

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