That’s an understandable decision, given the ramifications:
- react developers might not easily be able to port their components to Meteor
- and Meteor developers might feel uncomfortable by being boxed into a custom solution
However, conversely, Meteor may go from being an “isomorphic” framework to just a server side framework if Tracker is replaced by a purely functional approach not their own, and the only remaining remnants of Meteor on the client is subscriptions and ajax calls (i.e. all “Meteor methods” really are). I’m not sure MDG recognizes the ramifications of that. Basically it means this: the next logical thought is forget Meteor, I’ll just use RethinkDB with React/Redux on bare metal NPM. And that’s the end of the story.
As I suspected, MDG would take the “safe” approach. It’s an approach that I predict will hurt Meteor drastically. I know you imagine all these view layers, and being able to inter-opt with them all, especially since you yourself made one of them. However, I think 80% of your customers (i.e. Meteor developers) will want React, and 20% the other options. Meteor specifically targets intermediate developers looking for that 80% good enough solution across the largest swath of the stack using the most popular tools. So in short, you’re giving 80% of your developers nada, zilch, zip, if you’re focus is to provide many view layers, rather than do just the one they really want [React] extremely right. I and many of us wanna see something fantastic and Meteor-specific in terms of the view layer, not just what everyone else has, namely plain old React (plus Spacebars). This is basically the message that everyone in this forum is saying if you read between the lines. If you tell everyone: “look we got this kick ass Blaze + React approach, the crowd goes wild and all your Meteor developers are excited.” You could even pass on transpiling Blaze 1.0 at that point and be let off the hook. I hope we can come to more than an “agree to disagree” situation this time–but that’s my prediction here; that’s what they want. It seems MDG is hell bent on not giving that to them. It’s a case of: Startup knows better than customer, remains unwaveringly focused on their mission. I’ve been in this business for over a decade–I get it. It just would be nice if somehow some resources could be allocated to this approach…
As an aside, there already is Jade templating for React for example–it’s nothing special if we also get handlebars.
That all said, there’s a silver lining in the sky. I’ve put a lot of work into that “hybrid” approach you forewarned about. The first part was TrackerReact which is already out, which you have likely seen. I’ve got a lot more I might as well just put out there this week. Collectively it’s called Meteor.Component, eg:
class MyComponent extends Meteor.Component {
}
…it’s late for me, but I wanted to make sure I responded to you here before I went to bed…Evan, i’m going to show it to you real quick right now cuz I know you guys are about to make an announcement–maybe it will factor into what you guys are thinking. Here’s basically it:
I’m doing some transpilation tricks here in my own version of the React runtime:
it’s currently done with a regex, but will be replaced with a babel plugin I wrote which directly transforms the AST.
and here are the mixins:
those mixins will be incorporated in Meteor.Component in the next stage, which will be a drop-in replacement for React.Component (and won’t require actually including the mixins). Yes, I know, React itself is moving more towards “higher order components” in place of mixins and the like–but I think a flat class is something we’ll be able to maintain for a good long time regardless, and exactly what Meteor’s target customer is most comfortable with. …There are a few more mixins such as AutorunSubscribe, etc. It will very much be the Blaze 2.0 people everyone imagined in the back of their head, but in React. It will be a crowd-pleaser.
NEXT: I’d like to show you the versions used by the Sideburns project which replicates the Blaze 1.0 behavior:
That’s actually the more important code that you guys should look at. Basically, you can truly compile Blaze 1.0 to React. 100%.
I’m not sure why MDG wouldn’t want to do that.
As for the hybrid approach going forward, it may work out very well for us if you guys stay near the base-line while I scout out riskier territory where MDG wouldn’t want to promise too much to their developers. After all a lone developer like myself can promise Blaze 1.0 transpilation and fail and not much will happen to me, whereas a well-funded company like Meteor could get itself into some serious trouble if they did that–I get it. However, i think there’s some opportunities for some collaboration. For one, spacebars transpilation to JSX desparately needs your help–and that’s something you guys are promising too. The regex approach Tim Brandin has been using with Sideburns won’t work. At this point, spacebars transpilation to JSX is the only missing part. If you examine the last 2 links above, you will see that. My hope is you examine that and triage helping us with Spacebars transpilation to the front of the line.
So in short, all Blaze behavior is proven possible to replicate–yes, via hacks–in React. As mentioned, I get why MDG wouldn’t wanna get behind that. My suggestion is: empower me and let me be the fall guy. See what I’m saying.
Final Thought: Tracker has a magical implicitness to its abstraction that functional approaches make up for in predictability. I think if we could make Tracker and the patterns to use it more reliable, then we could compete with React and Redux. I think if we could make both fit nicely together (i.e. TrackerRedux) where developers could choose either for granular parts of their app, then we’d have a better option than either on their own. One of my ideas for improving Tracker is using a transpilation build step to fill in finder fields, i.e. {fields: {foo: 1}} based on “property level cursors.” So basically when transpiling spacebars, we determine which properties of a model are accessed, and then automatically go back and fill in the initial find call with those fields. I’m bringing up this example because the biggest problem with tracker is that it re-runs functions many more times than it needs to, and the biggest culprit is that nobody uses the fields option to constrain reactivity. The next idea is snapshotting Mongo and using the oplog to produce Time Traveling functionality. Totally doable–I just gotta get to it.
I’ve put many hours thinking about how to optimize Tracker/minimongo so it can compete with Redux. What I just mentioned were a few examples of many I have to optimize Tracker. I’m not sure if MDG internally feels that Tracker has some terminal issues with its reliability that make them willing to throw it out. It does throw exceptions that have nothing to do with anything you did wrong every so often. My goal is to essentially build an environment where Tracker runs less, developers have tools to constrain it’s behavior, and functional programming can be easily intertwined where its explicit predictability is needed. I think that’s a sound goal–unless MDG plans to ditch Tracker because of “irreconcilable differences” lol. You tell me.
