Bun and Meteor?

performance
21

It is already happening fs: improve error performance of sync methods by anonrig · Pull Request #49593 · nodejs/node · GitHub

5 Likes
22

The most important idea here, which @vooteles confirmed as well, is: get as close to vanilla ES Modules as possible, then switching between Node/Bun/Deno will be easy.

This isn’t about Bun. This is about simplifying Meteor so that switching to any runtime is a simple afterthought.

To get there,

  • reduce to vanilla ESM
  • add .js extensions in all import specifiers
  • avoid package.json exports, as that is not official in the ES Modules spec, but a Node-specific invention.

Keeping reify and compiling bundles is already fighting against this, and making that work specifically for Bun is too. Meteor needs to simplify to the most common base across all, vanilla ESM.

In this simplest form, not even @joshnix’s dear React will work out of the box, only things like custom element libs and html template tags will, but in this vanilla setup, it will be really easy for people to install any packages and add any build steps they want.

(And I highly recommend that Meteor consider moving to a simple buildless custom element setup out of the box, because custom elements are the future, will work forever, and believe me the spec authors are defining how to make them compilable for SSR solutions, etc, and Chrome already supports Declarative Shadow DOM for this purpose (which is soooo much better than React :smiley:, I can go on a rabbit hole to explain why, let’s make a separate thread if needed))

Meteor can define a build step later (or not, because build steps are just an npm/bun install away), after running on vanilla for a while and letting people write code that’ll stand the test of time and determining what’s really best for a long future.

Supporting all the tooling for things like React, Vue, Angular, etc, in Meteor has been a lot of work. Imagine if instead that time was spent on Meteor-made chat/forums in a simple way that would stand the test of time. Imagine if Meteor's own forum was made with Meteor

No one has written an HTTP/3 multiplexing cached gzipped ES Module server yet either. This might be the future of native ES Modules if it will legitimately compete with bundlers but without a build step. Maybe Meteor won’t even need an official build step at that point! Tracking issues for HTTP/3 in JS runtimes:

Ok, that’s enough talking from me!

If I spend more time on this, I’m going to take my fork of Meteor and try stripping it to vanilla ESM, and report back the findings.

I think the logic parts will be relatively easy to convert, and the painful parts will be things like Blaze templates (f.e. user accounts ui), but converting Blaze components to future-forward time-withstanding buildless custom elements will be a real delight.

The future of #webdev is one with frameworks that let you write apps without any build steps, but that give you optional build tools for optimizing just as much as current frameworks do.

6 Likes
23

This includes dropping Meteor globals, force implicit imports of Meteor’s API.

This makes a lot of sense. Not having extensions is a Node.js idiosyncracy.

Yeah, I would say this should be configurable somehow (via external bundler), but certainly not built-in.

3 Likes
24

I don’t think simplifying Meteor to choose everything is a good path. First of all it is anti-thetical to what Meteor always was, which was opinionated framework. It increases maintenance and makes things more complicated. At that point what would be the benefit of going with Meteor rather than with a light framework build on top of Deno or Bun?

Custom elements might be the future, but that has been said since their inception and this is the first time anyone has seriously mentioned them, so I’m afraid that if we focus on them we would just be decreasing Meteor’s appeal further. Adding support for them sure, if someone wants to do that, but I think there are more interesting things to worry about first, like the HTTP/3 & QUICK support and things in this direction.

Why we are looking at Bun so enthusiastically is that it could potentially simplify some aspects of Meteor like the build module and few other things, which would make maintenance cheaper and there is the added possibility of speed.

4 Likes
25

My main grudge is that I am unable at the moment to use the latest version of any of Sindre Sorhus’ npm packages in a Meteor app. For instance, trying to use mem v9 or above leads to package not found while v8 works fine. And clearly ESM support in Meteor is to blame: see for instance Release v9.0.0 · sindresorhus/mem · GitHub. The same struggle for all his other packages, and the switch to “pure” ESM was done 2 years ago! This is why I advocate for following standards: make Meteor understand “pure” ESM and get rid of Atmosphere.

3 Likes
26

Can you show us a light-weight framework that allows starting a full stack app with simple isomorphic code in a single command with reactivity that propagates across the database to all clients?

I haven’t seen one, and if it exists (regardless if it has a build or not) it would be valuable to know about it to compare it with Meteor.

I came to Meteor because I was able to write isomorphic realtime reactive database-backed code for dynamic multiplayer web apps. I didn’t come to Meteor because because of its ability to minify code or to transpile down for older browsers. So I think that, if Meteor were buildless (for sake of example) that it would not be antithetical.

Meteor’s build system is by far not the feature that made Meteor famous.

And Meteor can still be. Providing the opinionated full-stack multiplayer database-reactive app framework is still a very opinionated thing to have, regardless of build handling. I think we can agree we care about that much much more than the build, and the choices we make for the build are part of Meteor’s opinionated system (build, no build, or aywhere in the middle).

I believe this might be in your perspective, perhaps based here in the Meteor community, where some standards are already applied and haven’t changed. I’m just guessing though, as I don’t know in which communities you’ve been in.

In Astro, for example, one can write apps using Lit custom elements, including with server-side rendering, partial hydration, for both SEO and speed (this is still being improved over time). If one copies those custom elements out from an Astro app and into a buildless app, they simply work or at worse require minimal changes. This is really great!

I’ve been keeping up with web spec conversations (anyone can join, feel free to join, for example

etc). And for example, Declarative Shadow DOM (see even the section on server-side rendering) is already implemented in Chrome (behind a flag), which helps make it easier for custom element frameworks to support server-side rendering, among other niceties. Just this past week people from around the world met in Spain to talk person to person with optional video call-in on topics including template interpolation syntax, f.e. <div>value: {{someValue}}</div>.

Yeah, when Custom Elements first came out, they were minimal, not very feature-ful like React/Angular/etc. Things are changing, specs have been advancing. Non-custom-element framework authors are now participating in these spec converstions too. The custom element future is looking way more promising now than when custom elements first came out! Keep an eye out!

Browser devtools support custom elements out of the box: easily inpsect your tre of elements without installing custom devtools, in all browsers! CSS scoping works great, without build tools. CSS Nesting is already out in all browsers. etc.

Custom Element frameworks can already replace all functionalities provided by frameworks like React, albeit in custom-element-framework-specific ways (but this is not any worse than all the non-custom-element frameworks today all having their own incompatible server-side rendering implementations), and specs like Declarative ShadowDOM are going to help make the specifics more common across all the custom element frameworks.

The main idea is that, build or no build, Meteor’s bread and butter is providing a full-stack system that does its realtime job across clients, backed by a DB. The build was simply one way to support new language features, and to optimize.

With that said, if Meteor went buildless, it could then add build options in a new and better way that are more aligned with standards. The shift from ES5 to ES6 with classes and ES Modules was colossal, something like that will not happen again except for the upcoming decorators, which is easy to support with existing build tools. At best, we need a simple Babel/ESBuild hook (or whatever the current language-feature transpiler is) without going too deep. And that can be added on top of a vanilla ES Module setup.

Going to vanilla ESM first (adding build options, f.e. Babel, ESBuild, etc, on top of that later) will make the simplicity the same whether on Node, Bun, or Deno.

Or possibly after making Meteor vanilla ESM, figure out how to make Atmosphere be an ESM-first Meteor-curated package listing.

On this note, the future of ES Module package registries might be built on HTTP/3. We have to keep this in mind!

It could be very likely that an ES Module server (with TypeScript support) can eliminate bundlers, and serve entire module graphs stripped of types (see the TC39 Type Annotation Proposal that is very active right now), stripped of comments, minified, gzipped, and cached for repeat accesses, all in a network format that feels to the browser as single-file bundled download does today.

This needs to be verified, but alas no one has written such a thing yet, as Node, Bun, and Deno all do not have HTTP/3 yet. We really should be aware of this, because it could change the game (I’m hoping it will). We could be aligned as much as possible with these possible standard futures, for maximal longevity.

The less infrastructure we have that doesn’t have to do with Meteor’s full-stack-reactive-realtime-database-multiplayer premise, the more we won’t spend time on stuff unrelated to that in the future, plus we cannot say for certain right now what’s the best build-ful alternative to the current build setup, and going vanilla ESM means we can let anyone in the community create build setups to help inform us what Meteor finally needs (or we adopt community packages).

Let’s keep discussing the future, and plan to get on the same best page. :slight_smile:

7 Likes
27

Meteor’s build system is an echo of the state of the Browser/NodeJS world more than 10 years ago: lack of browser standardization, choose between callback hell or synchronous. Side-stepping these constraints and creating an isomorphic synchronous-looking experience was a revolutionary idea at the time. Today this is not so much the case anymore.

I must say I am quite happy the Fibers are incompatible with newer versions of Node because otherwise I do not know how much time we would have kept on dragging the dead-weight.

2 Likes
28

The fact that Meteor is currently “legacy” increases maintenance and makes things more complicated.

3 Likes
29

3.0 and post fiber will be good opportunity to further align and lean down the build system.

Less code and things the build system has to worry about, less maintainence and more opportunities to innovate.

4 Likes
30

@trusktr thanks for the React jab ;). It was amazing relative to what was happening before it when I started using it in 2015. I haven’t continually compared it new alternatives. I don’t have any false beliefs of it being amazing relative to other options. I’m not attached to it in the slightest, I’d replace it for any practical reasons.

@trusktr I agree with your comments that Meteor’s build system is of small significance for why I choose Meteor.

The Meteor bundle is quite big. I’m not familiar with it’s internals so this last comment may not be accurate, but similar to Meteor’s now irrelevant selling point of fibers… Matt’s original demo’s all sold Meteor with insecure and autopublish packages, glamorizing doing db.update() calls inside the browser, being able to access the whole DB and things like optimistic UI updates etc.

I don’t want/use/care about any of that stuff. And I’d hazard a speculation that the bundle could be made smaller if it only receives subscription data instead of having the ability to db.update() etc.

I’m not insensitive to the needs or wants of other developers. I’m not saying the things that I don’t want should not exist, but I’d like to see Meteor being more modular in a way that doesn’t hold back the core functionality components due to being entangled with features/functionality using legacy stuff.

Does Meteor have a package-survey?
Even without doing the work of for example splitting minimongo .update() functionality into a separate package, the functionality could be disabled unless people install a meta-package called minimongo-update. Just an example to get feedback from users about what they actually want or care about.

5 Likes
31

(Side note: client-side DB is great not just for optimistic UI, but also for offline-first apps)

3 Likes
32

Found an interesting article on dev.to, it also mentions Meteor (not in a good way sadly):

I mostly agree with this comment from Andrea Giammarchi:

Competition, the one you are against, is one of the reason npm became faster … there were better alternatives that helped shaking/focusing the main/original project … and same is the butterfly effect of Bun … it’s about the time some team realizes stuff can happen and such stuff can move pretty fast too … and this is good!

From the testing I have done we could probably move to Bun under the hood of Meteor.

Maybe a good idea for those who urgently need speed to make a fork with Bun and use it (if they can afford the drawbacks).

For the rest of us Bun just isn’t there and won’t be for a while. Maybe we could get the tooling to run on Bun (I already got the dev bundle to build with bun - the speed improvement is noticeable) or do something else with Bun. Lot of options for experimentation here, but at the end of the day I came to the conclusion that it is not time to switch Meteor to it (maybe in a few years if Bun can stand the test of time and cover everything we have with Meteor, including Windows support).

But I think we will see a speed increase with Meteor 3 and once we get to the latest Node
and then we will most likely see speed increases on Node as a reaction to Bun. If anything I think that will be the general effect on the ecosystem from Bun. If not then Bun will keep on improving and eventually will overtake Node, but that is going to take a while, after all Node has about 10 years lead on them.

3 Likes
33

I agree with your conclusion, better focus on stabilizing and aligning with node and leaning/simplifying the maintenance.

Node will get faster/better, and so other piece bun has, open source will catch and out pace, which is what happened with meteor, better just lean the gluing layer and piggyback on the most stable tools JS ecosystem has while maintaining what Meteor did well. That’s why I’m exited to moving to express and removing Fibers.

3 Likes
34

Would this approach address concerns expressed regarding legacy code, e.g.:

35

To move to Bun, quiet a few important legacy pieces will most likely have to go.

2 Likes