16 ms·

JavaScript? (2022)

141 points by airstrike 4y ago

superkuh 4y ago
Because it's the cheapest way for groups of people to do something that works enough most places. Unrelated, I sure am glad I can turn off CSS in my browser because that font was terrible on the eyes.
- MonkeyClub 4y ago
  Indeed a terrible font choice, while the writing could also do with a second pass. 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.
  - rbanffy 4y ago
    Oh I remember how support for Unix and Motif was - every Unix just had to be different from all others. Looking at you, HP-UX, AIX...
  - MayeulC 4y ago
    That Wayland remark is very weird.It probably comes from an echo chamber or someone who hasn't actually tried it/done some proper research. Or maybe they only use a DE that barely supports it? (which? XFCE?)
    - superkuh 4y ago
      I get the feeling that we're all just touching different ends of the elephant (https://en.wikipedia.org/wiki/Blind_men_and_an_elephant https://en.wikipedia.org/wiki/Blind_men_and_an_elephant). If you want to use applications that involve keyboard/mouse sharing, for example, the wayland stuff is very beta/experimental if it's there at all. It's not just DEs.
      - MayeulC 4y ago
        Thanks for the metaphor, I had forgotten about it. I'm of course biased myself, having started to use sway as my main "DE" in 2018. Sway is quite mature nowadays, though it still has a few bugs. > 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 Of course, this can be added to the configuration file to make the settings persistent. With this, a second cursor appears for the second mouse, with a different cursor theme, and a different focus, tied with the second keyboard. I can type into a terminal, and have another person next to me type a comment in the Firefox window next to it. 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).
tenebrisalietum 4y ago
Here's why, in rough chronological order: - 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.
jeroenhd 4y ago
It also helped that web developers can be hired for a lot cheaper than native application programmers. Fast, lightweight code is hard to write and therefore expensive. Much easier and cheaper to just add a slightly outdated copy of Chrome to your application and program the entire thing in Javascript.
- Klonoar 4y ago
  We repeat this one in every thread but I'm not entirely sure it holds true anymore. If anything, several C++ threads indicate those devs are tired of getting paid less.
  - eddsh1994 4y ago
    Yeah… I earn literally 5x working on a web stack with some Python than I did 4 years ago writing C# windows apps. Anecdotal but I’m pretty sure it’s normal to see big increases when you move over.
  - hajile 4y ago
    I can write as much of a project in a day using JS as a C++ dev could write in a week or more. My code will have fewer defects and more critically, will be 100% free of the worst kinds of defects that C++ enables. 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) That's a 5-7x increase in demand since React was first released in 2013 (despite all the framework wars of prior years, the number of dedicated frontend devs was relatively small). 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.
swatcoder 4y ago
It's really just an accident of history. 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.
- rbanffy 4y ago
  Interestingly enough, in the end, NetScape was right.
- scotty79 4y ago
  It's really incredible how bad are all of the native UI toolkits. So many of them. Zero progress, only handful of interesting ideas.
marstall 4y ago
Great writeup, thanks to the author for sharing his deep experience in such a readable way. My career has also spanned different eras of UI tech, from win16/32, through server-generated HTML, Objective C and Swift/UI on mobile, and now I'm a full-time react and react native neckbeard. 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.
- bombolo 4y ago
  Well if you include the "download all the js dependencies" step… there it goes any time benefit you might have gained.
  - marstall 4y ago
    that's not part of Fast Refresh. Fast Refresh only compiles the lines you've changed - something like that.
    - bombolo 4y ago
      You know that c++ also doesn't need to recompile everything if you just change 1 file right?
      - marstall 4y ago
        there's a magic with fast refresh which is that the code doesn't need to be rebundled and redeployed after a change. this would correspond to the linking and execution phase in c++. makes for an amazing experience when you are doing interactive development, orders of magnitude better in terms of responsiveness to the code you're writing.
mxmlnkn 4y ago
I see the advantages of bundled websites masquerading as desktop application in regards to platform support. 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.
diegocg 4y ago
>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 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.
- j1elo 4y ago
jjkaczor 4y ago
My biggest complaint about HTML/CSS/JavaScript apps on the desktop is that typically UI components written for the browser do not implement all of the keyboard commands for selecting/deselecting multiple individual items (or contigous sections) from lists/tables or trees - with or without checkboxes/ticks/toggles. 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.
- wizofaus 4y ago
  Even QT has that problem, particularly if using QtQuick/QML.
  - tabtab 4y ago
    Is that a QT-specific problem? Does the Tk and MonoWinForms kits also have that flaw?
- mvladic 4y ago
  Yes, I agree. And it seems that the author of this blog post agrees with that also, because he wrote: "If I could wave a magic wand, I would create an open working group, with the influence of the W3C behind me, to create a mandatory web standard for browsers that defines both a subset (to simplify and create an appropriate desktop security model) and an extension of CSS/HTML that is specifically optimized for marking up and implementing desktop applications, and have that all built into modern browsers as standard."
  - tabtab 4y ago
    Amen! Business CRUD & desktops have been ignored over sexier domains such as social media and e-commerce. But it's still important. Ignore the plumbing of the world, and you get a pool of shit on your floors. 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/h6zi86w/ https://www.reddit.com/r/programming/comments/otixwo/comment...
lasagna_coder 4y ago
Unless I missed something, the article neglects to point out that this is only a specific subset of desktop apps. Companies who build desktop GUI apps for products people are willing to pay for don't necessarily use any of the systems mentioned.
JCWasmx86 4y ago
> the desktop/UI sucks, its awful in almost every way, you are essentially targeting X11 which was developed in the 70’s and it shows. It works and it brings a couple of quirky features to the table which are quite nice, but, in essence, if you love Linux, just forget targeting GUI desktop stuff, you need a graphics screen, a browser (for a real UI) and a terminal window – that’s it… there is the Wayland stuff but its far too early, it’s also disjointed, barley supported and is grappling with compatibility with legacy stuff… 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.
- dylan604 4y ago
  >The only reason the web stack is used for desktop applications is because or is it that there are less bootcamps teaching OS native app UI development as there are JS front end library usage?
  - deleted 4y ago
    [deleted]
  - yen223 4y ago
    There's just straight up less educational material of any kind that teaches native desktop app development. I would love to see the equivalent of the MDN but for AppKit, but alas
pphysch 4y ago
I worked with a junior dev who was developing his own 2D/3D data visualization framework. He used XML and ended up reinventing HTML for the most part. 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).
MangoCoffee 4y ago
my legacy VB6 Winform app run faster than any html/css/javascript desktop app on Windows
adamredwoods 4y ago
>> there is the Wayland stuff but its far too early, it’s also disjointed, barley supported and is grappling with compatibility with legacy stuff… 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.
xrayarx 4y ago
I'd like to know how Dart and Flutter would compare to this. It was promised as a better way to write cross-platform UI Apps.
- doodlesdev 4y ago
  Recent discussion related to this: "Flutter desktop isn’t there yet" https://news.ycombinator.com/item?id=34643291 https://news.ycombinator.com/item?id=34643291
  - xrayarx 4y ago
    Ah thank you very much
deleted 4y ago
[deleted]
porcoda 4y ago
> 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 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.
- hajile 4y ago
  > 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.
  - porcoda 4y ago
    You fixated on what I said was the secondary reason, and repeated in a rephrased way what I said was the primary reason - economics/cost. 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…
college_physics 4y ago
The browser is a seriously capable desktop app. Think e.g. about dynamic manipulation of SVG with d3 or 3D stuff with three.js or any of the other countless other goodies that are now available via the HTML/CSS/JS set. 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.
- ridiculous_fish 4y ago
  I think the web is culturally incapable of standardizing GUI elements. The nature of web development is to rebuild from scratch. Standard buttons and menus look so vanilla, let's instead style a div with an onClick handler, let's use a hover selector with a scroll animation. The set of UI interactions collapses to its ground state: click, tap, basic text entry. 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.
  - college_physics 4y ago
    I wouldnt defend web culture in this respect. Some people also argue that html is really about documents and not a good basis for a gui anyways. 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
    - tabtab 4y ago
      > I think technically it is possible to overload whatever is available [in existing web standards] and have very decent, easy to build [GUI] apps "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.
criley2 4y ago
I found out today that the PS5's user interface was written in ReactNative https://twitter.com/syke/status/1619413099861413889 https://twitter.com/syke/status/1619413099861413889
- zerr 4y ago
  They mention React Native Windows - is PS5 OS Windows based?
  - rbanffy 4y ago
    > is PS5 OS Windows based? Not at all, but the Dreamcast was ;-)
  - mnd999 4y ago
    Not sure about the PS5, but I’d imagine it’s FreeBSD like the PS4 and PS3.
  - deleted 4y ago
    [deleted]
  - deleted 4y ago
    [deleted]
drewg123 4y ago
then your desktop apps written this way are pretty much 100% cross-platform too 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..
- 0x457 4y ago
  Uhm, I was running VSCode on FreeBSD[1]. It took a while to make it happen, but it did happen. It still sucks though and porting those apps to FreeBSD isn't easy. However, I recognize that anyone, myself included, who runs FreeBSD on desktop/laptop is ready for such struggles. We're a tiny minority within a minority. 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. [1]: https://www.freshports.org/editors/vscode https://www.freshports.org/editors/vscode https://www.freshports.org/devel/electron19/ https://www.freshports.org/devel/electron19/
  - drewg123 4y ago
    Maybe it doesn't need the sandboxing syscalls? I've tried and failed to run slack and spotify. I've never tried VSCode because emacs is my IDE :)
    - 0x457 4y ago
      It's not running a Linux version of Chrome. FreeBSD version of just isn't sandboxed. In fact, I don't think there is a single modern browser on FreeBSD that is sandboxed, even though Capsicum been around for more than a decade.
westurner 4y ago
Because Web Standards are Portable and Accessible. 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)
- tabtab 4y ago
  > Because Web Standards are Portable and Accessible. 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.)
  - ozim 4y ago
    But there is no open GUI standard. Everything platform dependent is platform dependent and proprietary and owned by someone. 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.
    - tabtab 4y ago
      > But there is no open GUI standard. 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_or_defective_gui_idioms_in_htmldom/ https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...
malkia 4y ago
There few requirements (in my mind) for proven GUI toolkit (at least on Windows) apart from UX points: - Support multiple windows - Support docking, and dock-in-dock - Deal gracefully with Remote Desktop services 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.
- wizofaus 4y ago
  Vs Code has docking and floating windows, so presumably there are html/js-based libraries out there that provide support for them?
bluedino 4y ago
This article makes my head hurt. 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...?
- Genbox 4y ago
  I've built GUI applications for Windows in the primary frameworks Microsoft provides (WinForm, WPF, MAUI, UWP). It is not terrible, but also not great. I have high hopes for MAUI, but honestly, it seems very PoC-ish compared to everything else Microsoft have provided. 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.
mnd999 4y ago
That’s a whole lot of stupid packed into one article.
- tabtab 4y ago
  Perhaps it's poorly worded, but we do need better business/CRUD/GUI standards for HTTP-based apps: a state-ful GUI markup standard. Attempts to get DOM & JS to do desktop-friendly GUI's well keep failing after 25+ years of trying, with clunky results & long learning curves.
  - mnd999 4y ago
    That’s also been tried with mixed result with XAML, XUL and QtQuick with pretty mixed results.
    - tabtab 4y ago
      XAML is static, and XUL had verbose and awkward syntax & commands. I think QtQuick is also static. QML is perhaps a closer example (but not XML), but many Qt-related tools are proprietary or have dodgy licenses.
johnbernier 4y ago
What happened is naturally growth. There are more developers today then ever before, corresponding to the rise in the global population. As there are more and more developers, there is an associated rise in the number of people wanting to get into making desktop GUI applications. Most people don't know desktop frameworks like QT and Swing, so new people coming into the application development space are going to make applications in what they know: HTML/CSS/JavaScript. 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?
- intelVISA 4y ago
  Qt is lowkey quite great, I just wish they hadn't thrown away their market share...
  - loph 4y ago
    WSJT-X is a cross-platform QT app. It is multi-threaded, processes audio in close to real time, talks to devices over serial interfaces, interoperates with other apps over UDP and TCP connections. It starts fast, and has a pretty small memory footprint (around 80 MB) and was literally written (largely) by amateurs. OTOH, it is not a beautiful, lovely app. The UI does look like 1999. But it works fabulously. (ref https://sourceforge.net/projects/wsjt/ https://sourceforge.net/projects/wsjt/)
msie 4y ago
Sigh. We'll be stuck with JS, HTML and CSS until the end of time. Just the other day I had to debug a problem in a webapp where come JS code concatenated a string with a (null) value and "servernamenull" was the result. Ugh.
- eddsh1994 4y ago
  TypeScript!
intelVISA 4y ago
Market forces dictate that it's cheaper this way for better or worse. Won't change unless the end user stops accepting these bloated horrors.
hkpack 4y ago
As a former desktop developer, the reason is obvious to me. You have to be insane to deliberately choose a career as a specific platform desktop developer nowadays. 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
- auggierose 4y ago
  Enough said. Of course. Everybody with half a brain understands that. I switched from Swift to TypeScript because of that for over a year now. There are things about Swift I love, and things about TypeScript/JavaScript I don't, but I can invest into bending TypeScript/JavaScript to my needs, and I can use it everywhere. EVERYWHERE. Also, I freaking love VSCode. Took a while, at first I didn't see it, but after coding TypeScript with it for a year, and now having developed my first extension for VSCode, I must say, this software is a gem. And so much simpler and cleaner than bloated monsters like IntelliJ.
- labrador 4y ago
  > I'm looking at you Microsoft I'm tempted to question the intelligence of Microsoft managers when I look at their desktop GUI strategy over the last 20 years
- Fraterkes 4y ago
  Dumb question maybe, but cant you "just" use something like sdl2?
  - rzzzt 4y ago
    You can, but the nice widgets don't materialize out of thin air, nor will they gain the accessibility support that a browser or an operating system provides.
deleted 4y ago
[deleted]
lucidguppy 4y ago
If I ever have to create a UI for the desktop - and I'm making something on the more basic side - I'm looking at flutter. It covers too many platforms to not be considered as a solution. Target desktop, web, ios, android all in one codebase? Put a django-rest framework behind it and you can then just focus on the actual problem you're trying to solve. I'd be able to get it to market - find out what to improve after that. For anything more complex then you need to do your homework.
sidlls 4y ago
Because it’s trivial to slap together a garbage app using cheap developers writing sloppy, inefficient code than going the native route. See also: Wordpress/PHP vs the rest of the web.
deleted 4y ago
[deleted]
loph 4y ago
On my work computer: 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.
- wvenable 4y ago
  > Emacs startup time blows away VS code. 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?
- radley 4y ago
  Apps built 30 years ago use less RAM because they had less RAM available: 16MB (1993) vs 16GB (2023). Back then, PowerPoint & other apps were considered to be the bloated apps. Worth considering: how often do you actually use those old apps?
  - palata 4y ago
    Still Teams and Slack are roughly doing what IRC does. Just using infinitely more resources. 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.
- deleted 4y ago
  [deleted]
- selfmodruntime 4y ago
  Note that while electron is pretty bad in that regard, it’s just that way because the entire chromium runtime ships with it. A leaner alternative could exist
favorited 4y ago
> If I could wave a magic wand, I would create an open working group, with the influence of the W3C behind me 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.
CamperBob2 4y ago
Something that doesn't get brought up often enough is a general loss of confidence in Windows as a target platform for native binaries. It's no secret that certain factions within Microsoft would either lock down Win32 or kill it altogether if they thought they could get away with it, turning the rest of us into sharecroppers in their walled garden. 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.
neeeeeeal 4y ago
With all the talk of X11 and .NET and Swift, has anyone considered that an embedded browser might function as a better desktop experience? Suppose Linux/Windows/Mac expose a browser that renders pages from somewhere in their file system as the “desktop”. To customize your desktop, just change the HTML/CSS/JS - easy. For bonus points, strip out a bunch of the clunky code supporting rendering the existing UIs to lean out the Os footprint. Wouldn’t this be a bit better than what we are stuck with now?
gaze 4y ago
Up until this moment I absolutely hated electron apps. Now I realize I hate the entire app ecosystem. Here’s why — to make an app that really feels like a desktop app, you have to build the whole thing from scratch. You have to pick a date picker from NPM or write one yourself. That date picker could be pulled. It’s probably maintained by some guy as his side project. More than likely you’ll do it yourself or extract it from an existing app. Suppose I want a sash — there’s probably 10 on NPM but are any really good? Are they as good as the one built into vscode? The vscode folks just built one themselves for some reason, I guess. What about the UI toolkit? Do I use bulma or bootstrap or something? I could — but the path of least resistance with those yields you something that looks like hypertext. Big airy spacing, big buttons, and something that is crucially designed to scroll! You have to really know what you’re doing to lay something out in a way that resizes and scrolls in a way that feels like an app. Having a layout engine it turns out is very nice. JavaScript imo isn’t good. Neither is typescript, but they’re good enough. They’re fine. I don’t abhor them. It’s this absolutely fractured ecosystem where everyone just builds what’s the most fun for them or what their company demands, in a way that’s specialized to THEIR application, rather than there being some grand unified way to just make something that feels like an app. I miss Delphi where I drop a control on the canvas and it feels like that control as situated in a desktop app, rather than starting a new react app and getting a white window with times new Roman and beating it into something that will almost but never quite feel like a desktop app, and never can because I’m just one person without the resources of a company to make an entire bloody custom application specific UI kit!
- paxhax 4y ago
  > I miss Delphi where I drop a control on the canvas and it feels like that control as situated in a desktop app... 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.
garbagecoder 4y ago
I skimmed the article. Editing is 90% of writing. Anyway, the answer to the (rhetorical?) question in the headline is that there are millions of web developers out there and there is a perceived savings in not having to retrain them. So, that's why. 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.
tabtab 4y ago
I keep ranting we need a state-ful GUI markup standard so that we don't have to keep reinventing GUI idioms in HTML/CSS/JS, which are NOT MEANT for that job. React et. al. have long learning curves because of screwy edge-cases, glitches, and JS's lack of type-saftey. 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 Fuller descriptions: https://www.reddit.com/r/programming/comments/otixwo/comment/h6zi86w/ https://www.reddit.com/r/programming/comments/otixwo/comment...
mikewarot 4y ago
It must be terrible for modern programmers who can't pick their own tools. I built a trivial GUI app in about 2 minutes to show my child this morning in Lazarus[1], a GUI builder that runs on Windows. (It'll also build for Linux, et al. I've even run Lazarus on a Raspberry Pi Zero W) 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. [1] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/
- deleted 4y ago
  [deleted]
- tabtab 4y ago
  Reminds me of this regret-rant, which basically wishes they'd gone into Delphi/Lazarus: https://www.reddit.com/r/webdev/comments/r59nzr/i_regret_going_into_web_programming_should_have/ https://www.reddit.com/r/webdev/comments/r59nzr/i_regret_goi...
  - mikewarot 4y ago
    Oh my goodness, that pretty much hits every single thing that is wrong with trying to use a Web Browser to do a GUI interface!
raspo 4y ago
The fact that web technologies use open standards is a huge plus. 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..
- euroderf 4y ago
  I do believe you are practicing the I.T. version of defensive driving. That is a compliment.
- p_l 4y ago
  A lot of that is something that Apple is effectively responsible for breaking. 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 :/
karaterobot 4y ago
I think this is a good article with a reasonable complaint, that goes out of its way to not be an old man yelling at clouds, so I just want to call that out. 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.
ogoffart 4y ago
I'm trying to solve the native desktop GUI with Slint [1] 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. [1] https://slint-ui.com https://slint-ui.com
anothernewdude 4y ago
Installing and managing updates on the desktop sucks. It will always suck I think. There's no single ecosystem to target, and each will have it's own story. It's why Java almost took off in this space. 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.
- tabtab 4y ago
  Then create a GUI markup standard so it's optionally like a web app, but ditch bleepin' DOM and JS. Oracle Forms was a kind of GUI browser in which one could run gazillion Oracle apps up-to-date without installing anything except the one "browser" (client). Oracle Forms had (fixable) weak-points, but as a proof of concept of a "GUI browser" it did CRUD perfectly fine for small and niche apps. Ugly, sure, but ugly that worked! (Oracle screwed it up when they rewrote the client from C to Java. Should have left it in C.)
Rodeoclash 4y ago
Because it's so much easier. I have an open source desktop app to help esports coaches (https://vodon.gg/ 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.
- tabtab 4y ago
  MS changed focus from small and medium shops into "enterprise" and big-market. They want to be the New IBM (per 1970's and 80's). While MS's GUI engines got more powerful, the learning curve also grew. It wasn't a free lunch: UI featuritus hurt smaller shops. WinForms still has the easiest learning curve of their GUI products for rank-and-file CRUD, despite lacking some allegedly modern UI features.
penguin_booze 4y ago
Is there a need to package a new browser binary with your app? Why not do the equivalent of xdg-open to launch the web browser (a standard install on all desktops these days)? Or, if the back end were in Python: import webbrowser # initialize back end # ... webbrowser.open(...)
seba_dos1 4y ago
Because when you have a hammer everything looks like a nail, and a lot of people happen to own this particular type of hammer. That's it. The article seems rather misguided in several ways.
- Spivak 4y ago
  Yeah but you also only need to own one hammer this way and you have to own this particular hammer because there are no other options to target web. 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.
anfilt 4y ago
Mainly wanting to save time/costs of having to create a UI for each platform. Also sometimes just laziness. Although electron sucks it wastes so much memory.

141 points by airstrike 4y ago

Because it's the cheapest way for groups of people to do something that works enough most places. Unrelated, I sure am glad I can turn off CSS in my browser because that font was terrible on the eyes.

MonkeyClub 4y ago
Indeed a terrible font choice, while the writing could also do with a second pass. 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.
- rbanffy 4y ago
  Oh I remember how support for Unix and Motif was - every Unix just had to be different from all others. Looking at you, HP-UX, AIX...
- MayeulC 4y ago
  That Wayland remark is very weird.It probably comes from an echo chamber or someone who hasn't actually tried it/done some proper research. Or maybe they only use a DE that barely supports it? (which? XFCE?)
  - superkuh 4y ago
    I get the feeling that we're all just touching different ends of the elephant (https://en.wikipedia.org/wiki/Blind_men_and_an_elephant https://en.wikipedia.org/wiki/Blind_men_and_an_elephant). If you want to use applications that involve keyboard/mouse sharing, for example, the wayland stuff is very beta/experimental if it's there at all. It's not just DEs.
    - MayeulC 4y ago
      Thanks for the metaphor, I had forgotten about it. I'm of course biased myself, having started to use sway as my main "DE" in 2018. Sway is quite mature nowadays, though it still has a few bugs. > 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 Of course, this can be added to the configuration file to make the settings persistent. With this, a second cursor appears for the second mouse, with a different cursor theme, and a different focus, tied with the second keyboard. I can type into a terminal, and have another person next to me type a comment in the Firefox window next to it. 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).

tenebrisalietum 4y ago

Here's why, in rough chronological order: - 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.

jeroenhd 4y ago

It also helped that web developers can be hired for a lot cheaper than native application programmers. Fast, lightweight code is hard to write and therefore expensive. Much easier and cheaper to just add a slightly outdated copy of Chrome to your application and program the entire thing in Javascript.

Klonoar 4y ago
We repeat this one in every thread but I'm not entirely sure it holds true anymore. If anything, several C++ threads indicate those devs are tired of getting paid less.
- eddsh1994 4y ago
  Yeah… I earn literally 5x working on a web stack with some Python than I did 4 years ago writing C# windows apps. Anecdotal but I’m pretty sure it’s normal to see big increases when you move over.
- hajile 4y ago
  I can write as much of a project in a day using JS as a C++ dev could write in a week or more. My code will have fewer defects and more critically, will be 100% free of the worst kinds of defects that C++ enables. 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) That's a 5-7x increase in demand since React was first released in 2013 (despite all the framework wars of prior years, the number of dedicated frontend devs was relatively small). 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.

swatcoder 4y ago

It's really just an accident of history. 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.

rbanffy 4y ago
Interestingly enough, in the end, NetScape was right.
scotty79 4y ago
It's really incredible how bad are all of the native UI toolkits. So many of them. Zero progress, only handful of interesting ideas.

marstall 4y ago

Great writeup, thanks to the author for sharing his deep experience in such a readable way. My career has also spanned different eras of UI tech, from win16/32, through server-generated HTML, Objective C and Swift/UI on mobile, and now I'm a full-time react and react native neckbeard. 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.

bombolo 4y ago
Well if you include the "download all the js dependencies" step… there it goes any time benefit you might have gained.
- marstall 4y ago
  that's not part of Fast Refresh. Fast Refresh only compiles the lines you've changed - something like that.
  - bombolo 4y ago
    You know that c++ also doesn't need to recompile everything if you just change 1 file right?
    - marstall 4y ago
      there's a magic with fast refresh which is that the code doesn't need to be rebundled and redeployed after a change. this would correspond to the linking and execution phase in c++. makes for an amazing experience when you are doing interactive development, orders of magnitude better in terms of responsiveness to the code you're writing.

mxmlnkn 4y ago

I see the advantages of bundled websites masquerading as desktop application in regards to platform support. 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.

diegocg 4y ago

>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 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.

j1elo 4y ago

jjkaczor 4y ago

My biggest complaint about HTML/CSS/JavaScript apps on the desktop is that typically UI components written for the browser do not implement all of the keyboard commands for selecting/deselecting multiple individual items (or contigous sections) from lists/tables or trees - with or without checkboxes/ticks/toggles. 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.

wizofaus 4y ago
Even QT has that problem, particularly if using QtQuick/QML.
- tabtab 4y ago
  Is that a QT-specific problem? Does the Tk and MonoWinForms kits also have that flaw?
mvladic 4y ago
Yes, I agree. And it seems that the author of this blog post agrees with that also, because he wrote: "If I could wave a magic wand, I would create an open working group, with the influence of the W3C behind me, to create a mandatory web standard for browsers that defines both a subset (to simplify and create an appropriate desktop security model) and an extension of CSS/HTML that is specifically optimized for marking up and implementing desktop applications, and have that all built into modern browsers as standard."
- tabtab 4y ago
  Amen! Business CRUD & desktops have been ignored over sexier domains such as social media and e-commerce. But it's still important. Ignore the plumbing of the world, and you get a pool of shit on your floors. 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/h6zi86w/ https://www.reddit.com/r/programming/comments/otixwo/comment...

lasagna_coder 4y ago

Unless I missed something, the article neglects to point out that this is only a specific subset of desktop apps. Companies who build desktop GUI apps for products people are willing to pay for don't necessarily use any of the systems mentioned.

JCWasmx86 4y ago

> the desktop/UI sucks, its awful in almost every way, you are essentially targeting X11 which was developed in the 70’s and it shows. It works and it brings a couple of quirky features to the table which are quite nice, but, in essence, if you love Linux, just forget targeting GUI desktop stuff, you need a graphics screen, a browser (for a real UI) and a terminal window – that’s it… there is the Wayland stuff but its far too early, it’s also disjointed, barley supported and is grappling with compatibility with legacy stuff… 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.

dylan604 4y ago
>The only reason the web stack is used for desktop applications is because or is it that there are less bootcamps teaching OS native app UI development as there are JS front end library usage?
- deleted 4y ago
  [deleted]
- yen223 4y ago
  There's just straight up less educational material of any kind that teaches native desktop app development. I would love to see the equivalent of the MDN but for AppKit, but alas

pphysch 4y ago

I worked with a junior dev who was developing his own 2D/3D data visualization framework. He used XML and ended up reinventing HTML for the most part. 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).

MangoCoffee 4y ago

my legacy VB6 Winform app run faster than any html/css/javascript desktop app on Windows

adamredwoods 4y ago

>> there is the Wayland stuff but its far too early, it’s also disjointed, barley supported and is grappling with compatibility with legacy stuff… 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.

xrayarx 4y ago

I'd like to know how Dart and Flutter would compare to this. It was promised as a better way to write cross-platform UI Apps.

doodlesdev 4y ago
Recent discussion related to this: "Flutter desktop isn’t there yet" https://news.ycombinator.com/item?id=34643291 https://news.ycombinator.com/item?id=34643291
- xrayarx 4y ago
  Ah thank you very much

deleted 4y ago

[deleted]

porcoda 4y ago

> 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 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.

hajile 4y ago
> 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.
- porcoda 4y ago
  You fixated on what I said was the secondary reason, and repeated in a rephrased way what I said was the primary reason - economics/cost. 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…

college_physics 4y ago

The browser is a seriously capable desktop app. Think e.g. about dynamic manipulation of SVG with d3 or 3D stuff with three.js or any of the other countless other goodies that are now available via the HTML/CSS/JS set. 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.

ridiculous_fish 4y ago
I think the web is culturally incapable of standardizing GUI elements. The nature of web development is to rebuild from scratch. Standard buttons and menus look so vanilla, let's instead style a div with an onClick handler, let's use a hover selector with a scroll animation. The set of UI interactions collapses to its ground state: click, tap, basic text entry. 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.
- college_physics 4y ago
  I wouldnt defend web culture in this respect. Some people also argue that html is really about documents and not a good basis for a gui anyways. 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
  - tabtab 4y ago
    > I think technically it is possible to overload whatever is available [in existing web standards] and have very decent, easy to build [GUI] apps "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.

criley2 4y ago

I found out today that the PS5's user interface was written in ReactNative https://twitter.com/syke/status/1619413099861413889 https://twitter.com/syke/status/1619413099861413889

zerr 4y ago
They mention React Native Windows - is PS5 OS Windows based?
- rbanffy 4y ago
  > is PS5 OS Windows based? Not at all, but the Dreamcast was ;-)
- mnd999 4y ago
  Not sure about the PS5, but I’d imagine it’s FreeBSD like the PS4 and PS3.
- deleted 4y ago
  [deleted]
- deleted 4y ago
  [deleted]

drewg123 4y ago

then your desktop apps written this way are pretty much 100% cross-platform too 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..

0x457 4y ago
Uhm, I was running VSCode on FreeBSD[1]. It took a while to make it happen, but it did happen. It still sucks though and porting those apps to FreeBSD isn't easy. However, I recognize that anyone, myself included, who runs FreeBSD on desktop/laptop is ready for such struggles. We're a tiny minority within a minority. 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. [1]: https://www.freshports.org/editors/vscode https://www.freshports.org/editors/vscode https://www.freshports.org/devel/electron19/ https://www.freshports.org/devel/electron19/
- drewg123 4y ago
  Maybe it doesn't need the sandboxing syscalls? I've tried and failed to run slack and spotify. I've never tried VSCode because emacs is my IDE :)
  - 0x457 4y ago
    It's not running a Linux version of Chrome. FreeBSD version of just isn't sandboxed. In fact, I don't think there is a single modern browser on FreeBSD that is sandboxed, even though Capsicum been around for more than a decade.

westurner 4y ago

Because Web Standards are Portable and Accessible. 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)

tabtab 4y ago
> Because Web Standards are Portable and Accessible. 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.)
- ozim 4y ago
  But there is no open GUI standard. Everything platform dependent is platform dependent and proprietary and owned by someone. 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.
  - tabtab 4y ago
    > But there is no open GUI standard. 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_or_defective_gui_idioms_in_htmldom/ https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...

malkia 4y ago

There few requirements (in my mind) for proven GUI toolkit (at least on Windows) apart from UX points: - Support multiple windows - Support docking, and dock-in-dock - Deal gracefully with Remote Desktop services 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.

wizofaus 4y ago
Vs Code has docking and floating windows, so presumably there are html/js-based libraries out there that provide support for them?

bluedino 4y ago

This article makes my head hurt. 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...?

Genbox 4y ago
I've built GUI applications for Windows in the primary frameworks Microsoft provides (WinForm, WPF, MAUI, UWP). It is not terrible, but also not great. I have high hopes for MAUI, but honestly, it seems very PoC-ish compared to everything else Microsoft have provided. 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.

mnd999 4y ago

That’s a whole lot of stupid packed into one article.

tabtab 4y ago
Perhaps it's poorly worded, but we do need better business/CRUD/GUI standards for HTTP-based apps: a state-ful GUI markup standard. Attempts to get DOM & JS to do desktop-friendly GUI's well keep failing after 25+ years of trying, with clunky results & long learning curves.
- mnd999 4y ago
  That’s also been tried with mixed result with XAML, XUL and QtQuick with pretty mixed results.
  - tabtab 4y ago
    XAML is static, and XUL had verbose and awkward syntax & commands. I think QtQuick is also static. QML is perhaps a closer example (but not XML), but many Qt-related tools are proprietary or have dodgy licenses.

johnbernier 4y ago

What happened is naturally growth. There are more developers today then ever before, corresponding to the rise in the global population. As there are more and more developers, there is an associated rise in the number of people wanting to get into making desktop GUI applications. Most people don't know desktop frameworks like QT and Swing, so new people coming into the application development space are going to make applications in what they know: HTML/CSS/JavaScript. 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?

intelVISA 4y ago
Qt is lowkey quite great, I just wish they hadn't thrown away their market share...
- loph 4y ago
  WSJT-X is a cross-platform QT app. It is multi-threaded, processes audio in close to real time, talks to devices over serial interfaces, interoperates with other apps over UDP and TCP connections. It starts fast, and has a pretty small memory footprint (around 80 MB) and was literally written (largely) by amateurs. OTOH, it is not a beautiful, lovely app. The UI does look like 1999. But it works fabulously. (ref https://sourceforge.net/projects/wsjt/ https://sourceforge.net/projects/wsjt/)

msie 4y ago

Sigh. We'll be stuck with JS, HTML and CSS until the end of time. Just the other day I had to debug a problem in a webapp where come JS code concatenated a string with a (null) value and "servernamenull" was the result. Ugh.

eddsh1994 4y ago
TypeScript!

intelVISA 4y ago

Market forces dictate that it's cheaper this way for better or worse. Won't change unless the end user stops accepting these bloated horrors.

hkpack 4y ago

As a former desktop developer, the reason is obvious to me. You have to be insane to deliberately choose a career as a specific platform desktop developer nowadays. 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

auggierose 4y ago
Enough said. Of course. Everybody with half a brain understands that. I switched from Swift to TypeScript because of that for over a year now. There are things about Swift I love, and things about TypeScript/JavaScript I don't, but I can invest into bending TypeScript/JavaScript to my needs, and I can use it everywhere. EVERYWHERE. Also, I freaking love VSCode. Took a while, at first I didn't see it, but after coding TypeScript with it for a year, and now having developed my first extension for VSCode, I must say, this software is a gem. And so much simpler and cleaner than bloated monsters like IntelliJ.
labrador 4y ago
> I'm looking at you Microsoft I'm tempted to question the intelligence of Microsoft managers when I look at their desktop GUI strategy over the last 20 years
Fraterkes 4y ago
Dumb question maybe, but cant you "just" use something like sdl2?
- rzzzt 4y ago
  You can, but the nice widgets don't materialize out of thin air, nor will they gain the accessibility support that a browser or an operating system provides.

deleted 4y ago

[deleted]

lucidguppy 4y ago

If I ever have to create a UI for the desktop - and I'm making something on the more basic side - I'm looking at flutter. It covers too many platforms to not be considered as a solution. Target desktop, web, ios, android all in one codebase? Put a django-rest framework behind it and you can then just focus on the actual problem you're trying to solve. I'd be able to get it to market - find out what to improve after that. For anything more complex then you need to do your homework.

sidlls 4y ago

Because it’s trivial to slap together a garbage app using cheap developers writing sloppy, inefficient code than going the native route. See also: Wordpress/PHP vs the rest of the web.

deleted 4y ago

[deleted]

loph 4y ago

On my work computer: 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.

wvenable 4y ago
> Emacs startup time blows away VS code. 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?
radley 4y ago
Apps built 30 years ago use less RAM because they had less RAM available: 16MB (1993) vs 16GB (2023). Back then, PowerPoint & other apps were considered to be the bloated apps. Worth considering: how often do you actually use those old apps?
- palata 4y ago
  Still Teams and Slack are roughly doing what IRC does. Just using infinitely more resources. 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.
deleted 4y ago
[deleted]
selfmodruntime 4y ago
Note that while electron is pretty bad in that regard, it’s just that way because the entire chromium runtime ships with it. A leaner alternative could exist

favorited 4y ago

> If I could wave a magic wand, I would create an open working group, with the influence of the W3C behind me 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.

CamperBob2 4y ago

Something that doesn't get brought up often enough is a general loss of confidence in Windows as a target platform for native binaries. It's no secret that certain factions within Microsoft would either lock down Win32 or kill it altogether if they thought they could get away with it, turning the rest of us into sharecroppers in their walled garden. 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.

neeeeeeal 4y ago

With all the talk of X11 and .NET and Swift, has anyone considered that an embedded browser might function as a better desktop experience? Suppose Linux/Windows/Mac expose a browser that renders pages from somewhere in their file system as the “desktop”. To customize your desktop, just change the HTML/CSS/JS - easy. For bonus points, strip out a bunch of the clunky code supporting rendering the existing UIs to lean out the Os footprint. Wouldn’t this be a bit better than what we are stuck with now?

gaze 4y ago

Up until this moment I absolutely hated electron apps. Now I realize I hate the entire app ecosystem. Here’s why — to make an app that really feels like a desktop app, you have to build the whole thing from scratch. You have to pick a date picker from NPM or write one yourself. That date picker could be pulled. It’s probably maintained by some guy as his side project. More than likely you’ll do it yourself or extract it from an existing app. Suppose I want a sash — there’s probably 10 on NPM but are any really good? Are they as good as the one built into vscode? The vscode folks just built one themselves for some reason, I guess. What about the UI toolkit? Do I use bulma or bootstrap or something? I could — but the path of least resistance with those yields you something that looks like hypertext. Big airy spacing, big buttons, and something that is crucially designed to scroll! You have to really know what you’re doing to lay something out in a way that resizes and scrolls in a way that feels like an app. Having a layout engine it turns out is very nice. JavaScript imo isn’t good. Neither is typescript, but they’re good enough. They’re fine. I don’t abhor them. It’s this absolutely fractured ecosystem where everyone just builds what’s the most fun for them or what their company demands, in a way that’s specialized to THEIR application, rather than there being some grand unified way to just make something that feels like an app. I miss Delphi where I drop a control on the canvas and it feels like that control as situated in a desktop app, rather than starting a new react app and getting a white window with times new Roman and beating it into something that will almost but never quite feel like a desktop app, and never can because I’m just one person without the resources of a company to make an entire bloody custom application specific UI kit!

paxhax 4y ago
> I miss Delphi where I drop a control on the canvas and it feels like that control as situated in a desktop app... 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.

garbagecoder 4y ago

I skimmed the article. Editing is 90% of writing. Anyway, the answer to the (rhetorical?) question in the headline is that there are millions of web developers out there and there is a perceived savings in not having to retrain them. So, that's why. 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.

tabtab 4y ago

I keep ranting we need a state-ful GUI markup standard so that we don't have to keep reinventing GUI idioms in HTML/CSS/JS, which are NOT MEANT for that job. React et. al. have long learning curves because of screwy edge-cases, glitches, and JS's lack of type-saftey. 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 Fuller descriptions: https://www.reddit.com/r/programming/comments/otixwo/comment/h6zi86w/ https://www.reddit.com/r/programming/comments/otixwo/comment...

mikewarot 4y ago

It must be terrible for modern programmers who can't pick their own tools. I built a trivial GUI app in about 2 minutes to show my child this morning in Lazarus[1], a GUI builder that runs on Windows. (It'll also build for Linux, et al. I've even run Lazarus on a Raspberry Pi Zero W) 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. [1] https://www.lazarus-ide.org/ https://www.lazarus-ide.org/

deleted 4y ago
[deleted]
tabtab 4y ago
Reminds me of this regret-rant, which basically wishes they'd gone into Delphi/Lazarus: https://www.reddit.com/r/webdev/comments/r59nzr/i_regret_going_into_web_programming_should_have/ https://www.reddit.com/r/webdev/comments/r59nzr/i_regret_goi...
- mikewarot 4y ago
  Oh my goodness, that pretty much hits every single thing that is wrong with trying to use a Web Browser to do a GUI interface!

raspo 4y ago

The fact that web technologies use open standards is a huge plus. 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..

euroderf 4y ago
I do believe you are practicing the I.T. version of defensive driving. That is a compliment.
p_l 4y ago
A lot of that is something that Apple is effectively responsible for breaking. 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 :/

karaterobot 4y ago

I think this is a good article with a reasonable complaint, that goes out of its way to not be an old man yelling at clouds, so I just want to call that out. 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.

ogoffart 4y ago

I'm trying to solve the native desktop GUI with Slint [1] 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. [1] https://slint-ui.com https://slint-ui.com

anothernewdude 4y ago

Installing and managing updates on the desktop sucks. It will always suck I think. There's no single ecosystem to target, and each will have it's own story. It's why Java almost took off in this space. 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.

tabtab 4y ago
Then create a GUI markup standard so it's optionally like a web app, but ditch bleepin' DOM and JS. Oracle Forms was a kind of GUI browser in which one could run gazillion Oracle apps up-to-date without installing anything except the one "browser" (client). Oracle Forms had (fixable) weak-points, but as a proof of concept of a "GUI browser" it did CRUD perfectly fine for small and niche apps. Ugly, sure, but ugly that worked! (Oracle screwed it up when they rewrote the client from C to Java. Should have left it in C.)

Rodeoclash 4y ago

Because it's so much easier. I have an open source desktop app to help esports coaches (https://vodon.gg/ 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.

tabtab 4y ago
MS changed focus from small and medium shops into "enterprise" and big-market. They want to be the New IBM (per 1970's and 80's). While MS's GUI engines got more powerful, the learning curve also grew. It wasn't a free lunch: UI featuritus hurt smaller shops. WinForms still has the easiest learning curve of their GUI products for rank-and-file CRUD, despite lacking some allegedly modern UI features.

penguin_booze 4y ago

Is there a need to package a new browser binary with your app? Why not do the equivalent of xdg-open to launch the web browser (a standard install on all desktops these days)? Or, if the back end were in Python: import webbrowser # initialize back end # ... webbrowser.open(...)

seba_dos1 4y ago

Because when you have a hammer everything looks like a nail, and a lot of people happen to own this particular type of hammer. That's it. The article seems rather misguided in several ways.

Spivak 4y ago
Yeah but you also only need to own one hammer this way and you have to own this particular hammer because there are no other options to target web. 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.

anfilt 4y ago

Mainly wanting to save time/costs of having to create a UI for each platform. Also sometimes just laziness. Although electron sucks it wastes so much memory.