Is anyone still preferring Blaze over React?

community
21

Meteor has no chance to compete with the resources of React, Svelte, etc.

Plus it’s a solved problem. Apple isn’t building an Instagram clone just because it’s popular on their platform. They even tried to embrace Google Maps and YouTube on the iPhone, before competition heated up.

Maybe 10 years ago, this could have been a good move, but today there’s too many good options, and it would be impossible to steal marketshare from them.

If Angular is dead now, what chance does Blaze really have…

If Meteor never existed, and we wanted to build something like it, I don’t think anyone would try to build it the way it is today.

The front-end tooling is just too good these days, and Meteor would have to go through a lot to catch up to it. The other alternative, if not to position as a React framework, would be to let anyone add it to their front-end framework. Otherwise, from a business perspective, it’s just too far behind and now too late to game.

22

To address this I think Blaze can be really forward thinking. It would be nice to see it adopt the declarative shadow DOM spec. This would allow every Blaze component to be a native web component that’s rendered on the server. It would open up some new possibilities for how Meteor could be used. For example, one could easily embed a Meteor application inside of a separate running application by sharing the application web component.

Oh and dump jQuery.

23

I don’t think Meteor would need to do a lot to catch up though. A lot of the tooling around React exists because React itself is so complex to use for anything but the most trivial UI cases. These are problems Meteor doesn’t have.

Also Apple invests billions into its Photo app and integrating social photo sharing throughout the the entire system. The instagram clone is iOS

1 Like
24

Here’s the translation:

"If I need to give an example, the first things that come to mind are:

  1. 2 way binding.
  2. Being able to perform simple JavaScript operations, e.g., {{#if foo || joo}}.
  3. Having an event mechanism for templates (like Svelte’s createEventDispatcher).

When I think about it in general, aside from the first point I mentioned, most of these have alternatives, which actually creates the structure of Blaze.js itself. This makes it feel a bit cumbersome."

25

That’s not quite what I said about coupling.

But more generally, we seem to have very different views on the subject. I fail to see how limiting Meteor to a specific view library helps in any shape or form improve technologies that are inherently separate from the view layer in the first place (there are only a handful of APIs that connect the data layer to the view, and that’s a good thing). Creating tight couplings between different technologies is mostly a bad thing in my book and should only be done if there really are significant technical benefits to be gained (this is seldom the case). But creating tight couplings between different technologies for no technical merits, but rather just for some hypothetical marketing purposes, is in my opinion just…not a good way to run a technical project, let’s put it like that in polite language. Let’s just agree to disagree here.

3 Likes
26

Well, let’s put it differently…

If Next.js started supporting 5+ view layers and diluted their marketing … would that be good for them? or is it better to double down on their strong alliance with the React community?

1 Like
27

Native view transitions and offline support would also be great for Blaze

1 Like
28

I use both Blaze and React in the same project - for simple stuff Blaze is fantastic. If I need to build out something more sophisticated I use React - of course you can do amazing things with Blaze but I’m just more comfortable with React once the requirement reaches a certain point of complexity.

1 Like
29

I think the idea of keeping the marketing, at least, simple and focused has some huge benefits. Easier to keep docs up to date, easier for folks to write tutorials, easier to help people on the forums, etc.

That said, I think it’s a mistake to look at the 90% (ish) market share of React and to say that in order to boost adoption Meteor needs to be the go-to React framework. The problem is that when the market is already 90% React, that means that 90% of developers already have a React framework they’re using productively. Telling them yeah, but Meteor is a better React platform is not a compelling enough story to induce a switch.

On the other hand, if developers are tired of React and are looking for a new front end framework, then they’ve already decided to eat at least some of the switching costs and are already in a mood to try out new things. That’s a much better environment in which to tell a “you should try Meteor” story.

The everyone-is-switching-to-React wave has passed, and it’s too late to try to surf it.

So what’s the next wave? I don’t know, and I’m looking forward to hearing what you guys think, but for now I think it’s important to agree that it’s not React.

4 Likes
30

Hmm, I’m still not sure haha - I think the web front-end paradigm has reached its peak, whether you do React or something else, these things are more of less the same now, and pretty perfect at their jobs

IMO, the next great evolution of these tools would be some kind cross-platform UI engine, but that’s going to be a struggle, every attempt so far has been a flop

If you look at Remix.js, it came out as a direct competitor to Next.js and looking at @remix-run/router compared to next, they are both doing around 6m downloads per week. If Meteor can do that in a year haha…

Meteor is very different from Remix/Next/SvelteKit/etc which can give it an advantage. If the dev already knows React, Node and MongoDB, it’s not much for them to try it for an app.

2 Likes
31

Just as an honest question. Why React and not Vue!? Is this really only because of marketing? I am working since a few years with React Native and I also work half time on a project using Vue and I think especially larger codebases are much easier to engineer with Vue than with React.

1 Like
32

Have to think more like a business person than an engineer here.

Imagine you can build an app for iPhone, Android or Windows Phone… which would you choose? Probably the one with the biggest addressable market.

1 Like
33

I think the biggest thing going for Blaze is the amount of integration especially when paired with Meteor packaging system where you get front and back end code lumped into one piece.

Am I too old or has everybody forgotten meteor-useraccounts?

The fact that you can spin an entire authentication system with all of the routes and UI in one go is unparalleled. Maybe if you compare Blaze’s features with other tools on the market it’d appear lacking but hey even if it’s I still would use it because it allows you to develop applications faster. I agree with what @acemtp brought up in Make Meteor great again

It’s about that tight level of integration that allows you to go much faster. It’s the sum of the tools rather every piece on its own. And that’s what made me choose Meteor and continue using it to this day. I hope Meteor continues in such direction.

Don’t fall in love with your tools; It’s never about the tools it’s about solving problems for users in a timely manner and I still cannot find a single user who can distinguish whether your application is built with React or Blaze or Fortran.

3 Likes
34

I prefer blaze to create the app but I prefer react to create low level components (dropdown menu, multi select, modal, …) but just because there a nothing as cool as shadcn.
If a shadcn blaze version was exiting I would definitely do only blaze

2 Likes
35

its AWESOME that its framework agnostic. this is the REAL niche you want to be in. its so plain obvious what Meteor is good for to us, and that’s what should be marketed.

7 Likes
36

Blaze is my go to for all my projects. I have a ton of custom handlebars helpers I have curated over the years that I use in all my projects to extend it’s functionality.

Special helpers like:

  1. {{luxon createdAt}} that will give you a “time ago” or “time until”

  2. $eq, $gt, $lt, etc.

  3. etc

Honestly the effort required to switch any of my projects over to something else like Svelte or React just doesn’t make sense to me…

I’m also someone who loves to move quickly and get an idea out of my head into a proof of concept. Blaze is BLAZING fast at allowing me to prototype and connect up mongo, reactivity, etc., with very minimal effort compared to others IMO… I like to move quickly or the motivation to continue hacking away will go away. Obviously a very personalized opinion, but it works for me and works really well for what I need to use it for.

4 Likes
37

I’ve always been curious how do you manage global store (or highly available data, or data where you need it) in Blaze.
Let’s say you have a modal window in a view which depends on variable let open = false. When open is true, the modal opens. How do you close the modal from a button deep inside a list in the modal. Do you use something like jQuery or Meteor Session?!

38

@paulishca For global state we use a globally accessible module with internal reactive variable:

export const AdminModal = {}
const state = new ReactiveVar(false)
AdminModal.show = () => state.set(true)
AdminModal.hide = () => state.set(false)
AdminModal.get = () => state.get() // reactive

import { AdminModal } from '/path/to/AdminModal'

Template.myCoolAdminPanel.onRendered(function () {
  const instance = this
  const modal = this.$('.modal-selector')  

  instance.autorun(() => {
    if (AdminModal.get() === true) {
      modal.show() // this is a bootstrap-internal method, yes we still use bootstrap :-D
    }
    else {
      modal.hide()
    }
  })
})

The actual trigger of the modal:

import { AdminModal } from '/path/to/AdminModal'

Template.adminModalFooter.events({
  'click .close-button' (e) {
    e.preventDefault()
    AdminModal.close()
  }
})

You can abstract this even further. Only disadvantage is that persistence requires another layer of implementation, as opposed to with tools like Redux.

3 Likes
39

There is also reactive-dict that doesn’t get much love.

4 Likes
40

We actually use reactive-dict everywhere, I just used reactive-var in the example to keep it minimalistic

2 Likes