And think it should totally replace Blaze as the default system for most components like admin panels, I like Blaze, but it’s so hard to shuffle through all the different files(css, js, html) when developing quickly , and Angular as the default, I never cared for because it felt it’s so bloated (see):
I would like to start porting over yogiben admin to React, but do smart scroll paginated lists?
I’m trying to carve out a time to give back to the community? Is this interesting to anybody?
Just thinking out loud.
Honestly, I’m optimistic that both will continue to be long-lasting view layer options. I think that (just like Meteor vs. Phoenix, etc.) there are really great use cases for both.
A path that makes sense to me: 1.0 in Blaze, acquire some capital, build out new features/2.0 in React.
That being said, for anyone who prototypes in Blaze, I think that easing the migration path between Blaze and React is always on a wishlist…
I am already mixing the two, which seems like fine for prototyping with the blaze-to-react package. I just think it’s so enjoyable to work in ©jsx. I find it pleasurable, It has a nice workflow.
I agree. But I also think that a workflow like that might be intimidating when trying to onboard other devs? I guess that’s part of my reasoning behind swapping in React when it makes sense.
I have projects with Blaze and other with React. I’ve never mixed, but I will most definitely go for React when Apollo becomes a thing, and Blaze loses it’s “home field advantage” with meteor reactivity 
That’s a fault of the development tools, not the language, rendering library, or view layer. I bet we see styling, events, and property sidebars in Atom by the end of the year to address this.
I think @debergalis said it perfect in his Meteor Night talk. Blaze for small simple apps and React/Angular for large complex apps.
Exactly. And that’s why there needs to be a refactor/upgrade path between the two. Which is where Sideburns/BlazeReact/ReactTemplates become relevant.
Large complex apps start out as small simple apps.
Couldn’t have said it better myself.
Today I slammed together a basic crud app for an office which was basically a glorified realtime todo app for their team. Blaze, AutoForm, etc… helped me get there FAST.
I’ve also used those same tools with hundreds of templates and a couple of team members and it literally starts slowing you down in time. Eventually you start to feel like you’re running fullspeed under water! (or at least without patterns like @awatson1978 advocates for)
I haven’t had time to let React decay much but it’s much much much easier to refactor and add features too (based on a 6 mo old React Native app with flux).
I’ve gone back to Blaze for 2016. Yes, it’s easier to come unstuck with larger apps (some of the issues can be mitigated with project structure) but it’s just quicker to get stuff done.
One thing I noticed that I appreciated last night when I was quickly mocking up a skeleton website for a colleague was the ability to copy and paste whole swathes of example HTML (for, say, Bootstrap) and just rejig it / add variables and have it immediately working.
Please note that I’m not conflating the two very different domains, but to me the arguments against React are very similar to the arguments Douglas Crockford makes against OOP in Javascript. With OOP you spend a lot of up front time designing type hierarchies which inevitably have to be greatly refactored or thrown out altogether as your app and its design evolves.
If you have a rock solid design going in and a near perfect understanding of what you are building, then that upfront cost is negligible. Otherwise it can be a real drag. And I say that as an OOP fan.
@peter.roehlen, well said!
Sometimes the emphasis is on speed and we may not know exactly where we are going until we get there. React requires some careful component thought in advance.
The folks at EmberJS (who use handlebars) are now looking into using VirtualDOM as well. That would be really cool with Spacebars/Blaze. You get the best of both worlds. We’ll keep watching that project.
Really well said. Mocking with blaze is fun, but I never ever want to give up again the ability to copy and past one jsx file with all the relevant html, js, and styles to replicate “a feature”.
I’ve made my choice to stick to React going forward, for better or worse. It’s liberating to not have to follow up on Blaze vs React arguments anymore.
I agree, but at the same time I think not everybody can afford the luxury of learning two different frameworks. If someone completely new to Meteor, Blaze, and React were to ask me which framework to use in 2016, even for a simple app I would still recommend React just so they don’t have to relearn a new technology if they ever outgrow the “simple app” stage.
You could see that as premature optimization if Blaze get’s the product initially quicker to market. Clearly it depends off course but for startup like projects I would personally go for the quickest option first. Later on you can hire and rewrite parts when you project is running.
I still have blaze in my projects but I want to switch to react. We have also some Ruby-on-rails-applications and its really easy to exchange static-views with react-components there. It’s therefore tempting to have only one view technology in the company as you can share innovation and exchange members in the team much easier.
i use react in a large meteor app.
My brother and I both use React. That knowledge can transfer easily to any other language or framework. With Blaze, we’re sorta tied to Meteor, whereas saying React opens the doors in many shops.
This is a bit off-topic, but I tend to disagree with this approach. Or rather, it only works if you have access to large sums of money and as much engineering talent as you need (i.e. are in the Silicon Valley).
Otherwise, the last thing you want to do if your startup does start to take off is have to embark on a costly refactoring using a new framework. It’s much safer to pick the right technology from the start.