It’s do not think it’s one versus the other in React/Blaze. I can absolutely see the need for React style codebase. My personal opinion is that one codefile for both view and component logic is anti-pattern, but one can use view template extensions for React if that is the desired pattern. You can literally write code with the identical patterns in both, and all of the core javascript logic in your component methods would work in both Blaze and React (this is what we spend most of our time writing). And you can write equally bad code for both.
I agree! Blaze is amazing with Meteor. So much less to worry about because of how well they are coupled and built for reactivity. I am glad you posted this! I am not the only ones who can see the brilliance in blaze/meteor
5 Likes
I absolutely love Blaze. I absolutely love React.
I use the both together. I think they compliment one another very nicely.
I typically start the build out of my app in Blaze. Most view and list screens, menus, etc are ridiculously easy to slap together in Blaze. With Mocha, chai, sinon etc I can get decent test coverage too.
But then I might hit a complicated UX that requires more fine grained control and testability. So I jump to React and Enzyme to build out these parts embedded in a Blaze parent template.
I use the best tool for the job. Blaze and React work together beautifully. Depending on the project Blaze may be all I need. But React’s got my back when things get gnarly and I need a more powerful toolset.
4 Likes
This sounds like a great approach. I hand’t thought much of using the two together. Also to be honest I prefer to NOT use a VDOM. I have seen instances where the abstraction away from actual ViewModel causes dependency on it. In other words, the Browser only ever sees the DOM, so I prefer to work with something that is a close to that as possible, rather than the extended abstraction. It forces discipline I feel, and makes for a lighter DOM in the end.
For anyone here, I’m hoping to get feedback on my package I just published for Blaze. It is quite handy and powerful for maximum flexbility in defining Modal views for Bootstrap in Meteor/Blaze. I would like to put the finishing touches on it, and it would be great to get input from other devs. [ANN]: MasterModal - Giving back, fully featured bootstrap modal package
I too believe in Blaze and like it much.
But the question is fundamentally as I have understood it for myself not about what you like but what you build with it.
React was not that revolutionary but everyone’s got hooked by the grand Facebook behind it. And it became self-fulfilling prophecy because when many people believe in something it gets components/code/support/etc.
So, even if we consider Blaze as wood and React as bricks (though I do not think it is that big difference), both have their pluses and minuses.
But what you have built with them matters more.
3 Likes
I combine jade and blaze for my app. My codes become much more beautiful than ever
2 Likes
There’s nothing wrong with Blaze… or really anything. The only “problem” is if you can’t live with ignoring the “must use XYZ framework or die trying” crowd. If you can’t bring yourself to ignore that stuff, then yeah blaze has problems.
1 Like
And over 6 years ago this was done in handlebars. So yeah this is nothing new. It was what I first looked at about 3 years ago too.
I wanted to do a different style. Something a little more elegant than putting operators in quotes, and it has a nice ternary feel to it. I realize I should have made that more obvious.
[edit]
I’ll add that to the docs.
1 Like
I disagree with that it wasn’t revolutionary. As far as I remember one of the first talks where React was introduced to the public was entitled “Rethinking best practices”. The biggest difference between React vs other frontend frameworks at that time was that React favours immutability. Instead of mutating the DOM manually you basically re-render entire application with new data. React also popularised virtual DOM.
2 Likes
Actually I think the revolutionary part of react was it showed an implementation of web components without the need change browsers, specs etc.
Web component has been pursued for long time without any success until react, the immutability and virtual DOM are implementation details.
What real benefits it has brought on some of your real project vs Blaze? And at what price?
Concrete buildings bring speed of construction but they also damn cold compared to brick buildings.
I’ve used Blaze a lot with bootstrap, and yes react is slower to start with when compared to blaze and for smaller project it adds little value. But as soon as you want to reuse and abstract then react offers an API to build those components.
Furthermore because it standardized the way components are built, NPM got flooded with all kind of react components.
Ok, let us say there are 2 web calculators - one is built on immutable objects (React), another on mutable - (Blaze). What benefits immutable objects will bring:
- to end users
- to the team (e.g. speed of releasing version 2.0, etc.)
I am more from business side of development and prefer - how fast and reliable does bicycle go and not ‘look mom, no hands!’
3 Likes
I’m also looking at it from business side, we’ve built a large set of internal of reusable components, and dropped down the cost of starting new projects through heavy reuse. New devs don’t need to write tons of html, just pick logo bricks and assemble the UI.
However I’ve used Blaze for smaller projects and it’s super simple to edit and modify the UI. It’s not react versus blaze, it’s just that the concept of reusable abstract components is undeniably useful for larger projects due to reuse and complexity management which will ultimately drop down the cost and time to market.
4 Likes
Well said @alawi. I think even Vue fits in the spectrum without full overlap with Blaze/React
I have worked with React on projects that were too small/early for it. It is a lot more cost and overhead that needed in that situation.
1 Like
react is only slower to start with if you don’t use react regularly
1 Like
I agree about moving faster in React once you “get” it. Blaze also has it’s tricky edge cases (why is passing data down the chain in a loop so damned hard). I don’t even have a hot rodded IDE - just a mostly vanilla VS Code.