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.
That would be great, since Vue has essentially been broken on Meteor since 1.7. This is the risk of anything “community” provided where the the “community” is typically just one guy, who now happens to be busy elsewhere. I do agree that if React gets a special treatment, it feels discriminating towards Vue , given the two seem to be quite equal rivals in terms of popularity.
But, having Meteor provide an integration for Blaze, React, Angular and now Vue is a slippery slope. We have tens/hundreds of frameworks already and new ones are appearing out of nowhere on a daily basis.
I’d argue MDG would be wise to craft a solution that works for any framework, in similar spirit to razzle. I have no idea how hard that problem is, though.
How far off are we? The compiler plugin for Svelte was really easy to grok, it pretty much just calls for Svelte’s compiler, transpiles with Babel and pushes the JS down the build pipeline. Then, when you take a look at the akryum:vue-component plugin, it’s quite a beast with all sorts of sorcery going on, which now have ended up breaking with the newest Meteor release.
So maybe there’s some room for abstracting that complexity away, since almost all frontend frameworks probably want those similar features from the build plugin, but the implementation is not entirely trivial, such as HMR.
That said, I have to mention, last night I got HyperApp running with Meteor v1.7.1-beta in a few minutes with routing and SSR included. All that was needed was a .babelrc file with one line of config.
I’ve debated switching to another frontend framework for a while now, but decided to hold out and see where things pan out. My feeling about the situation is we’re all fraying out into the frameworks we like best and are best for the job - not necessarily the most popular, but the ones that help us work the best. To some degree, ongoing support is important, but on the other hand, there are many key frameworks out there that continue to be used by thousands that are seldom updated. Because it already does everything it needs to do and it does it well (underscore.js comes to mind). Blaze is one of these frameworks. It’s solid and reliable. It may not be the most performant, but unless you are rendering hundreds of thousands of DOM elements, the difference is negligible in 99% of cases. And in two and a half years of using it, I have only run into one bug which I reported, and even that was minor and not functionality breaking.
If there were any other framework I’d be interested in, it would be Vue. But one of the reasons why I’ve stuck with Blaze is because it integrates so nicely with the core of Meteor. Everything just works. We are using Blaze heavily in our current code base that is over three years old. Over 36,000 lines worth just in Blaze-related code. But it’s slick and clean. We have even developed lightbox, popup, and tooltip plugins just for Blaze and they all work great. A lot of code cleanliness does have to do with the developer. We don’t have much spaghetti. And Blaze can do a lot of cool things I think most developers just don’t take advantage of.
I use the same rule for choosing a framework as I do choosing relationships. They have to add value to my life versus take from it. Doesn’t matter how pretty or popular they are. The list of workarounds needed to change frameworks makes it enough to tip the other way. And I don’t mean just in our project, but in general to get the framework to work with the same feature set I have been used to. If I was building mobile apps or using a lot of framework-based plugins, it might be different. There’s also the argument for hiring. You can find more React developers than you can Meteor. But where I live, there’s not a lot of people who know either. Meteor is much easier to learn (and by extension Blaze). So in our particular situation, the job learning that would be necessary anyway is easier to do with Blaze. I’d go further to say understanding Blaze before learning React is more advantageous because it’s a great way to learn the principles of reactive programming first without jumping into the shark tank.
We might change over one day, and it may or may not come soon. I do wish Meteor would have official Vue support. That might tip me the other way.
I know this is an old thread, but I just wanted to share some background and officially invite somebody to take over maintainership.
So when I got delegated this responsibility I organized issues and made some plans how we could proceed with the project. I have also identified some blocking issues I needed MDG’s help on for project to fully transition to community ownership. Primarily, moving packages to NPM so that people also outside of Meteor community could start using Blaze and we would get a live on our own. Sadly, those issues never got addressed, so things got stuck. Time passed which then hit against me having to focus on my PhD thesis. Also in meantime I moved on to Vue and managed to fully integrate it with Tracker which for me have then ideal combination of component based UI layer + Tracker based reactivity on top of Meteor. I am not using Blaze anymore myself.
So I fully endorse somebody else taking over maintainership if there is interest. My run was not how I myself expected it and it is clear I am not suitable for it anymore.
I still think Blaze was and is amazing. I do not know if you noticed how other libraries made a full circle and got back to what Blaze has already been providing since day 0. Like initially everyone was complaining how Blaze does not have components and object oriented organization because React had them and calling “abandon ship”, but now Vue introduced Composition API and React Hooks and to me this is like, heh, Blaze/Meteor already had that. So we really went full circle. And this is pattern I see in Meteor again and again. Code quality and ingenuity found in packages is really amazing. So visionary.
Thanks mitar for all your great work! To me, it is obvious that Blaze is dead, unless Tiny steps up, takes it under its umbrella and actually brings it up to a modern level. I loved Blaze back in those days, it’s great for beginners coming from HTML, but after moving to React, I never looked back. There were lots of thoughts about building a modern Blaze on top of Vue, but obviously, it didn’t work out / nobody had sufficient time for this. If Tiny can’t take it over, they should deprecate it officially.
Well, I think a package should be deprecated if there are no maintainers anymore. That’s what I meant. If Tiny commits to maintain Blaze, that’s awesome, of course.
Some background: In the old Meteor days, there was a famous post from Geoff / MDG who kinda deprecated Blaze before an official replacement like React was even available. At least that’s how many in the community understood that post. Which lead to quite some limbo at that time. Effectively, MDG didn’t invest much into Blaze from that time-point (at least it felt like so), which is why some community members (like mitar) stepped in and took over. Now that mitar - who did an amazing job btw - has to “give it up”, the question of the future of Blaze arises again. At least to me.
Basically, I see two options: Tiny commits to maintain, or the community takes over (once again). Tbh, I am not sure how many other maintainers Blaze has atm, as I did not follow the repo for quite a while. Maybe I am wrong and mitar’s drop-out won’t cause any “fraction” at all.
Besides: Is there a statistics somewhere how many Meteor apps are actually based on Blaze? I am really curious about this and I have no idea myself. My gut-feeling was that most people have already moved on to React, Vue, Svelte, or even Angular, although there’s still quite some big Meteor apps out there running on Blaze, for sure.
Anyways. I loved Blaze when I was still using it. But for me, all that limbo was the main reason why I moved on as well. And I never looked back.
