[GH-ISSUE #395] Cypht as a Progressive Web App (PWA) for offline use, etc. #326

Open
opened 2026-02-25 21:34:45 +03:00 by kerem · 7 comments
Owner

Originally created by @marclaporte on GitHub (May 3, 2020).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/395

Originally assigned to: @jasonmunro on GitHub.

If not 2020, let's try for 2021 ;-)

https://en.wikipedia.org/wiki/Progressive_web_application
https://doc.tiki.org/Progressive-Web-App

Originally created by @marclaporte on GitHub (May 3, 2020). Original GitHub issue: https://github.com/cypht-org/cypht/issues/395 Originally assigned to: @jasonmunro on GitHub. If not 2020, let's try for 2021 ;-) https://en.wikipedia.org/wiki/Progressive_web_application https://doc.tiki.org/Progressive-Web-App
Author
Owner

@dumblob commented on GitHub (May 3, 2020):

Hm, I think Cypht was deliberately designed to be so minimal, that PWA doesn't make any sense here. And the only thing I can think of where PWA could make sense is the GPG functionality (due to the GPG JavaScript library), but that's already covered IIRC.

All in all I don't think there is anything to do on this front. But of course, I might be missing something 😉.

<!-- gh-comment-id:623065830 --> @dumblob commented on GitHub (May 3, 2020): Hm, I think Cypht was deliberately designed to be so minimal, that PWA doesn't make any sense here. And the only thing I can think of where PWA could make sense is the GPG functionality (due to the GPG JavaScript library), but that's already covered IIRC. All in all I don't think there is anything to do on this front. But of course, I might be missing something :wink:.
Author
Owner

@jasonmunro commented on GitHub (May 4, 2020):

Meeting the guidelines to be considered a "Progressive Web app" (as outlined in Wikipedia) seems like mostly marketing fluff. We can and should do our best to deal with network interruptions, but Cypht was not designed to work offline. If that was the intention, it would be a desktop app :)

<!-- gh-comment-id:623264056 --> @jasonmunro commented on GitHub (May 4, 2020): Meeting the guidelines to be considered a "Progressive Web app" (as outlined in Wikipedia) seems like mostly marketing fluff. We can and should do our best to deal with network interruptions, but Cypht was not designed to work offline. If that was the intention, it would be a desktop app :)
Author
Owner

@dumblob commented on GitHub (May 4, 2020):

There is one thing I found PWA mandates, but Cypht can't. Namely loading Cypht offline (e.g. from local storage). Not to be confused with offline access which basically means Cypht should deal with network interruptions gracefully, but that's already partially covered (I didn't test longer interruptions though - e.g. 2 days off).

I do agree that offline loading could come handy (I myself work very frequently offline, so I actually really write emails offline - please don't call me a dinosaur 😉). But I'm afraid it'd need non-negligible developer work. But maybe I'm wrong and someone will make a PR.

Now the workaround seems to be to load Cypht somewhere with internet connection, pin the browser tab and don't close it 😉. I can live with that.

<!-- gh-comment-id:623387644 --> @dumblob commented on GitHub (May 4, 2020): There is one thing I found PWA mandates, but Cypht can't. Namely loading Cypht offline (e.g. from local storage). Not to be confused with *offline access* which basically means Cypht should deal with network interruptions gracefully, but that's already partially covered (I didn't test longer interruptions though - e.g. 2 days off). I do agree that offline loading could come handy (I myself work very frequently offline, so I actually really write emails offline - please don't call me a dinosaur :wink:). But I'm afraid it'd need non-negligible developer work. But maybe I'm wrong and someone will make a PR. Now the workaround seems to be to load Cypht somewhere with internet connection, pin the browser tab and don't close it :wink:. I can live with that.
Author
Owner

@marclaporte commented on GitHub (May 5, 2020):

@jasonmunro "it would be a desktop app :)" Many web apps do so. Here are great examples:
https://github.com/jgraph/drawio-desktop
https://github.com/jitsi/jitsi-meet-electron

<!-- gh-comment-id:624062352 --> @marclaporte commented on GitHub (May 5, 2020): @jasonmunro "it would be a desktop app :)" Many web apps do so. Here are great examples: https://github.com/jgraph/drawio-desktop https://github.com/jitsi/jitsi-meet-electron
Author
Owner

@jasonmunro commented on GitHub (May 5, 2020):

@marclaporte Many web apps != Cypht :) Seriously however those examples are basically JavaScript apps leveraging Electron to run as a desktop program (don't get me started on my disdain for Electron).

Cypht by design is as lightweight in the browser as possible so we use very little JavaScript compared to most modern web applications. This aspect alone is a large barrier to some sort of PWA functionality. There are features that utilize more client side code than others for various reasons (advanced search for nicer form interaction, PGP for better key security, etc), but I have no desire to port core functional logic that would be required for any decent offline experience (like page routing) to the client side code.

I'm aware my opinions on this are a bit curmudgeony, and a lot of current web development is focused on doing as much as possible client side instead of as little as possible. I'm comfortable dissenting from the majority opinion in this case :) With all of that said, I will leave this issue open and tag it "enhancement" and consider any PRs, but with a heavy does of skepticism.

<!-- gh-comment-id:624278712 --> @jasonmunro commented on GitHub (May 5, 2020): @marclaporte Many web apps != Cypht :) Seriously however those examples are basically JavaScript apps leveraging Electron to run as a desktop program (don't get me started on my disdain for Electron). Cypht by design is as lightweight in the browser as possible so we use very little JavaScript compared to most modern web applications. This aspect alone is a large barrier to some sort of PWA functionality. There are features that utilize more client side code than others for various reasons (advanced search for nicer form interaction, PGP for better key security, etc), but I have no desire to port core functional logic that would be required for any decent offline experience (like page routing) to the client side code. I'm aware my opinions on this are a bit curmudgeony, and a lot of current web development is focused on doing as much as possible client side instead of as little as possible. I'm comfortable dissenting from the majority opinion in this case :) With all of that said, I will leave this issue open and tag it "enhancement" and consider any PRs, but with a heavy does of skepticism.
Author
Owner

@marclaporte commented on GitHub (May 6, 2020):

Got it.

Let's see PWA as a toolbox, and we'll pick and choose stuff that benefits our use case.

<!-- gh-comment-id:624581282 --> @marclaporte commented on GitHub (May 6, 2020): Got it. Let's see PWA as a toolbox, and we'll pick and choose stuff that benefits our use case.
Author
Owner
<!-- gh-comment-id:1257270191 --> @marclaporte commented on GitHub (Sep 25, 2022): https://git.kolab.org/diffusion/RPK/browse/dev%252Fpwa/plugins/pwa/ https://archive.fosdem.org/2020/schedule/event/are_pwas_ready_to_take_over_the_world/ https://blog.etesync.com/announcing-the-etesync-progressive-web-app/ https://github.com/pwa-builder/PWABuilder
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/cypht#326
No description provided.