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 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
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.
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.
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.
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.
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.