Why do we create modern desktop GUI apps using HTML/CSS/JavaScript? (2022)
gerrysweeney.com
gerrysweeney.com
When would you even want to target X11/Wayland directly? Just use a toolkit and ignore the underlying stuff. For 90% of the application it does not matter.
> I find it difficult to see why this is going to change any time soon, the performance of a well written UI in a modern browser out-performs a native desktop application in every category of sped, usability and presentation for most usual use cases.
I always encounter the exact opposite. I've never found any web application with a good UI or any web application that outperformed a native one.
> Could you imagine a future where desktop applications were built like this, and in every sense of the word, “portable between operating systems” with the experience being identical on all platforms…
This sounds more like a really crappy future, if anything looks everywhere the same. Applications must integrate with the "host"-OS.
The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application.
The lock-in argument is just a very weak one. At some point you depend on something. Oh, your HTML only renders fine in Chromium or you use Chromium only JS APIs - you are locked-in to Chromium now.
or is it that there are less bootcamps teaching OS native app UI development as there are JS front end library usage?
I would love to see the equivalent of the MDN but for AppKit, but alas
You may want to go to a public library and see what books they actually have. Those are not good stuff. I have actually looked at those, have you?
At least on Youtube you have a comment section where people discuss the material. Or if you are willing to pay some money, udemy provides some decent discussions and Q/A. And there are even better options out there.
Old books about Windows or Mac programming have all sorts of information that has apparently been mostly lost.
Two books I remember, perhaps not the best, but definitely with information that transcends specific technical details, are Bruce Tognazzini's Tog on Interface (or Tog on Software Design), and Charles Petzold's Programming Windows 95. The original "Inside Macintosh" series also comes to mind.
Just googled “AppKit development guides”. Yes, they changed to a reference format, what a shame.
It seems that good guides were moved to archive: https://developer.apple.com/library/archive/navigation/#sect...
App Programming quick link: https://developer.apple.com/library/archive/documentation/Ge...
It seems you’re just a little late to learn it :)
Another reason is that it can just run in browser without installing anything and "just click and it starts working" is HUGE feature, especially if you're in corpo where every fucking app needs management/helpdesk approval to be installed
And so we're damned to this miserable existence of using webapps
Microsoft products are a big one. oneNote web lacks a ton of features, teams Linux is very unstable and will outright not show the message history, jumping days or weeks at a time. I needed to make a powerpoint once and it just wouldn't save, the page would repeatedly reload and lose all the changes.
MS intentionally cripples its web offerings because native ones can collect way more data. The web and its featureset are not responsible for issues like "unstable Teams on Linux" and "a page repeatedly reloading and losing all the changes"
It is the most astoundingly buggy software I've ever used. I've experienced what you mentioned and more. Once, the GUI elements somehow failed to load, and buttons and menus appeared as text strings, like `sidebar_contact_expander`, and it was this eldritch horror of long string spam everywhere. In a native application. On Windows. Written by Microsoft.
Sorry. I have to cathartically vent about it whenever given the opportunity.
Our most popular Teams sub-site is "How To Work Around Teams Oddities". I don't even know if they are "bugs" because I don't know what the fudge MS intended.
I could press a button that I looked at in native app 20 years ago. Current day apps can't even get stable layout displayed 99% of the time. The "see the link, click the link, whoops something else got moved under my cursor in that 200ms interval" is soooo common if you try to use anything web quickly.
Some web haters counter with the idea that if we had a common runtime / sandbox, native could target any OS as well. They miss that the browser is literally just that.
I remember when that was called "Java". :-) It didn't work out on the desktop.
The browser ultimately delivered on the promise
If applets had better up-front security, better version management and auto-updates (like current browsers do), and better download-modularity such that one didn't have to download the entire app to open one screen, for example. Oracle buying it didn't help, as they have a reputation for suing everything that moves.
But if you had a common VM, runtime library, and sandbox that was feature-competitive with browsers, you’d basically just have reinvented the browser platform, but without the ecosystem of existing code and developers.
Native widgets are also just design-wise ages behind web widgets. Rounded corners and a slight blurred drop shadow? Forget it.
FFS, in 1995 styling was something the user did to applications, now it is a way for developers to mangle the fucking GUI so they can look 'unique' and 'on brand'.
Fuck this entire goddamned industry.
The rest of the computer looks like shit. The Gnome 43 file browser, for example, is an abomination of microscopic buttons. Try hunting down the "new folder" button, it's hidden under a "..." menu that isn't the hamburger menu and isn't another dropdown menu.
Macs and Windows aren't much better. I haven't used Word in ages, had to use it for something yesterday at work, and when I hit "Save As" it did seemingly nothing, after some fumbling I realized clicking "Save As" added a very unrecognizable "Save As" icon to the fucking titlebar. I have no idea whose horrible idea it was to put some buttons in the title bar and some buttons in the toolbar instead of all the buttons in one place.
Except when I change theme, it all looks nice except your shitty electron app.
Nope. I'm not making a word processor. I was trying to match the application look and feel to the product and to other applications for that product.
It might suck to you but having a graphical application look like Notepad is not what anyone wants.
Looking like notepad is not what you or whatever high-on-their-own-farts developers want. Looking consistent with all the other software on my computer is what I, and many others, want.
Sadly there are too many people like you in our industry so it will continue to suck.
None of that even applies to software used to remote control a robot and mostly used by children who's primary other computer is a mobile phone or tablet.
Largely because of people with opinions like yours. It’s not that long ago that this was not the case.
Children are not idiots and they do not need things dumbing down for them.
No but if the next door app is shinier and more colorful they will go for it over your grey buttons, and you will lose business.
[0] Excepting games, I suppose.
That's part of the problem, eye-candy sells, but carries a complexity tax with it. Oracle Forms was butt-ugly, but got the every-day CRUD/GUI job done good-enough and was quick to develop with. Oracle Forms dev's ran circles around our web devs in terms of productivity. I looked into why, and Oracle Forms just required less code and less keystrokes to make apps and apps changes. (Oracle ruined OF when they rewrote the GUI client/browser into Java from C. Otherwise, OF would still be common. I don't like Oracle the company, but OF was magical productivity.) KISS style = KISS stack.
I want things to align as the native GUI does. I don't want apps that break my assumptions about what the UI should be and how buttons should present and where they should be.
Then, if the app is running on a different platform, it's reasonable for the users to expect it to adhere to their own UI conventions.
This is why a lot of toolkits will restrict the way you shape your UI elements - they are the layer that imposes consistency.
The native GUI does nothing.
If you lay out something and resize the window to be smaller, your GUI will just get cropped, and there will be buttons offscreen. That's not a good experience.
Also when you have, say, a chatroom where you have a huge box of scrolling content and then an entry area, you typically want the entry area to be constant height and the scrolling content to fill the remaining space, whereas there are other applications where you might want a percentage-based split. The native GUI doesn't know you want this. You have to somehow tell it that. CSS makes it super easy. Other toolkits make it very annoying to specify logic like this.
Where CSS falls down is anything user-resizable. For example, a split view that collapses instead of cropping a text label. The CSS "resize" property is awful.
Media queries largely address this
Those are, BTW, where CSS got a lot of its basic layout features.
Most people trashing JavaScript, Electron or web stack have never done cross-platform desktop application development and they will never understand how much worse other stack can be.
Web frameworks (and modern desktop frameworks are starting to do so) use a functional approach, the view is a pure function of the state of the application, when you need to change something you change the application state and the view updates automatically. This solves a lot of problems that you otherwise have.
Exactly! The React pattern is incredibly intuitive, to the point where even google implemented something similar with JetPack Compose for native android apps. The only thing I dislike about Compose is the actual state management and a few quirks, but in general, I'd love to see more native UI solutions to adopt this.
def view():
return h("GtkButton",
title = "Hello”,
clicked = …
)
Frameworks like React don’t do as much as you think they do wrt the paradigm itself. Most of work goes into pleasing performance quirks of both js and dom.
Hum... Yeah. Except when the view is not actually pure, or when the framework can't decide, and decides to handle everything like if it isn't pure. Or when the state depends on the view. Or when some of the view depends on data from other part of it. Or when there is server data to synchronize...
But yeah, when you smooth out the movement, UI is evolving towards something nice. It's just annoying when people claim it's there already. It's not, there are plenty of problems.
Anyway, desktop frameworks are moving too.
A lot of the bloat and complexity of web frameworks comes from the issue that they basically have to implement a modern, functional UI toolkit on top of an ancient, imperative one.
Unbelievably so, DOM also follows that. It’s apples to oranges comparison, because you could use React, Vue and other wrappers with Gtk, Qt and other runtimes, because it’s the same exact model as DOM, literally.
DOM only lacks collections/datasources, because it originated from a non-programmatic format which required every collection element to be fully described from scratch. This nuance caused around 50% of clusterfuck that web experienced for last 20 years. The other 50% was an inability (or reluctance) to support custom reflow hooks.
[1] Ignoring web-scale and "enterprise". I don't think it's possible to optimize a stack for smaller/middle end and larger end at the same time. One end has to take a hit.
VS Code seems to outperform all the other IDEs I've used in the past
Its great and in most ways feels like a native app, but this is a very different experience than every other Electron app I use which all tend to leak significant amounts of memory over time (VS Code does this too but to a lesser degree), lock up in weird ways (task still running in task manager but any attempt to invoke a new UI window results in nothing happening until I go and manually kill all the zombie tasks running in the bg), etc.
Additionally the terminal has to use WebGL to achieve usable performance.
Which is exactly the point—the UI is written in HTML/CSS, not the native platform language, and the high-performance modules are written in C++ and Rust, also not the native platform language.
MSHTML and XUL eventually lost into obscurity, Electron will follow their footsteps.
I invite you to consider that the converse may be true: if you can keep things performant by RIIR or even C++, it makes a great case that desktop apps should resemble web apps, with a native backend talking to a JS/CSS/HTML frontend. It does not function as a cautionary tale, but as a compelling proof-of-concept.
As usual in this industry, those that have been around long enough have already been through this fashion statement.
HTML, CSS, and JavaScript are the lowest common denominator of all modern desktops.
It's just another toolset in a long series that started with teletype control codes, and went on to curses, Motif, Java's AWT, and so on...
As an illustrative example, try to find a conversation in microsoft teams (electron app) that's more than a week old by scrolling through the chat history.
We're in a situation where scrolling up a list cannot be implemented without breaking the UI.
Discord (@discord): "We use electron for the desktop app, so it’s all javascript and react!"
Consumers disagree. Almost every application is running chromium now and they couldn't be happier that it just works. It's great on Linux too.
"The only reason the web stack is used for desktop applications is because it is a bit cheaper and less effort than writing a good - native application"
You will have to write an electron application before commenting. Native UI's cannot be universal UI's, it breaks user experience, causes more bugs and looks terrible. I want my system menu to have a system UI. I do not want my user applications to look like the system.
Times are already changed, native is dead, long live the chromium desktop.
consumers don't make that choice. developers choose electron because it is the only cross-platform target where almost all the cross-platform fiddly bits are handled for you. there are lots of cross-platform approaches where the fiddly bits are not handled out of the box, and those are all little more than background noise compared to electron.
consumers neither know nor care how the app they use is implemented. they care only about which devices the app is available on.
now to be clear, electron fucking sucks as a user of applications. it is dog slow and awful on RAM, and the billions of devices running electron apps definitely contribute to global warming far more than native apps would, but developers think that the One True Language is JavaScript and that the One True Platform is the browser, and well, cults are immune to logic.
Computer power usage is not even on a blip on the chart of power usage globally. A cult would infer the usage is small. On the contrary chromium is in almost everything nowadays, even medical equipment.
The most robust graphics rendering engine is of course going to be used everywhere for graphics.
Be careful with this reasoning: even if one Electron app might run fine, what about like 10 different ones at the same time? The overhead will compound worse than native apps.
To develop windows desktop app you have to pay MS tax. To develop Apple desktop or iOS app you have to pay Apple tax. To develop Android app you pay Google tax. You could develop Linux desktop app but you are not going to make people pay for it because people will expect that it will be free - because Linux….
You make web app that runs on only free GUI standards that in reality exist and you are free and don’t have to pay anyone anything. Your business is not tied to App Store or whims of a corporation.
No, making windows desktop apps is free. Microsoft even has a free IDE, with a caveat that it's only usable by independent developers, or small businesses.
VirtualBox is free and open-source software, GPLv3 license.
Native desktop apps are:
1. much harder to develop
2. they are way more limiting in terms how things should be done
3. are implemented completely different on each platform.
It will take years to become proficient app developer on a single platform.
And compare that to Electron:
- you instantly have access to a huge, very dynamic community with tons of documentation.
- web standards are battle tested and improve every year
- your knowledge does not invalidate when developing for different platform (or when your UI framework just gets randomly abandoned: I'm looking at you Microsoft)
- a lot of pain points solved much better for web that for standard UI libraries
- you can apply your knowledge to web front-end development as well
I'm tempted to question the intelligence of Microsoft managers when I look at their desktop GUI strategy over the last 20 years
Balderdash! Tools like Delphi/Lazarus, Visual Basic, Clarion, PowerBuilder made it snap. Sure, they may not be "enterprise" or for writing word processors, but for everyday CRUD they are far simpler than typical web stacks. I lived it and did it.
Everyone thinks tools that don't scale (team size or performance) should be dumped, but doing things well at the smaller end is a good thing. One size rarely fits all well.
> are implemented completely different on each platform.
Lazarus can do Windows, Mac, and Linux. But I'd really like to see a state-ful GUI markup standard so apps could send text (HTTP) gui commands/XML instead of tie them to binary libraries.
> they are way more limiting in terms how things should be done
"Should be"? Biz wants practical over time-drain-idealistic. Too much should-be is a YAGNI violation.
> web standards are battle tested and improve every year
Any commonly used standard has that benefit. And web standards are a poor fit for GUI/desktop/CRUD. You'd have to break backward compatibility to solve that because DOM is inherently flawed for that need.
Teams, an electron app, uses 600+ MB of RAM. Slack, another electron app, uses 250+ MB of RAM. Outlook (not electron) 180 MB of RAM. (Still a pig) PowerPoint (not electron) 70 MB. Excel (not electron) 25 MB. Gnu Emacs: 3 MB. Adobe Photoshop: 50 +/- MB. A simple windows SDK program (all C) 1.4 MB. A tiny windows SDK program, all C: 0.5 MB of RAM
This is just RAM usage. For CPU load and overall performance the native apps win. Emacs startup time blows away VS code.
The question is valid. Why do we create modern desktop apps using HTML/CSS/JS?
Electron apps are only good if you sell hardware.
I have a pretty old desktop (so due for an upgrade) and VSCode starts up fast enough that I don't think about it. I'm sure Emacs starts up faster but would I even notice?
Worth considering: how often do you actually use those old apps?
Modern tech stack makes it cheaper to produce software, in a world where consumer don't give a shit and happily buy new hardware to run the worse software.
Nah. Spacemacs take 5-10 secs to load on my PC, vs a fraction of a second for VS Code.
It's faster on Linux, but I run Windows out of necessity.
This definitely needs evidence to back it up since my personal experience (and apparently from reading the comments, others as well) is the opposite.
Just be honest: the primary reason by far for the preference for GUIs using web tech over native is economics. One code base, multiple platforms. Native requires nontrivial per-target specialized code, which is expensive to develop and maintain. Web tech has given us the closest I can see to what Java promised but failed to adequately deliver: write once, run everywhere.
I would guess there’s a secondary reason: the tech world has an excess of web tech developers running around, and they tend to use what they know - for better or worse.
It's more about how users are affected by cost/performance tradeoffs.
It costs less to make a web app than to make a native one on most platforms. The cost of porting that web app to multiple OSes is minuscule compared to writing versions of that app in several different languages/platforms.
For users, it turns into "will you take 20% worse performance for 500% lower costs?"
Most users will take that deal any day of the week.
Given that users rarely get to make the choice, I’m not sure we have evidence saying people actually are happy with the sacrifice. I do know people complain a lot about battery life, laggy apps, and unpredictable behavior that often can be traced down to the technologies used to implement them. The problem is, your average user doesn’t actually know that’s the case, and doesn’t even realize that alternatives are even an option. People like me and the audience on HN are the outliers : most people have no clue what’s going on under their bank app, corporate app, ticket app, etc…
I can never figure out where this idea comes from. Do javascript programmers not know about GUI libraries like Qt, FLTK, Juce, or that there are a huge number of cross platform libraries for C++ ?
For users, it turns into "will you take 20% worse performance for 500% lower costs?"
I think you mean running at 1/20th - 1/200th the speed of a native program and 10%-15% more time spent compiling and testing for each alternate platform. My experience is that it is mostly correcting errors that come from a different compiler. Almost every bit of C++ stays the same.
Styling every single input to look identical on every platform does indeed waste a lot of time—but that's not native's fault, it's the "everything must be On Brand at the expense of all other concerns" people's fault.
Meanwhile I very much doubt the customer gives even a subconsious shit that your "app"'s radio buttons look identical to the (also custom) ones on your website. They probably do give a shit that they look unfamiliar compared with natives apps, so take a little more mental energy to process, and they probably do give a shit if your theming introduces any jankiness that wouldn't otherwise be there (and it very often does).
But, yes, that level of making everything look and behave identically everywhere is far easier to achieve with webtech. But you could... just not, instead.
Qt development with C++ is slow.
What are you basing that on?
Development with QML means JS anyway
That's actually only for parameters of the QML UI, which is a tiny part of working program. Actually the GUI that can be done through any library is a very tiny part of most programs. Declaring widgets and laying them out is not difficult or time consuming, there isn't much logic there.
good luck finding JS devs with Qt experience
Any competent C++ programmer can just start using javascript after a day or two of tutorials. There is no need to hire "a JS dev", you just hire a good programmer. Javascript is not that hard. Modern C++ is not even that hard, but as a language javascript is even easier.
Anyone who calls themselves "a JS dev" is probably not that experienced to begin with. Learning languages is trivial to someone with experience.
Have you ever made a GUI program with modern C++ and FLTK ? It's incredibly easy and the results are lightning quick while starting at 100KB.
It is not like you can drop by and say “Joe tomorrow you also write JS”.
Same for JS devs as it is not that they could not do c++. It is that now you require more so you have to pay them more. If you don’t - they will go to work in company where they do only JS.
Yeah, it's not something anyone considers an issue.
It is not like you can drop by and say “Joe tomorrow you also write JS”.
I've never even met a C++ programmer that didn't know javascript. Every one knew multiple scripting languages and javascript isn't that different. Where are you getting this idea that individual languages are difficult?
Same for JS devs as it is not that they could not do c++. It is that now you require more so you have to pay them more. If you don’t - they will go to work in company where they do only JS.
This view that knowing more than one language means anything is usually not held by professional programmers. My experience is that this is only an idea held by people who have just learned their first language and feel overwhelmed by learning anything else.
JS is a completely different paradigm from C++ mixing in functional programming with dynamic objects in a way that C++ simply cannot do things.
If a C++ dev wanted to learn Python, they'd pick up and read some books on the subject. Same if they wanted to learn PHP, Java, Perl, C#, or whatever. But when it comes to JS, they just try to wing it.
Their stuff kinda works, but they don't even realize that they are fighting the language every step of the way. As a result, they complain that JS is slow and the design sucks when the reality is that they don't understand, but have too much hubris to actually go back to school for a little while.
I spent much of the early part of my JS career fixing the code written by these kinds of C++ devs. While they wrote amazing C++ code, the JS they wrote was a mess. I could rewrite their code in a fraction of the LOC while making it more readable and faster too.
Where do these ideas come from? Every modern language has elements that were originally considered "functional". Good programmers will do well with any language.
What are 'dynamic objects' and what is the way that 'C++ simple cannot do thing'?
You make these claims without backing anything up.
If a C++ dev wanted to learn Python, they'd pick up and read some books on the subject. Same if they wanted to learn PHP, Java, Perl, C#, or whatever. But when it comes to JS, they just try to wing it.
Where are getting this from? Most programmers learn javascript before C++ because it's so easy to try things out in a web browser.
Their stuff kinda works, but they don't even realize that they are fighting the language every step of the way. As a result, they complain that JS is slow and the design sucks when the reality is that they don't understand, but have too much hubris to actually go back to school for a little while.
Who are you talking about? Is this describing a single person you met?
these kinds of C++ devs. While they wrote amazing C++ code, the JS they wrote was a mess
I have news for you, their C++ was probably terrible too.
Even labeling someone as a "C++ dev" or "javascript dev" is a giant red flag of inexperience.
This is the foremost proof that knowing C++ doesn't mean you know anything about JS.
JS objects are dynamic with the ability to add/remove class properties and methods or to dynamically change what class/object it inherits from all as the program executes. C++ classes are static and determined at compile time.
> Most programmers learn javascript before C++ because it's so easy to try things out in a web browser.
Most C++ programmers started programming C++ long before JS became popular. Most people who "know JS" don't actually know the language to any meaningful degree. I'm not talking about subtle things like the difference between `-0 === 0` and `Object.is(-0, 0)` or why you might use `x === x`. I mean that most can't tell me what a closure is, why you'd want to use one, or even how to use it in something like a factory. For the record, this question isn't even JS-specific, but applies to Ruby, Python, Lua, PHP, the ML family, Rust (actually just a ML with C-like syntax), Erlang, most lisps, etc.
> Where do these ideas come from? Every modern language has elements that were originally considered "functional".
JS is multi-paradigm offering imperative, OOP, and functional approaches, but because its functions inherited heavily from Scheme (I really wish Eich could have implemented scheme), it gets a lot of really nice properties.
Consider the following code (leaning heavily into the point-free side for sake of illustration)
let prop = key => obj => obj[key]
let map = fn => arr => arr.map(fn)
let filter = fn => arr => arr.filter(fn)
let reduce = fn => arr => arr.reduce(fn)
let sum = (acc, x) => acc + x
let pipe = (...fns) => val => fns.reduce((acc, fn) => fn(acc), val)
let data = [
{
fname: "John",
lname: "Doe",
age: 41,
sex: 'M',
children: [
{fname: "Fred", lname: "Doe", age: 11},
{fname: "Jill", lname: "Doe", age: 8},
{fname: "Elliot", lname: "Doe", age: 3},
]
}
]
let printSumOfChildenAgeOfMiddleAgedFathers = pipe(
filter(x => x.sex === 'M' && x.age > 40), //get all males over 40
map( //for each male
pipe(
prop('children'), //get their children and age
map(prop('age')),
reduce(sum), //add ages together for father
)
),
reduce(sum), //add ages for all fathers
)
> Even labeling someone as a "C++ dev" or "javascript dev" is a giant red flag of inexperience.
I consider language design as a bit of a hobby and I've spent time with a LOT of very different languages. Even so, I only consider myself proficient in a handful of them. Even setting aside the impossible task of learning all those standard libraries completely (even most experienced Java or C# devs don't actually know the entire standard library of those behemoths), just learning the warts and weird edge cases of almost any language you can name takes at least a couple years and with large and/or convoluted languages (eg, C++ or JS) it can take many years.
You realize they're just hash maps / dictionaries right?
Most C++ programmers started programming C++ long before JS became popular.
Do you think most C++ programmers today started 30 years ago in the early 90s?
You realize you can write everything you wrote pretty directly in C++, python, lua or a lot of other modern languages out there right? I get the impression that you don't know much about modern C++ and just base what you are saying off things you have heard from other javascript programmers trying to avoid learning other languages.
That's only a conceptual idea. In reality, the JIT uses real arrays and dynamically generated structs.
You can't actually implement them directly as conceptually described anyway. You have to have a has of boxed pointers and when you get around to adding functions with types, things get really weird. The class implementation is actually much more simple in many ways (not to mention being much faster).
> You realize you can write everything you wrote pretty directly in C++
I know you can't write curried functions "pretty directly" in C++ (Python and Lua are the languages I was discussing directly and both are far better for UI work than C++). Give it a try and post the results. I'd be very impressed if it took even just twice as many lines of typical C++ code.
Have you ever used modern C++?
Though I may be misunderstanding your point.
You can recreate the accessible GUI widget tree universe in ASM or WASM, but it probably won't be as accessible as standard HTML form elements unless you spend more time than you have for that component on it.
For example, video game devs tend to do this: their very own text widget (and hopefully a ui scaling factor) with a backgroundColor attribute - instead of CSS's background-color - and then it doesn't support tabindex or screen readers or high contrast mode or font scaling.
It's a widget tree with events either way, but Web Standards are Portable and Accessible (with a comparative performance cost that's probably with it)
A good http-friendly GUI standard would be also (as I describe nearby). But do note that businesses still use mostly desktops for everyday CRUD and don't want to pay a large "mobile tax" if given a choice. YAGNI has been ignored, as the standards over-focused on social media and e-commerce at the expense of typical CRUD. CRUD ain't sexy but necessary and common.
It's not easy to do both desktop and mobile UI's well and inexpensively in one shot. I believe there are either inherent trade-offs between them, or that the grand unification UI framework has yet to be invented. (At least one that doesn't require UI rocket science.)
Web standards is only real implementation of GUI that is not proprietary.
Making a web app you don’t have to pay MS/Apple/Google tax.
QT is also proprietary and you have to pay them quite a lot.
Well, there should be. It's a big gap in our current standards. DOM is missing roughly 15 common GUI idioms, and its text positioning reliability is broken and likely can't be fixed without tossing backward compatibility. More on these gaps: https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...
/? flutter python ... TIL about flet: https://github.com/flet-dev/flet https://flet.dev/docs/guides/python/getting-started
Mobile-first development says develop the mobile app first and teh desktop version can get special features later; one responsive layout for Phone, Tablet, and desktop
Phosh (GTK) and KDE Plasma Mobile are alternatives to iOS and Android (which do have a terminal, bash, git, and a way to install CPython (w/ MambaForge ARM64 packages) and IPython)
This guy needs to come up with a list of those well written UIs, because every single one I know is noticeably worse than native apps. I work with a Ryzen 9 5950X (16 cores)/64GB RAM, and the slack application (which I only use because of work) lags for common UI operations like switching channels. This is an application that consists in...displaying some lines of text with small icon images, plus the occasional youtube thumbnail. A 27$ billion company can't apparently make an electron app that displays text performant.
I use two bank apps in my phone. Both use web UIs underneath. Both are incredibly slow. I have also been unable to complete some operation in both of them at some point because I hit UI bugs and wasn't able to continue - something moved and I wasn't able to move or tap into whatever allowed me to continue. Given that apps are the only way I interact with banks these days, I'm seriously considering searching for a bank that does have a native app. I would love to be the client of a company that cares more about customers than about having more than one codebase.
Web browsers aren't even good at doing web applications. And unfortunately, web makers seem to have (IMO) lost interest in addressing the core problems of browsers. Instead they focus in wasm (because reinventing Java is somehow revolutionary), adding even more HTML5 popups, and not wondering why web pages bother users with weekly newsletters JS popups (that's what RSS was invented for, but apparently we should forget about it).
Why do we create modern Desktop GUIs using web technologies? Apart from the benefit of a single codebase, it's largely because widget based UIs aren't as good at designing complex layouts as web browsers are. That's the strong point of browsers (also, people decided at some point that having an unified style for all UIs that you use is boring).
A lot of people keep treating web browsers as some kind of cool, new technology. These people need to wake up. Web browsers are actually a bloated, horrible dinosaur that sucks in too many ways and we only use because there is nothing better (someone described it once as the MS-DOS of our days). And browser makers are fighting hard to bloat it even more to cover corner cases that only a minority cares about, while having normal, fast UIs remains a privilege that is only affordable by Silicon Valley companies. I really hope at some point we can stop using HTML/CSS/Javascript not just for desktop apps, but also for "remote" web apps.
But new people get born every day, and they won't get to know what was possible in terms of low latencies compared to web-based UIs (not saying this particular author is very young, I have no idea, but clearly somehow they are not considering the full picture to realize how bad modern UIs are)
Apparently not. You'd think the author would clearly recall the scenario you described.
Because fully-fledged apps on Win98/XP were horribly slow compared to today. Loading Photoshop took a couple minutes, while today it takes a few seconds. Just regular user interface dialogs in Word sometimes took noticeable time to display. The main factor of course was spinning hard drive speeds, and swapping memory or loading code pages from disk.
While note taking and chat apps today are pretty instantaneous. The UX latency of software running on my M1 MacBook is faster than any other computer I've had over the past 30 years.
Sometimes when people talk about how XP was fast, I can only imagine they're running it in a VM on modern hardware. Because sure, in that situation it's blazing.
Not really my experience - it's obvious the GUI is doing a lot of work to take what Windows XP would require and redraw it the way Windows 11 thinks it should. They don't feel faster, but now they have animated transitions and transparencies, while the CPU does 10x more work (which becomes more or less the same amount of time for a CPU with 1/10 of its clock).
This is one reason why a lot of Unix graphics applications feel so responsive on modern Linux boxes - they are doing the same amount of time they did 20 or 30 years ago while the computer is 10x as fast.
Yep. Hardware wise, we're in the wonderful position where Lisp and Smalltalk systems, once regarded as too slow to be useful on commodity hardware, are open and ready for action before you can even blink.
There was a brief magical period when SSDs first became widely available that they seemed to have a huge impact because most software was still written for a HDD-based PC.
Easy. Use a high-framerate camera to measure the time it takes for an IRC client to change between channels. Thanks to being written in technologies decently close to the bare metal, every application in the Windows XP era was in the same ballpark of response times, when you disregard disk access times. We're only talking here about raw latency between a click and a graphical response.
Now compare it to the time it takes to switch channels in Slack, which is the 27$ billion company mentioned in the parent comment.
Spoiler: you won't even need the camera for the latter, because the web stack is so horribly inefficient that the GUI reaction is perfectly noticeable and I'd even say closer to a whole second.
"but apps do more thing nowadays" is a fair point but it gets cancelled with the fact that memory, cpu and disks have improved immensely since the older systems that are being compared here.
Every time a product owner decides to make a web UI, god kills a kitten. But with a lot of delay, so maybe we can still save it between keystrokes.
Easy enough to disprove those that say browser based apps are inherently slow. Modern JS is significantly more optimized and faster than most other loosely typed runtimes, e.g python.
WebGPU will just close the gap further.
Anyway you can write highly optimized native code and deploy to browser via WASM anyway. No reason at all to deal with OS quirks. WASM compilation will get better and better over time
Performance differences aren’t that meaningful at the margins. You tend to give up a lot of velocity when you eschew browser based rendering.
JetBrains is far slower than both
Where is the slowness?
The post is about UI being in native for performance reasons, yet most of the processing/heavy logic of an IDE already is, or in a separate thread, even if the UI is in Electron.
At which point you're just discussing the performance gap between Canvas rendering and native graphics, which to a large extent disappears with WebGPU.
Who knows about memory, but I use modern hardware so not really a concern. Id rather software optimize for responsiveness than minimizing memory use. Computers are only getting cheaper over time, aggressively deflating in real terms
I can see how being more memory constrained might flip the priorities
I hear this a lot, and I don't think it's outright false, but it's a bit like saying a supertanker is slower than a tug.
The capabilities are just so far apart that it's not a good comparison, IMO.
I'm an IntelliJ fan (and customer) so I'll state that for bias, but the sheer volume of things IntelliJ _CAN_ do compared to VSCode I think is just mind boggling. It might be slower, but I think to compare that aspect while not looking at why is not quite useful.
I don't know what your definition of "modern hardware" is, but if a 32GB machine isn't enough to edit text files and run a glorified IRC without occasionally having to restart everything to reclaim memory, then yes, it really is a concern.
Re: the IntelliJ comparison: to me, IntelliJ feels qualitatively slower on average than VSCode, but VSCode routinely just stops doing anything at all and I have to restart it.
Hardly reducing any gap.
The truth is that the perception gap between web apps and native apps only shrinks over time, so that perceived performance matters less and less
> This guy needs to come up with a list of those well written UIs, because every single one I know is noticeably worse than native apps.
I don't know the OP's context, but I have to agree with you. In no reality that I've been in has this been true.
Could it be he's confusing electron with native?
Just about any Electron app I know of can't do large tasks of any kind. The web platform is not built for this kind of work.
It requires clever tricks we learned in the 80's.
You can't keep the whole state of the application in a puny 64K of memory. With luck, you can keep about 30K of it, provided the app is small enough. What you need to do is to just load what you need to display, and get rid of the rest as it fills up the memory.
And beware of JavaScript arrays - they are a lie.
A desktop app written in Tauri that punts most of the heavy data processing to Rust with a UI layer written in well-optimized React or Solid.js is really plenty fast. In practice what we get with most Electron apps is not especially well written React with frequent coarse grained re-renders, inefficient data processing, frequent allocations causing GC pressure, and excessive JSON RPC. The problems here aren't HTML/CSS + JS for basic event handling, it's everything else about how the software is developed.
Unrelated, I sure am glad I can turn off CSS in my browser because that font was terrible on the eyes.
A comment on Wayland stood out, namely that it's
> barley supported
I'm still unclear whether that's a typo, or a snide remark :)
On TFA's TL;DR on the "why", though, I'd mostly agree: we have HTML/CSS/JS as desktop UI, because having a single to track is better than having to support at least three (Win, Mac, X11) GUI frameworks. It's the least bad option, even if that means that the underlying OS just becomes a facilitator for Electron.
What depresses me is that Electron is essentially the new Emacs, and JS the new Lisp.
> keyboard/mouse sharing
I'm curious by what you mean with this?
Adding a second set of mouse/keyboards with their independent focus is for me simply a matter of running a few commands:
swaymsg -t get_inputs # lists input, allows you to identify which inputs you want to add to another seat
swaymsg seat my-new-seat attach my:second:mouse:identifier
swaymsg seat my-new-seat attach my:second:keyboard:identifier
swaymsg seat my-new-seat xcursor_theme Breeze_Snow
I'm not sure if that's what you mean by it, but it feels better and easier to configure than what we had with X. There are a few bugs where apps don't handle multiple seats that well, and Xwayland applications are a bit left out (especially with cursor themes IIRC).
There was a sudden explosion of client platforms in the mid-2000's and the existing solutions for cross-platform UI were expensive and slow-to-modernize (QT), poorly suited to applications (game engines), or outright murdered (Flash).
But HTML/CSS/JS SPA's were becoming a mature application platform in browsers during that same time, and brought with it a huge generation of new developers that learned on those technologies first. When demand swung back to desktop apps, they brought their tech stack with them.
You can make arguments for whatever technical merits you want, but they're all just differences seen in hindsight. It was mostly just a de facto win.
Yet even as this happens and HTML/CSS/JavaScript rises that doesn't mean that there is a decline in the making of desktop applications. I think that desktop applications made with native technologies are being built as much as ever, its just that the industry as a whole has grown to accommodate the vast influx of new HTML/CSS/JavaScript developers. For example, my favorite applications are build in Swing (IntelliJ and related projects) or in QT.
> Just for completeness I should mention Linux, it is the best computing platform to happen to the world and should be admired in every way – except one! the desktop/UI sucks, its awful in almost every way
I say that KDE is awesome. So that is just your opinion, and not everyone agrees.
> Developing desktop apps in 2022 is essentially an HTML/CSS/JavaScript endeavour
That does not follow.
> the performance of a well written UI in a modern browser out-performs a native desktop application in every category of sped, usability and presentation for most usual use cases.
That is not my experience. Visual Studio Code doesn't seem to run as smoothly as I would like. Meanwhile every C++/QT application I have run works perfectly. Where are you getting this from?
OTOH, it is not a beautiful, lovely app. The UI does look like 1999. But it works fabulously.
I’m in a bit of a unique position where I work on both a Qt app using Qt Creator and a React app using VS Code. Qt Creator has crashed on me numerous times, has slower initial loads, regularly has weird visual bugs, and is overall much less enjoyable to use.
I develop on a modern windows computer. Maybe Qt Creator performance wins against VS Code on Linux? In my experience, VS Code does not perform as well on Linux as it does on Windows or OSX.
But I think that QT creator should have a faster initial load then Visual Studio Code, because the later has to open up an entire browser render-er to work. QT creator opens instantly on my system, but visual studio code lags for a second. The weird visual bugs might indicate something else wrong with your system which is messing up the program. A picture might help us to find what the bug is so we can fix it if there is a serious problem with QT creator.
As for the less enjoyable to use thing, there isn't much I can do about that. Visual studio code is probably more fun to use, and React isn't too bad either. Using React can be a joyful experience indeed. But enjoyment issues aside, I think that a good C++/QT based application should have a performance advantage over one made with HTML/CSS/JavaScript and Electron. Visual studio code can be more enjoyable but still perform slightly less well, because it doesn't have to make a difference to the end user that it does things a couple milliseconds slower.
If that would/could be standardized, I would never again complain about a desktop-scale data manipulation app shoved into an HTML/CSS/JavaScript host container.
Make CRUD/GUI Great Again! Mice & Desktops Live!
Do we need a mass petition to get the ball rolling? I'll sign, several times even ;-)
List of HTML shortcomings per GUI: https://www.reddit.com/r/programming/comments/otixwo/comment...
I have been working as a frontend engineer for over 10 years, developing javascript webapps, I know my HTML/CSS/JS, and I'm also very aware of their shortcomings (especially in the context of desktop apps).
I have tried multiple times over the years to build my own native Mac Apps, but ultimately failed. I failed because I found it to be much harder to get into:
- APIs are undocumented or lacking any examples
- I cannot simply look at the source code of whatever API and figure out what it does
- The platform itself will have bugs that are basically never going to be fixed (or until the next OS version)
- XCode is slow and very clunky (and you have to use it one way or another)
When I already have plenty of experience building UIs for the web, why should I invest in learning these proprietary technologies?!
All I really want is the better performance, lower resource usage and integrated UI, but I don't think it's worth the hassle.
Maybe I am better off writing the most efficient webapps that I can and rely on projects like Tauri to bring them to the desktop..
That is a compliment.
I am not an Apple fan, but I remember in older times being jealous of how XCode (circa about 2.0 or 3.0) would nicely come with pretty good documentation, documentation that is now close to deleted in exchange for stuff that makes unedited doxygen output blush, and when you find the old docs they are all marked as "outdated, do not use".
I miss the experience of dealing with Delphi, to be honest :/
Speaking from a FreeBSD user's perspective: No, actually they are not. No electron binary runs on FreeBSD because Electron is based on chrome, and some of the linux sandbox syscalls needed for chrome are not emulated. So when things move from a real native Linux app to Electron, they become unusable for me.
Not to mention that Electron is bloated compared to a native app..
I'm madder about google not allowing DartVM to be ported to FreeBSD because they "want to keep repo free of platform-specific code" while have code dedicated to Fuchsia, Chrome OS and Android-specific code in there.
I've tried and failed to run slack and spotify. I've never tried VSCode because emacs is my IDE :)
At the risk of sounding like yet another crusty old man here, I agree 100%. I cut my teeth on Delphi (among other things), and I took it for granted that whipping up an application with a decent looking and highly responsive GUI would always be that easy. (Because, why not?).
I came back to programming after a 20 year hiatus, naively imagining that there would be something like Delphi for the web where you could design your UI visually, hook up some event handlers, and off you go. Couldn't have been more wrong.
On the plus side, there are some things I never imagined being able to do back in those days, like use a good Smalltalk system and have it run blazingly fast on standard hardware.
It's frustrating that some of the greatest ideas of the past (Lisp machines, Smalltalk machines), things that were so far ahead of their time and were unaffordable on the hardware of the day, are now so easily affordable, but hardly anyone knows they existed. Coming back and looking at what's available today, it feels like kludges piled upon kludges.
But imagine you're writing a native mac app. Not even a cross platform one, a fully native AppKit app. For years, if you wanted window tabs like safari, you had to implement them yourself. Now you can but only if you use their whole windowing system wholesale. You still have to do everything yourself if you want tabs like Pages/Numbers. And that's the gold standard.
Not to mention complex controls like code editors, there are like 3 amazing ones for the web, on desktop you have what Scintilla? Setting that up is a lot harder than downloading an NPM package. Same with node editors, nothing comes close to React-Flow except maybe QSchematic and that has like 0 documentation and is not available in Python.
The situation is far worse on windows. WinForms and WPF apps need to be heavily styled to look even remotely decent (they don't look "native" by any measure, their menus and toolbars don't follow the native style), and both are pretty much deprecated now (they "maintain" them I guess but all the effort is going into WinUI 3)
Qt consistently fails to look anywhere near native on macOS and is way more painful to set up and use them even the web mess. QtCreator sucks and MOC is an abomination.
The only good "native" GUI framework I can think of these days is Avalonia if you can stomach XAML. All the good parts of WPF with less of the crap. They only need to have a good default style but at least now there's a fluent style you can get from a third party (there's the downloading random crap again)
HTML and CSS are sane approaches to the problem of highly flexible GUI being generated and/or delivered over the network. That said, their implementations could be vastly improved (CSS has come a long way, but HTML needs HTMX/Livewire baked in).
OS X is a dream to develop for. It really is amazing.
Windows, is honestly, not terrible. I don't know anything about C# or Winforms or whatever modern Windows GUI apps are created in, I used Win32 API and MFC. They may have been a little kludgey, but they got the job done. Lots of documentation and code out there, like 20 times as much for the Mac.
Now, Linux... I've tried. Haven't gotten far. Both Qt and GTK.
Anyway, it's obvious why everything is written in Electron and friends. People are familiar with it. Everyone's a web developer. It's cross-platform. It's a big deal to learn another environment. Why wouldn't you want to be able to run on Windows, web (phones/tablets), Linux...?
Tried X11 directly on Linux before I decided that it was just too difficult. Switched to QT, and there were a million bugs and quirks that forced me back to just Windows GUI development.
JavaScript/HTML GUI frameworks along with embedded browsers have been the key to cross platform compatibility without all the fuss. But it seem to also have become the death of good real-time and responsive UIs.
If anything, several C++ threads indicate those devs are tired of getting paid less.
Sure, my code will be 2-10x slower than the C++ stuff, but modern companies move really fast. A given user-facing project often gets thrown out every 4-5 years for yet another iteration. I will have been in maintenance mode and adding little features for 2-3 years. The C++ devs would barely be done with the MVP before it would be time to start over.
This means my total value to the company is higher than the C++ dev (even though they're a talented and amazing developer)
This is all before mentioning the supply and demand issue. Look at stackoverflow's surveys.
2013 5.1%
2015 6.0%
2017 8.5% (11.9% of the 72.6% that identified as doing web development)
2020 37.1% (peak)
2022 25.9% (current)
Everyone wants senior devs, but the number of devs with just 10 years of full-time experience is going to be 5% or less (despite the rhetoric, it takes more than 5 years to learn the frontend and that's only if we disregard the seriously niche things like WebGL). Instead, we see lots of "senior" JS devs that don't even know JS let alone the DOM. In contrast, you can easily find C++ devs with 15-20 years of experience (in fact, they may be easier to find than a C++ dev with only a handful of years of experience because people aren't learning C++ and C++ eats it's young).
The combination of productivity and lack off seniors drives up the salaries of middle and top end frontend talent.
Well, I agree it will have fewer memory bugs. But fewer issues altogether… you're just bragging now.
Your application will have awful keyboard navigation, will not support normal well established shortcuts, will contain vulnerable js that you will never bother to replace…
...what?
These are all things that any developer - C++, JS based or otherwise - needs to implement and/or be mindful of. This has nothing to do with the language/runtime/platform and everything to do with the team implementing it and their level of attention to the platforms themselves.
Hell I cannot tell you the number of QT-based applications I've opened on macOS that violate established shortcuts. This isn't an Electron-only problem. ;P
You rag on them for "bragging" but your entire comment is basically one big attempt at kicking down on another development platform.
There are many other reasons though. JS has only two number types (double and BigInt). As such, we can also essentially get rid of overflow errors that C++ does nothing to prevent. JS has an event loop baked into the core, so another class of C++ bugs go away. That same event loop bakes in its own thread pool to safely manage IO eliminating another class of bugs. Web workers (system processes) limit data sharing to slower, but more safe methods and eliminate yet another class of bugs. I'd note that these are some of the biggest possible sources of the hardest to find bugs and eliminates essentially all of the security nightmares found in C++ code.
Adding to this, JS code is more dense which tends to correlate with lower bug counts (until you reach super-high density like APL at which point you get maintenance issues). JS first-class functions with automatic closures adds a very powerful tool that is all-pervasive in real-world JS code, but isn't even present in C++ code (yes, closures exist, but in an extremely limited and manual way). Since ES2015, JS has powerful features like destructuring that make all the little data manipulations (so common in UI code) much easier and less prone to subtle bugs. If bugs do happen, JS makes it much easier to continue gracefully without everything crashing to the ground.
None of this should be surprising. C++ is an amazing language in its low-level area of expertise where all the features that can create more bugs are necessary and lead to amazing performance.
It also shouldn't be surprising that a very high-level language tailor-made for UI would be better at creating and maintaining a UI with fewer bugs.
As to keyboard navigation, that is entirely up to the devs to implement (whether C++ or JS). That said, web standards take A11y very seriously. Electron has `globalShortcut` and easy handling of shortcuts is baked right into the system if devs care to use it.
https://www.electronjs.org/docs/latest/tutorial/keyboard-sho...
On the other hand the C++ developer can use boost and Qt libraries to have a wide range of well tested, well implemented components that implement a wide range of things, without having to sift in npm for hundreds of low quality abandoned modules.
So IN TOTAL, your point is far from proven.
> As to keyboard navigation, that is entirely up to the devs to implement
No. Toolkits for example implement decent tabbing. The qt designer offers a GUI to decide the tab order. And assigning shortcuts is even easier.
If you go and use kdelibs you get support to completely customize every single shortcut from the control panel, or from your own application.
Oh by the way with Qt you also get support to find in which directory to save settings, data, and so on. Which is not so trivial because all the defaults can be overridden by specific env vars.
You can either use C++ and a toolkit that does all this stuff, or JS and reimplement everything every time.
Now you're arguing that reimplementing every time is faster. It's an opinion but I don't think it's as obvious as you think it is.
And I ran to the react stack about 7-8 years ago from native iOS development. It made everything so much easier. On the way out the Cocoa door, I was pelted with comments about Performance, which was viewed as lacking in JS, a true second class citizen on a smartphone.
And they were right. If your app needed it.
Which it generally didn't - until it did. When the app I was writing started dealing with larger and larger amounts of data, a larger and larger number of views to visualize that data, large images being panned and zoomed ... I wanted the bare metal, I wanted the multithreading. I wanted the memory control.
That said, if you aren't going to push things that far graphics wise, and most apps don't, js/css/html is, to me, a far more joyful way to go.
Author didn't even touch on compile-time benefits, but they are spectacular when you go from Xcode, to React, then put the afterburners on with Fast Refresh, which is, truly, instant.
We need to push for Wayland. With MS Windows adding in advertising, and OSX being a locked-in expensive choice, Linux desktop needs to gain ground now.
Our goal is to get native look and feel on every desktop platform, with a great developer experience (and also designer experience). To do that we want the developer to use the programming language of its choice by having idiomatic binding to many programming languages, and we want to build a design tool that a designer can use to produce the final artifact.
We've not reached all our goals yet, but we're progressing.
But, is it really worth to have applications that take up 1 GB just for editing text or just for chatting? If it was only one such application, then it might have even been fine. But the plethora of chat applications and all of them heavy-weight Electron implementations really is a waste of memory. I need that saved memory to compile in parallel.
The same goes for Visual Studio Code. For me, it is visibly lagging when moving the cursor, scrolling, or editing, especially when it is large amount of syntax-highlighted text. Good old native text editors are still so much more responsive and less resource-intensive.
This is why Valve -- a company whose founders know Microsoft better than anyone, having helped build it -- has been treating Linux like a first-class citizen since the introduction of the Windows app store model. It's necessarily part of the calculations in every meeting room and boardroom where major application platform decisions are made. "Is there a way we can do this without introducing a Windows dependency? Yes? Then for heaven's sake, do it that way."
It's likely that the only thing that keeps Windows alive as an ISV platform is that Microsoft as a whole just doesn't give that much of a crap about it anymore, one way or the other. But everybody who gives it a few moments' thought understands how quickly that can change.
If one could somehow abstract and standardize GUI elements it could unleash a lot of creativity around browser-based desktop apps. Native app development frameworks would benefit too, they could re-implement some aspects of those GUI elements natively (outside browsers). Developers would have less friction to switch from browser to native and back.
Has any new UI paradigm emerged on the web in the last 25 years? Maybe the hamburger button? Honest question, I struggle to think of any. The richest web apps are still aping desktop apps.
But I think technically it is possible to overload whatever is available and have very decent, easy to build apps and have a productive, cross platform option. Its not going to make those pushing gui limits sweat, but that is not its point.
In any case its not going to happen as the experience with standard development and adoption is quite painful
"Technically", perhaps. "Easy", no! It appears the DOM is inherently too flawed to serve GUI's well, and fixing it would likely break backward compatibility. Forcing DOM to do GUI's is possible, but turns even women bald.
The GUI markup browser-and/or-pluggin could be built on top of the Tk or Qt GUI kits to avoid starting from scratch. Put a nice XML wrapper over those C/C++ libraries and you have a GUI browser.
Missing or poorly-done GUI idioms in HTML/DOM:
* Stateful-ness tied to session
* Predictable & consistent text positioning
* Split-panels/frames (HTML5 butchered them)
* Combo-boxes
* Nested drop-down menus
* Context menus (right-click)
* MDI/dialog ability tied to session
* Tabbed panels
* Tool-bars
* Sliders and turn-knobs
* Editable data-grid
* Expandable trees
* "Normal" multi-select
* Status bar (newer browsers screwed them up)
* Fuller keyboard shortcuts.
* Graphic/art elements & data inputs at same time
* Consistent & biz-friendly number & date inputs
Wouldn’t this be a bit better than what we are stuck with now?
That said, I think the argument goes like this: "Developing GUIs with HTML/JS is hard, but is better than any other alternatives. A better solution would be to come up with a new standard that is better than anything else, and have all the vendors agree to implement it."
As such, it comes up against the "now you have n+1 standards" problem, which should be a red flag. It feels it would indeed require a magic wand to work. So, it's a non-starter for me.
And I did not agree with his complaint that it's hard to learn to make GUIs in HTML/JS/CSS. As evidence: I'm pretty dumb, and I can do it really well. As further evidence, millions of other people aren't much smarter than me, and they can also do it. I think HTML/JS is popular because it's actually pretty easy to pick up.
Yes, you can complicate it if you want to. One way to do this is to adopt a lot of complicated dependencies. But, that's not an issue with the underlying technology, it's an issue with the accessories. And if you suffer from having to rewrite your application because the framework changes underneath you, that's the framework's issue, too.
Anyway, I also hope somebody waves a magic wand and makes everything easier, but in the meantime I'm super happy that I can throw together an Electron app — albeit a pretty bad one — in just a few marginal hours.
I have an open source desktop app to help esports coaches (https://vodon.gg/). When I was designing the app I was happy to make it a Windows only, C# application (despite not knowing anything about C# development). I figured that if I stayed inside the Microsoft ecosystem then things would work relatively well and I could pick up a new programming language while I was building a new app.
My first stumbling block was the UI system. Windows seems to have a bewildering amount of UI frameworks to choose from and it was unclear which framework I should back (MAUI?). On top of that, the video processing library I wanted to use, GStreamer, needed to work directly with window handles which didn't seem to be possible for some of the newer frameworks as they have a global window handle for entire app. Instead I'd have to work with DirectX buffers and apply them to window surfaces. Ok then, I'll learn about Direct X.
After about a months worth of hacking around, I think I had a very basic two videos playing at once concept. At this point, I didn't even really know what the product was and hadn't done any work figuring out what actually would work aside from a sketches on paper and some thoughts in an Obsidian document. I'd had enough by now so I switched over to Electron and hacked together the app in about half the time, two weeks, that I'd spent noodling around in C# trying to make things work. Not only that, I could iterate very easily on my features as I went as I didn't have a solid idea of what this product would look like.
On top of all of this, even though I have a deliverable app in Electron, I still haven't signed my app so every user has to jump through all sorts of hoops to install because I don't want to shell out ~$300 per year to Microsoft (let alone Apple on top of that) to sign my free open source app to run.
The next version I'm working on will be entirely web based now that some of the browser file system APIs are advanced enough to work with local files which side steps the signing issue and makes it very easy to "install" the app (I'll likely go the PWA route).
Microsoft's killing desktop apps, or at least it feels like they're trying to. Between the inconsistent UI frameworks to code signing, it sure feels like malicious intent.
Won't change unless the end user stops accepting these bloated horrors.
It was promised as a better way to write cross-platform UI Apps.
"Flutter desktop isn’t there yet" https://news.ycombinator.com/item?id=34643291
If you start with UI toolkit not dealing with any of the above points, you are limited in what you can do. Maybe you don't need the first two, that's fine, this is where electron is. But if you have to do a content creation application (Maya, 3DSMax, Blender, Unreal Editor, etc.) - you need to support multiple windows and docking windows in other windows - preserve layouts, etc.
And then Remote Desktop, because you may need someone to assist and log in to the machine, or work remotely (especially today), and if RDP does not work (sorry, but there are some pure OpenGL toolkits), then it's a loss.
Ah yes, the W3C. The group that has so much influence that a different industry body (consisting of the folks who actually implement the browsers) decided to take over the web specifications.
Since he claims to have been around for 30 years, he should remember that this is a cycle. We always sacrifice something for interoperability. There's no reason not to make an electron app if getting it out now with your current set of programmers to as many platforms as possible.
Anyway, making the best out of constraints is just engineering.
For anything more complex then you need to do your homework.
But hey, a webapp? You're already in your browser and don't have to install anything. User acquisition suddenly becomes so much easier. So those apps win, even if they wrap their web app in a shitty browser to get on the desktop.
import webbrowser
# initialize back end
# ...
webbrowser.open(...)Not at all, but the Dreamcast was ;-)
That's it. The article seems rather misguided in several ways.
So anything cross platform would that includes web will basically be web.
It’s a very sad state where native platforms are so narrowly focused on their own use-cases that there’s no interoperability at all. The web for better or worse (definitely worse) is the best cross-platform toolkit. I would love to see Google/Apple/MS hash out a standard for native apps but it would be ruined immediately because every platform would try to inject their own nonsense into it because identity or branding or whatever.
Also sometimes just laziness.
Although electron sucks it wastes so much memory.
- Mid to late 1970's - people discovered they could build microcomputers, cheaper and less capable than the minis or mainframes of the day.
- Visicalc showed that micros could be a good business tool without all the expense of huge shared mini or mainframe systems.
- In 1981, IBM made a micro, so people started taking it seriously. Microsoft made a really good business decision to license not sell MS-DOS to IBM. It was the cheapest OS so the one most people picked.
- Rest of the 80s: Clone manufacturers made the hardware cheaper and cheaper. Clones also ensured Microsoft's OS worked as most software depended on it. This was the beginning of the downfall of IBM. Microsoft continued to acquire/produce business software for MS-DOS.
- PCs gained capability over the years. Microsoft introduced Windows 3.x, and people really liked it despite it's numerous flaws. With various GUI programs starting to become common and easy to do on the hardware, business interest of this platform flourished and it with Microsoft and Adobe products became the default.
- 90's: Microsoft started using OEM agreements and other business tactics to ensure OSes other than Windows were difficult to purchase. The Internet craze started and the PC was its primary thing that brought that to consumers in the 90's. After Intel came out with the Pentium, the Wintel marriage was solidified and thus began the downfall of CPUs in PCs other than x86.
- Microsoft continued to ride this domination wave until Javascript provided a way to deliver a desktop like experience without having to go througH Microsoft at all. 9/11 slowed things down everywhere. Microsoft let IE6 rot while it was working on Vista, giving Mozilla (backed by Google) a chance to sneak in a way to deliver a non-Microsoft experience on whatever platform was running the browser.
- 2007 - the iPhone - that began the shift from PCs to mobile for everyone. Because people wanted the Internet in the 90's, and email, and chat, and all it's good stuff, but they didn't really care about Windows. Windows was just what worked at the time. Apple adopted the walled garden model - meaning the browser was still the only way to deliver an experience outside of permission or control of another company. Why wasn't Microsoft in this position? It thought it was (and it looked lke it was)... it thought it could sit on its ass, collect OS license money and boss around both OEMs and cellular carriers like PC OEMs. What Apple did in the 00's with iPod->video iPod->iPhone iteration and timing is either super shrewd or super lucky.
- 2014 - cloud services - everyone finally saw what Google was doing and copied it, which was just a copy of the pre-micro mainframe way of doing things, but with prettier terminals that are virtualized and can do graphics and audio now. Unfortunately businesses don't want to give up Excel.
Pick your GUI elements, drop them into the forms, hook up some events, and you're golden.
The key to success on the Windows platform is to ignore the .net obsession that Microsoft has wasted decades of work on, and stick with the tried and true Win32 api set.
https://www.reddit.com/r/webdev/comments/r59nzr/i_regret_goi...