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.
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.
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.
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.
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.
