Could you explain the thought process behind that decision and how you view that decision now that you’ve moved to Capacitor? What are the advantages/disadvantages?
If I just concentrate on Capacitor with Electron vs Meteor-Desktop then it boils down to using version 10.1.3 (which is the last I can use right now) vs version 14.0.0 in Capacitor. Quite a difference.
As much as I understand Capacitor is agnostic to the frontend framework so using Blaze shouldn’t be a problem. Do you know that?
We noticed the lack of maintenance on Meteor-Desktop (and a seeming unwillingness to pull this into core, which make sense I guess), so initially intended to take over development ourselves.
In our opinion the Cordova integration with Meteor never worked perfectly, so we migrated from Cordova (bundled with Meteor) to Capacitor because it’s just so much lighter; it’s really just a WebView which allows us to expose native APIs.
When we noticed that Capacitor Electron existed as well, we experimented with that and found it further simplified/unified our stack.
The main benefit of Capacitor vs Cordova is that it’s newer and more lightweight, just a smaller and more modern codebase. The main benefit of Capacitor Electron vs Meteor Desktop is similar; a smaller codebase and support for later Electron version.
We chose to rely on server.url (load files from web) instead of bundling the assets with the application, which makes updates easier and less error prone (just a reload), but does make “compatibility versions” a thing of the past. For us taking this (no compatibility versions) in our development process was preferred (simply check whether functionality is available and if not gracefully decline) over writing potentially complex update logic.
Capacitor is just a wrapper around a webview, which loads files from a local server (like Cordova in Meteor) or from a server (server.url in Capacitor), so anything that works in a browser works in Capacitor.
Bedankt Koen for taking the time to explain the reasoning and also share your real life experience after switching. It’s these posts that will help people in a similar situation.
For now I have to focus on other, more important tasks and stick with Meteor-Desktop. However, given on what I read and watched on YouTube about Capacitor and also your confirmation on the benefits I think Capacitor is the better alternative long-term. Especially as we’re falling further and further behind in the version we can use though @efrancis has done a great job lately to fix bugs and breathe some life back into the package!
There were very little challenges to be honest. Meteor makes use of Cordova, and Capacitor supports (almost) all Cordova plugins.
I think to create a working Proof-of-Concept it took me no more than 2 hours. Simply initiate an empty Capacitor project, copy the cordova-plugins from the Meteor project, point server.url to localhost:3000 (set cleartext: true in server object in Capacitor to allow HTTP traffic) and run Capacitor Android/iOS on your phone/simulator.
We boilerplate a lot of things at our company, but even creating a ‘starter project’ for anything Capacitor-based seemed like overkill.
It’s now almost 3 years later and Meteor.com still proudly displays this right on their home page
Meteor is an open source framework for seamlessly building and deploying Web, Mobile, and Desktop applications in Javascript.
Yet meteor-desktop is stuck on Electron 9 with Electron 21.1 now released. That marketing is a bit deceptive atm. I’ve been using Meteor for 6 years and have been happily hosted on Galaxy for 3 years but with support like this it’s hard to recommend Meteor for any new project unfortunately.
As a consequence some developers have left this package and switched eg to Ionic.
I’m having less and less Meteor dependent code too, it’s not only good to have other options but also to be not putting all my eggs in a basket that is constantly maintained by too few developers that work for Tiny. Whilst I certainly see that Meteor is doing more than let’s say a year ago, it’s still too few people working on too many problem areas (which comes from years of neglection and little investment by Tiny and MDG before that).
I have two projects that depend on meteor-desktop and I’m really concerned now. This is the first time I’ve had these kinds of concerns with Meteor. It’s also a community package now - meaning it’s kind of vendor-embraced - and it’s sad to see how it’s being let go.
Could someone from Meteor comment on either getting that deceptive content removed from the Meteor.com marketing website, or getting some better support for meteor-desktop? It’s really misleading as Meteor does not really support desktop development atm.