Also take a look at ElectroMeteor and Electrify. They also seem that are not being maintained,
Yes this is the biggest issue @filipenevola, the package is fantastic and does all the work required to use Electron but the community is unable to contribute and it has a ton of open issues. Bringing it under an official meteor or meteor community org would enable us to keep it moving.
Someone has built a complete integration for Electron and it adheres to Meteors build target concept already, little work is required on Tiny. We just need to be able to maintain and update it.
3 Likes
Perhaps it is time to consider just forking the package? It seems like a good candidate for the meteor community org as there seems to be people willing to pitch in. As it is released under the MIT license there should be no legal restrictions to forking. It’s certainly polite to ask first, but that has already been done.
2 Likes
I second that. The original author hasn’t responded in a long time to both issues as well as to requests to update the package.
Forking it is a short term solution to implement bug fixes that are outlined by the various users but IMO its most important that this package is taken in under the official Meteor community as @efrancis also proposed.
1 Like
Now that desktop support is being prominently on Meteor.com I think it’d be great to revisit this. For example with HMR in Meteor 2.0 now, getting HMR support for desktop apps would be very helpful for faster development.
Or as another example, releasing an auto updating Electron app requires deploying to an S3 bucket. It would be amazing if Meteor Cloud supported this while deploying so that we could move entirely off of AWS and to Meteor Cloud instead.
4 Likes
PWA may be a first step for devs to support desktop platforms. What do you expect from your Meteor PWA (Draft here: https://github.com/activitree/Meteor-PWA-Explained) - #22 by paulishca
We can add a new section “Create PWA in X steps” to tutorials.
2 Likes
Let’s first take it over into the Meteor Community and fix those large amount of open issues.
Then we can look how we develop this package further.
1 Like
I think it wasn’t announced yet but thanks to @koenlav and @copleykj we now have the Meteor-desktop package under the Meteor Community umbrella:
https://github.com/Meteor-Community-Packages/meteor-desktop
Please report any issues that you find there so that we can improve the package further on.
Thanks Koen and Kelly!
5 Likes
@koenlav @copleykj do you still own that meteor-desktop community repo? I’d really like to get this fixed asap and get it published to npm. Mongo Atlas is forcing some tiers to Meteor 5.0 which requires upgrading to Meteor 2.6, and meteor-desktop is currently incompatible with Meteor 2.3+ because of this issue.
That means anyone using meteor-desktop is going to have their app break in production some time next week unless this is fixed and released to npm.
We have migrated away from meteor-desktop and started using @capacitor-community/electron.
We actually migrated our entire stack away from “Meteor bundled hybrid layers” (Capacitor/Meteor-Desktop) and moved entirely to Capacitor.
The MongoDB 5 upgrade is only forced for free-tier Atlas clusters, so this should not impact production apps.
If someone is willing to pick up the Meteor Desktop project feel free to mention this here (or beter: GitHub - Meteor-Community-Packages/organization: Discussions on organization of the organization 🎩), it should be relatively trivial to fix these bugs.
Thanks for letting us know, Koen.
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?
Thanks in advance,
Andreas
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.
4 Likes
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!
We had the same conclusion. We were to explore Capacitor when PWA presented itself to our team and we realized that PWA is perfect for our use cases.
Capacitor is still on my “wanted to try” list and still waiting for a good project needing the features it provide
Ahem, what do you do in your free time … just joking.
If you try it out, please let us know how it’s working out. I’ll do the same
Thanks for sharing!
Did you use Capacitor in a Meteor project? If yes, what were the biggest challenges?
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.
3 Likes
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.
3 Likes
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).
3 Likes
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.