5 ms·

How does this allow me to replace e.g. Vite? Is there a way to do hot module reloading, css pre-processing, or load framework specific plugins (like the Vue SFC

How does this allow me to replace e.g. Vite? Is there a way to do hot module reloading, css pre-processing, or load framework specific plugins (like the Vue SFC compiler)? Serving a static file isn't exactly new, so I feel like I must be missing something.

nsonha 2y ago
> framework specific plugins (like the Vue SFC compiler)? They have a plugin api, but honestly I don't like the sound of "framework-specific plugins". It is because of this, all front-end frameworks are now a mini compiler (inside a bundler/compiler) and being too comfortable now to come up with new wacky syntaxes. I prefer frameworks to just be frameworks and being able to write normal typescript.
- sampullman 2y ago
  If that's what you prefer, there are plenty of options. I'm happy writing Typescript with no framework (or even plain es6), as long as there isn't UI complexity. But for a large project, I'll happily trade a compilation step for the tools modern frameworks provide for managing complexity.
mythz 2y ago
From its documentation [1] it looks a lot like a parceljs replacement [2], i.e. a zero config bundler which processes and bundles the dependencies in .html pages. So great for simple websites, not for replacing an entire Vite stack. [1] https://bun.sh/docs/bundler/fullstack https://bun.sh/docs/bundler/fullstack [2] https://parceljs.org https://parceljs.org
- sampullman 2y ago
  Thanks for the links! I should have researched a little more before replying. It actually mentions HMR at the bottom of the docs, and I see plugins are already available. So while it can't currently replace my Vite stack for most projects, it seems like it eventually could. I'm not sure how I feel about this sort of coupling in general, but for small projects it could be very convenient (as you mention).
Imustaskforhelp 2y ago
bun has its own bundler as well. So I suppose bun already replaces vite & I also think it does css pre processing but just not framework specific I liked this approach because I actually wanted to create very simple / static serving in bun and I had to actually do a lot of hoops like reading it from Bun.file() and then some things more Its just nice that its now solidified into the standard library / behaviour I suppose

nsonha 2y ago

> framework specific plugins (like the Vue SFC compiler)? They have a plugin api, but honestly I don't like the sound of "framework-specific plugins". It is because of this, all front-end frameworks are now a mini compiler (inside a bundler/compiler) and being too comfortable now to come up with new wacky syntaxes. I prefer frameworks to just be frameworks and being able to write normal typescript.

sampullman 2y ago
If that's what you prefer, there are plenty of options. I'm happy writing Typescript with no framework (or even plain es6), as long as there isn't UI complexity. But for a large project, I'll happily trade a compilation step for the tools modern frameworks provide for managing complexity.

mythz 2y ago

From its documentation [1] it looks a lot like a parceljs replacement [2], i.e. a zero config bundler which processes and bundles the dependencies in .html pages. So great for simple websites, not for replacing an entire Vite stack. [1] https://bun.sh/docs/bundler/fullstack https://bun.sh/docs/bundler/fullstack [2] https://parceljs.org https://parceljs.org

sampullman 2y ago
Thanks for the links! I should have researched a little more before replying. It actually mentions HMR at the bottom of the docs, and I see plugins are already available. So while it can't currently replace my Vite stack for most projects, it seems like it eventually could. I'm not sure how I feel about this sort of coupling in general, but for small projects it could be very convenient (as you mention).

Imustaskforhelp 2y ago

bun has its own bundler as well. So I suppose bun already replaces vite & I also think it does css pre processing but just not framework specific I liked this approach because I actually wanted to create very simple / static serving in bun and I had to actually do a lot of hoops like reading it from Bun.file() and then some things more Its just nice that its now solidified into the standard library / behaviour I suppose