Now that Hono supports web sockets it is coming closer to replace Express in the future for us (talking a long term future of Meteor here).
Another interesting takeaway is that the have targeted their build to ES2022 and reduced their size. I think that is something that could be looked at with Meteor 3.1 as well.
Quick! Switch to Hono before Meteor 3.0 gets its stable release 
I’ve looked at bits and pieces of the Meteor source code before but I’m not knowledgeable enough to know if the following suggestion is too far out there, but: would it be feasible to make Meteor compatible with both Express and then Hono, in such a way that a gradual transition could be made (rather than another big breaking change e.g. Meteor “4.0”)?
On a tangent, something I found out about Hono recently, is that it seems intentionally designed to help you adapt WinterCG compatible frameworks to whatever targets Hono supports. For example, you could (though I haven’t tried yet) make a Elysia JS app and then mount it to Hono, then use Hono in whatever environment it supports, e.g. Node JS, AWS Lambda, Bun, etc.
See the tweet (post? what do we call these things now??) from Hono’s X account for reference:
https://x.com/honojs/status/1659569347168468995?s=20
(the actual thread starts here, but the tweet above kind of captures their intent specifically)
That said, the Hono project is quite ambitious. They’ve introduced something called Hono X (not to be confused with the pre-existing Elon Musk purchase) which seems to be something like Hono Next/Nuxt, but using the Hono JSX renderer and islands architecture? Nitro (the server engine used by Nuxt, part of the unjs project) is also doing something similar, e.g. file based routing etc, just missing the UI part. There’s also Astro moving into server-side, Fresh on Deno, etc. It’s becoming a crowded space.
Alas Hono’s my favourite “post-express” mini-server-framework so far. Though I need to play around more with Elysia JS and see how I feel about that too.
Anyway, the ecosystem Meteor 3.0 is being released into is quite different to the one Meteor 2.0 was released in… No more SPAs, a lot of different attempts at Hybrid SSR, Vite galore, and multiple viable JS runtimes to target that aren’t just Node forks.
Given this PR, I think is fairly possible to make it compatible with Meteor/ have a way to provide your HTTP engine so that Meteor works on top of it.
The JavaScript ecosystem is booming!
I think adding Hono into Meteor 3 is way beyond what that release should do. Maybe Meteor 4 or 5 if there is an alignment and interest. Who knows, maybe Express will deliver some interesting things in the meantime, but I think that more likely is that after around Meteor 3.2 we will start looking on where we want to move Meteor next and I think then Hono will be considered.
Yes, I think going all in too quickly would be quite disruptive.
Looking at the PR Grubba merged in, I guess a “Bring your own server” approach might be viable… But that’s a lot of areas to introduce some sort of pluggable API (vs just rewriting).
It’s interesting to see how Remix and Hono work together - somehow Hono uses Remix as a form of middleware. IIRC Remix is also slowly evolving into a Vite plugin. Could be a good direction for Meteor long term?