Meteor needs to redouble on its current products and rethink their strategy. Apollo is a great initiative and deserves the investment. That said, Focusing too much on the future and not on the present will continue generating these types of thread and discussion in the community.
I wrote an app in meteors early days and it was a pleasure. I sat down, drew a few diagrams, read a bit of documentation on blaze, installed a few packages and in 30 minutes I was writing code that pertained directly to my needs. 3 days later I had a testable application and didn’t need to write much code that didn’t pertain to my particular application logic. Like many, I thought meteor had hit a sweet spot.
Now we are on react. I think that’s great. React is wonderful to use. a bit more boiler plate than blaze, but well worth it. Last week I sat down to write a meteor react app and let look at how that experience went.
I sketched out my app, did some reading on meteor/react integration. Then I sat down and started writing. Set up some collections, worked with both create container and tracker react to see which appealed more and picked a direction. Getting data in and out was still a piece of cake. That’s good news. Data to react seemed reactive. all good. I picked flow router and that worked well. so far so good.
Then I tried the login packages for react and they were all crap. I had to write my own. Then I looked at integrating a few custom components and had issues getting Meteor.User as a reactive source. More headaches. and a ton of other small headaches.
The point is it was a different experience this time around. I spent significantly more time writing boilerplate and components that didn’t apply to this specific case. There was no magic any more. It left me wondering why I was using meteor. Elixr or horizon would have been a better solution. At least in those cases I wouldn’t have had to deal with the headaches of React/blaze, flow, react router etc.
Meteor needs to (IMHO), Pick a direction and fully support that. that means…
If you support react and include it in your documentation, then support it. Take the time to create all of the key packages, or throw bounties out to give me user packages, form packages, etc that give us all the same experience we fell in love with the first time around. Don’t document that I need to wrap a blaze component in react. It feels like a hack. I shouldn’t have to install blaze at all. That’s the whole point of react. You react documentation shouldn’t include blaze for a new project. the current document is find for hacking a transition together, but not for a NEW react/Meteor project.
Key point is, that MDG needs to take a step back and remember why many of us fell in love with Meteor. At the end of the day it wasn’t blaze. Blaze was just easy to pick up and then we were off writing our code. Our code. COde for our app. That wasn’t the case this time around, beyond the authentication example I gave above. Just my 2 cents.