You don't have to worry about Meteor Blaze going extinct. Tools don't die.. Fork the repo and in 25 years you can still pull 1.3.
carbon paper (still being made), steam powered car engine parts (still being made), Paleolithic hammers (still being made), six pages of agricultural tools from an 1895 Montgomery Ward & Co. Catalogue (every one of them still being made) . . .
But what's the motivation in continuing Meteor Blaze development? We put our first Meteor application in production back in version 0.6 and developed several more over the past few years, up until the present (1.3). But now we are doing new application development in Meteor + React + Redux and feel it's a better framework for our development. And we're looking forwarding to Apollo, which looks like a much more marvelous approach to querying data.
We kind of wonder if Meteor has any future at all. Instead of seeing a dedicated team of code custodians working to maintained Meteor, we'd rather see talented developers devoting their energies to next generation tools. Atmosphere can be replaced with NPM leaving Meteor's pub/sub, reactiveDict and things like accounts. But pub/sub stuff could be replaced (hopefully) with Apollo, and Auth0 gives you all the advantages of account-ui and more.
React syntax is kinda weird, but once you get past the initial learning curve, we find that it feels like a more mature way to build reusable UI components which have better separation of concerns.
We also find ourselves working more productively than ever thanks to Kadira Storybook. Storybook allows us to design and develop our React UI components, writing stories to represent each state. And if you configure Webpack to hot compile your LESS on file save, then you don't even need to run Meteor (webpack does it faster than Meteor's build process).
Then there is Redux, which allows you to do things like store your entire application's state. We've been using state machines in our Meteor + Blaze apps for years (thanks to the advice of @natestrauser) to manage complex UI like shopping carts and checkout pages. So Redux felt like a natural extension of an approach we were already using on an ad hoc basis.
So I just kind of wonder why you'd prefer to see work continue on Blaze when these other technologies have been invented to address the shortcomings of those approaches to web development.
I use to write Visual Basic applications in the 90s, and I felt it was very disruptive when the .NET framework replaced VB with a more strongly-typed, OOP version of the language, I had to learn new concepts and new ways of doing things. Ultimately I came to appreciate C#/VB .NET as a more professional framework which allowed me to work even more productively and better organize my applications. Meteor was a bank robbery; a framework developed to finance work on Apollo. It was also a valuable technical exercise.
So just wanted to ask why you preferred Blaze? Have you played with React? Do you prefer a more muddled approach to business logic?
If you’ve ever written a Blaze template with a ton of logic before, you can see the benefit in [React]. Instead of muddying up our markup with a gnarl of nested if/else statements, we get a much cleaner method call, putting our logic where it should be: with our other logic....
[React is] new and a bit odd at first, but it’s something that you should definitely consider adding to your toolbelt. Hype aside, it is neat and has a major impact on how you think about organizing your application.