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 ?
Your brain is turning into mush. STOP IT!
Don’t give me free time and tokens ![]()
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 (
), 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 ![]()
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 ![]()
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
![]()
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?