[loudmax]

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.

[_gabe_]

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.

[LASR]

> ported a game

Most of the immediate pain with native to native ports is shift between UI frameworks. This always requires a huge investment to do correctly.

Not sure about your specific game, but if you're using an engine or handling widget rendering yourself, you won't feel this pain.

Simply changing your compiler target is easy. This is not what people are complaining about obviously.

[_gabe_]

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

Also, here's a big list of C++ GUI libraries if QT doesn't float your boat https://www.reddit.com/r/cpp/comments/babfl5/a_pretty_big_li...

[mkoubaa]

Porting a large-scale windows desktop app to linux takes engineer years.

[anthk]

Not with QT and C++.

[fian]

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.

[asoneth]

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.

[fian]

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.

[madeofpalk]

This feature itself has nothing to do with Electron. Electron has long had similar capabilities.

[svnpenn]

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