100%. @vooteles has the right idea here. Double down on what is unique to Meteor and be UI framework agnostic. The nice thing about the UI frameworks is that they are more or less converging on using signals under the hood so it will mostly come down to what syntax you vibe with.
There’s one key theme missing in this thread though — innovation. To keep its reactivity promise, Meteor must address scaling pub / sub, which I think they are working on. Beyond that, there’s an opportunity to provide essential pieces to help people build great software. I outlined several of them here:
I’m sure others have great ideas regarding how Meteor can continue to innovate. Now that Meteor 3.0 is out, there’s a big opportunity.
Happy to hear this will be a focus. Finding a way to use and scale pub / sub that doesn’t rely on tailing the oplog should be Meteor’s top priority. Relying on an undocumented MongoDB API sounds like a recipe for disaster.
I hope this doesn’t mean spending a bunch of time converting the core framework to a bunch of .ts files. I think the current approach of using JS doc for typescript support is the correct one. Over the past few years other frameworks, like Deno and Svelte, have discovered this. The creator of Svelte does a nice job of explaining why here:
Ultimately, I think there are two outcomes for typescript:
- It’s so useful that JS basically becomes typescript. I have my doubts but I could see something like this type annotations proposal eventually making it into JS.
- It fades out over time (several years from now) and people use JS and types as comments for the intellisense benefits or they really love true static typing for which I imagine there will be better solutions (possibly gleam once it matures).