Just run into an interesting problem with Apollo, which I would categorize under better Apollo integration:
In a better integration creating fragment types json should be automatic (or via additional package to limit it to those who need it) as in Meteor we know the build system.
Listening to this episode of React Podcast, an interview with Andrew Clark, I learned that the React team is innovating really hard, not only on concurrent mode, but also on SSR and selective hydration for SSR (around the 40:00 mark). Observations:
Hello, as probably many of you already know I’m now Meteor Evangelist (I’m joining Meteor as Developer Evangelist!) working for Tiny and then feel free to reach me.
You can send me messages whatever you prefer, here in the forums is fine and also on Twitter https://twitter.com/filipenevola
And to be clear, the Meteor community is very important for Tiny and we will do our best to communicate well with you, understand your needs and help as we can.
React and Vue offer ecosystems that have predefined patterns that avoid code smells and anti-patterns. Having these frameworks as a part of my skillset helps me stay relevant and keep up with the larger Javascript community.
Blaze does not use the virtual DOM. Because of this, Blaze is slow. Wexpo Lyu has a great Medium post about why and how their team migrated from Blaze to Vue, and you can check out his benchmarks to see how Blaze’s performance compares to React and Vue. Blaze also is not as powerful. It requires many helpers for evaluating expressions that I can easily use Javascript interpolators and filters to evaluate inside the template using Vue.
No other nodejs backend provides what Meteor does out of the box. Auth and accounts are not as big of a deal as DDP imo. I’ve written other authentication, accounts management, and used SocketIO to attempt to replace a Meteor backend. It was a ton of boilerplate and did not begin to approximate what Meteor does.
Meteor is all about speed.
Meteor is different things to different people. For me, Meteor is about reactivity. I can use other frameworks to get my ideas online. If I was interested in less reactivity, I’d use a REST API. Meteor already has Apollo as well as Angular, React and Vue integrations, which I assume are the big complex frameworks you refer to. What benefits and advantages have been lost since these have been added?
While I’m also in the “Meteor is great as is” camp, I think it’s also good to keep in mind there might be some survivorship bias here in the forums.
This weekend I visited Q42, which a couple years ago was one of the biggest dev firms in the Netherlands using Meteor. Back then, they were also actively advocating Meteor, organising meetups, writing blog posts, and contributing to the framework. I was quite surprised this weekend when I mentioned Meteor, I got a response along the lines of “oh, Meteor, hah yeah that’s dead”.
Apparently they did run into some serious scaling issues on several projects, that were “impossible to fix” (I don’t know the technical details), and that eventually forced them through a very painful process of extracting Meteor from those apps. Needless to say, they won’t come anywhere near Meteor again.
Unfortunately, these people are not coming to this forum anymore to tell us about their experience. But I think given their experience and knowledge they would be a very interesting party for Tiny to give a call. Again, I don’t know the details, but this was a company that was very invested in Meteor on multiple levels, with great engineers, that was not able to get it to scale for some reason. That is definitely something that needs addressing, or at least investigating.
I think this is a good idea to reach out to them. And if I were Tiny, I’d make an effort to reach out to everyone on the partners list as a post-mortem since several of these no longer initiate Meteor projects. Likewise, it would be good to find out from the ones who continue to build with Meteor what their reason are. One of the things I worth knowing is if the current partners have encountered problems similar to those that frustrated (and perhaps lost) the former partners, and how these current partners have handled ir.
Yes @htchd7, premium support is already offered for Galaxy and Meteor itself
See the topics on GALAXY SUPPORT PRICING and METEOR DEVELOPER SUPPORT PRICING on
https://www.meteor.com/pricing
Support for latest Mongo commands via Collection entities?
in fact, a monolith with a blaze is much deeper and subtly uses all the capabilities of a meteor. What can be done with a blase in minutes, on the react will take hours by headaches with hooks, lifecycles, errors boundaries, etc
That has not been our experience at all. We have built both medium size (30K LOC) and small (5K LOC) systems in both Blaze and React. For small systems, React was just as easy to use as Blaze. For medium size systems, React was easier to use than Blaze due to its better support for modularity. “Hooks, lifecycles” etc are there if you need them in React, but in many cases you don’t.
Of course, your experience appears to differ from ours. If you have time, it would be interesting to post code samples written in both Blaze and React to demonstrate your assertion that Blaze both integrates with Meteor better and can avoid necessary and complicated features of React.
With respect, I feel the Blaze vs React discussion is getting a little off topic here. Maybe it’s better to continue it in another thread 
Would be nice to have an official ORM like mongoose.
ORM might not be the correct acronym, since we’re talking about MongoDB, but there is Astronomy.
You are right, I actually meant something like mongoose, “object modeling” tool, to help with relationships between collections.
I think such tool should be native to the framework.
Now I tried to use Mongoose in Meteor.
I work great
Hi, we read all the comments here very carefully and we are working in a roadmap to share with you.
We are excited and you are likely going to see things that you are expecting there, it’s also essential to notice that community involvement is much appreciated and that will be clear in the roadmap document when it receives the update.
For that, I would like meteor have more tutorials and get rid old-irrelevant tutorials.
Maybe it’s time to integrate webassembly/wasm build files with future meteor updates…
Maybe a good idea to close this topic now.
Updated Web, Android & IOS Native DDP libraries officially by MDG would be awesome 