Blaze is dead of self-sufficient?

blaze
54

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.

11 Likes
55

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.

3 Likes
56

We do have a Blaze group under MCP, so we could bring it there for the time being.
We could then have a discussion on how to proceed next.

7 Likes
57

The majority of Meteor apps stills runs on Blaze, by a large difference as per the latest statistics I have seen. So why should it be deprecated?

3 Likes
58

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.

59

According to the stats collected by @storyteller, and assuming the sample is representative of all Meteor users, Blaze is only one tiny notch behind React: Meteor Community Survey 2020 full results

That is very interesting. I would have assumed a bigger gap, given the amount of time that has passed since the whole deprecation debacle.

2 Likes
60

Indeed. Thanks for sharing this. I wasn’t aware of that survey. Kudos to @storyteller.

1 Like
61

I think this show that Blaze was a good technology and that upgrading to something else isn’t as appealing as many might have thought.

8 Likes
62

Nothing’s wrong with Blaze. Spin it off into a standalone frontend library, coupled with minimongo, and see what happens =)

5 Likes
63

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.

10 Likes
64

There is a draft PR that adds an architecture overview for Blaze, so upcoming contributors have an entry point: https://github.com/meteor/blaze/pull/312

2 Likes
65

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

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

I would encourage everyone considering moving from Blaze to check out the main Svelte tutorial here: https://svelte.dev/tutorial/basics

Blaze fans rejoice…we have a path forward! :slight_smile:

7 Likes
66

If scaling concerns you, here is the remedy: https://github.com/jankapunkt/meteor-template-loader

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.

If you concern about rendering large DOM structures, please consider this post: How to optimize rendering of blaze.js templates on pages with lots of elements

If you need to find dead Templates or want to measure UI/UX performance, here is another nice tool: https://github.com/jankapunkt/meteor-template-monitor

I think Blaze has lots of potential that is still unused. I am committed to improve on it after the impact conference asap :slight_smile:

9 Likes
67

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.

3 Likes
68

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.

5 Likes
69

I couldn’t agree more. If Blaze was viable outside of Meteor it would most certainly help! I respect and appreciate that some folks don’t want to learn or don’t have time to learn a new framework. I am super glad that there are still people willing and able to step up and Make Blaze Great Again! :grinning::crazy_face:

3 Likes
70

I’m intrigued as to how you did this? Did you automate any of it or all by hand? Any issues you had to solve?
Were you using packages like Autoform and Simpleschema beforehand? Simpleschema should still be fine but what did you replace Autoform with?

We love Blaze but we’re always eyeing Svelte with envy :slight_smile:

3 Likes
71

I know for us, we started from the ground up…but this was partly because the app needed a UI refresh anyhow. For us, we used SCSS and a framework anyhow; so I would imagine that if you don’t need the UI to change, your styles could remain identical.

The rest was pretty much a ground-up rebuild; however, many of the principals are so similar that this was not as large of a task as you would think. There are packages such as this one by @rdb (thanks man you have been awesome!) that could perhaps help…though I would leave it to him to say how production-ready it is: https://github.com/meteor-svelte/blaze-integration

Regarding autoform, we never really used it as at least for us it was pretty limiting; however, simpleschema we are still using. :slight_smile: I would honestly tell you that forms should not be too much of a concern, as they are so insanely simple in Svelte… it’s almost a non-factor. We use YUP for form validation, and would be more than happy to post an example if that is helpful, but check out this SUPER simple form example using Svelte (no validation):

<script>
  let values = {};
  const handleSubmit = () => {
    console.log(values);
  };
</script>
<form on:submit|preventDefault={handleSubmit}>
  <label for="firstName">First Name</label>
  <input name="firstName" id="firstName" bind:value={values.firstName} />
  <button type="submit">Submit</button>
</form>

I am not too sure it could possibly be easier than that! :slight_smile: Good luck to you!

4 Likes
72

I’m planning on doing a short write up and posting to #svelte so hopefully we can all learn from each other. Edit posted here: Converted a project to Svelte. AMA

Did you automate any of it or all by hand?

All by hand :slight_smile:. Porting code and some refactoring moved pretty quickly. Agree with the statement above: many of the principals are so similar that this was not as large of a task as you would think

Were you using packages like Autoform and Simpleschema beforehand?

No. My forms are pretty simple and with svelte the code is super straightforward. I considered introducing Simpleschema but it felt a little bloated. I’m using check but may move to something like ajv in the future.

3 Likes
73

I had used Blaze when I was just learning Meteor and, frankly, web development altogether. I had been drawn to React through Manuel De Leon ViewModel, which I traded for regular React eventually. But when I saw Svelte, it felt as simple and elegant, yet faster and leaner than most other options. So far, I really enjoy it.

And for the record, I’m working on a validation library that I hope might be able to replace SimpleSchema. I also developped a companion Svelte store that makes client-side validation simple and composable, even for very complex forms (which I deal with a lot). I’ll keep you posted when it’s properly deployed and documented… :wink:

7 Likes