As mentioned in the issue on GitHub I think Meteor should provide a reference implementation for Cordova, just like it does for React, Vue and Angular.
In a world where React Native, Flutter, Ionic, Electron and maybe even most interestingly Capacitor are taking care of providing any (Web) App with a (cross-platform) native layer Meteor should in my opinion not invest heavily in supporting a single platform.
The Cordova integration currently boils down to:
some CLI commands which map to Cordova commands;
a build step which copies the Meteor app into the Cordova project;
a plugin which both serves the Meteor app files to the Cordova WebView and enables Hot Code Push.
All of these things could easily be abstracted away from a specific integration between Meteor and Cordova (take the meteor-desktop (Electron) project for example) and allow for a more generalized integration.
For us it doesn’t matter really, we are slowly migrating away from Cordova either way (currently our best bet is on Capacitor), but it would be a shame to put significant resources towards an integration which isn’t ‘top of the line’ anymore.
Just my two cents, albeit not what people may want to hear.
Yes, I also agree, in the long term a transition to Capacitor is something to consider as it supports Cordova plugins, the main goal would be to improve our DX without losing compatibility with existent applications. We always need to keep mind that Meteor is used by many companies to deliver native apps and we don’t want to force anybody to rewrite their apps, we need to do our best to keep things working, but a possible Capacitor transition in the future could be done in a smooth way I think but I would need to understand and test this more.
My two cents about next steps:
Update Cordova version and fix any existent issue.
BTW, I have some native apps published with Meteor then for sure the integration is not broken right now but could be in a better state and with better docs.
I agree. If Meteor can expose hooks that allow other native/mobile app development frameworks to plugin to the CLI and build process to enable a similar integration then we can spin off Cordova integration outside of the Meteor core allowing for faster bugfixes and updates.
This is great news from my perspective, I was kind of worried that the Cordova integration would fall by the wayside. But if that is kept up to date and is a viable option for building a cross platform application that is a tangible benefit to Tiny taking control of the Meteor project. One of the biggest selling points to me about Meteor was the ability to build mobile applications so I am excited about this announcement
And if Capacitor takes off and becomes the Cordova of the future I agree that its a good plan to switch from Cordova to Capacitor if and when that day comes. Thanks for all the updates @filipenevola
Agree 100% on the need for a reference implementation. Cordova can be done very right, or very very wrong. Users shouldn’t be able to tell that it’s not native so an implementation that is performant (snappy, conscious of CPU usage) and built with a native-mimicking framework like ionic would be a great start to show people that it can be done right. If you just say “Cordova integration” I know a lot of ppl who won’t even consider it because it gets a bad reputation for clunky and slow apps.
I’m currently using meteor-imports-webpack-plugin to integrate with Svelte-Native. It works pretty well so far (caveat: I am not that far in to it). It allows me to pull in meteor packages, and other assets defined in my meteor app, without having to use a lot of re-implemented alternative ddp connectors. Perhaps this is the way to integrate with third party build systems? It should work for Cordova or React Native, with a similar set up.
Once I have more proof of concept pulled together (looking to get at least some login stuff working), I’ll post a starter.
These have been mentioned above but I will just add my reasons why I supported the decoupling of cordova integration from meteor core
Major reason was the resources allotted to maintain meteor core was not enough to do other stuff like maintaining the cordova integration. I believe the community is more than willing enough to help keeping the cordova integration up to date
And talking about keeping it up to date, I think we are two major versions behind.
There is this ongoing issue with Apple potentially blocking apps with the old webview engine and this is currently being solved by cordova. This potentially means a new version and I am not sure how fast we can use it
And there are other frameworks and libraries out there that are compelling alternatives with cordova eg. capacitor, react-native, etc
If Tiny, can help with 1, 2, and 3 above, then that is good. #4 will be amazing