Where I think Meteor is doing wrong with Blaze

core
1

Talking to some Meteor developers and I am noticing that people are not really liking the idea that MDG is downplaying Blaze. And I completely agree.

The point of Meteor is that it is an opinionated framework, so it is bad when they loose their opinion. :slight_smile:

This is why I like Django. In Django they are sticking to their templating language. You can use some other, if you want, but they have their own (Django template language). And if you do not like it, then you can go and use some other framework, or just another templating language. And this is what Meteor does not get it. What it means to be an opinionated framework and why that is Meteor’s main feature. (And there will always be people who do not like that.)

People chose Meteor because of what they have decided on. And if Meteor moves away, then Meteor looses people who chose it for those particular reasons. We chose Meteor so that we could have a stable ecosystem over unstable do-everything-you-want ecosystem of node.js. We leaved to Meteor to make some design decisions so that we can be assured they will stick and we have a stable base to build upon. That is that main reason why to choose Meteor over some other approach. Not because all design decisions are the best, but because they are opinionated and thus look like they will stick. But now you are destroying that trust. And that is the biggest problem. Not the technology. But trust.

It is like Meteor middle-age crisis. The good sides of Meteor limits some aspects, but if you start changing those to address the bad sides (and there are always bad sides, things are a trade-off), then you will lose those calm group of people enjoying it. Maybe to attract new people. But you will get a divorce first. Before you can get a new (more?) attractive group of people. Will Meteor then switch technologies every time there is a more attractive technology developed by somebody else? Yes, it should support it, but the core should be kept getting resources and love.

Meteor should support both Blaze and React, and definitely keep developing Blaze. It is not like that in web any given technology was a clear winner. There are pros and cons of everything. Blaze was what get people onto Meteor. Not just because of performance, but many other good design decisions which are different from React. And then there was a vocal group who wanted React. But in meantime people who liked what there was already stayed quiet.

Look, see React packages have only 321 and 900 stars. Not much more than unofficial Blaze Components (251). Official React packages has 10k installations, Blaze Components 4k. Just imagine what it would be if Blaze Components would be more promoted if people want components (my guess what is the most important feature of React).

This to me really feels like Jinja vs Django templates discussion. Where there was always a long debate in Django community that Django should switch to Jinja: it is more performant, you can write expressions directly inside templates, and so on. Gladly, Django didn’t change but kept developing Django templating language, which allowed ecosystem to count on that and grow. They support other templating languages though, for those who really want it.

From docs:

The Django template language is Django’s own template system. Until Django 1.8 it was the only built-in option available. It’s a good template library even though it’s fairly opinionated and sports a few idiosyncrasies. If you don’t have a pressing reason to choose another backend, you should use the DTL, especially if you’re writing a pluggable application and you intend to distribute templates. Django’s contrib apps that include templates, like django.contrib.admin, use the DTL.

(One old comment of mine as well.)

44 Likes
2

I believe this is largely addressed by my answer from an earlier AMA on crater.io, and I think the conversation should be framed in these terms.

Reposted below:

Answer to Blaze question on crater.io

https://crater.io/comments/ucDz7fibgDcJqHtFu

Many of us want Blaze 2.0 and not Angular or React. Is MDG committed to continuing the development of Blaze? If so, how? Thanks!

TL;DR: I think the best thing to do is probably build Blaze 2.0 on top of the React rendering system to get a nice developer experience while taking advantage of new tech like React Native and the React component ecosystem.

Blaze is a very interesting part of the Meteor platform, from a platform point of view. Let’s look at where we are now. Here are some of the benefits of Blaze:

  • Blaze is super easy to develop with - you get templates that look just like normal HTML, but behave reactively
  • Blaze integrates seamlessly with Tracker-enabled data sources like Minimongo, ReactiveVar, etc
  • Blaze works well with external JavaScript libraries, like jQuery UI or basically anything you pull off of the internet

These are all awesome benefits to have out of a frontend framework. I personally had a super tough time becoming productive with Angular, and Blaze was much smoother. However, even after a few hours of development I discovered that Blaze has some issues as well:

  • Data context instead of a more sane scoping model or control over inheritance, like Angular, React, and Vue.js have
  • Difficulty in operating on higher-dimensional data because of the way #each interacts with the data context (we have somewhat improved this with the new ‘each-in’ and ‘let’ block helpers in 1.2, but it’s still not ideal)
  • Performance issues when too much stuff bunches up into one Tracker flush cycle (you can see this in many issues on GitHub)
  • A fair amount of boilerplate to achieve encapsulated or extensible components (this can be mostly fixed by using Mitar’s Blaze Components package, which is similar to what I would have built to solve these issues)

Now we’ve established where we are. The question is, what should we do from here? One option is to invest more in Blaze to fix the above issues - some of them are harder to fix than others, though; I haven’t yet heard any great ideas for tackling performance since all of Blaze is built on top of Tracker.

However, even if we spend time investing in fixing all of the present issues and bugs with Blaze, we still aren’t in an optimal place because we haven’t even considered the things we could add. Let’s think of some of those:

  • Decoupling the refresh and render engine from the DOM, to achieve something like “Blaze Native” - given new technologies like NativeScript, React Native, and Angular 2.0’s integrations with them
  • Making Blaze a standalone thing so that we can expand the ecosystem of Blaze components beyond that of Meteor developers. Given that Meteor requires a buy-in into the whole data stack, the usage of a framework that is not tied to a specific data system will always be higher than one that is; so if we want Blaze to be a sustainable thing then we need to push on this angle more
  • Creating build integrations or NPM packages for compiling Spacebars, the templating language

So when we consider what needs to be done with Blaze, we also need to consider the long term implications of the above points.

The question for me is - how can we get the most of the benefits above, with the least amount of work? I can’t imagine a world where that answer includes building every single one of the above things from scratch here at MDG.

If you look at the points above in detail, then squint a little, and consider the resources we have available, I think you’ll come to the same conclusion that I have:

  1. Blaze as it exists now works for some variety of apps, and there might be small improvements and bug fixes we can make for long term support
  2. If we can combine the awesome developer experience of Blaze with the ever-improving technology of Angular 2.0 or React, we’ll be in a really really good spot

If we can spend time building a great developer experience, integration with Tracker/Meteor data, and a seamless build system, and just ride the wave to get native UI, a huge ecosystem of available components, improved performance, and more, I think we’ll end up with something better than what we have in pretty much all respects, with much less work.

I wonder how Blaze being the core of Meteor got lost and MDG prioritised React and Angular over Blaze.

A lot of this stuff has been mentioned above, but the way I like to look at it is - what’s the most important thing that Meteor brings to the table? I don’t think it’s the underlying rendering engine of Blaze. It’s the user experience and developer tools around it, the data system, one-step deployment, mobile builds, and a single tool to combine them all. So let’s focus on those.

Let me add a disclaimer: This is mostly my own personal opinion and analysis. Let’s have some more discussion about it.

6 Likes
3

“Meteor should support both Blaze and React,”

So it should be opinionated but it should have two opinions?

:wink:

2 Likes
4

As a separate reply, so it’s not lost in my answer above:

This is a large part of the point of the Meteor Guide - to act as the opinionated part of the framework for people who don’t need or want flexibility. But I think it’s good for the core framework itself to be as flexible as possible.

1 Like
6

May I chip in with our real happiness in coexistence of blaze and react?

This “opinionated” at its top :slight_smile:

7

My post here on the forum was mostly why I disagree with your @sashko Crater/Gist post and why I think that the positions presented there are harmful to Meteor and Meteor community. So that post cannot really be an answer to my post, because then we get into the loop.

Let me add a disclaimer: This is mostly my own personal opinion and analysis. Let’s have some more discussion about it.

It is not. It is visible that Blaze is not getting any love anymore and that things have been dialed down. The saddest thing is that while that is happening, MDG does not seem to even realize they made a conscious decision which has real consequences. Deciding not to do anything anymore with Blaze is still a decision. But I am not sure how aware you are that you made it. At least there was no blog post about it: “We are stopping development of Blaze”. Which is what has happened.

This is a large part of the point of the Meteor Guide - to act as the opinionated part of the framework for people who don’t need or want flexibility. But I think it’s good for the core framework itself to be as flexible as possible.

I see that you still do not get it. :slight_smile: The Meteor Guide will not allocate resources to continuing Blaze development. Thus it is not opinionated in the way frameworks are. Opinionated framework means you are putting resources into those opinions. Opinionated book means that you are claiming one option over the other, but that is it.

Also, it should be flexible, of course. Django is also flexible and you can use other template engines. But resources are clearly allocated in developing and maintaining Django template language (DTL), and hooks to support other languages. Recently, they added also official Jinja support. In this way it is similar to Blaze and React situation in Meteor. But, they are still fully putting resources in DTL. They have not replaced DTL with Jinja. Because ecosystem too much depends on DTL.

13 Likes
8

My post is not about this. My post is about MDG deciding to slowly back off from Blaze. Of course we should support coexistence of Blaze with other technologies. That was one of design goals of Blaze (to allow working with jQuery plugins, for example). That is great. And good patterns how to make them working together are also great.

4 Likes
9

What I am saying is that there is a quieter group of developers who are observing this fiasco with Blaze and React and how MDG started responding to hype. If we wanted hype-based ecosystem, we would stay outside Meteor. We do not need Meteor for that. What we need Meteor for is a stable ecosystem, a stable base, even if it is not ideal, on top of which we can build other stuff. If the base is moving all the time we cannot do that. We should have trust in the base.

Have you made any survey between developers what they would like to use? Are you sure that React is not just a result of very vocal minority? Maybe I live in a filter bubble, but from many Meteor developers I have interacted with, large majority still prefers Blaze over React.

21 Likes
10

I want a referendum. :slight_smile: Because I think MDG is not basing their decisions on data but hype.

13 Likes
11

LOL
I vote for mitar. I honestly believe React hype will die down.
Up on the barricades! Give Blaze the love it deserves!
Go BlazeComponents! (and Astronomy too, for that matter…)

(written with a smiley, but seriously meant)

10 Likes
12

prefers Blaze, but uses React … :smile:

Actually, more and more users are moving to React, more and more articles coming about moving to it. Even core community members as @arunoda moved. Have you seen latest Lightning talks, didn’t you see, how many people use React?

There is also a huge React community outside Meteor and the whole team, building and supporting it. Has Blaze even a team or 1 guy to support and upgrade it? Why the guys, who build it lost their love to it? I don’t know.

All in all, I am sorry to say, but there is no point in Blaze 2.0 because when and if it will come out, almost everyone will use React.

2 Likes
13

If the following were an official stance

TL;DR: I think the best thing to do is probably build Blaze 2.0 on top of the React rendering system to get a nice developer experience while taking advantage of new tech like React Native and the React component ecosystem.

where we know that we get to work with the familiar Blaze api’s and spacebars templating, wether or not it is react under the hood, and that we’ll get improvement both on the engine and the api, it would be bliss for a large base of developers.

Hype, wether it would stand the test of time, or not, will always be vocal and I think @mitar is spot on when he raises that question.

Where we stand now, we know, based on work by both @mitar and @arunoda, Blaze can be improved upon. But the nature of those improvements being way too central - as in belonging to core - creates a messy - as in hard to make a decision - situation.

I do appreciate @sashko’s thorough post, but unless it is an official position with viable actionable items, it is unfortunately not sufficient in calming down concerns such as this one.

React sure does have great advantages. But so does Blaze with its increadible simplicity. Perhaps if React were JS done in HTML rather than HTML done in JS, it would be easier to transition one’s mindset, especially those of the designers’ who can fairly easily pick up the spacebars syntax but are driven away by that of React’s.

Anyway, whatever it may be, I do hope we get an official, actionable response.

5 Likes
14

Gonna work with @debergalis to see what official/actionable items we can put on the table here in the next few days.

One thing is for sure for sure - it would be insanity for Meteor to do something that drops a huge majority of the current users on the floor. That means that whatever the next steps are, they will surely (regardless of the actual technology involved) involve a smooth transition path from what people are doing right now. It seems to me that this fact can be derived independently of everything else.

My goal with the long post above was to lay down some facts that are, in some sense, not reliant on any MDG decision making - they are just realities about the state of the world at the moment.

11 Likes
15

Thanks, foremost for driving the communication and keeping everyone engaged!

4 Likes
16

I think this is completely normal. There are always people who are trying out new things. And this is great. This is how you move things further. This is how ecosystem breaths.

But how ecosystem lives is that it has some stable base. So even if decision is to move to React, MDG should still invest at least 3 years of continued support (and improvements) for Blaze before stopping putting resources in it, for example. This is what stability means. Not that “let’s put resources into React” and now forget about Blaze. 1.0 version does not mean “we will not modify it anymore”, but also “we will continue investing resources into the API we made”.

I commented this already. See this:

While react support is great for innovators and maybe early adopters, MDG should cater also (to a larger) early and late majority who moved and are using Meteor because they thought things are stable and Blaze is here to stay. If you cut that community off now, and focus on innovators and early adopters only, then you are disappointing quite some people. Those who are not innovators and early adopters, but prefer stability and tested out solutions.

Yes, innovators and early adopters will be those which is good to provide tools for, to see what they can make. But you should still continue supporting others as well. Not just cut them off. This really bring loss of trust into the project. Not everyone wants to be on cutting edge. Many simply do not have time or resources to be. Once you convince your company that this is something your product should be based on and you work for a year on that, the last thing your boss wants to hear is, oh, they decided to change and stop supporting Blaze. That our bug or pull request we made will never be merged in. Because everyone else is moving to React. Everyone else might, but we are stuck with Blaze. This is why we chose Meteor in the first place and not some other technology.

That means that whatever the next steps are, they will surely (regardless of the actual technology involved) involve a smooth transition path from what people are doing right now.

I do not think transition is really possible because there will always be things which are possible in Blaze and not possible in React and you will have to drop some stuff or reimplement them.

I think a better approach is to continue supporting Blaze as it is and then leave to the community to decide through time by what they use. Maybe through time number of users of Blaze will be so low, that you can then remove it from core and leave to community to continue maintaining it.

So instead of trying to morph Blaze into React, a better approach is to keep Blaze and make it shine in areas for which is good (easy of use, simplicity, having a different reactivity model, interoperability with external DOM changes), while React does the same.

8 Likes
17

What about React/Angular2 native, built-in React/Angular2 browser debugging tools, etc? While we might be able to “keep Blaze”, it is already far behind other options in those dimensions. Who’s going to build the Chrome extension for debugging Blaze?

I think perhaps the recent focus on React is what turns the discussion to hype, but it applies just as well to Angular/Angular2, which are far and away more popular than any other option in the space.

3 Likes
18

100x this. Thank you for speaking up and putting this in writing.

To the extent that I’m hired by healthcare professionals and small businesses to deal with what they perceive as ‘tech heads’, and to speak in these forums on their behalf as a sort of lobbyist, I have to agree on behalf of a few dozen of those ‘quieter developers’ who aren’t regular contributors here.

From what we thought we were buying into 3 years ago during v0.5 days, and where we are now… well, I’m going to be generous by simply saying it’s been two steps forward and one step back the entire way. But fiasco may be appropriate also. (I’ve seen at least one project scrapped after over $100K was put into it’s development, partially related to MDG not accepting a PR related to the accounts management MongoId generation issue. These stability issues are costing some of my clients real money.)

Now that has been said, I’ll also say that I don’t think all is lost, and I think we’re very close to the end of the tunnel, and that all the pieces are in place to get the stability back into the stack (even if it’s been a year or two of wandering in the wilderness). peerlibrary:meteor-packages goes a long way to being able to create management pages for Release Tracks. And we just published the first release of clinical@METEOR to provide a stable, audited base for people building healthcare apps. I’m now excited about the prospect of redesigning the clinical.meteor.com Roadmap to use Mitar’s meteor-packages API. So all that is heading in the right direction; and I’m mollified and optimistic that things are falling into place.

However, I(we) do have quite a few questions at this point. In no particular order….

  • Are Release Tracks an officially sanctioned solution for building audited/stable ‘distros’ of Meteor? (They were vaguely communicated as such last year; but there’s not been much movement since.)
  • What is the monetization plan around Atmosphere?
  • Are we going to be able to rely on the Meteor PackageServer (aka Atmosphere) if we build out release-track specific functionality with the PackageServer API?
  • There were monetization plans around Atmosphere at some point in time. Are we going to billed a Pay to Play fee at some point in the future if we build on the PackageServer API?
  • What’s the status of tags and language fields on the Package.describe() API?
  • Will MDG consider PRs if we have needs around the Package API?
  • Are their any plans around incorporating Sideburns as a bridge between Blaze and React?
  • Are their any plans for auditing/migration tools using the Sideburns bridge?
  • What plans does MDG have for long term support of Meteor 1.0.3?
  • Are we going to get 2 year stable commitments to any release, like other open-source projects provide?
  • How does maintenance of a 1.0.3 stable-release relate to best-practices documentation vis-a-vis React integration?

If you could maybe also ask about some of those items, that would be real helpful for those of us who thought we were buying into a stable platform based on Blaze, rather than a bleeding-edge platform based on React. I’m actually optimistic that there’s going to be all sorts of benefits to running our own release track; and that it’s the solution to a lot of these problems. But it would be really great to have a little direction now that 1.2 is out.

ps. We’re looking at incorporating BlazeComponents into ClinicalMeteor. Still sorting out the CS/JS issues; but otherwise, everything that Mitar says is spot on, and applicable to our concerns. It’s very popular among the healthcare community to use higher-level languages to get first-drafts completed… lots of the prototypes we get asked to look over are done in Coffeescript, Jade, Stylus, etc. by local IT admins and analysts. They’re on the other end of the abstraction spectrum away from React.

7 Likes
19

Oh, that would be us with our Atom extensions for Blaze. Atom is built in Chrome. We have debugging tools, code highlighters, refactoring tools, Nightwatch/SpaceJam… and all of it is around Blaze.

6 Likes
20

Are they open source and/or publicized? I’ve never heard of these and I’m pretty sure I’ve been creeping on the forums since they started. These tools would be very valuable for the Blaze community!

3 Likes
21

I don’t think, Meteor is so mature to offer you LTS support. Lets take Laravel release - you can clearly see, there is LTS for 3 years. It has everything in core for you - router, ORM for a lot of DBs, validation, view layer, etc. So, you can come to your boss and tell him, this framework is safe to use for the next 2-3 or more years.

Until there will be such notes from MDG, you can’t expect LTS for any components.

You can expect that after half a year you will need to rebuild your app if you want to use the newest Meteor version and community stuff. Take the Iron Router - now it is dead, no one says it, but it is clear that it has no future. So you already need to transfer your routes, move auth and subs to template layer.

Blaze is working fine for a lot of people now, so they can use Meteor 1.2 with blaze for the next 1-2 years, it will work the same.

If you want to follow the early adopters/majority - switch to React now and use it in your projects as its future is already brighter (chrome tools, React Native, full Webstorm support, huge community not only in Meteor).

This is the choice and decisions you need to make before even starting to build apps with Meteor.

3 Likes