Blaze Next - Vision, Ideas, Tasks etc

blaze
7

I think there are some experienced Meteor.js developers who don’t understand what Blaze adds to the developer experience. Even though some members of the community are taking positive steps for Blaze’s future, the discussion keeps returning to the React vs. Svelte debate. In fact, have you noticed that this debate isn’t even between different people anymore? It’s become a monologue. Because they’re all difficult, not beautiful, and they’ve all released different versions with significant changes in their search for the right solution.

Despite its shortcomings, I still put Blaze ahead of React, Vue, and Svelte. If I had used Solid vs. at a professional level, they probably wouldn’t have changed my mind. If you’re developing with Meteor.js, you won’t encounter any major problems besides the lack of clarity in Blaze’s this keyword usage.

Perhaps you might feel the lack of scoped style in a large project. It’s something like an antipattern, but it just came to mind.

Blaze’s super simplicity. The absence of unnecessary hooks is a huge advantage for beginners. Especially experienced backend developers who don’t like frontend development are surprised by how easy Blaze is.

One of the most important things is state management; I wish ReactiveVar didn’t exist for that. I wish we could always use ReactiveDict. The modular use of the state is also great. I would have liked to see distinctions like Mutations and Actions, but it’s not that important.

Also, having two risky but great plugins like Tabular and Autoform is a huge plus.

The documentation is sufficient, but the lack of tutorials with several projects is a major drawback.

I don’t understand why SFC is important at all. What’s the point of scrolling up and down in a single file?

1 Like
8

Regarding progress with other frameworks, I wonder how important that would be. Some thoughts:

  • Performance improvements related to reactivity systems are doubling up on what Meteor has (or vice-versa) so you don’t really get to take full advantage of them unless you throw one of them away.
  • Hybrid rendering strategies tend to be gated by full-stack frameworks that don’t mesh well with Meteor out of the box and to replicate them in Meteor requires a lot of dev hours and taking on technical debt anyway
  • A lot of recent work in those ecosystems seems to be just reinventing things that Meteor had anyway (RPC, data syncing, code splitting, etc)
  • Another load of work has just been in gluing their communities back together after breaking changes (React Hooks adoption, Vue 3 rollout, Svelte 3 and Svelte 5 rollouts, etc). For Meteor, that’s the Meteor v3 version bump (and MDG → Tiny transition).
  • There’s also many high quality multi-framework libraries with vanilla JS cores like Unovis, heck there’s even a vanilla JS shadcn-clone (Basecoat) if you want it
  • There’s always going to be something new (e.g. Remix v3), and as people have pointed out some of that new stuff seems eerily familiar (see graphic at the end of this blog…)
  • There are probably rendering strategies that Blaze might be missing out on (unsure, I’m a bit of a tourist to Blaze)
9

Fully agree with Jan. Yes, I could switch from Blaze to the latest Svelte version but would be benefit be enough given the huge amount of work and the fact that our frontend is a ElectronJS app?

I rather spend crucial time on any other part of the app where it has a much higher impact (also on the financials of my company) than to run after every “pig that is driven through the village” as we use to say in Germany.

1 Like
10

Hi everyone,

I mostly agree with what @guncebektas said: for me, Blaze’s biggest strength is its simplicity. Not everyone wants (or needs) the more complex patterns/syntaxes from other frameworks, and that’s totally fine.

On a more personal note: I actually like separating HTML, CSS and JS. That’s one reason I’m not a big fan of JSX + utility-first styling (e.g. Tailwind). Again, purely personal preference — I know many people love it — but I think it’s important to keep space in the ecosystem for different ways of working.

Meteor + Blaze was the first stack I learned after my career change, so maybe my heart is speaking a bit here, but I don’t see myself throwing Blaze away without at least trying to improve it. Even if Blaze ends up being a “smaller” project compared to React/Svelte ecosystems, it’s still extremely valuable for certain profiles — and honestly, even in its current state it still satisfies me.

In fact, I started two projects in the last two weeks (one of them a fairly large B2B SaaS), and I chose Meteor + Blaze again. Maybe I’ll regret it later, but it’s the stack where I move the fastest.

Because of that, my personal priority would be to modernize Blaze technically first, with minimal or no visible changes for end users:

  • progressively remove/replace the remaining jQuery-based internals
  • move packages/tooling away from ES5 toward modern JS (ES2015+), better build tooling, and a cleaner package structure
  • reduce legacy/debt and make the codebase easier to reason about, test and maintain

To keep the discussion actionable, I’d personally see a 3-horizon approach:

  • Short term: focus on “invisible” modernization + contributor experience (review/test the ongoing jQuery-removal work, reduce ES5/legacy dependencies where possible, strengthen basic tests, improve repo/docs so it’s easier to contribute)
  • Mid term: modernize the foundation without breaking user-facing APIs (cleaner package structure/toolchain, dependency updates, refactors of proven core packages while keeping behavior stable)
  • Long term: explore optional modern capabilities (SFC/single-file templates, better state ergonomics, expressions, tooling) in an opt-in way, ideally with a gradual migration path so large Blaze codebases can adopt changes safely

One more thought before getting too deep into implementation: it might also be worth stepping back and asking why people prefer other frameworks today. Maybe a Blaze “renewal” is also an opportunity to borrow the best ideas from each ecosystem (developer experience, tooling, patterns, ergonomics) — while still keeping Blaze’s core philosophy of simplicity and tight Meteor integration

Once we’re back on a clean and modern base, we can then tackle bigger evolutions (SFCs, expressions, state improvements, etc.) with much less risk

5 Likes
11

Thank you all for your feedback so far, as you can see there are many perspectives and lots of things to be done.

@dupontbertrand I like the stages short, mid, long as they par with most of our development cycles. I also liked your idea of providing the LLM.txt to Blaze as you pointed out here How can Meteor position itself for the LLM age? - #11 by wreiske

Incorporating the inputs from others here, we should focus for now on short term improvements that won’t break existing setups at all:

  • agents support via LLM.txt but also via various GitHub agents (How can Meteor position itself for the LLM age? - #11 by wreiske)
  • get rid of es5 (as far as possible)
  • review, test and merge the existing PRs (including the jQuery drop and the performance improvements)
  • update the documentation to vitepress and optimize the ci for automatic page builds
  • sketch out even more the current architecture and online documentation to be well prepared for future refactoring or even breaking improvements
  • there are still some bugs reported in the issue list that need people who reproduce them and propose at least a potential solution idea

the big question

Who volunteers for these things?

  1. We need multiple people for one PR because we need to make sure, that even if tests pass, there is no breaking change in our setups (which means missing test coverage).

  2. I need someone who is willing to run their debugger hot and find the root cause of the bugs, reported

  3. Someone needs to review PR code (at least 1 person, optimally 2) together with copilot

  4. Of course people need to write code but for now I would opt to complete current PRs plus the agents stuff

  5. I need at least one more person helping me with migration of the website, I am quite deep into vitepress but is lots of chores to be done, even with agents as we need still to manually read through and check if information is still valid

1 Like
12

I can open a MR with the help of Claude and reviewers covering these phases :

  1. Tooling + tests
    Add eslint + prettier to the repo, verify all tests pass before touching anything

  2. Remove all external npm dependencies
    Replace the 4 lodash packages, remove uglify, and replace underscore references with native JS. Then 0 Npm.depends across all Blaze packages

  3. Remove JQuery (Finally)
    Rewrite dombackend.js to use native DOM APIs, WeakMap -based teardown manager instead of $.event.special , addEventListener instead of $.on() , querySelectorAll instead of $() , etc.
    This alone saves ~90KB from the client bundle

  4. ES5 => ES2015+ syntax
    var to let/const, prototype to class, arrow functions, template literals etc…

  5. api.addFiles → api.mainModule + ES Imports The most structural change. 7 packages still use api.addFiles with implicit globals. Migrate them to proper ES modules following the dependency graph, while keeping the public API (including Template[name] global access) stable.

  6. Keep backcompat.js as-is (zero cost, breaking to remove), keep the deprecated ui meta-package, update TypeScript definitions after all changes.

  7. Fill coverage gaps (3 packages have 0 tests), build a showcase test app covering routing, reactivity, events, lifecycle and edge cases, plus a benchmark suite to measure render/teardown/memory performance before and after each phase.

All of this is pure internal refactoring, zero breaking changes, zero new features, zero changes to the end-users, except a lighter bundle.
I’ve already audited the full codebase (well Claude already audited it) (~14K lines across 16 packages) Happy to split this into 7 separate PRs — that would probably make reviews easier and give us solid foundations to build on. What do you think?

2 Likes
13

Sounds good (if all tests are green), but I think you should also audit the code yourself before pushing PRs.

14

Of course :smile:
Claude mostly helps me with repetitive tasks like global find-and-replace and that kind of stuff. Then I do a review pass, and of course we go through testing/performance before pushing anything :+1:

But for example, points 2 and 4 require very little attention from me IMO, and Claude can handle them just fine without needing much help from my side :grin:

1 Like
15

@dupontbertrand regarding prettier and eslint - they will get us into trouble if we still have es5 packages installed. That is - either they will break things that are working but are considered not good practices or they pollute pull requests with their changes, distracting reviewers from the essentials of a PR.

In that sense I also like to provoke some more discussion as we are progressively adapting biome in meteor community packages and it is the much better tool chain in my opinion. However, getting rid of es5 must come first of we want to keep clean PRs

16

Ok I will open a PR with ES5 => ES2015+ syntax then :saluting_face:

1 Like
17

Hello team, I’ve opened the first two PRs: ES5 → ES2015+ and removing all lodash dependencies. Feel free to review them here (Converts var to const /let , arrow functions, template literals, destructuring, etc. across all packages. No API changes, all 416 tests pass :+1: ) and here ( Replaces the 4 lodash micro-packages lodash.has , lodash.isEmpty , lodash.isObject , lodash.isFunction with native JS equivalents. Goes from 5 Npm.depends blocks down to 1 -only uglify-js remains in spacebars-compiler. All tests pass)
These are non-breaking refactors- purely internal changes with no impact on the public API. Reviews and feedback welcome! :saluting_face:
Claude is currently reviewing the JQuery phase, going to be huge => First remove JQuery from blaze itself, then remove JQuery from the test :grimacing: You can check the plan here Feedback welcome as always :smile:

4 Likes
18

Amazing to see this working group front giving results <3

3 Likes
19

Big PR… :drum: The “dual DOM backend”!
If your project has jQuery, everything keeps working as before. If not, it switches to native DOM methods. Long but interesting read right here with exaplnations, and metrics!
S/O to Claude :smile:

2 Likes
20

vive la france :fr: :baguette_bread: :wine_glass: :duck:

1 Like
21

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 ?

1 Like
22

Your brain is turning into mush. STOP IT!

24

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

25

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.

26

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:

2 Likes
27

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