Is software ever going to become more responsive? I'm tired of Slack constantly fucking up its UI because I'm faster than it is, and that's on an M2.
Are companies going to pay for that development?
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.
I wish I had such a positive outlook.
New highways are built and they are quickly filled with traffic.
If it where an API directly usable by any lang, then it could fly further.
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.
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.
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.
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.
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.
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)
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.
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.
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.
I recall reading about a project who was stripping down chromium to its bare essentials, it seemed quite nice but cannot find it atm.
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.
Also, parent is maybe refering to the source code size? Which also includes a huge chunk of ChromeOS code.
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.
how hard can it be? spend 5 minutes and anyone thats worth keeping can figure it out.
Just a plethora of enshittified apps developed to be cheap rather than good.