I use Blaze for all systems I have created. Very simple, easy and efficient. So you don’t need a lot of packages to do a simple web interface.
4 Likes
I love React. Makes it easy to work between projects since I also use React Native (Expo).
1 Like
I appreciate both, but if I were the decision-maker, I’d choose Blaze. It’s incredibly straightforward—you don’t need to get bogged down in the details. With simple state/prop patterns and two rendering APIs, you are writing HTML and SASS. That’s it.
When using Blaze, Tabular and Flow Router are my go-to packages.
3 Likes
In my experience Blaze is very simple and the easiest to learn. But when you want a modern infrastructure and features, it is outdated and inadequate. Svelte was a good alternative for me here. I prefer Svelte because the syntax is similar to Blaze and it is simple to learn and easy to use.
1 Like
I still love Blaze but I’d always prefer Vue 3 over React tbh
If you look at tools like Next.js, they position themselves as “The React Framework for the Web”. I’m thinking that Meteor would be much better off marketing themselves as a React app engine than anything general.
This has been attempted in the past, see Add Meteor.js as popular alternative to Next.js in the new React docs
They basically denied 
I will probably be with React for the foreseeable future, but I want to look into Solid as that one seems to be a bit more aligned with what Meteor is doing. Plus on their community team there is a member of the Meteor community.
These are problems that if addressed could provide more reasons for people to pick Meteor in the first place
What would you consider modern infrastructure and features that Blaze currently misses? That would be a great input for the next major efforts in Blaze.
3 Likes
I had a similar experience and made the switch from Blaze to Svelte some time ago. Svelte and Meteor make a great pair.
Svelte is probably most in line with the ethos of Meteor of making the complicated simple and its focus on productivity. I would encourage anyone who isn’t married to React to take a look. I wrote about my experience with the switch here:
Having said that, one of the great things about Meteor is that you can plug in whatever UI framework you like.
I think this cuts both ways. If you position yourself as a React app engine, you go head to head with Next.js, Remix, etc. and make people who aren’t fans of React feeling that Meteor isn’t for them. You also sign yourself up to support features like React Server Components which come with a complexity that most apps don’t actually need.
IMO, Meteor’s marketing should be focused on simplicity and productivity. Bring your own UI framework. Get things done.
6 Likes
Just to throw in some general response to the comments;
I think in every way, modern front-end tools are superior to Blaze:
- For HTML templating, you have more advanced stuff where you can just call your JS variables instead of defining a helper for everything
- For CSS, you have automatic scoping of CSS to your component, which is a huge assist on larger codebases
- For JS, you can write everything inside of one function and have it be accessible to all your HTML and CSS
Considering modern frameworks can do it all in one file, with much less code, and run faster, it’s just superior. And if Blaze tries to get to that level, it will lose its simplicity.
Let’s not forget stuff like HMR, SSR, code splitting, etc, that works great in all other frameworks.
Blaze is great for beginner devs who have an HTML/CSS/jquery backgrounds but that world is long gone now.
There’s a ton of Next.js-type frameworks now, but they are all built around the SSR model for content websites. Meteor can differentiate against all of them as a real-time SPA engine, which is a fundamentally different way to build on web.
Trying to cater to everyone is a common business mistake, in the end, you end up catering to nobody, which is where Meteor is right now. Nobody knows why they would use it. There’s nothing on the website that seems unique.
4 Likes
In my opinion the benefits that differentiate Meteor from other frameworks is the data layer (minimongo, pub/sub, RPC) coupled with the accounts system. None of said features require in any material way a tight integration with the view layer. Quite the opposite. Meteor is able to provide its features to any view layer with not very much code at all. Instead of trying to pick sides in the never ending view layer wars (and then dealing with the consequences thereof), Meteor would do well by just staying agnostic on the matter.
5 Likes
I agree, the tight coupling of mongo/pubsub/rpc/accounts is a big part of what makes Meteor so great, you can essentially run a mongodb query on the client, everything is abstracted down to the database, and its automatically real-time. That’s an insane pipeline.
However, looking at the website, you would never know about it.
Positioning it as a React framework would just help get more people onboard, it’s like >90% of market anyway… capturing a bit of that would be a lot bigger than Meteor’s marketshare today probably
1 Like
That’s exactly why Blaze could be killer. Instead of being backend agnostic like every other UI tool it has the benefit of being built by the Meteor team. They control the whole stack, that means they can make any little optimization that they can think of. It’s like Apples ecosystem, on paper every product is underpowered relative to their windows and android counterparts, but their ability to optimize across the entire stack allows them to launch products that outperform (in some cases) their competitors.
[quote=“msavin, post:17, topic:61996”]
- For HTML templating, you have more advanced stuff where you can just call your JS much cleaner. I want as little logic as possible in my UI. What ends up happening in react as display values get more complex is you put the computation into a function. That’s just a helper.
Personal preference. Scoped styles are nice in the margins when this component really needs to look different from every other component but are a pain when you actually want to use the cascade. Reading through the updated CSS learning guides, CUBE CSS, and Every Layout has drastically changed how I write CSS over the past few years. My stylesheets have become smaller, easier to reason about, and more modular. I find myself reaching for tools like Svelte’s scoped styles and Tailwind much less.
Fair. Can’t argue against this other than my previous point of I hate JSX
This isn’t specific to React and could be added to Blaze
Agreed which is exactly the kind of baggage Blaze doesn’t have. It only has to work with Meteor
1 Like
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.
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.
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
Here’s the translation:
"If I need to give an example, the first things that come to mind are:
2 way binding.- Being able to perform simple JavaScript operations, e.g.,
{{#if foo || joo}}. - 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."
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
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