Blaze Next - Vision, Ideas, Tasks etc

Claude worked hard tonight, and the result is here. It’s an overview of templating and framework ideas, their pros and cons, and what Blaze could try to integrate maybe ?

2 Likes

Your brain is turning into mush. STOP IT!

Don’t give me free time and tokens :joy:

After some serious thought, I started an experimental re-write here… https://github.com/wreiske/blaze-ng

Goal is to be a Full, modern TypeScript rewrite of Meteor Blaze with 100% API parity, all 370+ original tests passing, superior performance, and minimal dependencies. Drop-in replacement for any Meteor app.

You can check out the plan and progress here: blaze-ng/PLAN.md at main · wreiske/blaze-ng · GitHub

I’ll report back when it’s further along and ready to test.

Woh @wreiske nice work!
A couple of thoughts from the Blaze modernization work I’ve been doing on the main repo (if it can help you) :

Use native <template> elements : Since you’re targeting ES2020+ and already dropped IE11 ( :partying_face: ), you could leverage document.createElement('template') in your materializer (Phase 3e). The .content property gives you a DocumentFragment directly, content inside doesn’t get parsed/executed (no rogue <img> loads or <script> execution), and template.content.cloneNode(true) is really fast for repeated rendering, which would pair well with {{#each}} over large lists. It’s cleaner than parseHTML(html) → DocumentFragment and aligns with your performance goals :+1:

Edge case from the jQuery removal : One gotcha I hit during PR #489: focus and blur events don’t bubble. jQuery silently aliases them to focusin/focusout for event delegation. Since you’re using native addEventListener in your event system (Phase 3g), you’ll want to handle that explicitly or your delegated focus/blur handlers won’t fire :grimacing:

And one thing though : full TypeScript might be overkill for a Blaze rewrite. The original codebase is plain JS and most Blaze users aren’t TypeScript shops. You could get the same benefits (typed APIs, IDE autocompletion) with JSDoc type annotations + a .d.ts file, without forcing contributors to write TypeScript. Just a thought :roll_eyes: :smiling_face:

4 Likes

So far pretty promising! The compilation takes a little longer, but the actual in-browser performance of running is better. Also SSR is working!!

https://blaze-ng.pages.dev/guide/performance.html#old-vs-new-head-to-head-comparison

@wreiske as long as this is non breaking for users we should consider this one for 3.1 as well. Against which branch did you compare the improvement?

1 Like

This will need a serious comb over and testing from the wider community before I would say it’s ready to be a “drop in replacement.” I had it run off main so probably missing any improvements that are living in branches :see_no_evil:

That is the goal of course, but with literally 0 lines of code touched by humans and 100% re-write by Claud Opus 4.6… I wouldn’t trust it without a code walkthrough. I have been fixing little things as I notice them and it seems to pass all the original tests / API, so it might be good. I’m going to test it out in one of my production apps and see who squawks :laughing: .

I’m also going to test out @blaze-ng/wasm | Blaze-NG which should provide even more performance improvements for sequence diffing and HTML tokenization.

Off-topic and unrelated to Blaze: I also notice that AI really, really likes to run npx meteor@latest run and it also put it in the documentation everywhere.

Meteor might consider making that work. I use npx all the time for other tools like wrangler, vite, etc…

2 Likes

Same for @wreiske :

As a user of Claude Code you should take a look into this package (actually the whole ecosystem):

“Greenhouse closes the last manual loop in the os-eco toolchain. It polls GitHub for pre-triaged issues, creates seeds tasks, dispatches overstory runs, and opens PRs when agents finish. The only human touchpoint is merging the PR.”

I’m using it extensively since a month and man, the speed of progress is huge.

Also watch this video which explains how we can manage open source packages way more effective and have a minimum of human intervention. This would speed up the work:

The Agentic Engineering Ladder

1 Like

Absolutely agree with that PoV

2 Likes