Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
-
require1k
A minimal, and yet practically useful, CommonJS/Node.js `require` module loader for the browser in under 1000 bytes
https://github.com/oven-sh/bun/discussions/712
But one of the advantages of integrating both things in bun is that it makes it the perfect standard tool to be used inside of a team. So no extra installations from other projects, no extra mental burden of what to use, etc... bun would be the perfect dev companion with both ;)
Probably a linter is a different beast (and not sure you or the rest of people working in bun want to get in there... probably not important right now), but a formatter seems doable and it does add a lot of value from my point of view. Given that bun already runs, installs, tests and bundles, to the very least _formatting_ seems like a natural addition to the family. To me a formatter is part of the standard toolset for developers nowadays.
Once again, thanks a lot for the effort to you and the rest of the people contributing to the project!
Also. As I am excited. Here you go for a one-click deploy .. https://github.com/OriPekelman/express-bun/ Very unofficial. Very.
Another datapoint - wisp, my favorite LISP-to-JS transpiler, also apparently works fine: https://github.com/wisp-lang/wisp/issues/174
This makes for a pretty awesome combination considering bun's system calls and sqlite support.
I am annoyed with the bombastic claims behind bun.
I wasted a day trying to get vite to work when they first announced it. Really excited about not needing >1gb of ram to compile a react project... Boggles my mind that react bundling uses more RAM than compiling linux.
It is still unable compile http://chatcraft.org due to some problem with wasm plugin.
They also said that bunx --bun option was a pre-1.0 workaround, and didn't keep that promise.
Performance-wise their claims are suspect, safari js engine was always better at startup and memory use at the expense of a relatively weak JIT. They paired that up with a ton of stuff reimplemented in native code to make their cli and hello world workflows fast. This means people will be in for a perf surprise when they start bottlenecking in JS hotpaths.
I'm not aware of any issues as long as you are on the latest Nuxt and nuxi versions, so it might be easier to help if you open an issue with a reproduction on https://github.com/nuxt/nuxt/issues.
Plus the additional complexities introduced by import bindings being live etc. are just annoyances that one has to deal with over and over again every time module interop is involved.
[1] https://github.com/Stuk/require1k