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
Nothing’s wrong with Blaze. Spin it off into a standalone frontend library, coupled with minimongo, and see what happens =)
5 Likes
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
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
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. 
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!
7 Likes
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
9 Likes
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
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
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! 
3 Likes
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
3 Likes
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. 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! Good luck to you!
4 Likes
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 . 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
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… 
7 Likes
There will be a discussion about Blaze at Meteor Impact:
Hello,
It seems that the discussion on Blaze had technical problems. Is it possible to get a look at it? Or at least a summary on what is planned with Blaze etc?
1 Like
I’m not aware of any major technical problems with Blaze. there are desired enhancements as far as I can tell.
Blaze is being successfully used in many production projects already.
2 Likes
Sorry for being not clear. What I meant that the discussion on Blaze at Meteor Impact Conference had technical issues and there is no video of it for those who missed the discussion. So if there is a video or summary of discussion that took place the day before yesterday that would be nice
Actually there is a 10min video with the attempts to get stuff working, but nothing on actual discussion…
1 Like
Ah got it.
For now, I can give you a quick takeaway since I was part of the discussion.
There was a consensus that Blaze offers Meteor a unique advantage given it is simplicity (very close to plain HTM, thus making it ideal for new developers, designers, hobbyists etc ), tight integration with Meteor’s backend (minimongo, tracker etc), many packages, and battle-tested production projects.
Therefore, there was a shared desire among the folks in the panel to continue supporting and further enhance Blaze.
Also, a fun fact that the current Meteor.com site is built with Blaze since the designers who worked on it preferred it over other view layers
3 Likes
Ok, thank you so much!
2 Likes
Honestly after Meteor Impact, I’m thinking to give Blaze another try, especially after it removes lodash/underscore and jQuery from its codebase.
4 Likes