Not having to spend money on Blaze will make them more competitive as a hosting business. Frankly, when is the last time you saw a billion dollar unicorn hosting business? Or a hosting IPO?
I doubt we will see SQL support. We will likely see something with GraphQL instead.
Heroku is probably the closest case study, in that they started as (and mostly remained in the popular conscience) a Ruby on Rails host. I believe they sold for $200+ million. Not a "unicorn", but not a small exit, for such a short period of time. They were only around as an independent company for a few years.
As a developer who is only using them for a personal project so far, I don't care one way or the other if they are incapable of becoming a unicorn - I just want them to be profitable enough to continue developing the framework. They may be under too much pressure from their investors to go that route, but wasn't hosting MDG's monetization plan from the beginning? If so, savvy investors would already know the likelihood of unicornization was low/zero when they invested.
You're certainly much more in the loop about SQL/GraphQL. Would GraphQL allow non-mongo databases to push updates out to clients for reactive updates?
Thanks for running Crater.io - I've been reading it a lot recently!
Meteor has as a better chance than ever, ESPECIALLY if 90% of what you can do in Meteor you can do in "bare metal" NPM! Meteor doesn't have to provide that many "features" to win over the NPM crowd that it has struggled to acquire thus far. It's so damn complex to implement all this stuff that most developers need help doing it.
Meteor's problem thus far has been it makes it easy but provides no way to "drop down" to a lower level and configure things like you would on "bare metal" NPM!!!! Despite its easiness, this has scared away many developers from Meteor--especially the expert developers who would otherwise evangelize once they joined Meteor.
Therefore, Meteor just needs to provide a way to BOTH do things with sufficiently less boilerplate (like it's always done well), but also allow you to drop down to make lower level tweaks as you would on "bare metal" NPM. And perhaps even an intermediate tier in between for some features.
For example, Relay + GraphQL is great but there should be the "beginner's way to Relay."
So the killer feature in fact isn't a "feature" in the traditional sense, but rather a mechanism that only a full stack framework could provide. Being the only full stack framework that matters (and the only "reactive full stack framework" in existence), Meteor is well positioned to scoop up the entire NPM market if it plays its cards right!
Unless this comment is from SMM team at Meteor, WTF? What is NPM market :)? "Bare metal" npm? Name single sizable project that uses Meteor? You do realise that for 90% of enterprise projects it's a wrong tool. There is no usable universial/isomorphic option, you can't expose API for external consumption, if you have to consume services on the backend the only cool feature that Meteor has is gone. Not to mention long term risks of what will happen to the project when vc funding runs out.
My assumption is that Meteor is moving towards becoming like any other app you can build on NPM. That means Meteor will be the wrong tool anywhere NPM/node/javascript is the wrong tool. That's a fine agreed upon limitation.
Currently Meteor is a layer above NPM, which is why I'm referring to NPM as "bare metal" NPM--you clearly knew exactly what I meant. Meteor needs to become an adjacent resource to thrive.
So my prediction is if Meteor does this correctly they will no longer scare away expert developers and grow more than they ever have.
NPM is a package manager. Expert developers are not scared it's just Meteor is horrible solution to majority of use cases that they need to address. You need to read up on what Meteor actually is and what it's limitations are. Major ones have being outlined above:
1) No usable uinversial/isomorphic option so SEO is gone.
2) you can't expose API for external consumption
3) you are tied to only supported storage backends
4) if you are not talking directly to storage layer it's only cool feature is useless
None of the above is limitation of node (or has anything to do with npm package manager).
yea I made up. But if you've been in any Meteor forum topics about NPM and support for modules etc, it would would make more sense. Meteor exists as a layer on top of NPM. It has done a lot of harm to its marketability. "Bare metal" in this case is a good thing, it's sought after deeper control which the Meteor community has awakened to realizing is a must.
"allow you to drop down to make lower level tweaks as you would on 'bare metal' NPM"
Meteor is entirely open-source and I've had no trouble diving into the lower levels to accomplish what I need to accomplish. Everything is split into reasonable packages and is relatively easy to traverse.
If anything, the Meteor team hasn't done a good enough job showing their true value (realtime via oplog->client updates, etc). Most of the current controversy stems from front-end developers jumping on the React bandwagon, splitting up the community as it stands. Not a big deal IMO.
this. and like most trends, it's shortsighted (and based upon the whims of contemporary front-end web dev fashion and not the needs of the meteor eco-system)
> First, Rails is not my job. I don't want it to be my job. The best frameworks are in my opinion extracted, not envisioned. And the best way to extract is first to actually do.
You are slightly wrong in your history of Meteor. It was extract from an app they built. Unlike Basecamp or Facebook, the app died off and they focused on just building the framework. So while it was extracted, I think MDG has missed a lot of the learnings that something like Rails gets from core contributors that are building applications and the framework together.
MDG has actually talked about taking one week twice a year to build 'apps' with the framework, but that just hasn't been enough. I am glad they are finally working with Meteor itself to build Galaxy and supporting Galaxy customers as well, that really gets some skin back in the game.
Imo, this post is just a manifestation of the deeper issue around profitability and the fact that MDG will need to jettison some of it's development costs and pick up a much larger base of customers if they want to be profitable.
Which PaaS also builds it's own programming framework...
You can easily use things like Heroku and Modulus to host your site. I think perhaps you are misinformed about your options and should read up a bit more.
I use Digital Ocean with MUP and it works great with minimal efforts.
What kind of load does that app you host on digital ocean have?
Edit: I'm not at all suggesting that isn't possible to self host a meteor app, I am saying that I don't know what the "beaten path" is for other companies/apps/products that have self hosted a meteor app to a significant scale.
It is a neat feature. I also hear that it will persist changes from node-inspector web interface back to your code itself... I didn't mention in the article as I didn't have time to confirm it myself.
Yeah, I am thinking of adding a debugging section as a PR to the Meteor docs.
Thanks. I was on the fence about listing testing as another form of debugging. Didn't feel right, but maybe I will write a separate article on that at some point.
I doubt we will see SQL support. We will likely see something with GraphQL instead.