Is anyone still preferring Blaze over React?

community
41

Hello, I wrote util for modal or drawer management. With this util, I render a drawer contentTemplate with the data and options you specify at the bottom of the project with Blaze.renderWithData. Util allows me to open and close the drawer in any part of the application I want.

e.g. open:

    DrawerUtil.show(
      Template.atomsDrawer,
      {
        _template: Template.drawersMultiLanguage,
        _templateData: { _languages, _i18nData, _inputType },
        _title: _title,
        _iconName: 'translate',
        _iconColor: 'primary',
      },
      { isSubPage: true }
    )
1 Like
42

Hello,
We use blaze for a very large production app used by a lot of customer and this is working perfectly
I have started with Blaze, I will continue using it.

7 Likes
43

Can I just say, it’s great that we’re having this conversation as a community. Thank you @msavin for the discussion prompt!

Also a Blaze → React convert. Loved Blaze. It was great coming from a frontend background. HATED React, but then started learning a bit about it and, yep, I made the (painful) switch. The biggest different for me vs Blaze was the clarity of data context. In Blaze there’s a little too much “magic” in where the available data comes from and what is currently available given the current template, event.target, #each loop, etc.

Another “developer experience” type reason to choose React is that VS Code has syntax highlighting for it. It’s very easy to spot which part of the component you are in based on the language styling.

If I did have some feedback for the Blaze team to make it even easier: simplify the data context. Give the developer more clarity on exactly what props are available where.

Long live Meteor!

5 Likes
44

If I did have some feedback for the Blaze team to make it even easier: simplify the data context. Give the developer more clarity on exactly what props are available where.

Totally agree! I still get confused after many years of using it.

1 Like
45

no.2 solved with template-helpers package

1 Like
46

Blaze perfectly runs offline, what issues do you experience?

47

@msavin do we have access to direct downloads stats?

npm i meteor doesn’t work for most of the folks and they revert to installation via curl/wget

48

Can’t tell for sure, but looking at meteor-base numbers on Atmosphere can give a clue for total number of times Meteor has been installed

IIRC, NPM counts every installation as one - so every time you re-install your modules, etc, those are installs.

Meteor counts every package as one install, based on the appId inside the ./meteor folder

49

Fair measurement, but we don’t know if any of 2.9M “installs per appid” reached to production where download rate is 100x due to modern deployment practices.

I think meteor-node-stubs used only by Meteor Apps, and at least installed before meteor build and maybe during deployments giving us constant rate of ~24K installs per week on average during past year

We don’t use meteor-base instead we use meteor, webapp, and ddp directly, skipping other packages from meteor-base bundle. Looking at meteor package stats does it mean in 10+ years meteor was installed only for 3M apps?

1 Like
50

I just took a look at BuiltWith which tracks what tools different websites use:

Framework Live Websites
React 48,969,543
Vue.js 4,495,440
Nuxt.js 763,481 (???)
Firebase 226,194
Svelte 159,278
Next.js 52,517
Remix 27,866
Meteor 24,311

Nuxt.js blows my mind a bit… shows what a close alignment to Vue could have accomplished, and Vue was created by a Meteor team member. Remix also going hard here… it launched in 2021 but surpassed Meteor’s 10+ year legacy.

2 Likes
51

Not sure I do understand how BuiltWith is counting it here. Is Meteor basically Blaze or what? Otherwise, Meteor can be React/Vue/ etc - so I really struggle to understand what they mean by it.

1 Like
52

It scans almost all the websites and then detects the technologies on them - so there would overlap between them