Very interesting, and not so much on the “who got there first” portion @superfail … but what is best today. This caught me on a day where I was reassessing whether to proceed with Meteor.js or let it go since on the whole it is not really an advantage, but more of a stop along the way. Unless it provably is.
As I looked through Skip somewhat it immediately reminded me of @leonardoventurini’s Helene without the devil in your bed involved by ever accepting Meta in your stack:
Except… that too is React focused which kills me because the idea is perfect, and the underlying concepts are honestly rhetorically beautiful… but then it excludes Vue or any other future framework on the client side.
I paused framework-side development to re-balance the front-end and in the process opened a lot of opportunity to simplify and perhaps remove a ton of excess that is totally unnecessary if you have more than client and server by design:
I put this out there because I have been questioning whether to use Meteor.js permanently. In fact, I am working to come to a decision one way or the other. And the “subscribe” portion is the key.
It seems there have been huge improvements on performance, but is it enough? I have been questioning if Meteor.js still has the advantage when it comes to both performance and quality.
But all this crashes into a real wall, which Skip further proves. The Meta factor. As much as I want to review Skip it fits the same situation as React which is to become dependent or encourage Meta to exist. It is already bad enough that Microsoft is behind TypeScript but that is different by a lot. Languages are always warzones but libraries are more like religions or political parties within those, lest we lose the ability to stand on our own two feet, as well as be on no sides but our own… which is the real foundation for mutual respect.
Even looking at Tailwind for example, their component library only publishes React reference implementations. There is a tendency toward Meta maintained libraries.
Or are there ways to do reactive backends that really beautifully blend with Vue as well?
That is the only real selling point Meteor.js has to me, since there is so much special sauce going on that it is extremely difficult to do anything really innovative which does not first involve working around the framework. I am not in the position of having code to migrate or maintain that is written in an older version of Meteor.js except for prototypes proving the design will work with Meteor.js ( with great hassles and no real need to stick with Meteor.js itself ) … I love the enthusiasm and spark but I am not seeing a truly dominant position.
But, my design requirements are extremely high, and principles keep me up at night. I do not expect that to be common unfortunately. I am in the process of deciding whether I am going to continue to invest in Meteor.js code. This library being posted, as well as the crushing feeling of seeing @leonardoventurini depart ( best wishes and hand on heart ) as well as the fact that after >10 years there has been no visible-from-space level excellence in impact for Meteor.js ( second and third and fourth chances are not good bets, but risk insanity as the real decision making formula ) all that has me questioning:
Why
Meteor.jsagain?
Skip seems like exactly the right word 
Skip everything but what is the actual best, including what you might already want to love.
Hoping someone has thought about this rather than just pushing forward on the status quo! All my code is abstracted so that >80% can be ported out without much issue, so I have no allegiance other than quality and performance ( within privacy and sovereignty )
Would love to hear from those who do not have the obligation to maintain code, but want to for good reason.
I am looking at this neighborhood but trying not to go far, just assessing the landscape:
Meteor pub/sub is not the only way to subscribe to things in Meteor.
For things such as “who is online” or chat to many in a room, live interactivity such as drawing board, I draw, I saved to DB but all viewer receive the update via Streamer and not via DB subscription.
Have a look at this meteor-streamer/packages/rocketchat-streamer/README.md at master · RocketChat/meteor-streamer · GitHub
I maintain this for one of my Chat projects and I am planning to use it more for other situations such as in-app notifications.
I’m still on fence of finding time to implement Nest/Jetstream KV based oplog + pubsub
IMO it really is as simple as “Meteor has unpredictable performance profile” and its even more unpredictable today than it ever was. I think Meteor is designed beautifully and JS community starts to recognize merits of what Meteor is by-design.
Meteor only gets complicated by the time you want to deploy it.
I love how the framework is immediately telling me what to do.
Have you ever tried deploy Laravel with Websockets? 
Or Meteor 1.x in Heroku without the horse buildpack