Hacker News Reader

Comment by bluedino | Hacker News Reader

It's kind of silly compare a bare bones get/post to an entire app. This reminds me of my attempts to write an IRC client in an evening.

Creating a native Windows app to mimic the Electron Slack client would not be a trivial task.

View on HN

His point is that this bare bones get/post app in Electron will be much, much "larger".

And that is why it would foolish for them to post a barebones slack client in electron. But they don't publish that. They have published a full featured client that is cross platform. I am not a fan of electron and would very much prefer a desktop app. But we are finally seeing emergence of desktop applications from major players for Linux because of electron. It's not ideal but so wasn't the previous solution.

Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution

And just because it's electron doesn't mean it's inherently Cross-Platform look at discord for example It took too long for a initial desktop client to be released and then it ha issues with things like screen sharing not working as expected

>Existing frameworks like Qt or GTK could also be used for a Cross-Platform solution

They could but finding engineers with that kind of experience would be harder and cost a lot more. Far easier to retrain web frontend engineers.

It isn't like Qt is some bizarre arcane wizardry. You give a web developer a few days and they can productively be contributing to a Qt app.

Yeah but then the dev has to investigate how to solve certain patterns in Qt's ways which they already know how to solve in the web frameworks, and just like with natural languages, sometimes there are no straightforward ports for concepts, and it requires a ton of extra work that you couldn't foresee until getting halfway through the whole project. Adopting new tech is not without serious costs and risks. Also, no GUI framework I've ever seen has figured out a decent composability solution nearly as well done as the DOM, for better or worse. Not to mention the gigantic web ecosystem that just works in Electron.

Sorry, but if the way forward really is that every desktop application of the future has to ship with a full copy of Chrome, come with all the bloat and baggage of the web platform and continue its questionable UI conventions - all just because companies are too cheap to offer some training - then I really don't see how that is a desirable future.

Electron is bad enough from a user perspective, but it's downright horrible to see how it's instilled a rather defeatist approach in front-end developers.

"But I already know Javascript, it's too hard to figure out something else"

> But we are finally seeing emergence of desktop applications from major players for Linux because of electron.

In my experience, Electron applications seldomly follow the UI conventions of the host OS or offer much in terms of integration.

If the desktop app is really just the web site in a locked-down browser, then what benefits does this offer to just the normal web page?

I like the conceptual separation. I like alt-tabbing to "Slack" not "Chrome". It also doesn't have any of the header bar so the electron app has more UX control, including access to OS level window menu options. Also it can do things that you can't do inside the browser. E.g., I've seen electron apps that come with other background processes. I also think it performs better in terms of versioning/caching resources. So an electron app could be just a web-site, but they often are much more.

That's true but some of that could already be implemented in browsers itself. E.g. web page could request to be in a separate window with different icon and ask for OS-wide api permissions. Now we have to run several fully-featured browser (Elecron) instances, not sharing system libraries, under different versions. This reminds me "write once, run everywhere" Java with bundled binary JREs because of incompatibilities between vendors... But there is some progress - for example IBKR TWS client can't play sounds as it was linked with an old libavformat.so which I no longer have in the system. Browsers have most of libs statically linked.

Web pages are constrained by the functionality made available to them by the browser - which is (purposely) very limited. Electron apps run on a native JavaScript interpreter (NodeJS) and have full access to the OS.

As far as UI inconsitencies go, most libraries I have used for native apps (Qt, Swing, Tk, etc) also do not feature UI elements that are consistent with the OS. Many developers simply can't afford to support multiple UIs just because they subjectively look a bit better.

> most libraries I have used for native apps (Qt, Swing, Tk, etc) also do not feature UI elements that are consistent with the OS

Huh? Okay, maybe Swing doesn't support native-looking widgets (I have less experience with it), but I can personally attest that Qt and Tk (or more precisely Ttk) apps nowadays use a platform-native look-and-feel on Windows, macOS, and Linux alike, by default (i.e. with zero effort on the part of the app developer). It might not be absolutely pixel perfect, but it's way closer than an Electron app.

Most likely, the real solution here is to make a very highly performance tuned Electron for Wayland, and make it possible for multiple Electron apps to share at least some part of the footprint of that runtime.

> But we are finally seeing emergence of desktop applications from major players for Linux because of electron

It's not like Maya, Steam, Chrome, Firefox, Skype, Adobe Reader, Houdini, DaVinci, Nuke, TeamViewer, Blender... haven't been working on Linux for ages (or more recently Bitwig, Reaper...). And conversely it's not like every Electron app has a linux build.

Fixed costs vs variable costs. That fixed cost of Electron does come with some sizable benefits, so if you don't take advantage of them ofc Electron will just be bloat.

I think you could get pretty far without Electron. While a closer Slack experience would require some HTML rendering (VS languages have had an embeddable web view for a long time), alot of the formatting could be native (probably have to do some parsing) as could things like file uploads, image display, etc.

Reply on news.ycombinator.com