Blaze Next - Vision, Ideas, Tasks etc

blaze
1

Hey community,

today was the first Blaze user group meeting (we keep them organized in a separated thread).

I did a small presentation on the topic, which you can watch here: https://www.youtube.com/watch?v=wDS9R2tL7yo

I opened this thread in order make the vision, topics and tasks collection a community effort beyond the “closed circle” of the meetings.

Let me summarize the presentation topics:

State of Blaze

good

  • Stable and predictive
  • 100% Meteor integration
  • Works well with many npm packages
  • Scales „technically“ from simple to complex
  • Good legacy browser support

not so good

  • Lacking modern features
  • Future of Meteor integration?
  • Future of npm packages integration?
  • Scales not so well in terms of manageable code

Old Issues and technical dept

Some packages still at some ES5
Package structure makes it very complex to understand
Backend is built on top of jquery methods (there is a PR ongoing by @harry97 but we need people to review, test and help to improve)
Async integration was an afterthought (see @radekmie 's blog on the amazing effort for Async integration)
Website feels like a separate thing… (and is using an outdated tool)

Missing Modern Features

  • No teleport
  • No builtin State
  • No single file components
  • No expressions {{#if foo && bar > 0}}…{{/if}}
  • No IDE support beyond some outdated plugins
  • No integration of modern tooling

Our mission

  1. Create/refine our vision for Blaze Next (today)
  2. Do some research, create tasks / todos
  3. Build a roadmap together (triage, voting)
  4. Work on tasks
  5. Start next cycle from 1.

Our Vision?

  • Future capabilities
  • What is a must?
  • What is nice to have?
  • What must be changed / removed?

Topics

I would really love to hear your opinions / input on the topic and if you are willing to join the user group.

5 Likes
2

I wasn’t able to attend, but it seemed like it was productive. I wanted to comment on a few of the items.

  • No builtin State

I strongly agree with this one. I used to enjoy using frozeman:template-var, which removed some of the boilerplate and made state simple. Kadira/Monti APM use flow components, which have a similar api.

Though reactiveVar/reactiveDict is a little more verbose than in other view libraries since you have to use set/get. I think there is a lot of potential to build state on top of proxy, as vue and svelte have moved to. State could then be initialized to instance.state = reactiveProxy and used as a normal object. I was thinking about building this, but I started migrating to svelte instead.

I think the common term is single file components (SFC), though flare called them single file templates instead to match the term Blaze uses.

These tutorials created a wrapper around blaze (it compiled the flare templates into a plain blaze template, which blaze then compiled). The design for the single file templates I went with wasn’t great since I was more focused on the tutorial aspect and learning than building something well designed. But it showed what is possible without modifying Blaze itself.

No expressions {{#if foo && bar > 0}}…{{/if}}

Part two of the Flare tutorial implemented js expressions: Implementing Flare, Part 2
It works with vanilla blaze. It might be more complicated to implement it directly in Blaze, but in Flare we extract the expressions into helpers and modify the template to call the helper.

Though you can’t build this without having breaking changes. For example, the comment tag ({{! this is a comment }}) starts with !. There are also valid js expressions that start with ! (for example: Account enabled: {{ !user.disabled }}, or {{ !description ? 'Add description' : description }}). There is no way to know if these are a comment tag or a js expression, so you have to break something (flare decided to not support comment tags in flare files). There’s a few other features and syntax in spacebars that cause similar difficulties.

I think it makes sense to build this as part of single file templates. You can make all of the breaking changes you need in the design of Blaze and state management, and there is a clear migration path projects can do gradually. There’s also some syntax improvements other template language have made, that it would be nice for blaze to do too (the main one is replacing {{ with one {.

I am finishing a redesign of Monti APM that switches from Blaze to svelte, so I’m no longer using Blaze, but I would be happy to be involved in the discussions on single file templates.

Another topic I would be really interested in is how Meteor packages can provide UI elements that can be used in any Meteor app, without requiring an app to load two view libraries, or the package to re-implement the components for multiple libraries. For example, the accounts-ui, zodern:pure-admin, zodern:aurorae, dev-error-overlay (I used direct DOM manipulation with it to avoid this issue completely), etc. Would it be possible to compile a blaze template (maybe only a single file template) to web components? Or have a minimal runtime for these components in apps that don’t use blaze, or are there other solutions?

4 Likes
3

(Apologies, posted this in the wrong place and hadn’t read Zodern’s comments beforehand!)

Re Blaze 2.0 3.0 Next, it would be interest to know how much Blaze has been monkeypatched or similar by downstream consumers and other packages, and how much Blaze could be “cut down” without breaking. Might be worth proposing the “dream” version (similar to Jan’s slide of “missing modern features”) and then seeing how much reality is going to make that unrealistic.

Re SFCs, syntax and inline expressions, it would be interesting to see how coupled the templating system is with Blaze’s rendering functionality. Inspiration for modernisation could perahps come from other templating engines and syntaxes like Adonis’ EdgeJS. Agreed though that if you had SFCs then allowing arbitrary expressions wouldn’t be as big an issue but then rendering in loops is still more convenient when you can do arbitrary expressions. You’ll just be at risk of breaking compatibility since you might need to ban certain syntactic patterns that used to be used by spacebars.

Backwards compatibility seems like a huge benefit.

Agreed that docs (I’m assuming especially API docs in this case) are still necessary. Types are a big trap for both ignoring docs and tests (guilty…).

4

Thanks for the update.

I think the one thing that will hold progress back for Blaze is older packages, like the ones that still use ES5 or have dependencies on old versions of jQuery, _underscore etc.

Remember that our progress is always restricted by the slowest moving component, or in this case, the “oldest” and most “frail” in that sense.

So I’d tackle that first to modernize before tackling new features.

Just my two cents worth, I’m personally looking forward to Blaze being developed further! Thanks to everyone who contributes to this.

1 Like
5

Personally, I think it’s time to abandon Blaze. React, Svelte, etc, are just so far ahead. We are talking like 5-10 years of progress with well funded teams.

When I’m in a Blaze codebase, seeing html/js/css split across three files is just painful. Not being able to call variables directly into the component (instead, having to expose via helpers) is painful too. Plus, you don’t get SSR, etc.

I prefer the idea of Meteor becoming something like Next.js/SvelteKit, and IMO it’s better since you do have an option to swap view layers, more flexibility on architecture, etc.

If I had to choose between Meteor doing something like SSR support vs Blaze enhancements, I’d choose the former.

6

@msavin for new projects I agree but as I stated at the beginning of the recording of the meeting - the primary purpose is to keep Blaze up to date with Meteor’s ongoing development so users with existing (large) codebases don’t need to migrate off of it.
For some projects it’s just not feasible to switch frontends.

1 Like
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