Blaze Next - Vision, Ideas, Tasks etc

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.

2 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?

1 Like