yea, MDG, if we know you have no plans to keep up with Blaze, it’s basically the same as killing it today. We need to know you plan to fight the good fight with it. I remain completely unconvinced by React and these “rebuild the virtual-dom every tick” systems. What Meteor did with Blaze and tracker was and STILL IS phenonomal and better. They implicitly track data context, aka .props and tracker variables (cursors, session vars, reactive var, reactive dict, etc) implicitly tracks reactivity. You don’t need to pass functions from parent templates to child templates, jumping through all these hooks to work with almighty “STATE”! By very little additional syntax, Meteor implicitly knows which variables should trigger reactivity. This is genius and, interface-wise, a far superior system than React and all the extra work React has you do.
People keep saying, just look how many people are working on React and Angular, indicating it as a reason Blaze has no chance. Perhaps, React was so beautifully architected by David Greenspan that it chose the path of least resistance whereas as those frameworks did NOT. The whole virtual dom motif essentially makes it so you can’t imperatively interact with the dom like u used. That means basically every other javascript/jquery plugin in the world can’t be used with React. Sure there are hacks, but my point is all the work all these React developers are putting their time in is remaking everything such as Animations in the pure React way, when that simply doesn’t and shouldn’t be the case for many things; and is often more complicated. Doing animation in React is a lot more complex than using the non-documented/unofficial Blaze animation uihooks. …Anyway, the same goes for Angular. Just go to their new website–you can filter all their docs by Typescript, Dart, ES5, and ES6. That necessitates many more developers. That’s definitely not the path of least resistance. The point is the semi-walled garden that is Meteor allowed David Greenspan–just like us–to be far more productive than developers in the plain node world that gotta support a million more scenarios. Blaze does have a fighting chance! We just need to be vocal about it and make the right points about. We can’t act like we don’t get what’s good about it. I hear a few people saying that they like its simplicity. That’s a start, but that really is it’s selling point, and it needs to be further clarified: It’s not just that it’s simple; that almost makes it sound like a toy; it’s that it affords you the least amount of work to get the most amount of power. That ratio is near perfect in Blaze (again, minus the fact that it needs to evolve into a Components API where you can count on the value of this).
At the end of the day, only David Greenspan knows what we should do with Blaze. Correct me if I’m wrong, but he seems to have spearheaded blaze and did the vast majority of the coding. So what I’m saying is this: you know when you build something for a client, and currently functions great, but you know down the line it could run into some serious problems, and you have that fear lurking in the back of your mind. I think we have all been there. Right. So David has seen all the performance issues we have had with Blaze. The reality has been it was a great innovation what Meteor did with their reactivity system. I couldn’t believe it when I examined how they did it several years ago. However it’s always been kind of a big bet. A “big bet” that even MDG wasn’t sure how would pan out. And clearly we do have rendering issues. When lots of stuff is going on, it starts to behave funky, animations skip frames, timers are messed, etc. So the only reason not to continue with blaze is if David and MDG don’t believe they can surmount those hurdles. But if we do, I don’t see why we cant have a component system or even Blaze Native.
If Meteor wants to stay competitive, forget SQL, the options are 2 fold:
- double down on Blaze and take it all the way to Native, being willing to fight Facebook every step of the way:
or:
- join Facebook and the “The React Stack” completely. That means get married to GraphQL, Relay, Webpack, in addition to React, and perhaps replace Mongo with RethinkDB. Make a big bet and skip a step, willing to cut some of your losses.
But if MDG’s plan is to not take a stand, and just let us do whatever we want with the frontend framework, it will spell the end for Meteor. It’s just not going to work where the most important part of the stack–the part of the stack driving all the trends, i.e. the frontend–is anything less than the best. All the node developers will go to where they can use the best stuff. I think MDG is at the most pivotal stage in its life right now. It doesn’t seem to have the money to hire a team that can truly compete with React or Angular, which as everyone has pointed out is horrible given it is a full stack solution rather than just a frontend framework like the former 2. They are clearly banking on Galaxy to alleviate this situation. I do think MDG’s timing has been near perfect. Their execution near perfect. They couldn’t predict how fast this cambrian react explosion would happen, but Meteor has been basically right on time for the major stuff they have done, and the community has done wonders to fill in the blanks with basically every package you could need until then. Take a step back and think about the history of meteor and the last 3-4 years. We’ve wanted certain things like components to come sooner. I think we wanted Blaze sooner than when we got it. Same with galaxy. But given the realities of software, everything actually ended up being delivered right on time. I.e. not some ridiculous amount of time late, or that late at all. Just a little late, but exactly what anyone with any experience would expect.
So we are here with Galaxy. MDG is aiming to strike gold right now. Put yourselves in their shoes for a second–thats what I’m asking. They are aiming to turn that into a money making machine and asap. I bet you nobody over there is focusing on anything else. They know they have their bird in the hand, and they gotta make sure to snap its neck and cook it. We are essentially putting a wrench in their system, their plans. We are allowing React to do so. If I was MDG, my main priority would be to make this Galaxy system print me money, raise more money than ever at a higher valuation based on that fact, and then use money from both sources to quadruple the size of the team. And then 6 months from now, i’d blow whatever react is doing out of the water, and I’d focus back on the view layer, and the interface to their system. Make Meteor a true OOP system. Not this imperative gobbeldy goop we all be writing. Anyway, I’ve described that point above in detail. The point is they are at a pivotal time, need to make money, and then they have a lot of work to do, and not even on new areas, but on revamping the original areas. Meteor is basically like Ruby right now or PHP, i.e. a language with solid HTTP bindings (in Meteor’s case called: the “Connected Client”). They need to take their Ruby, and make the Rails. Overhaul that entire docs.meteor.com site like Angular.io has and make it feel like a million bucks. See what I’m saying everyone! The docs site f**ing blows. It’s low quality. They just finally got around to giving the rest of the meteor site a face-lift, but still the core set of documentation is not up to par. And the real problem is: the API it details there is not up to par. It steers novice programmers down the path of writing imperative code, whereas Rails steers you down writing solid object oriented code. All you guys obsessed with the functional trend du jour, just pipe down a sec, and recognize the benefits of a basic oop approach: short single purpose methods! Forget the problems of inheritance leading to brittle code for a second. Just having a consistent value for the this changes everything. Why? Look at most Meteor packages, its long procedural/imperative code you can barely understand, simply because well named single purpose methods are not frictionless to create. You write a helper vs life-cycle handler, what’s the value of this, eh!? Exactly. What’s the prescribed way to deal with models, relations, aggregates, etc?
Meteor is going to die because its API sucks. The messed part is that the javascript world has moved so far along so fast that Meteor basically needs to revamp the whole thing and one-up the competition if it wants to stay ahead. Again, reference GraphQL, Relay, etc. The competition is fierce. I think Meteor has lost its foresight. It needs to regain that. Thats what I’m saying here. I don’t like these Facebook solutions. Their interfaces are not correct. I rather Meteor keep us as is for a year, but release a 2.0 a year from now that perfectly addresses all of this and is far beyond the competition, and exhibits some of the same prescience we see the various camps within facebook exhibiting.
In short, a major rethink is what Meteor needs. MDG has likely wanted to stay blind to everything that is going on outside of Meteor. You hear little blurbs like in that AMA the other day on crater.io about how they just started looking into Webpack and the like. You get the idea that the node community outside of Meteor has passed them by. To be honest, that’s very much has happened to me. So I could be projecting. But the point is it’s a likely thing to happen given the scenario: open source software pulls away from main open source thread/branch and builds semi proprietary solution. We have detached from the main branch (of Node). And now we are finally paying the price! That’s the point here. Remember the days when everyone was questioning how we would implement our own package manager system, and use Fibers instead of async, etc!?!? Well, they were all basically saying: “watch out, something like [what is happening now] might happen.” And it has. We are too far away from the main branch to easily incorporate anything that’s going on in it, and we are paying the price.
That said, one fix-all might be more closely aligning our isomorphic package manager with what’s going on with webpack, es6 modules, etc. At the very least if we could make it so incorporating all this stuff is just as easy as in plain node–even if we had to still be married to a few things like Fibers, Mongo, etc–it would level the playing field and put us on equal footing with node developers outside the meteor community. …so that’s one idea.
In a worst case scenario, I think we see GraphQL/Relay take off just as quickly or more than React. RethinkDB easily plugins in via GraphQL, and boom Facebook comes up with an isomorphic package manager and node server to connect all the dots–what then? It just seems to me that a lot of what Meteor has brought together from day one via the semi-walled-garden Apple style development approach has finally been caught up to by the community. It’s like death by a thousand paper cuts. So our options (and these are just a different way of presenting the 2 options presented above):
- beat em
or
2) join em
See, I really believe–and I think we all have believed–Meteor had a chance to be the platform to end all platforms, the Ultimate Web Development Platform, the Ultimate Javascript Application Platform. So sure, it could live on as an average platform. Or it could go on to truly be king. And I’ve set the bar high for Meteor. I think it can go on to be not just one of many MVC platforms that exist for PHP, for example, but like Rails be the only MVC platform worth considering for Ruby. Meteor could be that for javascript. That’s the f**ing point here. I think framed in those terms, each and everyone one of you long time meteor developers would have a hard time disagreeing. And I think MDG itself might have lost its way along the way, but I still believe they could make it happen. When Galaxy is truly done and printing them money, I recommend they do a deep rethink and reevaluation of their plans. Where they make the hard decisions to drop pursuing SQL, and a bunch of other similar nice-to-have features. I recommend they operate like a startup again working on the smallest MVP possible. And I recommend that the value proposition there be nothing other than the interface into Meteor. I recommend they make it look the way Rails would look for the modern “Connected Client.” Answer that question. And along the way crush React (or fully embrace the React World/Stack). And do things like: make their build system look more like what the node community at large uses, perhaps even offer a non-fibers async node api as an option, or at least a better interface than wrapAsync, bindEnvironment stuff; something that looks more like what the rest of the node community is doing. I think MDG has learned a lot since the beginning to formulate a server side plan that wouldn’t get as much backlash from the rest of the node community (disclosure: i personally love fibers; im just making an extreme suggestion to paint the picture for how far they should take their reevaluation). Then finalize the strategy by coming up with a nice migration process from Meteor 1.0 to 2.0.
The type of developers Meteor attracts are those that love a good interface. We are all defecting because we like the React interface. We like the interfaces of things like Webpack, Browserify, build tools like Grunt, Gulp, super shiney new useful interface like GraphQL. All this shit we see day in and day out, we want to use. It makes the interface shown on docs.meteor.com look like it has lost its luster. MDG needs to understand that. They need to understand the marketing value of their interface, the sexiness of their docs site. And ultimately the usefulness and cohesion of providing a proper framework. Now that most stuff “just works” they need to circle back and turn Meteor into a real “Framework.” That’s the bottom line. They need to make it their top priority to deal with the “Facebook React Stack” challenge/problem/competitor, and drop everything else. It’s that serious. (After Galaxy is printing them money of course in a hopefully a few more months.) I’ve used nothing but Meteor for over 3 years, but as soon as Facebook’s solution goes “full stack” it will likely be an obvious decision to jump-ship for all new projects. Facebook is moving at such break-neck speeds that it almost feels that that time is inevitable, that it’s no more than a year away. Overnight React Native seems to be full stable across iOS and Android. GraphQL and Relay popped up out nowhere. Facebook is not far from the bottom of the stack already. It’s only a matter of time. And from there, of course they will wrap it up into a nifty facebook-sponsored full stack isomorphic solution. And instead of Meteor, they will call it “Rocket” or something lol. Meanwhile Meteor will be exploding hear on earth, while Rocket is launching your projects into the stratosphere lol. This may sound like Fear Mongering, but I think we and MDG needs a healthy dose of it to see the reality. Something is-uh-cookin’ in the Facebook React world, and doesn’t start and end with a frontend framework–whether Facebook has planned this far themselves already or not. See what I’m saying, it will be birthed by one of their many sub-camps (i forget what they call all the “companies” inside their company). You know, all that move fast and break things developer freedom they allow for over there; the same philosophy that has lead to the birth of so many leading open source projects within their company walls. It seems to almost be manifest destiny that they build the full stack solution to what Meteor did first! I mean these smart people all buzzing around their offices. They pass each other in the hallways and say: “oh, wow, now that you built GraphQL, I got an idea, I’ll build Relay, to really coordinate things nicely between GraphQL and React.” You think in that same conversation someone isn’t saying:
-“we really need to address the server side?”
-“why don’t we build a database of own?”
-“Hey Mark, we really need a 50 person team building a RethinkDB competitor or you gotta buy RethinkDB itself?”
…etc etc. If you think these conversations aren’t happening you’re kidding yourselves. That’s why one option is Meteor could step to Facebook and be like “we wanna fill in all these gaps [from ddp down]”. Or at the very least figure out how to interoperate with GraphQL first, and maybe Facebook won’t even waste the time at that point. Or in the worst case scenario, snag an early piece of what is likely to be another bustling ecosystem.
That’s how MDG needs to think. Otherwise, they/we will be another niche community. And there are many of those on the net. I however have always envisioned us as more, as having way more staying power than that. Having a run several times longer than even Rails.
Final thought: if MDG doesn’t have the money/resources, they need to empower the community to do so, to contribute towards this vision (or whatever their “life saving” strategy ends up being). It’s very hard to contribute to meteor. I don’t know the answer to this one, but they should basically segment out some official areas for community contribution, and find a way to trust us to reach the “high standards” they hold themselves to. And they should first lay out their true road map. That trello board is bullshit. I mean I get and like how it only has one task in the present column: Galaxy. It shows their supreme focus. But everything after Galaxy is a hodge-podge with no official declaration of what they will do and what’s important to them. MDG should publicly display a running proposal of what they plan to tackle post Galaxy. How are they gonna operate? How do they envision the future? Do they see how grave the threads I’m mentioning today are? What do they plan to do about it? They don’t need to set a plan in stone, but delineate different options and ideas for how they’d tackle the different options like I have done here today. What will their focus be?
