Great article @awatson1978! I fully agree with your thoughts. Would just add something to your next steps: Adopt Vue.js as an alternative view layer to Blaze and at least with parity to React on integration with Meteor. I know most people are into React and Apollo, but I believe that Vue is a much better fit to Meteor principles and could become a very good alternative to Blaze.
5 Likes
As someone who only recently started visiting the forums, I’ve been wondering where are the women contributors.
A valuable article, worth understanding the minutia.
4 Likes
I do have to wonder… if my analysis is enough to cause “FUD” among your clients and stakeholders, what does that say about their trust (or lack thereof) in Meteor?
4 Likes
It could say more about psychology or mere politics rather than Meteor’s true technical merit. Following all this thread/news closely, it could arguably be that the weight of your opinion with Meteor has historically been heavy, so stakeholders technically-inclined enough to know Meteor will naturally greet any lack of perceived confidence on your part with increased skepticism or perhaps even lost trust in Meteor.
3 Likes
An incomparable analysis. I was using Meteor in 2015, even within driving distance to Silicon Valley/San Francisco, and the energy was palpable. Decisions were made. Projects were announced. It was an epic journey and faults were found. What you describe as “the Monolith Problem” was expressed to me by others and in response we saw that Apollo was “incrementally adoptable”. It’s important and helpful to recall the history.
3 Likes
Because of your past prominent work with Meteor, your opinion is viewed by many as carrying more weight than of a lesser-known person. Therefore, it is easier for your publicly posted opinions to reassure or frighten people regardless of any objective truths or falsehoods you have expressed about Meteor and its future.
9 Likes
Oh, trust has never been particularly robust. I simply locate the reason for that mistrust elsewhere than you do.
Any trust that we’ve developed has been due to the QA and continuous integration infrastructure. Being a monolithic framework has been mostly irrelevant, as long as it supports interoperability channels. It’s the same as dealing with the other monolithic frameworks in Python, .Net, and Java/Oracle, and just becomes a staffing issue.
That being said, I’m mostly all for NPM nowadays. Much better adoption from other Node/Javascript developers when they understand that Meteor-the-build-tool is different than Meteor-the-tech-stack. I really, really, really hope we can rebrand the build tool and disambiguate it from the tech stack that’s shipped by default.
7 Likes
Apollo is far from success. But MDG wants to give us that kind of impression because it’s their hope of financial future.
2 Likes
By this do you mean http and websockets?
oh, gosh, that’s funny. We were asking the exact same question when Congress started using that ‘interoperability protocol’ term in MACRA and 21st Century Cures in 2015.
HTTP and websockets stop at layer 4 in the Open Standards Interconnect 7 layer model, whereas the specifications that have been approved as meeting the definition of ‘Interoperability Protocol’ use all 7 layers. So http/s and websockets are part of it, but not all. Data packet shape is also defined, as well as application registration. There’s also a legacy interop protocol called HL7 v2 that uses push messaging over raw TCP with defined application endpoints.
But once those things are in place, they just park the monolithic app next to the other monolithic apps.
It’s like commercial trucks and having a loading dock and parking for semi’s. If you’ve got the infrastructure, and the vehicle behaves properly, having a monolithic something isn’t a problem. But don’t try to roll your mad-max customized art-car up to a loading dock if it’s not meeting ground clearance requirements, etc.
3 Likes
I speak policy 
Are there any packages, e.g. meteor or npm, or somewhere outside of Javascript, which provide complete compliance?
1 Like
Not even close. The standard is sprawling at this point, and basically amounts to a hospital system architecture. If you add up all ~190 packages we’ve published under the clinical-meteor track, we have about 40% of it?
We only used about 20% of the standard when submitting to Apple, but it’s operating on a Pareto rule, and it’s the 20% that accounts for 80% of the data traffic that’s being sent between hospitals right now. Patient admit/discharge/transfer, observations, medications, allergies, etc. Not the esoteric stuff in the long tail like medical imaging, genomics, nutrition tracking, mental health, etc.
That being said, HL7 publishes the raw standard in JSON and XML in the IETF JsonSchema standard (which Mongo has recently adopted also). Which is why I’m advocating that we help Collection2 refactor away from SimpleSchema to JsonSchema, and increase overall usage of JsonSchema throughout the framework.
https://www.hl7.org/fhir/downloads.html
There have also been some attempts to republish these definition files on NPM. This is the closest thing to a library providing ‘complete compliance’, but would need some heavy lifting from Tiny to support.
In an ‘embrace the ecosystem’ philosophy, I’ve been trying to incorporate any emerging FHIR libraries that are published. So all the following are fair game, but need auditing and reconciliation. It’s a grab-bag of different build pipelines and module formats still, which is where the Meteor build tool could help contain the madness.
2 Likes
Understatement of the year. It was just completely neglected
2 Likes
I will be carefully optimistic. On one hand I think it can’t get any worse with Meteor, so having Tiny on board sounds like we’re finally going up again.
Then on the other hand I don’t know what they are going to do with and I’m well aware of the art of Marketing (that’s why you have PR people that make even worse things sound like the new Hallelujah).
So now they have Galaxy, which finances itself and is a good platform that can be developed further to grow and become a cash cow.
Now what to do with Meteor? I’m not sure what Tiny’s intention is and only time will tell.
Our app is build on Meteor and yes, we’re one of those traditional ones with Blaze (no Vue/React), heavy MongoDb operations at the backend and ready to scale up (thanks to Lambda, AWS Fargate, Atlas and lot’s of time spend on thinking it through). But because MDG neglected Meteor so much, we had to go ahead and write our own extension of it to be able to use MongoDb 4.2 with the newest driver and more importantly for us, use Transactions.
That was painful and a lot of work for a small company. So my sentiment is that it would be great to have that for everyone (as Enterprise apps will have a lot of database interactions) but the benefit for us will be small. It’s rather another PITA to again rewrite much of our code
So in summary, we have one foot out of the door for a long time, not because of frameworks looked more promising or better but because Meteor went nowhere in the last years. Just some small cosmetic changes.
Just my two cents,
Andreas
Author of https://yourDNA.family
5 Likes
Reading all these posts I wonder if Tiny imagined the amount of frustrations, missed opportunities, disappointed hopes caused by the decision of the founders to focus on Apollo to the detriment of Meteor.
10 Likes
The react integration isn’t exactly amazing. I replaced the withTracker HOC with my own solution pretty quickly.
Have you looked at this? https://github.com/meteor-vue/vue-meteor
my reaction to @sacha’s article was more focused on the first two of his next steps, talk to the community and get a couple big wins to start things off of the right foot (getting a new feature like HMR added to Meteor and hiring Ben would be the big wins). Those two steps would show everyone that Tiny is going to have an impact on things and encourages community involvement. And that will buy them time to then take the transition more slowly and form a plan.
I think they are off to a good start though and hope for more exciting news in the future.
6 Likes
Does anyone know what will happen to Meteor Developer support, their support program? https://www.meteor.com/solutions
Is it going to stay with MDG, or go to Tiny? And who will be providing the support there?
1 Like
From my communication with Tiny, it looks to me, that it will go with them. But I might be stretching from the little exchange we had.
Sharing thoughts as a Meteor user & developer. For me, at a very basic level, the most important elements of the Meteor stack are:
- unified framework for both front and back-end, with a single programming language, and a common codebase for both the web app and the iOS / Android apps through cordova.
- ability to pick whatever front-end technology is best suited for my project (Blaze, React, Angular, Vue, … you name it).
- Reactivity. It may be a small thing, but the way Meteor is natively inducing data reactivity by observing collections is amazing. It kind of forces you to think about your entire app in a reactive way.
- Minimongo. Life would not be the same without it. The benefits of data manipulation on the client side using the same exact methods as on the server side are huge. Using the mongodb grammar and syntax is really powerful.
What I would love to have at this stage is an easier way to handle data persistence and offline operations for the mobile apps. This is something we have still not entirely solved in our project.
7 Likes