5 ms·

Bun: A Complete Overhaul of the JavaScript Ecosystem

69 points by freeqaz 4y ago

freeqaz 4y ago
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 https://news.ycombinator.com/item?id=31993429
- verdverm 4y ago
  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 https://www.youtube.com/watch?v=3NR9Spj0DmQ
  - Ramiro 4y ago
    I agree is early, but the same thought around WASM crossed my mind. Interesting approach though
  - freeqaz 4y ago
    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.)
    - verdverm 4y ago
      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
      - fendy3002 4y ago
        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.
        verdverm 4y ago
        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
        verdverm 4y ago
        Turns out bun is not a drop in replacement and has decided to make its equivalent of package.json a binary file... smh
        eyelidlessness 4y ago
        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.
  - amir734jj 4y ago
    Agreed. I started using blazor webassembly and I love it. It enables logic sharing between backend and frontend.
lioeters 4y ago
> 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.
chociej 4y ago
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!
- light24bulbs 4y ago
  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.
  - chociej 4y ago
    I remember feeling like they snuck that feature in without a lot of fanfare. Seems like it was easy to miss!
yrgulation 4y ago
https://dayssincelastjavascriptframework.com/ https://dayssincelastjavascriptframework.com/

69 points by freeqaz 4y ago

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 https://news.ycombinator.com/item?id=31993429

verdverm 4y ago
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 https://www.youtube.com/watch?v=3NR9Spj0DmQ
- Ramiro 4y ago
  I agree is early, but the same thought around WASM crossed my mind. Interesting approach though
- freeqaz 4y ago
  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.)
  - verdverm 4y ago
    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
    - fendy3002 4y ago
      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.
      - verdverm 4y ago
        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
        verdverm 4y ago
        Turns out bun is not a drop in replacement and has decided to make its equivalent of package.json a binary file... smh
      - eyelidlessness 4y ago
        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.
- amir734jj 4y ago
  Agreed. I started using blazor webassembly and I love it. It enables logic sharing between backend and frontend.

lioeters 4y ago

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

chociej 4y ago

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!

light24bulbs 4y ago
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.
- chociej 4y ago
  I remember feeling like they snuck that feature in without a lot of fanfare. Seems like it was easy to miss!

yrgulation 4y ago

https://dayssincelastjavascriptframework.com/ https://dayssincelastjavascriptframework.com/