Before diving in to all this, I’m just going to say, I still find a LOT of value in Meteor - as is. It’s got a ton of stuff that the other platforms don’t have, or are hard to set up and require a lot of maintenance.
Meteor has so much going for it, it’s just sort of obfuscated. Even during that period when it had the outward appearance of being abandoned (which the new Tiny team has been dutifully correcting), it made huge progress. Look at all the features that shipped during that time: perfect code splitting, modern bundles, constantly updated node.js, cordova, babel, the addition of typescript, and tons of other stuff I’m forgetting.
If I had my way, I’d focus on a central reorg of the way the app’s internals are organized, and maybe work on some splashy marquee features:
- Separate the build system in to it’s own project similar to the way React Native does it with Metro (and maybe some other parts too). (It’s entirely possible this doesn’t make any actual sense, given the tight integration between build system and server. But it’d be nice to be able to use Meteor almost like a CRA alternative for non-Meteor backend projects more easily.)
- Part of this could involve a more formal interface between the various parts - which could lead to opportunities to make things more pluggable - imagine if the node.js tier was as pluggable as the front end.
- Deliver a first-class service worker (hopefully, one built with the extracted build system! That’s not strictly necessary, a statically generated service worker is possible).
- (Begrudgingly) Provide HMR (hot module replacement) or at least some sort of support for the upcoming react fast-refresh. HMR is a splashy feature that people think they want (and maybe is necessary for tighter integration with platforms like React Native) - but is also problematic in a lot of ways. I end up disabling that half the time on projects that can support it. But people want it, and it sets a minimum bar in that way, from a product perspective.
- Alternatively, or in addition to - continue to make improvements on rapid client refreshes when working on local dev. Maybe for example, there is a way to disable server builds for files linked by SSR during development, without having to comment out the entire SSR system (this is pretty easy if your SSR code is in a standalone file, but it can cause workflow side effects, like constantly being in your way when committing to git, etc.). We now have
--exclude-archs
to avoid recompiling legacy bundles, or cordova bundles, etc, but it’d be nice if we could target specific aspects of a build, rather than the entire arch in some cases (like SSR).
- Alternatively, or in addition to - continue to make improvements on rapid client refreshes when working on local dev. Maybe for example, there is a way to disable server builds for files linked by SSR during development, without having to comment out the entire SSR system (this is pretty easy if your SSR code is in a standalone file, but it can cause workflow side effects, like constantly being in your way when committing to git, etc.). We now have
Other nice to haves, but not essential features:
- Better command line output. I’m thinking webpack dashboard type stuff
- Maybe some tools for generating PWA assets, similar to how Cordova works
- Better integration options for NativeScript based platforms and React Native (we’re getting there - at least there’s a guide now!). My main goal with the idea of breaking out the build system is to make it more generally useful, but also to make it clearer how we might add extensibility for these types of additional build targets.
- Tighter, more performance focused integration for Cursors with React, as I’ve mentioned elsewhere (some of us are already working on this, maybe we’ll get somewhere some day).
- I once thought that GraphGL/Apollo should be more tightly integrated, but I kind of like Meteor’s system. We could maybe use some higher level abstractions on Meteor’s pub/sub, with data over methods. I’ve got a pretty good base for that that I build for PixStori - I just need to work out the live subscription strategy (I’m actually doing that now for a hobby chat project, might even open source that). The idea is to make it all more compatible with SSR out of the box, providing pagination by default, and make it more scalable than going through pub/sub for everything.
- There was once thought of moving everything to
npm
. I still like the idea, even if we would have to extendpackage.json
, and/or ship source code, as other projects like svelte are doing. (Or we could jump to deno and support git hosted projects instead -npm
can load from git end points)
There are also things I’d like to see - more open ways to debug problems like memory leaks which only occur in production builds on Galaxy, and things like that. There are some things in the build pipeline that might need adjusting sooner rather than later. I’m adding more and more npm packages to the recompile list of late, for example. I’m not sure there’s a better way to deal with this than what I have set up (which would make a good Medium article - I’ll get on that, it’s kind of important for some things), but it’s becoming an issue.