The easy mobile back end field is beginning to narrow. Reasons cited include competition in the cloud space from Amazon, Google. While using AWS with Cognito, DynamoDB etc. is pretty sweet when it’s all up and humming, there’s some serious yak shaving to get to that point.
I think there’s an opportunity for Meteor here that extends beyond Cordova support.
Being one who spend a lot of time on parse, i will surely miss it! But since i didnt build any large production app in it ,I’m safe! While meteor is awesome ,its frustrating building on mobile. i prefer native! because performance matters!
Meteor really needs React native since Cordova isnt performant or Dont try to be all at once… meteor belongs on the cloud(just a personal opinion!)
I hope those who are affected with this announcement finds an alternate and a backup for that alternate too. Time to learn Angular in case FB decides to get rid of React 
I’m in complete agreement. Perhaps react native support is the answer, but official native SDKs for iOS, Android would be nice. While I get that that’s a diversion from writing JS code, it’s not that hard either. And while community contributions are cool, this is such a core part of a mobile app, I think many people/teams/organizations would rule out basing a big native project on a community package with uncertain support.
On the other hand I have to wonder, if Facebook, with all of their economies of scale, couldn’t make enough money with Parse to justify keeping it running…
Sure it can happen to React / React Native as well. It’s great that Meteor is opening up to the JS community; though I’d like to not see Meteor turn into a “React stack” and have some perspective.
Yeah I think with the new data stuff we are working on part of the focus should be making it work with a variety of frontends. So that you can easily spin up a GraphQL server on Galaxy and call it from a simple client on iOS or Android.
Even Angular is not an official product of Google, if that is your concern…
True!
It’s not Cordova, it’s the web. There are ways of doing things performantly, and ways of doing things in a completely non-performant manner. For example, here’s a tiny web-app with simple animations that could have us tricked for a native app: https://www.pokedex.org/ (try it on both mobile and desktop).
WebGL is plenty fast. We can code an app entirely in WebGL. “Native” environments like those in Android or iOS simply have more history and more libraries for working with OpenGL, but more JavaScript libraries for WebGL are appearing. For example, here’s a new library for rendering fonts in WebGL. With that, we can imagine animating quads with text in them (i.e. a UI) performantly. Soon, there will be libraries that make it easy to render UIs in WebGL instead of with DOM.
DOM itself is getting a ton better than before, especially if we use hardware accelerated transforms for animation, as in this example (try it on both mobile and desktop). The elements of the periodic table are just <div> elements (not WebGL!) animated in 3D with an (outdated) CSS transform technique! The performance can even be further improved using more recent techniques (nesting elements to take advantage of transform caching). That demo is buttery smooth. Imagine using the same techniques, but moving rectangles that are composed into the UI of an “app” instead of a floating periodic table.
So, really, it all boils down to knowing how the web works, and taking advantage of certain techniques, and leaving other techniques behind in the dust.
If we’re using jQuery (for example) to animate things, then of course things will perform badly, because the techniques in jQuery are outdated (even though they still work), of a time before hardware accelerated CSS transforms. Animating top/left properties of an element’s style in JavaScript won’t be hardware accelerated at all, and will eat CPU time away from all the other stuff you need to do (as opposed to running animations on the GPU with CSS transforms).
A-Frame is a new library by Mozilla for writing Three.js scenes using HTML. It’s a really good example of where the Web is heading, and shows how me implement HTML interfaces that render performantly (just like “native”, with emphasis on the quotes). I myself am also involved with a project with similar goals of providing an HTML-based, easy-to-use 3D library that will mix DOM with WebGL (and aims contain the aforementioned idea of rendering text (and images too) in WebGL instead of DOM.
In due time, the web will win! 
Agreed, I think it would be really great to have some solid native mobile SDKs that make it easy to work with Meteor on the backend. The new Meteor data layer is very exciting and a lot of app developers could benefit from being able to use it. Cordova works great for some use cases, but plenty of serious app developers will want to go native. No reason they shouldn’t be able to use Meteor!
True, nonetheless, despite my affinity for the web, it would definitely be awesome for native developers to partake in Meteor.
(Or maybe we can lure them in. Muahaha).
Also, in addition to your great points, for Android you should use Crosswalk and for iOS wkWebview. You will get great performance out of the box.
I think you’ve replied on a post on our startup before. You definitely know your stuff about performance, paints, etc.
Have you ever considered writing an article about this? I’d love to learn a thing or two from you about that topic since I believe in the power of the web just like you 
!