2020-05-09

Web vs Native Apps

The thesis for native applications generally falls within the realm of properties related to fidelity.
The thesis for web applications generally falls within the realm of interoperability.

If you're building anything you need to draw your venn diagram of values and pick the relevant tools.

You can't build Final Fantasy 7R (PS4) in the browser, but you could build Final Fantasy Tactics (PS1) in the browser and have more fidelity than the PS1 version — in that sense, your ceiling for fidelity is maxed. so you would want to maximize other verticals such as distribution and multiplayer if you're choosing to build on the web.

When to develop on the web:

When you're experimenting — and quick iteration is critical—native applications are expected to be "set in stone" and polished—if you're in the early stages of building your product and pivots/re-architectures are likely, web is the way to go.

Caveat: Keep in mind that you are not likely to push the bounds of what's possible on the user interaction and delight side. This proves especially problematic if you expect users to spend extended amounts of time using the application on a regular basis.
When it doesn't make sense to build a native app - not all apps need to be native, nor should they. Before you create a native app, consider its utility and how entwined it would be with your users' workflow. General rule of thumb is: if they use it for creating stuff, it should probably be native and vice versa.
When millisecond performance doesn't matter that much — if your customers are not power users and your tool serves a niche.
When native is cost prohibitive — especially if your app serves cross-platform users and you're short on engineering resources.

Note: a native app is an application built using the OS provided tooling and maps 1:1 to a given operating system.

When to go native:

When you're seeking to maximize fidelity — if performance is your top concern. This is especially problematic when building new tools, as it is difficult to quickly iterate and experiment with options that are so vastly different.
When your users love your product — where frequent interaction is expected and you're looking to test the bounds of productivity & efficiency and see just how far you can push them.
If it's a creator's tool — The key idea here is native provides you with lower latency, allowing you overall quicker interaction, I/O and so forth especially if it's a collaborative application. This comes in handy when you're engineering more efficient navigation and interaction modes with the content and users of your application.

Content on its own is insufficient, if it were might as well have it printed on a physical piece of paper. How we work with the content, what we can do and how easily we can have it reflect our intentions is a critical part of any tool, in other words, the medium is the message.

When your app is mission-critical — failure tolerance is essential in the case of any server outage or network connectivity issues. Offline-capable local-first sync-when-connected design is key to avoid any potential disruptions in the work process.
App-first, page-second — The core idea here is that the means of interacting with the data is given equal (or greater) importance as the content of the application—because a great interaction mode can be leveraged for various applications.

Dev Caliber

It is certainly possible to develop web apps that rival the best native apps, but not without a significant amount of design and engineering effort—more than your typical web developer is accustomed to— especially if they're not front-end developers.
The bar for what can run on the browser is a lot lower than what can run on a native computing environment. Not only is the bar low, in fact, there is no bar — web developers start out building static websites (page-first) which let them get away with little in the way of performance and interactivity that come out of the box in native OS components (app-second).
Getting a web app to feel, look, and perform like a native desktop app is a monumental feat requiring close sync between design <-> dev and superb attention to detail. It is often an exercise in patience as you spend ungodly hours tweaking minute details that come out of the box in native development kits.

The reality is most people don't have the talent to build and utilize native applications to their full potential (maximizing fidelity). Building products like Sublime Text 3 take years of domain knowledge. The web on the other hand is generous, it accepts creations of lower fidelity.

Web vs Native Components

Primitive components exist in native UI kits that provide a minimum level of interactivity and animation which set the standard in user expectations having grown accustomed to them over years of computer usage—anything less feels clunky and slow.
On the web however, the bar for building an app is much lower as the point of reference on the web is static html—the thought model is typically page-first app-second whereas it's app-first, page-second on native.
The page-first mode of thinking leads to a suboptimal overall application that can only be overcome by great developers, where issues of transition, rendering, and other design and performance concerns rise.
performance rivaling native on that web is not attained done by bad, mediocre, moderately good, or pretty good developers. Only great ones.

I get especially delighted whenever I encounter a spectacular web app, Linear is one of my favorites as it is clear that they put in the time and effort.

Eng Resources & Community

In this regard, web handily beats native in developer and business preference because:

It's client agnostic (OS and device do not matter)
Most diverse and largest software ecosystems and communities by far—likelihood is you'll be able to build more complex things on the web as you would on native if simply due to the amount of resources available and the size of the web community.
The pool for talent is also that much larger.

Electron.js, Proton Native, and React Native

While there are significant differences between the 3, the underlying principle is the same—you do not write native applications.

Electron.js — run your web app in a faux native context using zero native components
Proton Native — compile your javascript code into OS native components using the Qt framework
React Native — compile your javascript code into Mobile OS native components

The Business Case

Businesses prefer web apps because of their cross-platform interoperability, which makes economic and practical sense. At least on a surface level, but going down this path can hurt them, it's typically a business-decision due to cost and engineering effort trade-offs, but it can quickly become detrimental if your product is a platform on which you expect other things to run (e.g. Slack) where the core platform requires a high degree of fidelity to support add-ons and extensions.

Another product I find guilty of this is Notion. Which I now use with less frequency due to it not being as performant as it can be.

Native Apps I like

Telegram for Mac — really great, quick, snappy. Reliable, and smooth interactions. Open Source.
Things 3 for Mac — haven't personally used this one but it seems critically acclaimed and widely adored.
Sublime Text — fast & reliable.

Thanks to @wwwjim for helping me articulate these thoughts better, @kilianvalkhof for advocating the merits of web apps, and @jtvhk for tolerating my incessant rambling about this topic.