Bun and Meteor?

[jam]

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:

Seeking Community Input: Meteor.js Roadmap

Doesn’t look like anyone mentioned this, so I’ll add on! I think that Meteor’s modules and ecmascript system is fairly out of date now, and quite a source of complexity that keeps Meteor in legacy, especially as time moves on. It was built during a time when a revolutionary set of language features were introduced but before engines supported the new features. It was necessary in that time. Today, the language churn has slowed down compared to the ES2015 transformation of JavaScript. The major…

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.