Consider supporting downloadable frameworks

[mardy]

Hi!
My application is about 100MB in size, caused mostly by QtWebEngine. I've been thinking of some ways to reduce the size, and I'd like to bring forward the idea of having downloadable dependencies, that would then be shared in the user's system among different AppImages. This in a way can be seen as defeating the whole point of AppImage, but there might be a possibility of doing this without overturning the philosophy of AppImages. I just wrote a blog post with some brainstorming about the idea:

http://blog.mardy.it/2018/09/brainstorming-on-appimage-downloadable.html

I would like to gather feedback about it, especially to understand if this is something that people would use (I searched in the past issues, and I cannot find any request for such a feature :-) ).

[TheAssassin]

Our credo is "one app = one file". No external dependencies, nothing to care about than one single file per application. Disk space is cheap, and updates are cheap, too, when using https://github.com/AppImage/AppImageUpdate with its binary delta updating.

Any sort of "external dependencies" requires some additional user and developer efforts. You suggest to solve the problem of lack of frameworks by providing some "installer". That goes against anything AppImage stands for: we want self-containedness, installer-free experiences, everything must "just work". Applications should start up immediately after having been downloaded. When having external dependencies, how could you "easily" copy AppImages to a USB disk any more? Using more "assistants"?

Then, who's going to "ship" those additional dependencies? The only viable way seems to me to re-use some existing distribution systems. Maybe something like conan, which already provides some sort of "library download and distribution system". But that'd add a dependency to such a service.
The AppImage team is not interested in maintaining any centralistic systems. One of the biggest advantages of AppImages is their decentralistic approach.

Also, size-wise, most applications link to their very own libraries or a hell lot of different versions. I guess you overestimate the advantage of reducing redundancy overhead.

The best way to remove overhead from AppImages to reduce their filesize is to reconsider how applications have to be written. It's a huge anti-pattern to use web-browsers, web-engines or whatever to build real applications. Look at this electron stuff: every AppImage comes with a complete web browser. People are just too lazy to learn the right technologies for the job. Companies started to think "let's save a few bucks for wages and let's have our designers write the entire applications, not just design/create the UIs", and started to write real applications in JavaScript, a language that is just not suited for the job.
Web browsers are supposed to display websites, and not to be shipped in application bundles together with static files.

I don't think that will ever be supported officially. It'd break with our most important concet: "one app = one file".

[mardy]

Thanks @TheAssassin for your valuable comments (especially I didn't know about conan.io, I'll have a look!).

However it looks like you misunderstood my idea, or didn't read my blog post carefully -- or I just failed to express myself. The installer would be part of the AppImage; so, if you move the AppImage to an USB stick and open it in another PC, it will either work out of the box (if the target PC already has the dependency installed) or try to download the missing libraries. Is it more hassle than a single AppImage file? It certainly is, especially if you don't have an internet connection in the target PC :-)

Also, the system I describe is decentralized; it allows for central repositories, but at the end the final decision on where to fetch the dependencies from lies on the application developer.

But other than that, I agree with your analysis. And for the record, PhotoTeleport is not an electron app :-) It's just that I need the browser to perform the OAuth authentication -- I've thought the possibility of using the user browser, but that makes the experience rather worse for the user, in that he needs to copy and paste codes from the browser to the app. Or maybe the problem is that QtWebView on Linux does not make use of the user browser, but uses its own QtWebEngine...

[TheAssassin]

or didn't read my blog post carefully
And for the record, PhotoTeleport is not an electron app

I've read through most of your blog post, I've seen it's a Qt app which needs Qt's webengine. My words on the Electron and other web browser apps were more like for the next person to suggest something to make their bloat "more efficient". I see that you don't have any other choice.

or try to download the missing libraries

That means you're depending on an internet connection. With AppImage, it is possible to download an AppImage in some place, and then go to a disconnected computer and run the applications there. You'd have to manually copy "cached frameworks", which is very counterintuitive. That's a lot more hassle. That use case would have to be supported by your project, which adds more and more complexity to the "simple" system you might have in mind.

Our rule "one app = one file" is "simplicity in person". There have been lots of attempts to break with it, but all of them lead to a lot worse UX.

But hey -- AppImage is free software, and if you want to go that way, sure! But it can never be part of AppImage. I'm pretty sure @probonopd agrees.

[probonopd]

Hi @mardy

My application is about 100MB in size, caused mostly by QtWebEngine. I've been thinking of some ways to reduce the size

No need to reduce the size. We have seen way larger AppImages.

and I'd like to bring forward the idea of having downloadable dependencies

The main point about an AppImage is that it has no dependencies besides the target system (= least common denominator of default installation of most Linux distributions).

If we would allow for dependencies, then the user would need to be online to download additional stuff, would likely need a package manager (or installer) of sorts, and the whole advantage of AppImage ("it just works") would be gone.

This in a way can be seen as defeating the whole point of AppImage

Exactly.

People who like this are imho served just fine by Snap.

Our target user experience is: Go to an Internet Cafe, download one single file, take it home to your Linux computer, run it. No installation, no downloading of additional stuff, no package manager, no installers, no installation, no dependencies, nothing complicated. Just one file that contains everthing the app needs to run on most Linux desktops. The fact that your application is 100 MB (or a gigabyte) is fine.

[jgrisham]

Apologies for commenting on a closed issue, but since this specific issue is linked to from the documentation...

---

It seems the OP’s concerns can eventually be mitigated by the combination of:

• A built-in framework for binary delta-updates (implemented -> reduces network traffic on all but the first download for each user)

• Filesystems that automatically and safely perform variable-chunk-size binary de-duplication (I don’t think this is common on non-server setups in 2021/2022, but hopefully it will be in the near future -> reduces local storage overhead for shared components between multiple versions of the same or different Applications)