All in all, it’s a tough situation. When Meteor came out and for years after, there was nothing that could compete. The real truth is that it’s still true to this day, but that day is soon coming to an end. Nothing in plain Javascript currently offers full stack reactivity. Firebase is closed source and far from a complete solution. RethinkDB is just the database and requires you to manually hook it up to a webserver as @mattkrick has done with Meatier . GraphQL and Relay is slated to have subscriptions, but doesn’t yet. When that day comes, MDG will have to cook something MAJOR up if it wants to stay competitive. Otherwise, there’s no way people like myself can recommend Meteor anymore for top tier apps–not when NPM allows you to customize even more, which top tier professional apps will always eventually need.
It’s a tough one. It’s why ClojureScript is looking more and more like the answer to me. If everything is going functional, I rather just program in a functional language to begin with. If it’s geared towards being full stack from the start in combination with Clojure on the server (which is the same language, plus a few lesser-used features), perfect. If it’s reactive by default and even has a database built for such subscription-based usage, I mean I don’t even know what to say about that–that’s a dangerous combination. If it’s combining the best of React, Redux, Relay, GraphQL already, from the ground up with no legacy APIs to support, hmm. The only downside is I have to learn a new language and new programming paradigm? And for many that’s probably not even a downside, not when it’s upping your programming skills to such a degree. I personally have enjoyed it, and it’s been exactly what I need at this point in my career where I haven’t focused on a new language in some years. So you do the Math–Meteor absolutely positively must come up with something groundbreaking/world-changing again if it wants to not get lost in the sea of options that will be competitive by this time next year.
I love Meteor, and owe a lot to Meteor, which is why I’ve taken the time to voice a lot of this. I’d like to see Meteor have what appears to be the never-ending lifespan that something like Linux has. Meteor may have the opportunity to be the operating system of the “connected client.” If it want’s to achieve that level of permanence, something else will need to be dreamt up. But right now, Meteor is risked being dethroned over night. I guess what I’m saying is: Meteor can’t even win if it does a perfect job at copy-catting the latest and greatest (and whether they can do that is far from a known at this point in time); it needs to come up with something as groundbreaking as Relay + GraphQL. The question really is: is Meteor a “one trick pony” [full stack reactivity] like Google has always been criticized for search, or does MDG have something new and equally (if not more so) magnificent to bestow on the world of web development?? And most importantly, what is that, what would really make Meteor the OS of the connected client?
ps. this is the first time I, myself, have thought of these questions framed this way–but what quickly came to mind is: being the brain of all possible clients (browsers, phones, desktop apps). So, a way to really feel like you’re at the center of a codebase serving all potential clients. Really nailing that in a super consistent idiomatic way would be big. It really looks like–once Relay/GraphQL has support for subscriptions–everything else is nailed. I’m less of a fanatic about MySQL support than many, but I guess if it could show it offers support for at least 2 databases, then Meteor will really come off as a sort of operating system that lets you plugin in whatever software you want into it. It seems the GraphQL abstraction layer will go a long way to promoting the development of support for other databases. It will push a lot of common problems into code that can be shared between multiple DBs, and in doing so pave the way for plugging in more DBs. Nail integration of Reactive Native and Electron on the top of the stack all from a single folder in your file system that you can run commands on all utilizing shared code, then you have a recipe for success.
I guess that’s nothing new, and likely the realization MDG had when they brought in Cordova support. But it still needs something to feel more like an “operating system.” A command-line only operating system like Linux maybe worked 25 years ago, but in 2016 we need a GUI. One you can access whenever you are working on your app in the browser, similar to Dr Mongo and @msavin 's Meteor Toys. You open up the panel and you can see big buttons for each device you support, you can click each and you can examine static stats for each codebase. I say “static” because there would be plugins for things like @arunoda’s Kadira to display aggregate/statistical runtime stats within the platform. That way MDG wouldn’t be responsible for building all of it.
Anyway, one can pontificate forever. Clearly MDG is moving in this direction and execution just takes a while. I guess I’m just saying, marketing is an important aspect, even if all the sub-pieces of the puzzle aren’t ready yet. And to achieve that use a web-based GUI to give the feel of a real operating system, not just run time stats in galaxy of your server, or what kadira does, but something you can use in development before you even launch your app that gives the feeling that all the clients you support are orbiting around your Meteor server, that you’re achieving the closest thing possible to the “holy grail” of write-once-run-everywhere. I think at this point in time–especially thanks to React Native–we’ve come to understand that write-once-run-everywhere is pie in the sky. I’m very ok with what React Native has come up with–based on lots of experience at this point of the custom needs that apps of different screen size and capabilities really do have, I wouldn’t even want write-once-run-everywhere. It makes a lot of sense to put deep fine grained control across-platforms of code-reusability in the developers’ hands.
So that’s the sort of stuff this GUI could help you with–do things like product “coverage” stats of how much common shared code you have, and let you drill down into the files. Perhaps, wire up different github REPOs for different clients–that way they dont have to all live in one repo, but your meteor app can conveniently see them all is one (that perhaps is the killer feature here!). I don’t want to make an Electron app by copy/pasting generated client code into the of an Electron app. That’s an obvious one, and obviously Electron is far down any sort of Roadmap.
You get the idea: Meteor needs to really supplant itself somewhere to have the sort of permanence Linux has. The whole competition with NPM needs to 100% be eliminated asap. We have to be 100% NPM compatible (for reasons discussed elsewhere). Once we do that, we’re in a scary point in time–because then if that’s truly done right, Meteor is only a build tool, and one which will be replicated using Webpack or other (so you can run the same codebase without calling meteor from the command line). So for when that time comes that Meteor has essentially given all its value back to the NPM community, it needs to have a new Killer App, and that’s a panel of sorts as just described. Then from there, the business concept is that it segways nicely into the even better paid Galaxy panel, which takes production/runtime stats into consideration. But both should feel like a consistent experience. The latter a natural evolution of the development experience. From a marketing standpoint, that will give javascript developers something very solid to look at and latch on to and say “THIS IS METEOR. THIS IS WHAT METEOR PROVIDES ME. IT DOESNT REMOVE FROM THE GREATER NPM ECOSYSTEM. IT LETS ME MANAGE ALL [or at least %80] THE TOOLS MODERN APPLICATION DEVELOPMENT REQUIRE.”
)