We’re almost to production but not quite there yet! The “release candidate” of our first product goes out next week to our team members with customers going out a few weeks after that. I put release candidate in quotes because aside from the software the Groves have mechanical, electrical, and biological components to evaluate and test as well, so it’s not your traditional concept of a release candidate
As far as Blaze vs React… The web has followed a template-based approach because the web was designed as a document platform. HyperText Markup Language! But the web today is much more than that, it’s a distributed application platform. We have highly dynamic applications with lots of state, and it’s hard to reason about the state of your interface when your building blocks are stateless templates. The concept of Components is not a new one, it’s traditional good programming: you have clear interfaces of what each component expects (
propTypes), you have composition where you can inherit functionality from other components (
mixins), and you have fine-grained hooks into the life cycle of each component. All these come together to make robust, reusable components.
So the benefit of React is that it helps you to make a clear flow of state. If you can take your components, your solutions, and just render them to other end layers, that’s awesome. And that’s not just native, that’s Canvas, WebGL, or even a custom TV graphics library. I haven’t built anything with React Native yet, so I can’t speak to that specifically, but if they nailed all of the difficult asynchronous things that need to happen to make it performant and possible on iOS then that sound way better than trying to make DOM feel like Native. I very much like the idea of “learn once, write anywhere” rather than chasing the dream of write once, run anywhere. Writing and designing for the platform results in a better product.