Wow, @SkinnyGeek1010 wins helpful user of the week award! 
Thanks for putting so much time into your replies.
I think I’m sold on React. I’m a little fuzzy on a few things, like the concept of server-side rendering (never heard of this term before now). I definitely have some reading—and tutorials—to dive into later!
Wow, @SkinnyGeek1010 wins helpful user of the week award! wink Thanks for putting so much time into your replies.
You know what, this thread and his replies have finally allowed me to decide giving react a go in a project and the more I skimmed through those links he provided, the more it grew on me.
I’m now excited to finish the one I’m working on and take on some brand new react challenge 
Yeah man! This is what the developer community is all about. 
Turning our peers onto new ways of doing things, so that we all learn and grow and become even better (and faster?) at building things.
I got totally burnt out on web development several years ago, because it was feeling stagnant to me. Now that’s changed, and I feel like it’s more exciting to be a web developer than it ever has before.
I fully agree
But concerning the new ReactiveVar, its simpler to use my https://atmospherejs.com/frozeman/template-var
I don’t get why its not more popular, because this makes handling states inside an template instance a breeze and its a standard package in all of my projects.
(It also allows you to get the reactive var of another template)
I have to disagree with this one.
If you write you meteor templates/components smartly and use template instance specific reactive vars (like template-var), you can very well write modules, where simple pass reactive data in and get a nice component, which doesn’t pollute you global apps namespace or variables at all.
I totally agree with you. I think I should have said something more like, “Blaze lets you make a mess. It’s totally up to the developer to write good modular code.”
React and it’s ecosystem is concerned about building scalable (as in team/code size) maintainable apps. This concern trickles down into the docs and APIs. The core team developed these to solve their own problems.
I think this would be a much better situation if MDG had a very clear suggested architecture, methodology, style guides… eg.
// bad
$('body').hasClass('extra-large-fonts')
// good
appState.get("hasLargeFonts");
most examples in the open use a mix of imperative and declarative paradigms where declarative would work better, and storing state in the DOM instead of a Reactive Dict or Var. There’s also no suggestion to component-ize things so a lot of code is like a static HTML page with duplicated (or global) helpers used across each page (instead of making re-usable Blaze components).
Here’s a decent example of using Blaze in a modular way similar to React (with the exception of how it renders).
Also Template vars are something recent. It’s unfortunate that they’re optional and feel ‘bolted on’ instead of being first class. Over the years this transient state was stuffed into a global Session (oh man I feel like a cranky old timer now 
).
If I can find enough time I would really like to do this. I think the differences are not obvious as most people compare speed and how much ‘more complex’ it initially looks compared to handlebars.
The big differences are in code maintenance, debugg-ability, test-ability, and an easier to reason mental model of how data flow throughout the app.
These aren’t obvious until you have the chance to work on an app with tens of thousands of line and many months of half-thought through product changes. Once you’re in this spot it’s much easier to see the differences. Small todo apps are always easier in Blaze 10/10 times.
After writing a lot of React code it’s made my Blaze code 10x better. However it’s hard to go back for new projects because it’s solved a lot of issues for me (I still write Blaze though!)
As with the link above… you ‘can’ write Blaze like React but no-one really does (in the open).
just my $0.02
I did not see any mention of SSR. For me, it’s a killing feature that could justify the use of React. (or angular 2.0)
I think this covers the only real pain point with using Blaze. I sometimes avoid creating sub-templates only because child templates can’t inherit reactive helpers (so far as I can tell). Is there any discussion/roadmap to address this?
@frozeman that template-var package is exactly what I’ve been looking for 
do you typically grab data from subscriptions for a template and store them in templateVars as well to keep all template state in templateVars, or just data that’s not from a subscription? I’m deciding between Blaze and React and although I really like Blaze’s simplicity and syntax I love how React maintains state for each component. I’d prefer to explicitly state each Blaze template’s state variables rather than assume everything required is present from a subscription
Just wanted to provide an update:
I’m knee-deep in React and building a new SaaS using it. There’ve been a few growing pains, but I really like it! Too bad there aren’t more tutorials out there for Meteor+React.
I mainly use it to keep the template instance specific state there, e.g. what box is ticked, or slided out etc.
Glad that you like it!
Wouldn’t you just handle the radio button change with a function in the React component that used setState on a variable that could be used to hide or show a form?
This might not be a very important concern for people reading meteor forums, but: React is more ubiquitous. You can use it with Meteor. And with Rails. And with .NET. And with any other backend. Whereas with Blaze… I hadn’t even heard about Blaze before trying Meteor, and I try my best to keep up with the industry.
This also has a benefit of more experience being out there. For any given problem, there have been more people solving it with React than Blaze. More people have given thought to structure and best practices. And maybe even released the solution as a library you can re-use.
And in the end, if Meteor does not work out for you, it’s easier to migrate a React frontend to something else.
The only reason I’m not using react in my current project is because it is stated that “React router APIs will be totally different in version 1” and I don’t want to rewrite things.
If only I had a rough idea of when it’s released…
react-router has a release candidate and should be fairly stable as far as the API. If you’re not planning on launching very soon I would use that instead. FlowRouter works too but doesn’t have nested UIs.
I’m personally migrating one app to 1.0-RC very soon as it has a lot of nested UI.
The new 1.0 has an easier Link API which should make it much easier to migrate older apps:
// v0.13.x
<Link to="about">About</Link>
// v1.0
<Link to="/about" activeClassName="active">About</Link>
This is out of topic, but do you know if it’s possible to pass properties directly on the route in 1.0? Like <Route component={MyComponent} components-data={data}/> ?
I believe so. If not I know you can wrap it like this:
<YourDataComponent data={data}>
<Router component={MyComponent} components-data={data}>
<Route foo={} bar={} />
<Route foo={} bar={} />
</Router>
</YourDataComponent>
As that’s how the Redux does it so you’re only passing it in once. However I bet you’ll be able to pass it into each individual route if that’s preferred.
With FlowRouter you need to do it for each one so I made a helper to do that:
Use Functional Programming to Simplify Your Meteor Code
Is it possible to use React Router without using webpack/browserify and using require statements? Call me strange, but I’m not a fan of going that route, it feels very “un-Meteor” and cluttery to me.
Check out this official React-Todos example: https://github.com/meteor/react-packages/blob/devel/examples/react-todos/client/routes.jsx
Pretty simple!
I love this aspect of React and I think it’s been very helpful for app development.
That said, I’d like to point out that, so far at least, these architecture trends have been influenced by the fact that many web apps are much simpler than desktop apps. They do work great for the typical web apps of today. If on the other hand I was trying to design an intense performance critical app, like a video game or CAD software for example, I’m not sure I would take the monolithic store approach where every change propagates all the way through the state hierarchy.
Redux tends to advocate passing actions through a wide variety of handlers, whether or not they are relevant to that particular action, for the sake of simplicity and robustness. This is fine for many apps but it means that the more elements you add to your state tree, the more work it’s doing each time. And it might still be a negligible amount of work, but in my app there can be many actions a second when the user is dragging things around, so I chose to narrow down my event handlers by key. Even if performance is still acceptable, consuming less battery is also desirable these days.
I met one developer working for a company implementing Adobe InDesign-like software for the web using Backbone, mustache, and HTML canvas, I don’t know what else. For all I know that could offer them the best performance.
All design decisions have tradeoffs, so I think it’s important to keep an open mind.