With all this Electron and PWA focused development a cannot shake a feeling that we add an extra layer of a "runtime" on top of an operating system, that could be avoided. An extra layer which occupies RAM space and processor time which feels unnecessary but it is where we are headed. I wonder if the reason is simple, that we (myself included) have not provided anything better or the reason is that big corporations who control most of the market have pushed this technology forward. I hope we can learn from this and bring back some of this lost performance while keeping the productivity and security gains.
The bottom line is that Electron is portable. Unless native apps become as portable as Electron there will be a need for this layer.
The optimistic scenario is that WASM becomes the single target that everyone settles on, and that the performance penalty is minimized while the security sandbox is strengthened.
I see this all the time, and I honestly do not get it. As someone that has ported a game written in C++ for Windows to Linux... its not that hard. It took me 2 days, about 4 hours of work total, and most of the ports I had to make were because I'm an obstinate developer and didn't use the std lib functions that would handle the OS wrapping for me.
Now, I've never ported an app to mobile, and that may be entirely different. However, and this may be an unpopular opinion, I don't want developers building an app that's meant to be used on a mobile device and a desktop. They're 2 separate ways of using a computer and they should be treated as such.
When I think of desktop apps like Photoshop, Outlook, Word, Chrome, and Da Vinci Resolve, they all look and behave very differently than their mobile counterparts (if they have one). If you want to develop for mobile and desktop, then you need to invest the time to make it a good experience on both. I hate desktop apps that have been mobile-ified to support mobile-first design. Design a proper UI and UX for the platform you're targeting. Otherwise don't bother "supporting" a platform you never test, intend to test, or design specifically for.
> Not sure about your specific game, but if you're using an engine or handling widget rendering yourself, you won't feel this pain.
Out of all the apps that I listed, I don't believe any of them use native desktop widgets/controls/ui frameworks, except the Microsoft products. And even then, the Microsoft products are definitely using customized widgets which means they're writing a lot of custom rendering code anyways.
Edit: I'd also like to add that the original comment said that electron is portable, implying that portability is a tremendous feat. This is what I'm arguing against. Sure if you wrote your entire app in WPF, that's going to be next to impossible to port. But if you want to make a cross platform app, then it's not difficult to use a framework like QT to have a native cross platform app as opposed to embedding an entire browser runtime to get a portable app. This false dichotomy is what I don't get. It's not 2000 anymore, there's no reason portability has to be treated as some boogeyman that can only be solved by shipping extremely bloated software for a native cross platform app.
Java Swing apps were portable across Windows, Mac and Linux desktops waaayy back in 2004 and probably earlier. Write once run everywhere _was_ very much possible back then.
The biggest complaint was they didn't look native. From working on a Swing application back then, management and marketing would often ask if we could make it look more like other Windows applications, because looking like a native Windows XP application suggested it was modern and cutting edge.
As soon an iTunes landed on Windows, the requests for UI improvement changed from "make it look like Windows" to "make it look sexy" - which meant different things to different people.
Electron, to me, feels like an attempt to take a browser engine and turn it into a poor replacement for the JVM.
I worked on Java apps around that timeframe. Despite spending a lot of effort refining our widgets and using some animated transitions (ref the "Filthy Rich Clients" book) the applications generally felt more dated and cheaper-looking than native apps.
For enterprise apps with no strong competitors these minor aesthetic issues didn't impact revenue so those UIs remained in Java. But for everything else it was worth it (financially) to migrate to native.
I sometimes armchair quarterback and wonder whether Java would have been more successful if the Swing folks had focused more on design. It seemed like the most they ever did UI wise was attempt to catch up to platform native widgets so they were perpetually several years out of date and slightly inconsistent. Had they skated to where the puck was going to be rather than where it is perhaps Java applications would be the ones people pointed to when asking devs to "make it look sexy" instead of iTunes.
Yep, we did some deep customisation of a couple of key UI widgets and found it very time consuming. Changing the Look and Feel to Nimbus was a major improvement, but that came with semi-regular breakages when performing minor version JVM updates. I vaguely remember us overriding a couple of Nimbus defaults but finding that could have unexpected consequences elsewhere in the UI (ie LaFs are complex), so we didn't go down that path much.
While Swing styling support wasn't that great, I miss the flexibility of nesting layout managers for composing complex, resizable UIs.
When Java FX was first announced, I started learning it to see how we might use it for our applications. At the time it lacked a lot of widgets we needed, but it had much better support for styling. Sadly I didn't keep up with Java FX. While I have no direct need for it in my current job, I still get the itch to whip up the occasional desktop app, so I plan on getting back up to speed soon.
> The optimistic scenario is that WASM becomes the single target that everyone settles on
oh hell no. I reject this in the strongest possible terms. You don't need a web browser to create a program. This is pure laziness. I am a developer. Browser based app is fine for small stuff. But nothing as large as Visual Studio Code, should ever be created as a browser app. This is just an awful idea because it results in dogshit performance, an order of magnitude worse than native solutions.
I encountered hell the other day. I saw a corporate Citrix deployment that had 45 users running three electron apps on an underprovisioned server with the CPU, disk and memory rammed at 100% lagging out. That’s 135 separate browser stacks basically.
Microsoft are moving office to this stack as well. Ugh.
Of course I was there trying to work out why our simple old fashioned web app was running slowly in a chrome tab…
Our hospital system uses Citrix and the application patients have to sign in with runs on some web framework instead of being a native Windows app. Such a frustrating experience using the on-screen keyboard to enter your name to sign in.
It makes perfect sense for the user but developers will always argue for Electron so that they only have to test one browser engine.
I can’t even gets web devs to test on anything but Chrome and when something they code does break I have to listen to the Safari whine even though they all use iPhones so are part of the reason it’s relevant. Dread to think how an argument for supporting 3+ web engines for a “native” app would go.
A lot of developers are not fans of Electron. Generally, it's a quality vs quantity tradeoff. Are you willing to make a crappier thing if it means more people can use it?
For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user.
> For companies like Microsoft making something like Teams, I think it sucks. They have the resources to make native apps and when you have tens of millions of users, adding support for another platform would cost them pennies per user.
Back when I worked at Microsoft, 2014 or so, we had serious problems finding Win32 developers. We essentially had to train people up. While I am sure the Windows org had lots of them, put out a job req and even internally not very many people are going to have native Windows development on their resume.
Nearly had to draw straws to see who had to get "stuck" learning Windows stuff.
I imagine native MacOS developers are similarly rare as a % of the overall developer pool.
Android and iPhone developers, easy peasy.
Likewise, Web developers, not a problem.
The other thing is, Electron has tons of momentum behind it, which means more and more people jump onboard to learn it, which makes hiring easy. Tutorials and learning resources get made, making developing for it even easier.
IIRC we ended up dropping the native C++ Windows app and just used C# and one of the UI toolkits, I forget which one.
> Back when I worked at Microsoft, 2014 or so, we had serious problems finding Win32 developers. We essentially had to train people up.
Microsoft only has itself to blame for this. They charge an arm and a leg for their dev environment setting it up is a pain no matter what, the stuff you get “free” when you pay for the dev environment is not nearly enough to create anything worthwhile. So why should any CS department bother with win32 circa 2005. As much as Balmer liked to chant about the importance of developers he sure liked to milk them dry.
For decades MS had the best development environments, best training, and best documentation.
MS fucked it up with the wpf->silver light->winrt transitions.
Win32 is a horrible API but it was stable and there was a time Win32 developers were everywhere.
Visual Studio is still one of the best real IDEs out there. The tooling for modern languages is a sad joke compared to what we had in 2005. And modern documentation is so bad it is absurd. People don't realize how much $$$ MS used to spend on sample code (MSDN samples were large fleshed out sample products!) and on documentation teams.
Comparison point, last time I tried to use Google cloud, I had to use the way back machine to look at an old version of the docs because the embedded sample code had gotten broken during an update 2 years prior and no one ever fixed it.
You forgot another two major fuck ups, killing .NET Native and C++/CX, without a proper migration path to a GUI framewokr that is anyway WIP and will take a couple of years to even reach some kind of parity with WPF.
I still mostly use Microsoft technologies, but that was a big middle finger to everyone that was willing to go through all WinRT rewrites since Windows 8, advocating for the technology.
It may be more the myriad of technologies and the fact that they change them out almost as often as their underwear. Same problem we have with javascript frameworks.
What is it that we need 10 years experience in this week? Win32, OCX, DCOM, CORBA, OWL, ActiveX, WinForms, WPF, ASP, SliverLight, .Net, XNA (etc. etc.)?
Kind of amusing that so many people turned to web tech to escape that treadmill and then just totally recreated it in javascript.
When WinDev keeps pushing for stuff like COM, with tooling that already felt primitive when Visual C++ 6.0 was around, it is no wonder that they have such hard times.
Eventually even those of us that know Win32 quite well don't want to deal with it.
What seems even crazier is not even wanting to test against different builds of Chromium to help keep pace with Electron updates. At that point isn't one's code just too brittle?
> Dread to think how an argument for supporting 3+ web engines for a “native” app would go.
Well, on mobile, it's slightly different. If you use Capacitor, it uses the OS' native WebView, which is either Chrome (Android) or Safari (iOS). You gotta test for two web engines, but fortunately, they're relatively close.
I think a solution like this for desktop would make sense. Modern browser engines don't have that many differences and it would make the runtime a lot smaller (thin wrapper around the already installed browser engine).
Sure, it has its downsides, but mobile apps have been written like that forever (via PhoneGap before and now Capacitor) and have come a long way since.
I mean I wish I worked with people with that opinion but somehow the 60+ devs I've worked with over the past 5 years manage to code things that work in Chrome but with many parts broken in Safari and an attitude that it's Safari's fault.
I have little patience for this attitude because the period of time I worked as a dev I had to support IE5.5, IE6, IE7, Safari, Firefox and Chrome. But it is the prevailing attitude.
That won't meaningfully change performance at all. Browsers aren't slow because they have to make slow syscalls - they mostly don't. They are slow because web technologies themselves are slow, sometimes by design, sometimes because of security/abuse concerns, but often just because HTML & CSS are absolutely crap platform for interactive UIs, something they were never intended to be and retrofitting that doesn't result in a very efficiency stack.
> HTML & CSS are absolutely crap platform for interactive UIs
I mostly disagree. HTML is great for plain forms, that seamlessly work at different form-factors (from mobile to desktop) with very little work. Browsers are also good at graphical outputs.
Browsers can fall down when you need rich, complex, or custom inputs: because virtual keyboards are very different from real keyboards (iOS especially poor), and touch is very different from mouse, and game consoles are something else again!
But we go where the users are, which is usually a wide variety of devices which makes browser based deployment the default choice, so you work within the limitations of browsers.
I'm not sure I'd call that an "interactive UI" though as that's pretty much a static layout. Which yes HTML is fine at handling.
> Browsers are also good at graphical outputs.
They're okay graphical outputs, not good ones. The feature sets are good, but the performance is all over the place and pretty much always sub-par as they are very defensive against content. Meaning the difference between the fast path (so plain scrolling) and the "slow" path (nearly anything else) is absolutely massive. Even things that are all but free on native toolkits, like just animating a color, can tank browser performance.
> But we go where the users are
Of course, which is mobile apps ;)
No but the point is just browsers aren't slow because they are an OS inside an OS. The layering isn't the cause of really any problems other than the binary size of the browser itself.
I have seen this attitude on HN before, and it really confuses me.
You know what an OS is, right? You can't just say, "the browser window is the only window" and say that "is" the OS. At some point some native code is going to need to send bits back and forth between hardware. You will need to provide a filesystem, you will need to provide device drivers, you will need to provide a windowing system, etc etc.
By the time you get from NAND to usable browser, you will have build an OS. Sure, I guess you could throw in a JS runtime and insist all user level software is in node/HTML/CSS, but there is still an OS underneath all that! (And the OS isn't why it's slow anyway.) There is so, so much more to computers than running JS and rendering HTML and CSS.
better yet we should just outlaw personal computers and laptops, they are causing too much trouble. Better for everyone to just have iPads and iPhones, kill Android too.
I choose it for portability. I can ship to my users today, work on new features for all users, or I can spend 3-4-5-6 months dealing with differences in platforms, differences in tooling, build environments, deployment, etc....
I also it choose is because as a programmer it's far easier IMO to make a web tech app look good than a native app. CSS, Unicode text, emoji, images, video, canvas, webgl, it's all easy, portable, and batteries included, vs the various platform specific ways of providing those features.
I'm gradually starting to see X11/Xlib as a solution for cross platform desktop apps. It is the native GUI API for most UNIX operating systems. Ports exist for Windows(win11) and Mac which makes X11 technically portable to them as well.
Its not exactly an elegant solution I have to admit. But the licensing problems with QT make a lot of people nervous, GTK seems to be pretty polarizing, and for whatever reason WxWidgets and FLTK never really got much adoption/didn't progress very far.
I think wxWidgets was pretty big in the 2000's, with quite some programs using it. To name one example, the Code::Blocks IDE uses it.
FLTK has never seen adoption even to the level of wxWidgets I think, but to be honest it is also quite simply hideous. I have not found a proper looking theme for it either, since I was mildly interested in using it to add a simple GUI to a Rust tool.
I don't know why WxWidgets seems to be less popular now than it was back then. I remember it being somewhat popular. Now people hardly seem to know about it.
FLTK looks horrible next to most modern applications. But FLTK 2.0, which has been abandoned for 10 years, actually looks pretty modern and the API is actually pretty elegant. There was some kind of split in the community about FLTK 2.0 breaking backward compatibility and I guess the 1.0 people won in the end.
When you see decades of Windows version after Windows version, each billing itself as "the fastest Windows ever!" and each having higher minimum system requirements than its predecessor, two conclusions are inescapable:
1. The Redmond wizards have devised a method to make software run faster and all it requires is faster hardware.
2. Microsoft is in bed with hardware manufacturers.
The system requirements are something they put out on paper, parent isn't necessarily saying you need a better PC, just saying Microsoft themselves say that, which you can verify yourself.
Modern Windows PCs feel very noticeably snappier and more responsive than older ones. For all my complaints about Windows, that certainly isn't one. I've had to go back and work on old XP boxes, and that is not a pleasant experience.
Admittedly a good chunk of that is SSDs, and better hardware plays a role. But hardware was going to get better anyways regardless of Windows - at least they didn't use the better hardware to make the effects fancier/get sloppy and end up at square 1 like so much of other software.
