Hi Geoff; Hi Evan,
Thank you for weighing in on this topic. I just wrote a page of text replying to Evan’s questions; and as I was sorting through my thoughts, I came to a conclusion similar to Josh Owen’s recent post… this is fundamentally about backwards compatibility and a migration and maintenance issue.
The question shouldn’t be ones of ‘what do we like/dislike about Spacebars/JSX’. That’s really missing the point. The questions should be:
- What are the migration and refactor paths from Blaze to Blaze 2?
- What utilities do we use to move to Blaze 2 (i.e. and therefore to React)?
- What upgrade utilities were missed during the Meteor 1.2 release?
- What packages/utilities can be created to coherently integrate or migrate apps from Blaze to React?
- Is Blaze 2 going to be API compatible with Blaze 1?
- If not, what happened to the '1.0 release` and long-term stable APIs that were talked about pre-0.9?
The reason that many of us are clamoring about Sideburns/Blaze-React as a workable solution, is that it offers a super clear migration path for all the existing Blaze applications in production. The refactor path is basically this: add the timbrandin:blaze-react package; replace
.html file extensions with
.html.jsx file extensions; et voila; your app is running on React. That’s what existing Blaze users need to get all of our projects migrated over to React.
Seriously, don’t change the existing API if possible. Not right now. The API isn’t perfect, but that doesn’t matter. Use the existing API as a baseline; swap out the underlying functionality; and make sure it’s feature compatible. It’s a classic refactor. It’s not as fun and glamorous as producing new functionality or stomping out bugs; but it’s the boring, responsible, professional, and trustworthy thing to do. Once Blaze 2 is proven to be feature compatible with Blaze 1, then lets start adding new features in Blaze 2.1 and later.
ps. Serkan concisely summarized my previous page of text with his simple breakdown… it’s all about the HTML. As fancy as JSX is, it’s simply not HTML.
pps. I vote for Inferno as the name of the project. Spark > Blaze > Inferno.
ppps. MDG is doing a great job of managing the front of the change curve; but as a startup hasn’t had to deal with managing the back of the change curve.