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
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
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
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
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
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
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
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
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:
-
{{luxon createdAt}} that will give you a “time ago” or “time until”
-
$eq, $gt, $lt, etc.
-
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
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?!
@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
There is also reactive-dict that doesn’t get much love.
4 Likes
We actually use reactive-dict everywhere, I just used reactive-var in the example to keep it minimalistic
2 Likes
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
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
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
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
Blaze perfectly runs offline, what issues do you experience?
@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