Back in the day with PHP things were much more understandable, it's somehow gotten objectively worse. And now, most desktop apps are their own contained browser. Somehow worse than Windows 98 .hta apps, too; where at least the system browser served a local app up, now we have ten copies of Electron running, bringing my relatively new Macbook to a crawl. Everything sucks and is way less fun than it used to be.
We have many, many examples of GUI toolkits that are extremely fast and lightweight. Isn't it time to throw the browser away, stop abusing HTML to make applications, and design something fit for purpose?
It's not "the web" or HTML, CSS, or JavaScript. That's all instant in vanilla form. Any media in today's quality will of course take time to download but, once cached, is also instant. None of the UX "requires" the crap that makes it slow, certainly not thousands of lines to make a table sortable and filterable. I could do that in IE6 without breaking a sweat. It's way easier, and faster, now. It's just people being lazy in how they do it, Apparetnly now just accepting whatever claude gave them as "best in show".
Not going to happen until gui frameworks are as comfortable and easy to set up and use as html. Entry barrier and ergonomics are among the biggest deciding factors of winning technologies.
The problem with cross platform UI is that it is antithetical to the purpose of an OS-native UI in its reason of existence. Cross platform tries to unify the UX while native UI tries to differentiate the UX. Native UI wants unique incompatible behavior.
So the cross platform UI frameworks that try to use the actual OS components always end up with terrible visual bugs due to unifying things that don't want to be unified. Or worse many "cross platform" UI frameworks try to mimic the its developer's favorite OS. I have seen way too many Android apps that has "cross platform" frameworks that draw iOS UI elements.
The best way to do cross platform applications with a GUI (I specifically avoid cross platform UI) is defining a yet another platform above a very basic common layer. This is what Web had done. What a browser asks from an OS is a rectangle (a graphics buffer) and the fonts to draw a webpage. Nothing else. Entire drawing functionality and the behavior is redefined from scratch. This is the advantage of Web and this is why Electron works so well for applications deployed in multiple OSes.
I have created and used them. They didn't look terrible on windows.
>What a browser asks from an OS is a rectangle (a graphics buffer) and the fonts to draw a webpage. Nothing else. Entire drawing functionality and the behavior is redefined from scratch. This is the advantage of Web..
I think that is exactly what Gtk does (and may be even Qt also) too..
I think it is just there there is not much funding going to those projects. Web on the other hand, being an ad-delivery platform, the sellers really want your browsers to work and look good...
The remnants of the dotcom era for web definitely helped shape it in a more design contentious way, in comparison. Those standards are created and pushed a few layers above that in which cross platform UI's work in.
https://imgur.com/a/ruTGUaF#ntnfeCJ
https://imgur.com/yGhgkz2 -> Comparison with another open source app Notepad3 under Windows.
> I think that is exactly what Gtk does (and may be even Qt also) too..
The problem is they half-ass it. Qt only does it with QML. Qt Widgets is half-half and it is a mess.
Overall these do not invalidate my point though. If you want a truly cross-platform application GUI, you need to rewrite the GUI for each OS. Or you give up and write one GUI that's running on its own platform.
> I think it is just there there is not much funding going to those projects. Web on the other hand, being an ad-delivery platform, the sellers really want your browsers to work and look good...
Indeed, Google employs some of the smartest software developers and ones with really niche skills like Behdad Esfahbod who created the best or the second best font rendering library out there. However, Qt has a company behind (a very very incompetent one, not just the library but operating a business). I have seen many commercial libraries too, they are all various shades of terrible.
You can do the core functionality of your product as cross platform, to some extend, but once you hit the interaction with the OS and especially the UI libraries of the OS, I think you'd get better software if you just accept that you'll need to write multiple application.
We see this on mobile, there's just two target platform really, yet companies don't even want to do that.
The choice isn't surprising, in a world where companies are more concerned with saving and branding, compared to creating good products.
It'd be nice if companies could just play nice and agree on a standard interface. That's the one good thing the web managed to do. It's just stuck to what's ultimately 3 decades of tech debt from a prototype document reader made in a few weeks.
They basically do though. Every cross platform native ported app I've used the GUI is the same layout. Well, except on macos the menu ribbon is on the topbar and windows it has its own ribbon layer in the application window. But that is it. All these frameworks already have feature parity with another. It is expected that they have these same functions and ui paradigms. Here's your button function. Here is where you specify window dimensions. This function opens a file browser. This one takes in user input to the textbox. I mean it is all pretty standardized and limited what you can expect to do in ui already.
Or you can use a VM, which is essentially what a modern browser is anyway. I wrote and maintained a Java app for many years with seamless cross platform development. The browser is the right architecture. It's the implementation that's painful, mostly for historical reasons.
Yes, they were comfortable and easy to set up (and use), particularly when compared to web development.
> a platform where their best bet at dynamic layout is `OnResize()` and `SubmitButton.Enabled = False`
This is a great description of what web coding looked like for a very long time, _especially_ when it started replacing RAD tools like VB and Delphi. In fact, it still looks like this in many ways, except now you have a JSX property and React state for disabling the button, and a mess of complex tooling, setup and node modules just to get to that base level.
The web won not because of programmer convenience, but because it offered ease of distribution. Turns out everything else was secondary.
React is over a decade old, and as far as I remember, desktop apps using embedded browsers (Electron) started becoming dominant after it came out.
The ease-of-distribution advantage is huge, but web technologies are big outside the Web too, where it doesn't apply.
(Besides my main point, idiomatic web UIs don't implement resize handlers for positioning each element manually, but instead use CSS to declaratively create layouts. Modern GUI libraries with visual builders can also do this, but it was decidedly not the norm in the 90s. Also, modern dynamic GUIs generally don't use a static layout with disabled parts, but hide or add parts outright. That kind of dynamicity is hard to even conceptualise with a GUI builder.)
The current idiomatic way of doing web layouts was, back then, almost entirely theoretical. The reality was a cross-browser hell filled with onResize listeners, in turn calling code filled with browser-specific if statements. Entire JavaScript libraries were devoted to correctly identifying browsers in order for developers to take appropriate measures when writing UI code. Separate machines specifically devoted to running old versions of Internet Explorer had to be used during testing and development, in order to ensure end user compatibility.
In short: The web was not in any way, shape or form more convenient for developers than the RAD tools it replaced. But it was instant access multi-platform distribution which readily allowed for Cloud/SaaS subscription models.
Electron happened more as an afterthought, when the ease of distribution had already made web UIs, and hence web UI developers, hegemonic. Heck, even MS Office for the web predates React, Electron, and something as arcane as Internet Explorer 9.
Things have gotten much better, but we're still having to reinvent things that just existed natively in VB6 (DataGrid, anyone?) - and at the cost of increasingly complex toolchains and dependencies.
ImGUI is the single exception that has been simple to set up, trivial to deploy (there is nothing to deploy, including it is all that's needed), and nice to use.
Great. How do you get all the hardware and OS vendors to deploy it for free and without applying their own "vetting" or inserting themselves into the billing?
We had Flash for exactly that purpose. For all its flaws, it was our best hope. A shame Apple and later Adobe decided to kill it in favor of HTML5.
The second best bet was Java Applets, but the technology came too early and was dead before it could fly off.
Some may mention WebAssembly, but I just don't see that as a viable alternative to the web mess that we already have.
I agree we need in built-in controls, reasonably sophisticated, properly style-able with CSS. We also need typed JS in the browser, etc
Just use jquery and this plugin, 7kB minified:
https://github.com/myspace-nu/jquery.fancyTable/blob/master/...
what's not great are the complexity merchants, due to money & other incentives etc that ship to the web.
there's better web frameworks that are lighter, faster than react - but due to hype etc you know how that goes
I wouldn't say that. The web had done way more good than harm overall. What I would say is that embedding the internet (and its tracking and spyware and dark patterns that have gain prominence) into every single application that we use is what is at fault.
The web browser that we built in 1990 was all on-premise obviously. And it had a very different architecture than HTTP. There were two processes. One used TCP/IP to mirror the plant computers model into memory on the workstation. The other painted the infographics and handled the user navigating to different screens. The two processes used shared memory to communicate. It was my first job out of university.
You know, or something.
I know that Chrome pulling the plug on XSLT in the browser is imminent - so how are you refactoring?
Instead it's just piling on a dozen layers of dependencies. Webassembly feels like the only real glimmer of what the "next generation" could have been like.
My 17 year old core 2 duo should not feel faster on a lean linux distro than modern hardware and yet it does. Wild to see and somewhat depressing.
I see old videos (Computer chronicles a good example) of what could be done on a 486 for instance. While you can see the difference in overall experience, it isnt that extreme of a difference, the 486 being released 37 years ago...
[1] Why Aren’t Operating Systems Getting Faster As Fast as Hardware? https://web.stanford.edu/~ouster/cgi-bin/papers/osfaster.pdf
It's not though, is it? Even browsers are capable of painting most pages at over 60 FPS. It's all the other crappy code making everything janky.