| ▲ | jasomill 6 hours ago | |
So long as the web views provide for accessibility (and thus UI automation), this sounds perfectly reasonable for the majority of applications. Speaking of which, my dream is an "HTML light" standard with a subset of functionality specifically designed for local UI use, ideally with lightweight non-browser engines supporting this standard shipping with all major OS platforms as shared system components. We had browsers that ran on systems with 8 MB RAM, after all, and while it's not a fair comparison, there's no technical reason why a system with three orders of magnitude more RAM should struggle to run more than a handful of applications merely because they use HTML and JavaScript for rendering. | ||
| ▲ | nicoburns 6 hours ago | parent [-] | |
I am building such a lightweight browser engine: https://github.com/dioxuslabs/blitz. It targets most of HTML/CSS, but leaves out (or makes optinal) a lot of the extra stuff that browsers pull in). It also has the option to use Rust instead of JavaScript for the scripting layer. Though 8 MB RAM is a non-starter when a single RGBA texture @4k is ~30Mb and modern system often require 2 or 3 for buffering. Somewhere around the 60MB to 100MB mark seems to be the base for modern setups, at least on macOS. | ||