I’m really excited about bringing TypeScript to Meteor, but no-one’s mentioned this slide:
-
Meteor’s data system should be database-independent, rather than tightly coupled to Mongo
-
Making everything reactive and real-time by default is great for rapid prototyping, but also a source of scaling problems for Meteor applications
-
If Meteor becomes more agnostic about the sources of your data, we can’t keep calling its client-side query language “Minimongo”
-
As a company, we should get out of the business of shipping monolithic all-or-nothing frameworks
nor the homage to next.js.
IMO, both those slides seem to provide an insight into @benjamn’s thinking of the direction(s) Meteor should develop in. On the one hand remove tight MongoDB coupling and (seemingly) provide better integration with Apollo: by extension a more attractive path into wider adoption of Meteor. On the other, more of the “expected” functionality of a JS/TS development platform - again providing a more attractive developer offering. These would be huge changes.
Ben also mentions Meteor’s commitment to backwards compatibility and its (possibly over-zealous) zero-config approach. Now, I love those aspects of Meteor, together with its rapid prototyping, but I’m doubtful that all the potential changes on the table would be compatible. Perhaps, we’re looking at a future Meteor 2 and the clearest signal of all that Meteor is still the right tool to run with.
