I’m curious as to Trackers role in React. Will it ever see true integration, or will I have to buy into Redux to rerender components correctly? I love implicit reactivity, and really want Tracker to work 100% outside of Blaze…
2 Likes
@vonwao Whoa, whoa, buddy – that’s a bold claim!
I love Blaze thanks to:
- its extremely intuitive APIs.
- it’s “just HTML” with some template tags, and thanks to those tags being reactive, you get implicit reactivity and can code fluently in a completely natural way, without having to think about stuff like
componentWillUpdate. - the fact that I can achieve basically everything with its lifecycle methods, event system, and helpers.
- that I can make Blaze template act like really reusable components if I want to, thanks to features like passing data contexts, scoped reactivity with
ReactiveVar/Dict,template.subscribe(), andTemplate.instance(). - its concept of sub-components with
{{ > component }}.
I’ve been checking out React (with Redux) and Vue.js for a while, and I honestly cannot see the upside of using React instead of Blaze, except for a performance increase and potentially server side rendering. I’d love to be enlightened though!
Many of people’s arguments for React can be achieved in Blaze as well, if you organize your template code into components, which means
- think of how you pass data around – should the component be “dumb or smart”? Should it know about its dependencies and create subscriptions, or should it receive everything from an outer scope?
- think of the internal state of each component – are you causing side effects?
- think of what code that should reside in the component – is there too much of it in there?
I think we have all the tools we need in Meteor to create just as great UI components as in any React setup. All the mucking around with Redux stores and reducers just seems too abstract for me.
9 Likes
I agree with @johanbrook on this one.
I have built a rather large application on Blaze. I use smart file and variable naming, and considered organization to keep things maintainable.
I use Blaze components that built myself (without a package) and they work great. I can make a change to a component and the change propagates to all my forms.
I’m super productive as well. I can get a feature from concept to go in no time. When my clients have an issue, I know where to look even before opening Atom (the editor).
I’m dreading the new direction Meteor is being dragged. 
2 Likes
Ok, well you are free to use the tool that suits you best.
You proved my point, “extremely intuitive API… just HTML”, means it’s very friendly for beginners. React is a little less friendly for beginners, because it’s not necessarily targeted to beginners, it’s targeted to professional developers. Just like if you use a “professional” construction tool it will not be as user friendly as a consumer product. The same arguments was once made about Unix: http://arstechnica.com/civis/viewtopic.php?f=20&t=912937
Tracker and blaze components have problems, reactivity is not predictable, React has one-way flow and so it’s easier to understand and virtual DOM so it’s higher performance.
I’m talking about complex UIs with many components and subcomponents. That’s where blaze will hit it’s limits and React will help you most.
But you have to make the choice for yourself.
Also I agree that Redux is too complicated, I’m hoping Meteor or someone will come up with a better solution.
1 Like
Well, I’m all for progressive tech like JSX, but at the end of the day, it’s a technology invented by a company – not a world wide standard, like HTML. I think it’s too early to separate “newbs” and “pros” just by their knowledge of React/JSX.
Tracker and blaze components have problems, reactivity is not predictable, React has one-way flow and so it’s easier to understand
These things I’ve got problems understanding. Just like @aadams above, we’ve put in some time organizing our (I would say pretty large) Meteor app into well-defined components, and that’s been working out great for us. No one of my or my co-workers have had problems with “bidirectional data flows” or “unpredictable reactivity” after moving away from Session when that went out of fashion.
I’m talking about complex UIs with many components and subcomponents. That’s where blaze will hit it’s limits and React will help you most.
Yes, as I said, I’ve been building a pretty complex Meteor app with a load of subcomponents. Limits as in organizational limit, or performance limit?
I just don’t think one should be so quick to jump on the React bandwagon and drink the kool-aid. Add support for it in Meteor: totally. Throw away everything and buy into the Facebook stack: not so sure. I remember when every smart web person thought Backbone was the most awesome thing… 
I think there are a lot of great insights and opinions in this thread, by @aadams, @faceyspacey, and @mweststrate : Next steps on Blaze and the view layer (around post 465 and down).
3 Likes
I just don’t get this @vonwao, I have many templates with 50 or more Blaze components. On these same templates I have many level deep #if statements. I have conditional, multi-level validation on these components. On these same pages I have bar charts. Maybe 10 subscriptions, pulling in data from many different collections, time subscriptions, count subscriptions, joins. I have many calculations and logic too inside the helpers. These pages seem as complex as anything I did in C# and F# when I use using .Net using webforms and winforms. These pages are as complex as anything I’ve seen using the MEAN stack. This works, it seems relatively fast (I can’t compare to React), and I’ve have NO issue debugging or fixing bugs fast.
What walls did I hit using Blaze? What great doors will open for me using React over Blaze?
I don’t understand how you can generalize as much as you have. It almost seems like you’ve not really used Blaze in much depth.
1 Like
You’re contradicting yourself. You said react is only supposed to take 8hrs to learn and some basic concepts…now it’s meant for professional developers? There’s a big difference there.
1 Like
I totally agree with this. Blaze gets a bad rap from the lack of guidance and structure. As much as I dislike FBs saying of they aim to have the developer ‘fall into the pit of success’… they do so much more than Blaze. It feels like you get a shovel, flashlight, and a map and you’ll need good luck or experience to not make a mess.
Much like jQuery actually… you can write a mess but i’ve also seen some really nice SPAs written in just jQuery. However, they had lots of structure (Backbone has made me a better programmer comes to mind).
On a side note, everyone one in JS had been making messes with their UI with jQuery and then Backbone came along and created a paradigm shift in how we made UI. This was 10x better than most jQuery apps.
Anyway, I feel like that ship has sailed and there isn’t much time left to change Blaze so that devs fall into the pit of success.
With Iron Routers reactive routes and Session some legacy apps I made feel like playing whack-a-mole when maintaining it. Newer Blaze apps are much easier to maintain after adopting better patterns, making it more declarative and dropping Iron Router and Session.
I do hope that Blaze will be something that can be used for several more years, I would hate to see it just drop out of the ecosystem.
I’ve been checking out React (with Redux) and Vue.js for a while, and I honestly cannot see the upside of using React instead of Blaze, except for a performance increase and potentially server side rendering. I’d love to be enlightened though!
I think React is one of those things that looks horrible from glancing at docs or tinkering with for a few mins. You almost have to build an entire crud app with it to really appreciate the different way of thinking. Redux is 10x more so… almost impossible to grok from looking at readmes or even tutorials. I think Redux also makes more sense once you hit the edges of building a React app without flux and can then appreciate what it does.
I do wish Redux didn’t have all the ‘extras’. At it’s core it’s just a pattern like:
user clicks button
|
V
even handler gathers data from UI
and calls dispatch( buttonClicked(data) )
|
V
buttonClicked function prepares data and
does dirty work (send db reqs) and then
returns object which is returned in dispatch call above
|
V
a 'reducer' function takes old state and new object from above and
merges them together, returns what the new state should look like
|
V
UI layer listens to specific keys and updates if they change
That being said I still think Blaze is a great UI layer. It’s more important that users like your app and that you’re productive so you spend less time debugging and more time working on the real featues.
Here are some ‘patterns’ that were pre-react that helped me build better Blaze apps:
https://github.com/AdamBrodzinski/react-ive-meteor/blob/master/both/actions/post_actions.jsx
https://github.com/AdamBrodzinski/react-ive-meteor/blob/master/both/domains/feed_domain.jsx
The key is to decouple the UI and make things predictable for your future self and team.
5 Likes
I think if you do not like React and its quirks you can use Angular. It is nicely supported within meteor and has a bigger community than React. So if you do not like React there is Angular and lastly Blaze isn’t dead. There are projects that help you with Blaze like Blaze components etc.
I think people are just overreacting on the thread. React is not the end game of web programming. It has introduced a new way of thinking in web apps and many people appreciate and like it. If you do not like it there are tons of very popular frameworks present to suite your needs.
2 Likes
Jsx will only take 8 hours to learn. A simple react component with a simple render method.
1 Like
I guess you haven’t hit enough edge cases. It’s not about how many templates or if statements, it’s about the complexity, coupling between components, reactivity loops. Because react is one-way data flow you don’t have reactivity loops.
2 Likes
also it is really important how many people works on one app With Blaze and big app it is hell 
but of course it can be done.
This sounds so matter of fact. Are you saying there are situations on the UI in which Blaze simply cannot be used? If that’s what you’re saying, I’d love to hear these edge cases know about.
I believe firmly that Blaze can do everything React can, but I can do it faster with Blaze.
If you read what I wrote, I have interdependencies between components – very complex ones that are multi-level deep. Every component on the page is tied in reactively. I’m just not hitting the walls you speak of – will you start being more specific if you can? And conversely, can you be specific what React will give me tangibly over Blaze? 
4 Likes
This is a great point @juliancwirko. I believe that I might not have any issues with a large Blaze application because I’m the one that built it. If I brought other on and had to on-board them, I might have a harder time of it than with React. I simply do not know because I’ve never used React.
1 Like
It’s seems to me that the reason devs are having trouble putting into words the specific benefit of React over Blaze is because it isn’t a technical matter…It’s a disciplinary matter regarding how data is structured in one’s app.
You can essentially achieve a “one-way” data flow in Blaze if you’re carefully organizing your components. React just makes it that way by default.
and @vonwao in regards to your 8hr remark…would you hire someone with only 8 hours of experience with React? No. Then why argue that is all the time needed to learn React properly? Talk about edge cases…React may not be the most complex technology on the web but when the discussion becomes about “how easy it is to learn” something, then it becomes completely subjective based on people’s learning environments and capabilities. Everyone is different.
6 Likes
my humble opinion is that Blaze is better for medium projects if there’s a good Project Manager, because React lacks the separation of concerns.
If I need every designer to know JS and react on top of HTML, then I need to pay people more. With blaze I can design the UI, then make it works.
1 Like
I would hire someone with 0 hours of experience in React, if they have experience with Javascript, are smart enough and willing to learn a few new concepts. You can fix not knowing something with a few hours and a little patience, but you can’t fix stubborn or stupid. And most people are actually stubborn, they want to stay within their comfort zone and don’t like any change.
2 Likes
It’s not JSX or React that is difficult to learn; it’s the entire React ecosystem. There is an awful lot of churn and uncertainty. Best practices seem to change daily and it really feels that no one “knows” how to write an app with React. Debates about functional reactivity vs side ways data loading, ui state vs domain state, the dozens of libraries. Not to mention the several ways to integrate these flows with Meteor.
It’s figuring out how to go about writing the thing rather than just writing the thing.
It’s not React per se that is difficult; it is everything else around it. This isn’t a criticism by any means, just an observation.
5 Likes
Yes, I hear your point.
So at this point, I wouldn’t recommend jumping on any bandwagon (redux/flux/relay), but you can still use dip your toes in the react world pretty easily, you can even use it side by side with Blaze.
If you decide React is something you like, gradual refactoring is the way to go: you can create some new react components, drop them in your blaze app (or viceversa).
1 Like