[RFC] Target platform

[perryprog]

This issue will just be a gathering of everything we know about each platform we've though about, listed in order of likeliness of use.

This is a tracking issue for the card

Deciding on what platform we're developing on, setting it in stone

@laurajohman can also add the survey results once we get done with this.

• Web based
• "Native" via Electron
• Native via Kivy (Python UI library)

Pros of web based:

• No need to install
• Works on all platforms
• Easiest to "set up". No compilation, nothing!

Cons of web based:

• Cross browser support
• Ease of use on mobile
• Not as good support for things like sessions, and similar things
• Can't get to system information or save files locally
• There was something I was about to write and I can't remember now

Pros of Electron:

• System level access
• It's an app, so easier to open
• Can save files locally
• Good session support, log in once
• Better notification and system tray support
• No cross platform support needed
• Easier dev setup with guaranteed ES6 support

Cons of Electron:

• You have to install it
• Slow as molasses
• It's Electron ( ͡° ͜ʖ ͡°)
• You have to compile things (depends on if you need that)

Pros of Kivy:

• Supports the most platforms as a native app
• Python

Cons of Kivy:

• You're making your UI in Python for every screen size imaginable.

Please feel free to add on to this!

[TheLonelyGhost]

I'm going to scope this to hashing out the target platform(s). We can have survey responses as evidence of a particular platform, but I have a feeling this is going to be strewn out enough as it is.

[TheLonelyGhost]

Now my response:

File persistence (web)

There are some inaccuracies above in what is possible with web tech these days:

• localStorage allows for a basic key-value store in the browser that persists after closing the application.
• Export and import of a config file (or whatever reason we need to persist files to local filesystem)

No compiling for web

True, it's not required per se, but it does have significant benefits. In JavaScript-land it's commonly referred to as "transpiling". There are things like Babel (allow latest javascript to be backported for older browsers) and Webpack (page load optimization for JavaScript) that package assets and make the application significantly more performant.

I fully expect a web-based platform would still include some level of tooling ("compiling") to package it up for deployment.

No ease of use on mobile (web)

I'd argue web is the most compatible way to get the application on mobile devices. I have an iPad Gen 1 (yes, the fat one) that I mainly use for web browsing and reading PDFs. While the browser hasn't been updated since 2010-ish, it still works for many sites. At least in part.

Web technologies were designed to degrade gracefully. If a feature in CSS, for example, is used by a web site that the browser doesn't support, it ignores it. Same with HTML. JavaScript might be different, but a common design pattern is to use feature detection in your code to continue this graceful degradation approach.

This means my iPad might not be able to do everything on all of the sites, but that's just fine since I can still read blogs using the latest web technologies. I can still do everything I need.

Mobile apps

Apple requires apps target the latest iOS version, which might not support all iOS devices. My iPad Gen 1 does not support iOS 11, obviously. If we make an iOS app, Apple would exclude devices that have not yet or cannot upgrade to iOS 11.

Android doesn't have the same requirement of targeting the latest platform version, but even if they did we can sideload an APK.

Other platforms besides iOS and Android do still exist, despite not having a significant market share. The commonality between them? They all (or most of them) have a web browser. We can get everyone with a web app.

Electron is "slow as molasses"

It's not that electron is slow as molasses, it's that it's a full browser instance running. There are issues of memory usage going through the roof, inefficiencies because we're using web technology (like running a lightweight VM on the machine) instead of a UI and language coded to the OS's existing APIs, etc. Sure it's really slow compared to a native application, but that's the sacrifice made to use web technologies to build an application that can be launched without opening your favorite browser and navigating to a specific URL.

Since Electron is a slightly paired down version of Chrome (or Chromium, to be specific), we would have very similar results if a person runs the web app version in a full Chrome browser.

As a web app, we have other options that might handle memory and CPU usage better:

• Firefox (v58, a.k.a. "Quantum", supposedly offers the same DOM features as Chrome with better CPU and memory usage)
• Edge (formerly IE, but a ground-up rewrite. Not my preference, but it has demonstrably followed web standards better than Chrome has at times)
• Safari (not as many DOM features, but incredible difference in battery life on MacOS)

It's up to the user which works best for them. With Electron, we're effectively saying Chrome-only. That has benefits in using more bleeding edge features in the browser but I'm not sure if we'd even need anything beyond what's currently available on all modern browsers.

Kivy (or other native UI framework) tradeoffs

We still need to deal with bundling an interpreted language with the interpreter (python) for each target platform. How do we figure out what platforms to support? One transcriber mentioned using a Wii U gamepad. I don't even know how we'd approach supporting that, even if we wanted to.

Additionally, I'm not exactly excited to replicate platform-specific issues on, e.g., Windows XP running the app. You know people out there still run it. Same with Windows Vista. There might also be hardware failure issues that present in odd ways that a web app would insulate us from. The browser is responsible for handling those issues.

[perryprog]

I'll response this to this when I have time (hopefully this weekend), thanks a lot!

[itsthejoker]

Closing because this was decided and not updated; the answer is Web.

[perryprog]

Oops, thank you!