Building a hackable editor in the browser

> 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).

This. And to make matters worse, a lot of benchmarks start with something like, "To be fair to , let's cripple by implementing the programs using the paradigm favored by ." If you want the real results, have an expert in each language implement the spec without looking at the other program.

Someone mentioned Photoshop being slow compared to Slack/VSCode. That is Apples to Oranges comparison if I ever saw one.

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

And don't work natively on any platform. You essentially program for the lowest common denominator and do not take advantage of any of the features provided by the platform -- especially accessibility. For example: Zoom In on any half-way decent editor increases the text size. Zoom In on VSCode (macOS) blows up the entire UI -- leaving little space for actual text. This is just one example -- I can line up many more.

> 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.

both Debian and Fedora use wayland by default now. And wayland alone only gives you the ability to open a viewport, so you are going to need a lot of stuff if you want your UI library to do something as simple as :

    #include 
    int main() {
        linux_window* window = linux_ui_create_window();
        linux_widget* label = linux_ui_create_label(u8"お早う御座います");
        linux_ui_widget_set_parent(label, window);
        linux_ui_widget_set_pos(label, 50, 50);

        return linux_ui_process_events();
    }

> 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.

But almost no one makes Win32 apps with the Win32 API anymore anyways. The majority of desktop windows apps created today are using WPF or UWP which does not use any "native" stuff (that is, the win32 UI API), Qt or Electron. If this model does not even work on windows, why would you want to port it on linux instead of letting people ship their app as they wish ?

> 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.

Even if someone made this magical new library today, I would still have to package it along with all its dependencies in an AppImage because I have users still on ubuntu 12.04, 14.04, and 16.04 as well as debian stretch and jessie.