Thinking about a Desktop App

[elijah-potter]

Related Pages

#1878

Brainstorming

I've been working on our Chrome extension quite intensely for the past few months. I would love to extend our reach to desktop eventually (as Grammarly and co does) and want to think about how to do that.

At a bare minimum, any desktop app we have should bundle the editor you can find on our homepage, plus filesystem access. Ideally, we would use platform-specific accessibility APIs to do linting on any application open on a user's desktop. I believe @lukasmwerner has does some research in this area.

I'd love to do some kind of end-to-end encrypted cloud sync between the various consumer-facing clients (the Chrome extension included), but that's a wish-list item.

I'm posting this as a discussion because I would like your thoughts. Would something like this be useful? Is it worth exploring?

Pinging @jlarmstrongiv and @KraXen72 for visibility.

Possible Tools

Tauri. We could use all our existing JS frontend code, plus we could run our Rust code natively.

I've used Firebase in the past for apps that require real-time sync, but it definitely does not fulfill the end-to-end encryption requirement.

Technical Details

If we chose to do this, I'd first want to take each of the existing reusable Svelte components in the Chrome extension and on the website and move them to a component library.

[jlarmstrongiv]

I wonder if there’s a world in which having both a PWA and a desktop app would make sense.

A PWA is nice for locked-down computers like student chromebooks and company-provided computers, with no installation access.

A PWA is straightforward, using the standalone editor as the base and vite-plugin-pwa. It can also have limited filesystem access with Chrome and Edge (Firefox and Safari oppose local filesystem access)

My only other comment on filesystem access is that it should not be designed like ProWritingAid, where it’s impossible to just have an untitled document open.

Building and publishing a PWA is a lot quicker and easier than a native desktop app and can be completed in the short term. That way, users can have a limited desktop experience, rather than no desktop experience, while a fully-featured native app is being built.

There are some quality-of-life improvements that could be added to the standalone editor #1878 (comment)

---

For a full and complete desktop app, the only answer is a native app. For example, using platform-specific accessibility APIs to do linting on any application open on a user's desktop requires a native app. I think using Tauri so that you can run the rust code natively sounds like the best approach.

[grantlemons]

One issue I see with this is matching the experiences of using the PWA and native app. It'd be weird to have them completely different, so our native app would probably end up being close to a clone of whatever editor the PWA is based on, which gives us less flexibility for tailoring the experience.

Also, providing support for two different desktop applications could get difficult. Do we expect all users to know the difference between a PWA and native app and not mix up the two when looking for documentation or filing an issue? I'd expect not.

[jlarmstrongiv]

I expect the PWA and the standalone website editor to be the same. The PWA installation method is directly in the browser ( https://web.dev/articles/install-criteria ). I expect the website to promote the desktop installation, and only offer the built-in browser PWA installation from the standalone website editor.

The desktop app would be completely different. The desktop app can open local files, have a list of recent files, multiple tabbed windows, integrations with other applications, syncing, and more. The PWA can only partially support some of those features in some browsers, so PWA feature parity is only possible with the standalone website editor, not the desktop app.

[elijah-potter]

I think both of your concerns are valid, but I don't see them as major barriers to building either a PWA or a desktop app.

One issue I see with this is matching the experiences of using the PWA and native app. It'd be weird to have them completely different, so our native app would probably end up being close to a clone of whatever editor the PWA is based on, which gives us less flexibility for tailoring the experience.

This is the main reason I'm leaning toward Tauri. We could build components or even entire pages inside a Svelte component library, and simply import them into the website and the desktop app. Even client-side routing could be carried over.

Also, providing support for two different desktop applications could get difficult. Do we expect all users to know the difference between a PWA and native app and not mix up the two when looking for documentation or filing an issue? I'd expect not.

As for this, I don't think this is practically a huge concern. We say "PWA", but we really mean "website with enough caching it can run offline". The maintenance overhead is not much higher than the site on its own. We already direct people to different installations (Firefox plugin vs. Chrome plugin) based on what browser they're using. We could just direct people who visit our site on a Chromebook to install the PWA, with everyone else installing the desktop app.

[lukasmwerner]

The PWA would practically just be the https://writewithharper.com/editor page correct?

[jlarmstrongiv]

Yep! Pretty much