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.
I wanted to chime in here awhile ago when I saw this post, but just got around to doing it. Blaze is by far my favorite javascript UI framework I have ever worked with. On the Blaze documentation site it says:
What sets Blaze apart is a relentless focus on the developer experience, using templating, transparent reactivity, and interoperability with existing libraries to create a gentle learning curve while enabling you to build world-class apps.
All of that is 10,000% true. Working with Blaze is a dream come true. It’s easily organizable, keeping track of state is a breeze, I don’t have to mesh html into my javascript code, and controlling view state has never been this transparent. I wish I wasn’t so damn spoiled by it before learning React and Vue.
If Blaze was decoupled from Meteor and was able to be built in webpack with support of a community lead team. There’s not doubt in my mind that it could become very popular. My only wish is that Blaze was faster in rendering, because it is not nearly as fast as React/Vue.
But anyway, Blaze is what keeps me in Meteors framework. If I had the extra time or the money I would support it more. Unfortunately that’s not a real possibility for me at the moment. I am hoping that someone, or the Meteor team, is able to pick it up and continue to support it even more in the future.
I 100% agree with you about Blaze! I had actually learned JavaScript frameworks via Handlebars at first and then Angular V1, and then Blaze, but along came React and ruined all the fun! All of a sudden forms were tough to work with and all of my code seemed more verbose. I found myself missing my long lost love Blaze!
I had written 4 specific apps in Blaze, and due to COVID-19 have found myself back working on the very same apps 3 years later (it pays to not burn bridges folks!), and fell right back in love again; however, like going back to a previous girlfriend…I saw the flaws much more clearly this time around.
It’s just my opinion, but time has passed Blaze by.
I knew it and needed something to replace Blaze. Unfortunately, Blaze just can’t keep up and does not scale very well (though not impossible at all). Enter Svelte. For all of you Blaze fans…despair no more! I would implore all of you to take a real hard look at Svelte! Under the surface it could not be more different than Blaze; however, when you look at the syntax and the way things “just work” it starts to quickly feel very familiar! Forms are no longer a nightmare…in fact, they have never been easier! Lifecycle methods work for you not against you (I am looking at you React)…and the entire philosophy of what a framework can be has changed…in fact its NOT a framework, but rather a compiler.
Register some async functions that import templates and load them only when they are actually included in another template. This got use to reduce the initial client bundle to nearly 1MB. Plus scalability is then infinite.
I’m pretty late to this party - but I too wanted to chime in.
I’m more than willing to jump in as a maintainer - I’d love to see a few small tweaks made to Blaze to fix some little performance issues (particularly with HTML fragments), but I’d also like to see it permanently move to NPM - there is no reason that blaze could not be used in projects outside of meteor. Unfortunately this requires quite a lot of effort (I already released a proof of concept to NPM that “works”) as Blaze has quite a few dependencies that would also need to move to NPM - and arguably should!
For this meteor would need to adopt a naming convention (and ideally an NPM namespace @meteor/ or similar), and start moving components into NPM.
Completely agree. Blaze is awesome. Svelte feels like the next evolution of Blaze in a lot of ways.
I’m wrapping up moving a fairly large project from Blaze to Svelte and it has been great. Many of the concepts have a pretty direct translation. Would encourage Blaze fans to check it out.
, given the two seem to be quite equal rivals in terms of popularity.
