Given that I know react, and don’t know blaze, it’s significantly faster for me to build a view layer with react than it is for blaze.
That’s just not true for everyone. I have been working in the latest years with Meteor, react and now grapher and is a much better DX than working with blaze + minimongo. And not using blaze and minimongo doesn’t mean I can’t benefit a lot by Meteor accounts, build system, atmosphere packages, npm packages, no config, easy RN integration… I also use webpack with serverless and Meteor is far easier to deal with, so it is not just “use meteor with blaze or go the webpack, parcel or -insert new bundler- way”.
Also, you can still do things the blaze minimongo (old) way without any problems, but probably that backwards compatibility is holding back some new features or improvements.
So, this is relative to the developer, for you is easier and better blaze minimongo for others is better and easier react, grapher, etc. Probably there will be a place for both and even more.
The reason why, from my perspective, is that asking developers to now learn Blaze after already knowing Vue or React isn’t going to fly. Blaze doesn’t offer much in terms of a unique value proposition compared to existing frameworks with much larger communities. I don’t think Blaze is a faster developer experience than Vue or React and certainly won’t be faster for someone who’s never used Blaze.
Besides if we wanted to go with something like Blaze, then Vue is basically a more modern version of it in my eyes. IMO the only reason to stick with Blaze as the main UI layer would be to placate the people already using it.
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:
- It may be a major lift for other front-end frameworks just to keep up.
- Support for React will be a strong selling point for Meteor.
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.