I started with Meteor 1.0 and still use meteor. Why? Because i don’t have to think about anything but coding the javascript and following the rules i use in Blaze. Simple.
The key for me with meteor is that it is simple to build a full front and back end reactive app if you are a half-decent javascript programmer - and quickly.
Quickly and simply is the key. And this is the key for any smaller app.
I still use blaze, i still use ‘classic linking’, i still use iron router, and it still works.
When building apps quickly and simply - meteor is still the boss for me. All 12 apps I have written are now running on v2.7.3 and work for my purposes.
I have not moved to 2.8, because fibers also work great for me.
you can update to 2.10 fiber still lives there 
On this topic I want you to refer to this article:
Many issues like this have a long history in Meteor (and you can find many existing discussion on these forums about them) and changing them will require a significant effort. So unless you start on it yourself or support people working on these and other issues you will have to wait till items with more priority get solved so that the devs can move onto this.
Lurker of 4ish years here with a first post. I’m also in favour of this idea (decoupled NPM packages in a Monorepo). But I have broader reasons than mentioned in the OP, and I am not so opinionated on the technical side about symlinks etc.
I’ve been watching what’s happening in the NPM ecosystem and seeing a lot of positive progress, as long as you’re prepared to bring the glue and figure out what to research. For example:
-
NextAuth.JS has recently become Auth.JS, and it’s quite cool to see what was once an opinionated authentication system just for NextAuth become what might very well end up being the new “Passport JS” for fullstack. They have SvelteKit and SolidStart adapters in progress, and reading their documentation I reckon it might be possible to even make a Meteor auth compatibility layer. You’d need to define a database/persistence adaptor and a way to integrate the request handler with Meteor’s connect middleware.
-
Prisma seems to keep growing and now supports MongoDB, which seems like a nice complement to TypeScript and application-driven database development, and thus aligned to the way Meteor was tethered with MongoDB in a way.
-
SWR and React Query make “soft-realtime” applications much easier (using the old fashioned poll-and-cache approach). Vue also has SWRV. These approaches are likely less efficient than websockets and DDP, but they get the job done fairly reliably (though I’ve only ever used SWR).
-
Import Maps and aliases have also matured a lot too, so JavaScript project organisation has a whole new frontier to explore too, e.g. swapping modules out based on environment (client, server, testing, etc). Look at some Deno projects like Fresh to see how that is being done nascently.
-
There’s also things like Mock Service Worker (MSW) which can also change testing practices dramatically. I’ve yet to use this one but I’m excited to give it a try if I have a good use for it sometime…
(NB: the next few things I want to say with great respect to the Meteor developers and community whose work and resources have helped me get ahead in my role without sweating the small stuff early on)
Considering the above, it seems like Meteor was already having a go at many of these issues early on, but because of its more recent “isolation” in the ecosystem, a lot of developers don’t engage with the ecosystem at all even if they like one aspect (who’s going to use Meteor accounts in their NextJS app?), and because of coupling, the community has to live with the design decisions and planning made when the JS ecosystem was much less mature, even if that goes against the general idea of Meteor being a “go and get stuff done” all-in-one framework.
Of course, you can start from Meteor and add all the “new” stuff in (I think everything above except import maps should work), but sometimes that isn’t practical, and that’s also not necessarily the point. The point is that Meteor has had a lot to offer as a collaborative member of the JS ecosystem, rather than an island. And its current status as an “island” wasn’t necessarily an intentional design decision, but more a product of fate.
But of course there’s the twist to that - you can’t just split Meteor up trivially without breaking a lot of existing applications. Meteor’s existing stability is a new-ish reason why a lot of people like Meteor now - as an “island” it has been spared a lot of the churn outside in the Node JS ecosystem. But already we are starting to see that some churn can’t be escaped (e.g. managing fourseven:scss related dependency issues across several apps and branches has given me a lot of grey hair, and we all know about fibres…). So there’s going to be critical migrations for some applications soon anyway.
So maybe it’s time to think about the second rough decade of Meteor stability.
2 Likes
Interesting. I took a quick look. I find their disdain for passwords puzzling. Still an interesting project to consider integration in the future.
1 Like
You might not, but I and many people do and the accounts-password package is super important, so switching to something that doesn’t support it is going to either require a lot of extra work or break a lot of apps.
But this is off topic.
1 Like
And that’s the beauty of choice. You can mix and match whatever fits your needs (which I believe is the gist of this topic). What doesn’t make sense to someone isn’t true for everyone.
I find their disdain for passwords puzzling.
Yes, it’s a bit of a sore spot! They do provide a guide (somewhere in their currently-being-rearranged documentation) under the title “Credentials Provider” that shows how you can set up username and password authentication, but the experience is not as streamlined and instantly usable as Meteor’s – I don’t think they even mention the sign up process and the important security processes required to do that responsibly.
But, once you need to go a bit deeper they provide a nice framework for it (e.g. customising database access etc), and I think their main strength lies in supporting OAuth best practices.
On a related note, I notice Serverless Stack’s Auth constructs also avoid email and password, but that’s in order for them to have streamlined “serverless” (AWS version of that at least) auth system, so email authentication was easier for them to start with.