Nobody really cares.

I’m not usually the type to complain about input lag; most modern apps on a recent machine are snappy enough for me.

But I’ve been messing around with egui lately, and it just feels… fast. It’s weird.

But nobody really cares.

unlikely

Who will develop a cross-platform UI system as capable, flexible and well-embedded as HTML/CSS and as responsive as native UI? Google did its shot with Flutter, it's not exactly eating the world. The performance issue will long be solved before somebody comes up with a capable contender.

Trying to do that with Slint: https://slint.dev No need to use compiled language like C++, still possible to use a language like JavaScript/TypeScript, just no need to bring a browser.

> The performance issue will long be solved before somebody comes up with a capable contender.

I wish I had such a positive outlook.

New highways are built and they are quickly filled with traffic.

Flutter suffer, badly, to be tied to a specific lang.

If it where an API directly usable by any lang, then it could fly further.

There is https://gioui.org/ for Go.

This doesn't seem to cover a single point in the comment you're replying to.

> Who will develop a cross-platform UI system as capable, flexible and well-embedded as HTML/CSS and as responsive as native UI?

History shows that you can only choose one. If you're not using the platform's native UI stack, you're going to end up with a slower, less capable solution that will look and feel foreign and clumsy in comparison. What the industry really needs is a React Native-type solution that isn't tied specifically to React.

Isn't this what WebAssembly or Rust is used for? IIRC Figma's web app uses WebAssembly and I prefer that way more than the native app.

Maybe when native languages manage to come up with a single good UI framework

Macs have Cocoa which is a good UI framework. There's your single good UI framework for them.

iOS has UIKit, which is a good UI framework. There's your single good UI framework for them.

Linux has GTK and Qt, though I'm not sure which one is in vogue these days, but both of which seemed fine when I used them in the past.

etc

But it sounds like what you're actually saying is "I only want one OS to exist".

Every OS has its own UI API, because every perform has different UI design language, UI interaction, and UI behavior. You cannot make one UI that is good on every platform because every platform is different and those differences are what make people prefer one over the others, but a single UI is (as Java and Chrome wrappers demonstrate) going to produce a bunch of exceedingly mediocre apps that fail numerous basic UI tools on their respective platforms.

If you want a cross platform apps you have cross platform core logic, and per platform UI.

If you want a single UI framework across platforms, it cannot be good, and it will inherently at best produce the kind of mediocrity we get with chrome apps, or you only have a single platform and have the same UI toolkit across all of them: desktop, phone, tablet, etc. I'm going to guess that's going to produce a fairly terrible UX on at least one of the options if it's good on others, or maybe it will just be mediocre across the board.

Then nobody will go back to making native apps

Yes, the problem is easy crappy apps are cheaper for developers even if they're worse for users.

The alternative "single UI framework" is "everyone must run the same OS".

As long as people keep buying/using crapware apps that's all that will happen. The fact that so many people are ok with that mediocrity is depressing, but that they do so while then complaining about things being slow is actively annoying.

It is totally possible to have a "runs on anything" UI framework; it simply has to have bindings for every applicable platform. SDL does this, for example, in 2D Graphics. Java has a few "run anywhere" UI frameworks, and Microsoft has .Net Maui (as well as the 3rd party avalonia UI). The problem with most native frameworks, however, is they are nowhere near as flexible as HTML and CSS (which many pre-teens taught themselves as a way to customize their tumblr and myspace pages). Other frameworks, by comparison, require programming knowledge or more setup than just a text editor (usually requiring an IDE and the rest of your toolchain).

I can see native software making a comeback if it is:

1. Declarative: only software engineers like imperative UI systems

2. Flexible: some frameworks (like any of the XAML-based ones) are strongly typed and you can only combine certain XAML elements with other certain XAML elements, and will fail to compile entirely if you mess something up

3. Unopinionated: HTML, CSS, and Javascript don't require you to implement any particular paradigm for getting data on the screen; that is left up to the coder

4. Dead ass simple: the litmus test is that a 7th grader should be able to learn the basics of it on their own, and the tooling should be ideally no more complicated than a text editor

5. Totally sandboxed: You can't trust 99% of frontend devs with security

The people you need to appeal to are not hardcore software engineers, but hobbyists and newbies, since they end up being the majority of frontend devs anyways.

Honestly I think you could get pretty far with just adding declarative languages (read: XML) to existing native frameworks, like gtk and Win32.

Your post is thoughtful. Why do you care so much about declarative? I tried SwiftUI last summer to see what it was about and I find the whole style rather awkward. Writing a desktop app in XML sounds even worse. And I'm not seeing the benefit to the user. With an imperative coding style, you can more directly control the user experience and give them the best one.

With an imperative style, you need to learn a programming language before you can start making applications. With HTML, you can start making applications immediately by just writing HTML, and then you can learn the programming language (javascript) later. It's a barrier to entry for non-engineers

The problem is not putting bits onto the screen, that's all SDL does. It does not integrate at all with the host platform, to an even greater extent that chrome based crapware.

1. That's an opinion, not a fact, and most "declarative" UI frameworks have poor performance and can't do anything not explicitly models by the declarative framework. The fact that people want to just draw a UI doesn't mean that the resulting UI is either good, or works correctly, and the idea that it's "easier" simply implies lower understanding of what is being done and that you aren't considering any of the edge cases you still need to handle.

2. Not sure what to say here, as I don't know your point? it seems more about the type system of your language and not at all related to the ui toolkit

3. This is BS. html, css, and the DOM all have a very clear model for how and what a UI is, claiming it isn't means that you haven't apparently spent much time working in any other system. Much like I keep meeting people who say that they don't have an accent, everyone else does.

4. Application development is conceptually complicated unless your application is not doing anything interesting. I'm also curious what makes a browser ui more "simple" than say Cocoa?

5. Sandboxing is a part of the OS, not the UI framework. All applications on iOS are sandboxed, that vast majority on macOS are.

Application development is hard, and it's not because of the UI framework you're using. The overwhelming amount of any actual application is the application logic, not the UI.

Chrome based apps are all abysmal because to make an actual application using a browser engine, you need to reimplement, in html+JS, a huge amount of work the host OS would otherwise just provide for you.

If all you want is a webpage, just make a webpage, don't force everyone to download a 600Mb copy of chrome.

> It does not integrate at all with the host platform

SDL does in fact make system calls and have OS-specific code (DirectX implementation, Metal implementation), even if most of them don't directly manipulate OS UI controls, though it can initialize a window with a rendering context on any of its OSs.

I feel like you're missing the point that performance matters less than accessibility for UI frameworks. HTML and CSS are the most popular choices because a child can learn them quickly. Native apps aren't as popular because all the frameworks out there require you to be an engineer to use them.

> 1. the idea that it's "easier" simply implies lower understanding of what is being done and that you aren't considering any of the edge cases you still need to handle.

I don't see how that follows at all. HTML is declarative and powers most applications at this point.

> 2. Not sure what to say here, as I don't know your point? it seems more about the type system of your language and not at all related to the ui toolkit

Web browsers are very forgiving with HTML errors, native UI frameworks (especially those which simply convert the markup to imperative statements) often refuse to run entirely if there's a single markup error. A native framework which seeks to become as popular as HTML would need to be as flexible as HTML

> 3. html, css, and the DOM all have a very clear model for how and what a UI is, claiming it isn't means that you haven't apparently spent much time working in any other system. Much like I keep meeting people who say that they don't have an accent, everyone else does

You're not understanding what I'm saying. You can run an ajax request and get some data, but to put that data into the UI would require you to run a query on the dom and manually set the innerHTML of the element to the new data. Some other UI frameworks will force you to bind specific variables or lists to a control in order to auto refresh when the bound variable changes. This is an opinionated framework: one which tells you how to manage updating the UI rather than allowing the developer to do it themselves. Such an opinionated framework would become more difficult for people to learn

> 4. Application development is conceptually complicated unless your application is not doing anything interesting. I'm also curious what makes a browser ui more "simple" than say Cocoa?

I have no experience with cocoa because I don't use a mac, but from what I can tell it requires you to know Objective C and run XCode. HTML requires, at the very least, notepad to write. It is extremely easy to get setup with HTML and start learning it as a lay person.

> 5. Sandboxing is a part of the OS, not the UI framework. All applications on iOS are sandboxed, that vast majority on macOS are.

You would want to make sure that programs written in this framework are sandboxed away from any resources. On Windows this means AppContainers and on Linux there are different implementations (snap, docker). But the host which runs and loads the UI should run all applications sandboxed by default (i.e: like a web browser)

Gnome is 120FPS butter on Javascript.

As far as I know, Gnome profiled a bunch of their biggest UI slowdowns and none of them would have been (much) improved on native.

Bad code is bad, JavaScript isn’t the main culprit here.

This.

I've wrote plenty of (very) high performance code using a Javascript/WebGL combo.

Most people bitching about JS are not even good coders to start with.

Truth to be told, there's a lot of terrible js out there, and some of it is mine.

At least you're honest about it. I don't have any JS out there period, so your terrible JS is much better than I could have done.

sometimes I do think about my first contributions. how i could have done this and that completely differently. kind of like going to first grade again with what you know (and are) as an adult.

yeah but look at freaking chromium, 3.2GB compressed archive. That is absolutely insane, and cannot be defended in ANY WAY.

look at what they started with with webkit? chromium is an abomination the likes of which definitively proves there is no god, or that god HATES humanity, as god would have 100% for sure schmited us all down for the atrocity that is chromium.

Yeah, agree with that.

I recall reading about a project who was stripping down chromium to its bare essentials, it seemed quite nice but cannot find it atm.

Contempt culture is so ugly. The bullshit asymmetry principle is so in play, makes it so hard to reel in or temper the ardent zeal.

You're also off by 15x. Installed size is 247MB on Debian. https://packages.debian.org/trixie/chromium

Chromium is one of the most amazing fully featured bundles of computing the planet has ever built. We should be in awe. But, "this has made a lot of people very angry and been widely regarded as a bad move." Contempt is rampant.

Yes, and people often forget that web browsers provide 100% backwards-compatibility to 100s of legacy web standards. Of course that bloats things up, see also Windows.

Also, parent is maybe refering to the source code size? Which also includes a huge chunk of ChromeOS code.

you might want to look at what the source archive costs your diskwise :)

One doesn’t even need to go as far as C++ or Rust… many best in class Mac apps were written in Objective-C (which is notably slower than either) and were plenty responsive on single core PowerPC G3s, G4s, and G5s.

I think a great deal of the issue comes down to bloated frameworks, bad application code, and a prevalent attitude of nonchalance towards optimization that compounds with dev machines being powerful enough to mask most performance problems.

I think it's probably more productive to think of this in economic terms; "nonchalance toward optimization" <-> "I can write this code in an hour instead of three hours". And, from a company's perspective: "I can get this code running acceptably at 1/3 the dev cost".

Surely we’ve crossed a threshold of diminishing returns on this by now though? There has to be a point where the gains in convenience/DX/speed are too tiny for the costs involved and the weight of the average app ceases to grow.