Meteor-desktop needs to have first-party support

#1

Since Meteor is receiving a new resurgence of funding and engineering backing, I think it’s time to discuss meteor-desktop. This project adds a desktop environment build target via Electron, similar to how Meteor uses Cordova for mobile targets.

The problem

The project is seriously impressive, but its support has dwindled and now it’s 5 major versions of Electron behind. You can no longer submit apps to the Mac App Store because it rejects apps built with older Electron versions. Critical security and performance fixes are only in newer versions. Community support for Electron v2 is pretty much nonexistant.

This stuff happens in open source and I don’t think the project maintainer is to blame here, but others are struggling to get access to help support the package and there are companies like mine who’s core business model depends on having support for a desktop build target. As a small startup focusing on building a product we simply don’t have enough time to dive in and take full ownership of the package ourselves.

Bringing full support to meteor-desktop

I would really love if this could be brought into the limelight and supported as a core build target, alongside iOS and Android. This could be a big marketing point for Meteor as the easiest way to get an Electron app codebase up and running while Electron continues to gain popularity as the easiest way to target cross-platform native applications, and it would be very much appreciated by community members like myself who heavily rely on the package.

21 Likes
Making a MacOS desktop app using Meteor in 2020
#2

This is a huge sticking point in the usability of Meteor for prototyping and as a ubiquitous framework.
I can build for Web and then deploy to mobile and desktop apps later on without huge modifications using tools like React Native Web or Nextron. Meteor needs this flexibility in order to stay relevant IMO.

2 Likes
#3

Meteor was a leader in cross-platform builds, introducing “meteor add-platform ios” and “meteor add-platform android” before React even existed.

Back then, “meteor add-platform desktop” seemed like the logical next, but somehow that never became a project that MDG took on. It’s not too late. With apps like VSCode being built in Electron more and more people are seeing its utility and looking for the easiest way possible to build desktop apps or desktop clients using it. And there are already packages in existence that have allowed meteor apps to build for desktop clients. So Meteor wouldn’t have to start from scratch here. Looks like this just needs Meteor to take it up as something worth doing in 2020.

#4

Can someone from the Meteor team comment on what they think about getting desktop supported as an official build target?

#5

As Desktop PWA’s are now supported by all major OS’s (Linux, macOS, Windows).

Would a Desktop PWA meet the majority of people’s requirements for a desktop app experience?

I am curious what additional benefits (current and long-term) may exist by turning Electron (meteor-desktop) into a 1st party supported build arch/platform vs Meteor focusing on becoming a great PWA for both mobile & desktop?

Google isn’t the only big player who advocates for PWA’s.

Microsoft has been drinking the PWA kool-aid for awhile and have been turning PWA’s a true first class citizen alongside native apps within the Windows 10/Universal Windows Platform (UWP) ecosystem.

You can already submit PWA’s to the Microsoft Store (resources and dev tools to do so). Once accepted into the store these PWA’s can be installable across all UWP devices like desktop PC, Xbox, Mixed-reality headset (halolens), etc..

Here’s a 1 min 45 sec video by Microsoft highlighting their PWA support along with some of the additional platform specific features you can add to PWA’s when they are installed on a UWP device.

3 Likes
#6

Part from having access to the local file system, what advantage has Electron for desktop over the web app we can already build?

To me it sounds like it’s a very niche use case and while it’s understandable from a business perspective (as I run my own startup as well I get your situation), I want priorities to be set so that projects that affect the majority of Meteor users will be handled first.

To me it sounds like a second order project, sorry.

#7

Make that 2010 but not 2020 unless someone explains to me why desktop apps are the new 2020 hype.

Checked the hype cycle and somehow it’s not in there :wink:

#8

A few thoughts

The local file system is an obvious one, access to peripherals is another.

A third - which is probably more common - is the bundling of a specific browser version. The software I build is B2B - and the users are told repeatedly to use Chrome, and yet some still use Safari. While the idea of the software working fully across all browsers is ideal, it’s not always the case, and the dev time to find and fix all the browser specific quirks is prohibitive and some very odd browser specific bugs come up. Even if coaches are using Chrome, there are some weird things that change between chrome versions which can be extremely hard to debug, some of these are deprecation’s and can be found with care, some of them are pure bugs in the browser. By bundling the application as an electron app, we can tie users into a specific version of Chrome and avoid all these issues.

A fourth is performance reasons, any data intensive app that is used across multiple tabs requires individual connections per tab, with data being sent repeatedly to each tab. While the use of an application specific client side data cache could help with this, it is usecase specific. Bundling the app with electron gives the possibility of a single data connection from the electron side, with each tab/window using that same collection to reduce data transfer and improve performance.

A fifth reason is the UI - there are limits on what you can do with a PWA, namely - no tabs, or split views, unless you encode them into the application itself. I won’t go into all the details of this drawback, but switching from a full browser to PWA doesn’t allow you to have tabs, and split views are ONLY possible within electron, unless you make them visible to web users, which isn’t always desirable (e.g., only enabling Meteor.isCordova, etc). Similarly, if you want modals without electron you are limited to two types, in app modals (stuck within the same window) or full new windows, rendering the entire meteor app a second time (potentially with a specific route). Using electron gives a third option: custom modals designed specifically for your app, these could still be built using blaze/react and thus reuse code from your main application, but would not require the entire JS bundle be evaluated by each modal. I’ve found (only in a controlled test environment so far) that this can make the opening of modals significantly faster, which vastly improves the UI experience.

Lastly, while Microsoft has embraced PWA’s, Apple has not - you cannot submit PWA apps to the app store, which has an (admittedly small) impact on branding.

It’s worth noting that I am a massive proponent of PWA’s I hate having to build iOS apps with cordova just because Apple doesn’t want to support PWAs on iOS. It drives me mad.

1 Like
#9

Our app is probably well qualified as “data intensive” as we do handle DNA data and people have thousands of matches which need to be compared for both copies of the same 23 chromosomes.

But we use MongoDb and AWS to handle that in the cloud so that no matter how slow the users PC or Mac or Linux or device is, he will still get his data in the same time. It just takes longer to maybe display results when we use D3 and use graph networks with the force algorithm but again I wonder why you haven’t considered moving to a web app and utilize the full power of the cloud instead of relying on users desktops (and using multiple tabs).

Like I wrote above (with tongue in cheek) that isn’t a technology of the current era IMO. It’s a relict of the past and when people point to Electron desktop apps like Slack or MS VS Code then I have to point out that they take a huge amount of memory in comparison to their features.

Moving away from your desktop to a web app is obviously a bit investment in time and resources but it will pay off IMO.

But I really can’t see even with the 5 points mentioned above (which are probably all valuable pain points for you) why this should be a first-party support for Meteor when the number of current and potential users will be small (not even talking about the market for such apps).

#10

Forget a hype train.

I have a need to make a desktop app. If you don’t have that need, maybe start your own thread. But please don’t come here telling me that my needs aren’t trendy enough. I’m here to see who else has those needs, and if Meteor sees a value in extending their cross platform builds to desktop, to become a true deploy anywhere solution.

3 Likes
#11

Meteor supports Cordova, Electron is akin to that. PWAs don’t supply nearly the same solution as Electron apps, which have access to a number of desktop APIs that a webapp can’t use.

VSCode, Slack, Skype, Discord, WhatsApp, Atom, they all use Electron. It provides a compelling solution for those who want or need cross-platform desktop applications, and a number of billion dollar companies are using it.

#12

Data intensive has many meanings - doing work on the server side is a viable solution in some cases, not so in ours. Our users often wan’t to look at multiple intersecting sets of the same data (statistics for person X across period Y, then statistics for person X + … across period […, Y, …]) - also, the granularity they need really precludes us from doing much aggregation on the server, all the data really needs to be sent to the client.

Perhaps consider for a moment that I have considered moving to the cloud - and indeed utilise many of the same components you probably do. Mongo, AWS spot instances, lambda, etc. Some things simply require significant data be sent to the client, unless you really want to do all the client side rendering on the server, which has it’s own drawbacks and limitations.

Also, perhaps we’re talking about different things, but my guess is that many people on this forum (the one for a webapp technology…) who want electron are already using a webapp, and in fact want to move in the other direction, for numerous reasons.

Regarding the resource consumption of those apps you point to - ignoring for a moment the scale of the companies you’re talking about: microsoft, spotify and slack all service millions of users - I have not found the resource consumption higher than an equivalent chrome tab running the same software. Of course, if you are comparing electron to a native custom built and optimized app, then of course electron will lose.

All this being said - I don’t necessarily think that Meteor should fully support electron. What I want to see instead is them refactor their build process to allow for electron and cordova support to be added separately, in a customizable way. Recently I tried changing the cordova built to use the modern web bundle rather than legacy, and it was a nightmare, I had to abandon it - what seems like it should be a simple flag is not at all.

#13

For what it’s worth I did end up producing a desktop app using Meteor + Electron. It’s listed in the Mac App Store and has received sales. If desktop apps are not a technology of the current era, then the actual people who demonstrate that they are willing to pay for desktop apps would beg to differ. Nothing outlives it’s usefulness. The Mac App Store exists because commerce is happening on it. If it would be of a bygone era then it would go the way of iTunes.

As for the process itself… It wasn’t easy. Went back and forth with different versions of Electron, bundled and un-bundled node and mongo, and sand boxing the app wasn’t entirely trivial, but all no of this can be made easier with better documentation and tooling.

1 Like
#14

I would also love to be able to publish an Electron-based desktop app for my Meteor app. I’ve already added PWA support with a service worker and everything, but the fact is, many of my users simply want a standalone app so they don’t have to access the app through their browser. PWAs don’t cut it.

I tried meteor-desktop in the past and got it semi-working, and from looking at the repo it looks like folks are still working on it in various forks and branches, though I don’t know how close it is to being brought up to date and working.

@larry, if you have any hints to share about what ended up working for you, I’m sure it would help the effort…

#15

@banjerluke this month they updated the main branch. Prior to this, I have an issue on their github where I detail what ended up working for me.

#16

meteor-desktop works fine if you follow the docs, we’ve been releasing regularly for over a year now. It took a little while to get the full pre-release and release build pipeline in place for Windows, macOS and Linux w/code signing and there were a few gotchas we encountered that were specific to our build and some native c++ libraries we were using but once it’s set up you can just forget about it. They’ve recently updated to Electron 6 (from Electron 2) and decoupled the various internal components for building and packaging, so it’s in the best state it’s ever been now. I’d recommend giving it another shot.

2 Likes
#17

+, this really could be important for the future of meteor. We use meteor-desktop, but there really a bunch of issues like lack of support for last versions. Our fork located here, we resolved a bunch of current issues, but any help is very appreciated

#18

There’s been a good amount of recent development in the main branch, if you have improvements open PRs to get them back in :slightly_smiling_face:

#19

We will do so soon, just haven’t enough. time recently :slight_smile:
When we only started our fork repo was a bit staled, with some open (useful) PRs, without any response from wojtkowiak, so we did a bit of incompatible changes. Looks like we need now to make a branch which we will be able to apply to master when opening PR back to parent repo in order to provide compatibility