The server-side network model he describes here is the same architecture Meteor is designed with (see this page: https://www.meteor.com/why-meteor/features). With Meteor, you get client side prediction and latency compensation (they call it "optimistic UI" now) for free. I've always been impressed they decided to build that, because I sure never would have myself. In fact the Meteor team has always said you need this kind of architecture in order to build true real-time applications. But I haven't seen other web-oriented platforms take a similar approach. Did the Meteor team just know something no one else has picked up on (despite it apparently being common practice in the games industry)? What gives?
Even though I don't use Meteor anymore, I still like DDP[1] a lot. It's simple (can be implemented in 50-100 lines), but it is the core of Meteor. There's a specification for it in their Github repo. Meteor's "optimistic UI" is basically an abstraction on top DDP, IMO.
To be "The Javascript App Platform", as displayed prominently on the Meteor homepage. If you build an app with Javascript, MDG want you to build it with Meteor. In order for you to do that you need to trust that you can use the tools you want to, and derive benefits from the fact that the stack is designed to work as a single platform. So if GraphQL is where it's at, it makes sense to design a place for it in Meteor.
Well yes, that's their general goal, but hasn't the developing React stack already won on that front?
It frankly seems they at least believe it has, as it appears their plan is to take it, bundle it together under one name and re-implement some parts.
The question is then, why would anyone on the React stack, which has become so popular, switch to Meteor? The stack of libraries Facebook has already put out there (not to mention third party libraries such as Redux) are designed to work together, and do so easily and very well - people are familiar with them and already using them.
I suppose the only dimension on which they could coax people over from the existing React stack, Relay in particular, is by developing its feature set faster and better than Facebook can. For what it's worth I think it's a good thing, I just find it pretty intriguing if that's their play - going up against the popular tide and basically directly competing with Facebook on bundling together their own libraries. Will be great to watch their progress!
Has it won? Where can I go and write `react-stack create my-new-project` and get a guaranteed working integration of the various elements that make up the stack, including a working server environment, pre-installed and configured database, and all of the other inbetweens that come with Meteor (such as DDP, livequery, Tracker, Blaze, ReactiveVar, etc)?
The "React" stack has certainly been an up and coming potential competitor for Meteor, but until Facebook or someone else actually shows signs of preparing the kind of integrated development experience that Meteor ships with out of the box, I don't think it's really similar. So that's what they're doing: tying together the best of the Javascript ecosystem, which happens to currently include a couple of projects by Facebook, into one cohesive whole that "just works".
Is "react-stack create my-new-project" really preferable to something like "git clone git@github.com:react-stacks/react-firebase-template.git my-new-project" ?
I'm sold on the latter, since often enough I'll customize and publish my own tweaked templates as I become enamoured with different tech.
The point is that Meteor will be handling the subscriptions side of things, the reactivity. There's a near-endless amount of work there to get it right. GraphQL and Relay don't even have an interface for subscriptions yet. The plan will likely be to make Meteor's actual concrete system work with the interface they provide by specifying a few lines of code. Facebook and React likely won't do much to address the implementation of subscriptions, which may very well be a larger undertaking than all of GraphQL itself.
In addition, what Meteor is about to build here is a long time coming. It's something they have been thinking about in one form or another for years. What I'm referring too is a purely webserver-based interface for subscriptions that doesn't take advantage of any special database features, and is therefore database-agnostic. GraphQL happens to come at the perfect time as the solution to supporting multiple databases. And as the only open source full stack reactive solution worth its salt, they know the challenges of building this solution better than anyone.
Their current solution, Oplog Tailing for Mongo, has been on the chopping block for a while since it doesn't scale far enough. They've experimented with PostgreSQL triggers. And now they're drawing from all this experience to harness GraphQL types to build the best-in-class interface for anyone to take on full stack reactivity. My guess is it will likely not be as performant as direct Mongo oplog tailing, but will allow developers to customize it to make it faster where you need it, which is something we've never been able to do. In addition, if the low level interface is good enough, it will likely result in many packages that provide for specific optimized reactive/subscription scenarios.
So no, the "React stack" has not "already won" on this front. Subscriptions is a big problem with many different solutions. Likely what Facebook has can't be used by anyone but the largest of companies. If Meteor both provides a decent database-agnostic subscriptions interface + an API to customize it for performance, Meteor will likely have done what nobody else has or is willing to do.
I'm a React fanboy, and use it and React Native in production on some pretty large apps. However, Meteor adopting React (and related tooling) still has merit, as to build those projects required me to wire them all together, enforce convention for the other developers using it so that we didn't try to use the tools in ways they weren't intended, and work around the various issues that crop up when doing Unviersal Javascript. Meteor can solve all of these, and can market themselves as that integrated solution. We all win, in that case.
Meteor doesn't need to steal any developers from vanilla React, because React has negligible share of the addressable Web development market. People will start on Meteor because it is easier and then they'll stay on Meteor. I doubt vanilla React will catch up with Meteor in marketing or ease of use because Facebook isn't hungry in the same way MDG is.
Let's avoid turning this into a "Meteor is doomed" or "Meteor failed" comment thread; Meteor is and has been growing consistently since it launched (see: https://twitter.com/Rahul/status/673992512768507905). The title of Sacha's post reads a bit inflammatory, suggesting something "went" wrong and that it's too late now. Rather, as his post explains, the community is currently in a bit of an identity crisis as two groups with disparate sets of opinions on where Meteor should go from here collide.
As someone who's been building with Meteor since 2012, I see all of this as a good thing. It's a sign more and more people are lending their voices and opinions to Meteor's direction. As NPM support arrives with 1.3, and as a more agnostic approach to view frameworks becomes part of core, we'll continue to see more people join, because the platform will be more open towards them.
Meteor was a new platform. It's now a mature, growing platform. And it will be a successful platform if we all keep contributing.
The post's title is "What Went Wrong". What kind of comments were you expecting here? Running an OSS project is no different than running a startup in a lot of respects – marketing and PR matters. It's great to write candid posts like this, but you can't jump into other forums where the post has been linked and try to manage the conversation after the cat's out of the bag. It ends up sounding like damage control.
Instead, you should welcome further observations about some of the perceived mistakes the Meteor team made and point out specific examples where they're being addressed.
About the tweet: It's not a graph, rather some neat bars, until it has some numbers. It is suggested that it shows relative growth, make it relative to point zero and you get undefined-ly long bars, or compress it to make it look like the product is stagnating: http://i.imgur.com/TOBLaSa.png
Also, consistent growth isn't really enough, usually, to capture a market and exponential growth is usually expected from startups.
This seems to be the same issue with other frameworks when they get to a point where they have enough adaptation and find out they need to change/update parts of their framework to get it to the next level.
Same thing is happening right now with AngularJS. Been around for a while, had massive adaptation, then they realized they needed to make major changes. Enter pivot to 2.0 which pissed a lot of people off, but the heat is dying down now and people are coming to their senses.
I'm pretty sure at some point React and other frameworks will hit their wall too.
Rails didn't hit that wall. Neither will Ember. FYI Ember is introducing new ideas by the second (pods, composable components, components over controllers, DDAU, etc) but the community eagerly awaits and embraces them. I don't know why that is.
This is really a fantastic point. It's sometimes as if people think these type of projects exist in isolation and any perceived flaws are permanent. They often fail to appreciate how much the flaws will invoke a response to address them, making them better than they would have been had the flaws never been strongly felt by the community in the first place.
If you had just posted the comment without "Sorry, but" at the beginning it would have been a great additional insight rather than disparaging to the OP :)
> The Million Dollar Homepage is a website conceived in 2005 by Alex Tew, a student from Wiltshire, England, to raise money for his university education. The home page consists of a million pixels arranged in a 1000 × 1000 pixel grid; the image-based links on it were sold for US$1 per pixel in 10 × 10 blocks. The purchasers of these pixel blocks provided tiny images to be displayed on them, a URL to which the images were linked, and a slogan to be displayed when hovering a cursor over the link. The aim of the website was to sell all of the pixels in the image, thus generating a million dollars for the creator.
The sheer "internet"-ness of the idea at the time was brilliant. It also seems like the kind of thing you can only really pull off once. And it was funny watching it slowly fill up, discovering what kind of businesses turned out to spend on something like this, what colours they attempted to choose to stand out, and how the result was a chaotic mess with everyone fighting for attention. Subtle commentary and somewhat prophetic of the current situation with ads...
Highway1 (http://highway1.io) is doing a great job of helping startups figure out how to get their manufacturing strategy set up. The advice and insight the two companies I worked with in their most recent cohort (Spinn Coffee and Game of Drones) received was absolutely essential to getting off the ground, so I'm expecting to see more of this kind of incubator/accelerator in the future.
