Goodbye, Native Apps

Eh, BIOSes had an API-like interface under ASM assembler macros under DOS. It was relatively easy to do stuff directy with hardware.

>many PCs had a 60MHz Pentium 1 or a 100MHz 486DX4 with 64MiB of RAM and it ran

By 1998 most people switched to a Pentium because of the huge performance gain. And by 2000, everyone had a Pentium2 with ~96mb of RAM.

then why still use Electron? why not just c++-backend with an embedded http server for frontend that uses the browser

Normal users don't care how much RAM their programs use, because they don't know what RAM is. They think that computer hardware has a single one-dimensional property called "speed" and that if their software performs badly, it's because their computer is too slow, not because the software is bloated.

My daily driver has 4GB of RAM, and it's possible only usable because I'm extremely frugal with my software choices. I run Debian with XFCE and pipe memory usage to my panel so I can always see whether I'm in danger of swapping. I use a Firefox extension that prevents me from opening too many tabs. I stick to the terminal for as many tasks as possible. I categorically refuse to use electron apps. And despite all that, I still ending up OOMing and having to hard reset every few days. For a normal person who doesn't know what RAM is and has an antivirus constantly running the background, the 4GB are going to be used up almost immediately, their machine will start swapping, and then they'll get the impression that their 4GB machine is "slow," despite being faster than high-end computers people used to do exactly the same things ten years ago.

Any tips on getting stuff to run fine on low end machines. I'm currently running Lubuntu on a very cheap laptop and while its usable, most applications are get pretty irresponsive. I've also tried running some BSD's on it whith very bare bones wm's (i.e. ctwm) and that became unusable quickly. Although, I think the issue there was lack of proper graphics drivers and being stuck with the framebuffer driver.

Apple is definitely not developing cross platform. Swift the language is cross platform. But the SwiftUI is only "cross platform" within apple's different devices. A true cross platform is when a SwiftUI app would work on Android.

Native OSs can be built to be "cross platform". For example, the OpenGL API. The same API works on different OSs, developers can code against the same API and it works on different OSs. In an ideal world, maybe there could be a standard API for presentation controls, UI drawing, animation, 2D/3D graphics, networking, filesystem access, threading and more. Each OSs would implement the same API and add additional platform specific APIs to differentiate themselves. The key is application developers would have a common core set of APIs and language to implement the 80% business logic and UI logic.

Note, this is essentially what HTML, JS and CSS is doing. But the web platform is creating a runtime that exposes APIs to do a lot of different things. A CSS transform a single API that causes the DOM to animate in specific way. There are thousands of these APIs, and the runtime implements all of them. This is why the web runtime itself heavier and it takes 100mb just to show something simple on web platform.

For flutter, the core engine is just a 2D drawing surface, the APIs it exposes is just drawing shapes. And all of the widget self contains rendering, various settings and the application pulls in the widget used in the app. This makes the runtime smaller. Flutter is more efficient because the abstraction is lower and the core runtime is trying to do less things. On the scale of level of abstraction, flutter is on one end and the web platform is on the other. For our ideal OS platform, we can select the right level of abstraction to balance between performance, standardization, and flexibility.

But in the real world, all of this require collaboration between OS vendors. Apple's business model is try to sell more IPhone, Mac, Apple Watch, IPad. They make the argument that Apple's platform has the best apps that isn't available on Google's or Microsoft's platform. And this actually works. Why is Android tablets not taking off, and IPad Pro is? People buy the IPad Pro for apps like Notability, Photoshop and more. People still buys Windows and not ChromeOS because its got native Photoshop and Matlab. These apps are coded using Apple's or Micosoft's language, frameworks and APIs. And that exactly is what is preventing these apps from appearing on Android and ChromeOS easily and reducing people's need to buy Apple and Microsoft's devices. While these vendors may not say they are actively trying to lock in developers. They definitely don't want the some developers who coded an complex application for their platform to easily move it to another platform. If this transition cost is too low, it doesn't play into their business model. Their business model pushes them to differentiate their platform against others, and as a side effect, it increases the barrier and transition cost.

This is a tug of war between application developers desire to have all platform as similar as possible, and the platform owners desire to differentiate their platform and prevent other platforms obtaining the same capabilities as my platform.