I think you’re underestimating what that all means. From a business perspective, it make no sense to invest in another view layer when there are many competing open source packages, back when Meteor started, there was no React or VueJS so Blaze made a lot of sense, but today having the view layer flexibility is much more preferable. The choice of view layers seems very subjective, just look at the vue versus react debates.
However having a build system that favours convention over configuration with a solid packaging system and integration with a popular view layers is very much needed in the JS ecosystem.
And I did say Blaze is good to have, but in my opinion, should not be the priority for MDG.
It’s great to have choices, and the ability to easily add third party packages has been one of Meteor’s defining characteristics. But nothing wrong with a tightly-integrated view layer from a technology standpoint. No third-party view layer can be as tightly integrated with Meteor as something built specifically for it.
What does the argument that Blaze made more sense back before React and Vue existed do for Meteor? Meteor had the leg up. What Meteor should have done back then was release a fully stand-alone version of Blaze (with minimongo!), asap, keeping the tight Meteor integration as benefits to using Meteor with it. Even to this day it’s still very much Meteor-only. If Meteor plays the “let’s be super visionary and pioneer everything, and then depreciate it piece by piece when someone becomes the-new-hotness-for-x” game… then what will it be left with when next month AirBnB or Netflix or somebody with a giant tech budget releases a more trendy build system and backend that works with vue/react? What will Meteor have to offer besides the same third-party packages and pricey hosting?
The tightly integrated, wholistic, end-to-end framework, with the option of using third party packages, is what made Meteor a compelling body of work.
I hear you, but once again, I think I see way more value and appreciation to what Meteor is providing beyond the view layer which I think you’re underestimating. A lot of effort has been put on the core features such as dynamic import, latest node support, SSR, ability to create two bundles (legacy/modern), faster build times, the ability to create minimal meteor project etc. are all features that made Meteor more appealing to us, if the effort went into the view layer (Blaze) while neglecting the core, I’m sure lot of people won’t be happy now.
I’ve nothing again Blaze/Mini-mono I’ve used it and still use it several projects but I just think something like React is more suited for more complex project and I don’t want to be restricted to Blaze. I hope we’re not arguing past each other, I’m just stating the given the tight resources/constrain for MDG, focusing on the build/core Meteor, in my opinion, is the right thing to do, I’m just being pragmatic here.
IMHO, abandoned Blaze is only a symptom here, not a cause. And if we search for a true cause of where resources are directed it is not the one ‘hot thing’ being React but 2 at once: React and GraphQL, and the fact that these hot things were achieved at the expense of features, unique to Meteor.
Blaze is still alive but meteor hosting is not. It was deleted in favor of GraphQL. But I guess the expected effect is not achieved. If you look at https://search.packtpub.com/?query=meteor&refinementList[released][0]=Available you see 12 books about Meteor, with most in pre-React/GraphQL era but no book about Apollo or post-hosting-deleted features despite their intended coolness like evergreen browsers etc. Maybe because they are not exactly core cool things like one line deployment but just ‘nice to haves’ or ‘external standard compliancy’ categories.
As someone who prefers to develop everything from scratch, I’ve found Blaze to be beyond sufficient. It’s just three things: templates, events, and helpers, and that’s all you need. Everything else, you can get from third party libraries or add in yourself.
I think Blaze works really well as a default view layer. It’s kind of like with Rails or other frameworks - they have really simple view frameworks in place and then you can layer in whatever you would like.
If there’s one thing that could help Blaze significantly, its updating the data layer or getting people to think about it differently. I suspect that’s where most of the performance problems are coming from.
@hwillson Your post simply made our day. It would be great if this can be made prominent somewhere. It has huge significance for Meteor users like us, who rely on Blaze for their production apps!
This reminds me a bit of the Thunderbird guys saying they stopped development “because it is done”. But in principle, you’re right. Blaze is amazing and allows for insanely fast development. I still love it. However, its performance on mobile devices is not really good, at least to my experience. And if you combine this with the slow development pace, this is still a valid reason to give it up and move on to other frameworks, if you’re a mobile-focused developer. This may be different for people developing web apps, of course.
My experience with Blaze resulted in a lot of spaghetti code. I don’t blame Blaze for that, I blame myself. However, the tooling around React actively promotes good practices and I do think that is something that Blaze never had. You could play fast and loose with contexts and never see a warning in the console.
Also, you still see posts here questioning the use of Session vs reactiveVar vs reactiveDict. I certainly agree with the sentiment that Redux isn’t for every project, but the lack of a true state management tool I think also hurt Blaze.
I was a big proponent of Blaze, and I still really enjoy how close to the html it allows the code to be. But I’m not sure it lives in an ecosystem where it can make developers (and the code they write) better.
I had similar experience with a growing Blaze code base. However, as you stated, those issues could have been avoided with good engineering practices but those practices are built-in something like ReactJS from the get go. This is not surprising, Blaze was created from the handlebars/jQuery era before font-end components took over. I’ve mixed feeling about Redux, I think it’s an overkill for most react projects and React17 is heading toward making async calls within the components.
With that said I still think Blaze is the fastest way to get a web app built and I still use it heavily.
The funny thing is: React actually taught me how to setup my Blaze templates right.
Just one example I encountered today: In Blaze, templates inherit the data context of the parent template automatically. This is cool when you start building the template, since you don’t have to pass the context explicitly. But you get into trouble once you have to enhance the data context for the child template at a later point of time. In this case, you will have to change the template’s API, which will force you to change every spot where the template is being used. In the React props concept, you just can’t access the parent component’s data context (props) if it isn’t passed explicitly. And that’s just one example where React forces you to program in a modular manner.
Another sample is passing callbacks as props. In React, this is common practice, to de-couple a UI component from the business logic in a container. Since I was missing this in Blaze dearly when extending my Blaze templates, I tried to figure out how I could do it there. And you can in fact do this by defining a helper in the parent template that returns the callback functions as an object and then pass this object as a parameter to the child template. It’s a bit weird, but it works. I would have never come up with this idea if I hadn’t known the decoupling concept from React.
Even when required, spiderable or other solutions that serialize a DOM are decently acceptable in many cases, I’m hard pressed to think of cases where spiderable/DOM serialization + caching isn’t enough.
Have been playing in the last couple of weeks with Meteor Vue (https://github.com/meteor-vue/vue-meteor) and I’m loving it. For those used to Blaze (specially if using ViewModel, but not necessarily) it is a very natural move. The React model never “fitted” naturally into my thought patterns (not straight a React problem, of course…), but with Vue, after a few hours reading the great documentation to get the basics, wow!
I cant understand why everyone is so thrilled about React… MDG should ensure that Meteor support for Vue is at least at a level-field to React.
I’d just like to say that this has been an outstanding thread. Given its title, it could have descended into a pit of despair, but instead pros and cons of Blaze, React, etc. have all been discussed with great professionalism.
And again, this is venture capitalism world. Why make Meteor Developer Edition plan and do long way of gathering annual USD100*10000 developers, do all the chores like billing, accounting, etc. and be obliged to balance between the different needs of developers (because they are clients now). It is better to make some newsworthy features, and hope for VC to come and grant several millions at once.
It is not meant to be an offense, it is just like observing the facts ))) We are not clients, we are fellows )))
But this does not diminish greatness of both Meteor and folks behind it.
