Bun 1.0 is out. It claims that:
Bun is a drop-in replacement for Node.js
But could we just drop it into Meteor somehow and get some benefits?
1 Like
I was playing around today, and at the moment, we can use it to install dependencies and as a test runner - similar to Jest. Similar to this Next.js guide.
We have a block to use Bun on Meteor’s internal due to Reify and Nested Imports.
We could use it as a bundler too, since it has the same API as Esbuild, which would be very beneficial to the Meteor’s ecosystem.
This is not an official statement from the Meteor team, I’m just throwing some ideas here
10 Likes
Already discussing it here:
But if @hschmaiske says it is pretty easy then that is good news.
4 Likes
Not sure if the above is indeed pretty easy, but good if that is the case. I, for one, still don’t grasp how both works its magic in meteor
Not easy, for sure! I think it would be similar to fibers migration. I wish it could be that easy.
1 Like
I think to do it right would be somewhat of a large undertaking, but on the plus side, could give people an even stronger reason for adopting Meteor. Imagine a completely modernized Meteor with Bun under the hood for best in class performance.
For example, you’d likely want to use Bun websockets instead of ws, sockjs, etc. Meteor packages would probably need to be ported to npm.
IMO, it’d be ideal for a skunkworks type team to do this in parallel of ongoing Meteor improvements beyond 3.0 so core contributors stay focused on the top features mentioned by community members in Seeking Community Input: Meteor.js Roadmap
It’d be a great opportunity to strip out legacy code and fix the issues highlighted here:
Reify was ahead of its time and nested imports are useful but it feels like maybe it’s time to move on. Am I correct in thinking that the only benefit of Reify at this point is nested imports? Could dynamic import() be used instead where needed? I understand they aren’t exactly the same but maybe it gets you to the same spot with the tradeoff of execution time. Please correct me if I’m wrong 
. It looks like you can use import and require in the same file with Bun so I think that enables nesting with require when needed.
7 Likes
Totally, dynamic import('raw string here') is (already) statically analyzed, and effectively works the same as nested imports today in Meteor. Migration would be simply a matter of converting to import() and not using dynamic strings (f.e. not import(dynamicVariable), because that is not statically analyzable, and Meteor won’t know what files to include in the browser)
Whether we are on top of Node.js or Bun, I think it would still make sense to strip away the customer ES Module handling, and let it be native on both side (Node or Bun handle them on the server side, browser handles it on the client side). In this scenario, native import() calls can be static or not, doesn’t matter.
We’d use importmap scripts to define where packages come from.
In a project I recently started with Meteor, I put all my client side code in the public/. Here’s what the HTML index looks like including the importmap:
That main.html is still handled by Meteor’s build system. You can see there that main.html imports main.js natively, not handled by Meteor’s build. Here is main.js:
At that point, and with a little dancing to expose Meteor libs as globals to get them onto the vanilla ES Module side (see client/main.js), everything is just vanilla web code on the client.
This is really great because I have zero worries about libs not being importable in Meteor’s build system. If there is some lib that is not an ES Module but instead exposes a global variable, it is really easy to wrap that up into an ES Module and link it in the importmap, where the file exports the global var. From then on, TypeScript knows how to find the type definitions of libraries from node_modules, so the IDE experience in the client code works fine.
The really nice thing about this that the client code will essentially work forever, in any browser. Ripping it out and putting it in any other stack will be easy, without having to fiddle with any build configs.
After having some sort of setup like this, it would then be possible to optimize: read (maybe even generate) the importmap, understand the dependency graph on this standard, then produce an alternative html output file with everything bundled.
(jspm is an example tool that knows how to generate importmaps from node_modules)
To add support for non-standard languages (TypeScript, CoffeeScript, Sass, etc), an additional step plugged into the optimizing step (similar to Parcel) would be needed to transform the code along the way, and whoever uses these non-standard languages would simply not run without the build step.
I highly recommend against this. This is going to make code incompatible with Node.js and other ESM environments. And it will fight against the push of the JavaScript community to migrate to the ES Modules standard, and by mixing CommonJS like this, we’re gonna end in a Frankenstein world of JavaScript code. CommonJS needs to go away.
7 Likes
If the requirement for Bun is that we need to port all the packages to NPM then that is indeed a very long undertaking, but I think we can do without it. Though Meteor packages will all have to be what today is ecmascript version and export values. I think modernizing all packages like that is a good middle-step before fully moving into NPM, but analysis will have to happen to make sure that it isn’t more work than it is worth.
Having to abandon reify, if that is needed then I think that is worth the price.
So first we need a more thorough analysis in these regards and I think we should go for an incremental approach as much as possible.
9 Likes
I don’t think it would take much work to use bun to run the app. Meteor bundles the server files, which requires using your own module system (or the other option some bundlers use is to rewrite and merge the modules into a single module). Meteor then uses node:vm to load the bundle for each package and app. That should work with bun without major changes (assuming it supports enough of the node:vm module).
The challenging part is loading npm packages so live bindings with ecmascript modules work correctly. We would probably need to rewrite https://github.com/meteor/meteor/blob/release-3.0/tools/static-assets/server/runtime.js to be a bun plugin. Reify’s runtime was designed to work with most commonjs environments, but it might still need some adjustments to work in bun.
Stop bundling on the server and using native modules can be done independently of switching to bun. Though it would be easier after switching to bun since it is closer in design to Meteor’s module system compared to Node.
We can support nested imports with bun. We would have to still compile them, but it would only need a simple compiler and runtime (it would change the import to a require, and then update the places the imports are used to call a function to get the imported value).
From a quick glance at bun’s docs, another thing that stood out is it handles require for async modules differently than Meteor 3. Meteor 3 returns a promise, but bun throws an error. I think Meteor should change to match Bun’s behavior - it would remove the need for some of the warnings in Meteor’s TLA docs and reduce breaking changes if we ever decide to switch to bun and use its module system.
If we decide to switch to bun and stop bundling on the server, I think we would still want to make the current module system work on bun. That would allow packages and apps to individually opt in to using bun’s module system and migrate over time.
12 Likes
Probably worth looking into after 3.0, move Meteor to the bleeding edge and the claimed performance improvements are impressive.
7 Likes
Probably worth looking into after 3.0, move Meteor to the bleeding edge and the claimed performance improvements are impressive.
Absolutely agree! 
It’d be amazing for Meteor to start supporting Bun shortly after the release of 3.0 where Meteor finally sheds years of baggage and starts working with the greater Node.js ecosystem seamlessly.
Better get going though 
5 Likes
Meteor on Bun LFG!
I’d love to have a new Meteor version where we can drop all the transpiling, bundling, fibers, conditional imports, etc and use as much native Bun functionality as possible. I would migrate all my projects immediately.
Remember Meteor made the controversial move of moving away from Blaze as it’s focus to rather supporting React and Angular etc? Though a small loud minority rage-quit Meteor because of it; it was absolutely the correct move. React is SOOOOO much better than Blaze it’s a joke.
I’ve been building projects in Meteor since 2012 and Blaze. Since Matt had all black hair and was doing demos exciting the JS world. Before Telescope, before Galaxy, Discover Meteor and all that stuff, long before I had any grey hairs.
We can’t stay 400lbs obese and outdated forever, it’s time to cut the fat and start a new chapter.
These days I hardly use that much of Meteor’s system anymore anyway, basically just subscriptions, methods, imports/bundling etc, custom login mechanism. Nothing that is irreplaceable.
I don’t even use Meteor Mongo stuff on the server-side. I use the official MongoDB Node.JS driver. I made the switch because Meteor Mongo was antiquated and lacked modern features etc. For publish I’ve needed to keep Meteor Mongo capable with some cable-ties and duct-tape known as tunguska-reactive-aggregate.
So I’m very aware of how old Meteor is in absolute age, and also how outdated much of it is.
If Meteor doesn’t adopt Bun, realistically sooner or later even though I love Meteor, I’d likely look to alternatives to achieve the performance and bundle sizes etc I’m looking for.
Meteor is already so unattractive for a lot of devs wanting to start a new project. The upside is less than the downside if I’m being objective, without a doubt.
Sorry to be the bearer of bad news, and I hate to pee on the tech that I use, but I’m saying these things because I think a reality check is in order, for hopes that Meteor can turn the race around. When I tell other devs that we use Meteor they turn their noses up, and not for superficial reasons.
Never forget that JavaScript is a fast-moving ecosystem. The last time that Meteor was truly impressive relative to other options was around 10 years ago. Now it’s nowhere near the lead. Meteor is barely qualifying in the race these days. It’s not enough that Meteor was disruptive and amazing nearly a decade ago. The industry doesn’t stand still. Meteor simply cannot stand still on it’s pile of legacy code and expect to even have a place in the race in future. The other contenders aren’t waiting for Meteor. It’s go go go. Either we move or we will continue to be left in the dust.
I think maybe a change of thinking is in order.
Instead of thinking “It’s going to be so much work to make all the legacy Meteor projects work in Bun”
I’d be very happy with a minimal new alternative Meteor release, built right, with no excess compiling steps integrated, native bun everything where possible. And a minimal feature-set. Even an alpha release with a tiny feature-set compared to current Meteor. Bring it on.
Just like Blaze was “soft dropped”. (half-heartedly semi-maintained) the same thing should be done with the current (let’s call it legacy Meteor).
How about a soft drop of legacy Meteor, where you don’t even say anything to suggest a soft-drop so that the old-timers don’t rage quit. Instead just release a new alternative version with all the modern goodness. And I’ll be the first one to adopt that.
Then the old-timers will choose the new version after they see it gaining traction and see how good it is, and they’ll come support it, instead of needing to convince them to move. It’s the efficient thing to do. Avoid all the politics etc. LFG!
As always I want to express immense gratitude to the Meteor team, to Tiny and all the people who have contributed to Meteor. I understand, appreciate and respect how much work has gone into building and maintaining Meteor. Having said that, a lot has changed. The landscape is completely different. When Meteor first entered the scene in 2012 a lot of web-devs were still supporting IE6. These days it is the standard that browsers stay up-to-date it’s a requirement for security in modern times. These days I don’t give a rats ass about supporting older browsers, anything older than TLS1.3, babel and all that stuff. JavaScript doesn’t suck anymore. We can build NEW things using the core technologies that are widely available without so many hacks layered on top. The situation is completely different. A fresh approach is in order.
7 Likes
In addition to being leaner and better DX, the web socket performance looks amazing relative to Node, which is highly relevant for Meteor apps.
8 Likes
Transition to Bun is an interesting option with potentially a major increase in performance and reduction in overall complexity (though the specifics would need to be assessed thoroughly before committing to anything). It seems to me that if this is seriously being considered, then this task would be a good candidate for crowdfunding. Assuming that @zodern expresses willingness to take on the job, is able to put together a rough plan of work that needs to be done and has the time budget necessary for it. I’d be willing to sponsor $300 to $500 on my own, should this idea lead to somewhere. Would there be others in sufficient numbers? And would zodern have interest in it? Does the Meteor team have any thoughts here?
I’d be hesitant to take away any focus from the 3.0 work currently ongoing, as this is both critically important and time sensitive. However I’m not really sure how engaged zodern is with that work right now.
7 Likes
As you mentioned 3.0 is priority, but I’m willing to sponser similar amount as well. I tried BunJS on a large node project and there are some edge cases still.
For example it is failing resolve conditional require statements require(x || y), it also fails to resolve packages using git commit ids, and I found one other minor edge case which I don’t recall well but a dependency didn’t get installed correctly, I’ve reported those, but the majority works and it is super fast.
We also need to assess the risk with going with a new tool that is heavily VC funded, those who been in the Meteor community long enough understand this kind of risk very well.
With that said, it seems to be BunJS is good fit with Meteor, ultimate anti-bloat, there has been talk about Meteor Lite, this could be it.
6 Likes
An alternative to porting all of Meteor internals might be to develop Meteor SDK with API that works on BunJS (ddp support, auth, methods, publications etc.).
3 Likes
Yes. Forgot to mention that in my post. Targeting the new shiny tool has its risks. I think transitioning to Bun only makes sense if the required work and technical commitment is small enough that it is not only possible to move to Bun with reasonably small effort, but also moving back to node would remain a realistic option as well should the need arise for it. Ideally if Meteor keeps close to vanilla js, then node, bun and deno would all remain viable options.
6 Likes
Ideally if Meteor keeps close to vanilla js, then node, bun and deno would all remain viable options.
Which is the ultimate goal really, Meteor working with Bun would be a side effect of achieving this goal.
Bun is indeed impressive, but at least the statement about the drop-in replacement seems a little bit too early, according to a maintainer of Node.js: My thoughts on Bun and other Adventures
So, I’d wait a little bit before doing such a big change.
5 Likes
Absolutely agree. It is even less of a replacement for the Node running in Meteor.
I have already started working on that replacement, but I doubt that I will be successful without @zodern or other devs who have already developed in the core. For me it is a test of how far can I get and also to learn more about Meteor internals.
A good thing that at the very least is going to come out of this is that Node will try to improve performance. Which in the short term at the very least is a win for us as well.
8 Likes