Building a hackable editor in the browser

What about libui?

> Tab support was added without linking against the new SDK: apps would get it "for free" when running on macOS Sierra.

Yeah, right. I remember being very happy as some of my not-worried-about-mac applications (it's a word processor that uses a special format only used in our country) had tabbing enabled. :-)

Of everything that list all you really need is the X libraries and you do not need to carry (meaning distribute) those since they are part of the every single desktop environment and have a stable ABI. The rest aren't strictly necessary, but i think Cairo has a stable ABI. I'm not sure if it is available everywhere though. OpenGL (and Vulkan) can be provided via dynamic linking, though only via an API that doesn't guarantee its existence (it doesn't exist in all X11 desktops - AFAIK Raspberry Pi doesn't support them).

In any case, the dependencies i mean here are dependencies for the applications that target your API, not the dependencies your API has. You can make your API use whatever library you want to -e.g.- load PNG, JPG or whatever, but that can be hidden from the user of the API (ie. their binary will link against libyourapi.so.1 for yapi_load_image and what that specific version of libyourapi.so.1 uses to load the requested image is an implementation detail).

Note that this is in the context of making that API a standard people can target, not a reusable library (and its own dependencies) people carry with their binaries. Basically the equivalent of how you do not need to give USER32.DLL on Windows to your users because you can pretty much expect that it will be there.

Nowadays the only equivalent on Linux is the X libraries, anything else is either not guaranteed to be there now, or not guaranteed to be there in ~5 years because thanks to CADT people cannot stick with an API and feel the need to break everyone's programs to feel useful.

> In data centers, loading data from networked server, where it's in memory, can be used over loading data from a disk, because disk is comparatively slow.

RDMA has no relevance to this discussion.

> A web app can load JavaScript assembler, which isn't much slower than a desktop app written in C.

This is incredibly wrong. An Electron app goes through many stages before code is executing with acceptable performance:

1. A full web browser loads.

2. JavaScript is loaded and parsed.

3. JavaScript runs interpreted, which is very slow. It is only here that the "application" starts.

4. After a while, the JIT may decide to compile some code. This is very resource intensive.

5. After compilation, you finally have some parts that have decent performance. However...

6. Gaurds fail (i.e. bad assumptions), and the code is deoptimized, running at slow speed again. JIT compilations may be tried again later with new assumptions, and if you're lucky, they might hold.

At #5, you have code that is as fast as it gets. It is nowhere near as fast as native code (any benchmarks you think of are synthetic and designed to show JavaScript as fast—it doesn't take a lot to shake out the issues).

For a native application, however, the process looks like this:

1. The application starts, and it runs.

Done. There is no parsing, interpreting, optimization. This single step is orders of magnitude faster than just #1 of the life of an Electron app.

> Bigger - and slower - parts of the web app can be loaded after the app starts interacting. So - at least in principle - no sizeable speed difference, which would blow somebody away.

We are talking a speed difference in orders of magnitude here. An electron application is not even done preparing Electron before a good native application is done loading.

And it's all fine and dandy that you can load heavy things later, but for a good native application has nothing to load later. It's done.

A fun comparison:

1. Slack cold-start on my machine: ~3 seconds before anything shows up, ~5 seconds until a main window with a loading indicator is visible, ~10 seconds till fully loaded and usable.

2. Telegram-desktop cold start on my machine: ~1 second till fully loaded and usable.

And telegram-desktop is a very slow native application! A speedy application starts in 250ms or less, and never waits after that.

> Advantage of web app is cross platform uniformity.

And the disadvantage is that they are are huge, resource intensive and pathetically slow.

We have very functional cross-platform toolkits, like Qt that telegram is based on.

I interpret this comment by how I feel about the idea. I have no words to describe how awesome a hack this is!