3 ms·

How does bun make a difference in the frontend tech stack that you mentioned?

• nsonha 2y ago
  not up to this point, but with this release, bun is now a bundler. That means potentially no webpack, vite and their jungle of dependencies. It's possible to have bun as a sole dependency for your front and back end. Tbh I'll likely add React and co, but it's possible do do vanilla front end with plain web components.
  • cal85 2y ago
    Bun has always been a bundler (and package manager, and Node runtime). This release adds "HTML imports" as a way to use the bundler.
    • matt_kantor 2y ago
      Doesn't the name "bun" come from the fact that it's a bundler?
      • nsonha 2y ago
        No it's just a name. Originally it's an alternative to nodejs.
    • nsonha 2y ago
      not really a bundler without a dev server that you can just set to an entry point, and css support
• DanielHB 2y ago
  Last I tried (several months ago) it didn't, the built-in frontend bundler was not very useful so everybody just used 3rd party bundlers so (for most people) it would not have any meaningful differences compared to nodejs. It seems they are putting more effort in the bundler now, so it seems like it can replace plain SPA applications just fine (no SSR). The bundler is inspired by esbuild so you can expect similar capabilities. IMO the main benefit of using their bundler is that things (imports/ES-modules, typescript, unit tests, etc) just behave the same way across build scripts, frontend code, unit tests, etc. You don't get weird errors like "oh the ?. syntax is not supported in the unit test because I didn't add the right transform to jest configuration. But works fine in the frontend where I am using babel". But if you want to use vercel/nextjs/astro you still are not using their bundler so no better or worse there.