The integration being developed at https://github.com/meteor/react-packages/pull/273 is excellent (I’m using it currently).
5 Likes
yes and I replied him back in that post, because I strongly disagree:
Sorry but I think that would be a major mistake. Meteor beauty is derived from its original vision of simplicity. It’s different—and valuable—because of Monimongo. Blaze is just a template engine, but it is simple and perfect for many use cases in mid-range application development. React is fine too, but a lot more complex. It would be ok let the user choose the template/framework for the View, but Minimongo—nad reactivity made easy—is what makes Meteor different. Getting “rid of the old Meteor” is equivalent to kill the project to make “just another Javascript framework”—that we don’t need sincerely. In a Javascript world where new frameworks get released every other day, I think we need something that keeps users focused on the business side instead of configuring and re-configuring their development environment. Not everyone is making big products that need to scale a lot. Most of the programmers create projects for customers or tiny niche products. I think that Meteor should fill the gap in the mid-range applications market to make things even easier and hide the complexity of the Javascript world—which is pretty messed up in my opinion. The enterprise needs this because there are plenty of options to build complex and core business systems. There are just a bunch of options to deploy a project in weeks and none of them is as good as Meteor in the Javascript space.
8 Likes
I strongly agree with this. The fact that there is no Meteor experience equivalent within the webpack/graphql/react ecosystem almost 4 years later is not due the lack of trying by the JS community but due to the inherent complexity of those standards/APIs and tools, a complexity required by large enterprises (thousands of components, multiple endpoints, multiple teams etc.) but unnecessary in many other contexts.
Flexibility in view layer is great but the Meteor experience need to be preserved and even enhanced. Tiny to Meteor can be the Steve Jobs return to Apple, double down on what works, fix what does not but preserve the identity/experience of what we all loved about Meteor when we first joined.
7 Likes
I agree with you regarding Apollo vs. MiniMongo/DDP. But I am not sure if I still agree regarding Blaze vs. React.
One thing is clear: Blaze was what got me into Meteor, since I loved its simplicity, and it was very easy to get into it if you came from a pure frontend web developer background, like me.
However, if I would encounter Meteor today, I would wonder if I should really use a technology that nobody else is using. I guess I would rather go for React, because it’s way more wide-spread in the overall JS community. Or maybe even Vue, because it’s more similar to HTML and Blaze. Plus, there’s so many more ready-to-use React components out there, which is also a big plus.
2 Likes
I built my fair share of apps in Node, some as services to support our main Meteor app, and, damn, I couldn’t find anything to even come close to the simplicity of DDP and Meteor methods.
While in the front-end, Minimongo and Tracker are just a joy to work with. Blaze was and is perfect for any medium size project, though I understand why one would want something that is guaranteed to be maintained.
2 Likes
The preference for a view layer tend to be very subjective and dominated by hype, yesterday it was handlebards (and blaze), today it’s vue and react, tomorrow it svelte and web components. By keeping the core/backend flexible (yes at the expense of some end-to-end full-stack magic) you shield the framework and whatever is built on it from that churn and ensure the longevity of the platform. Furthermore, companies do re-write their view layers to update the user experience every now and then and pick the view technology of that time (hence the churn) but their DBs and backend are way more stable since those are battle tested.
7 Likes
But of course Tiny could always decide to maintain it again. Also, I think given similarities between Vue and Blaze, it would be relatively possible to build compatibility later on top of Vue exposing Blaze. Moreover, I have already done work which allows combining Blaze and Vue together, with great simplicity (using Vue inside Blaze and Blaze inside Vue), with reactivity working across them.
So, putting more people on this and all this could be pretty neat.
6 Likes
I very much agree that Meteor should stay view layer agnostic and just be open to integrations with whatever view layer necessary. There are hordes of developers pouring massive efforts into React/Vue/Svelte/whatnot and no reason for Tiny to duplicate any of that in any capacity (i.e. repeat the mistakes made with Blaze).
A good example here is the semi-official Vue integration created by the Vue core dev @akryum. The only two components of such integration that are actually needed in most apps is the vue-meteor-tracker (links Vue to Meteor’s reactivity) and vue-component (links Vue to Meteor’s build system). The first one is around 400 lines of code and the second around 1500 lines of code. If Meteor is able to maintain a codebase where a nicely working integration can be achieved with only 2k LOC, then I don’t see any good reason why not to keep Meteor separate from view layers and allow such integrations to do the work.
13 Likes
Oh, I’m familiar with your work 
. I hope there’s going to be some investment put into it. Personally, I have nothing against Blaze. On the contrary, I found it very productive. We have 1000+ templates in our application, many of them as reusable components - using best practices as per Meteor Docs, the app is fast and nimble as a wasp.
To me, the tribalism and “politicking” surrounding the multitude of JavaScript frontend frameworks makes no sense, but, well, such is life.
1 Like
I can only agree and say: Great News guys!! I am so happy to here of these news and frankly I am very optimistic for the future of Meteor now! 
#makeMeteorGreatAgain
4 Likes
Spot on! (enough text for 20 chars)
I think the backlash caused by @sacha’s article is getting a bit too far. I’d say the FUD is unintended, and mostly caused by his desire for Meteor to have a future.
Sacha is one of the staunchest defenders of Meteor, and one of its most dedicated fans. Being pessimistic is not difficult to imagine, given the lack of communication we have all complained about for a while.
8 Likes
Nobody writes an article with a clearly articulated plan for an open-source project if they aren’t invested in the success of that project in my opinion. So maybe some people thought the timing of the article was poor due to @sacha’s stature in the community, but that isn’t so bad really. I’m sure most of the people who read the article are already on Meteor’s side. I think the web development community at large is more concerned with Meteor running on Node 12, having modern features, support for Typescript, and up to date packages that solve problems that they need solved. And some signs of life regarding Meteor from its benefactor Tiny, like new blog posts discussing new releases, or new packages, etc.
11 Likes
Thanks for sharing,great write
The thing about Blaze vs No Blaze is nuts IMO
Blaze is just view layer. Don’t use it or include it… your choice. Same thing can be said for React, Vue, Angular or whatever.
But unlike those “other” view layers, Blaze could be considered a “gateway” view layer that makes it incredibly easy to get your mind wrapped around Meteor for new users without introducing any additional complexity. Even devs that are fluent in React or Vue might find value in that potentially. And, once you get a taste of that Meteor goodness… you sorta get hooked 
As we all know too well.
Plus Blaze plays nice with React and Vue at this point so it’s incredibly easy to migrate to more mainstream view layers in-flight once you’re settled if that trips ur trigger.
So in that way, I think Blaze is an important part of the Meteor equation and it would be disappointing if it was dropped.
7 Likes
I agree, even though I am not using Blaze anymore. It’s a fantastic way to get talented frontend devs into fullstack quickly.
4 Likes
The discussion isn’t about using Blaze or not. It’s about investing in its development. Many argue that investment should go into more important parts because there are great alternatives. There simply isn’t any need for Blaze anymore.
People who are heavily invested in it might disagree with this of course. But looking at the future, just pick an alternative instead of fighting for some legacy software.
If enough people really cared about it, they could maintain it themselves. But looking at the repository, the people using Blaze just want to consume it, not investing in it. I understand because how should all these entrepreneurs using Blaze find the time to do so.
For me, Blaze is no longer part of the Meteor goodness. The lack of API improvements, tooling, and re-usability outside a Meteor environment are some of the reasons I moved on. And guess what, the alternatives are at least as good as Blaze. If people were educated to use an alternative from the start, then again, there wouldn’t be any need for Blaze.
This is very untrue for many cases. Once you created a serious application, migrating to another view layer is very time consuming and a waste of resources.
I would advise starting with a view layer with wider acceptance, to prevent unnecessary migration paths in the future. Unless you are already heavily investing in Blaze, or your goal is to educate juniors, or if you’re only using it in a hobby project this might be a path to take.
Disappointing for some. But from a business perspective, there is barely any ROI for Tiny if they invest in Blaze.
TL;DR: View layers have been solved. Blaze isn’t needed. Invest in something else.
8 Likes
Thanks for your perspective very much appreciated. Perhaps we can agree to disagree. As to the “investment” angle, Blaze is already split out into a community maintained package so I am not sure I expect Tiny to carve out a significant investment budget for it. Blaze is just another view layer, it has its purpose for some, and apparently for others it is not worth considering.
Many think of Blaze as a ‘feature’.
MDG did think this way because it is comprised of technical not marketing people.
But Blaze is a benefit for quickly learning and building MVP.
Many developers laugh about developing in Sencha/Ext.Js but if you look at their price tag and adoption, it really provides the benefit of something like Blaze + Meteor Kitchen. But Blaze and Meteor Kitchen provide clean code vs Sencha providing crazy complex and awkward code.
3 Likes