Live data from Hacker News

Electron considered harmful

drewdevault.com

11–20 of 256 posts

Re: Electron considered harmful

#11
post #2

Electron, and to a great extent the cross platform fetish, is a perversion of DRY. They don't want to write the same code for two platforms. But its usually not the same code. Its the same logic implemented on two different platforms. Developers are so into code sharing, write once run everywhere, that they don't stop and ask if they should. In every case you are paying a price for abstraction, like running Electron…

Well, it's the same logic - so almost by definition it should be platform-independent. People are too lazy to introduce proper abstraction between what the application does and what it shows on screen, and suddenly porting is hell.

Either way, Electron sucks because it ships a whole goddamn browser to give you just portability; you have to still pile on a ton of JS and CSS hacks to get a decent-looking SPA UI out of it, which you'd get for free with any proper GUI runtime. All that waste because people want to write JavaScript (which I understand - I have my favourite language I'd love to write more too) and this was the most brute-force way to allow it.

Embed a system webview if you must, don't ship the goddamn browser!

Re: Electron considered harmful

#12
post #7
post #4

See, I totally agree with this essay. But what are the alternatives? Getting started with Qt/GTK isn't nearly as easy, for example. Maybe someone should write an intro to native GUI programming for JS devs.

What's wrong with JavaFX? I don't ever see it recommended, but a lot of us can do Java, and from my experience, it's way better than swing or awt.

I'd say nothing. If you're working on JVM, it's the best choice.

Re: Electron considered harmful

#13
post #2

Electron, and to a great extent the cross platform fetish, is a perversion of DRY. They don't want to write the same code for two platforms. But its usually not the same code. Its the same logic implemented on two different platforms. Developers are so into code sharing, write once run everywhere, that they don't stop and ask if they should. In every case you are paying a price for abstraction, like running Electron…

Cross platform is a perfectly fine goal. Why should a developer care need to write `open()` on one system and `OpenFile()` on another, when all they really mean is "open this file" with the exact same semantics? That said, I think electron is overkill from a technical standpoint, and ultimately is probably too harsh on hardware, but I've given up caring about that in the short term, because there are bigger problems with how our stupid computers are implemented.

Re: Electron considered harmful

#14
This article makes a good point, but what's the alternative? There is no good cross-platform GUI solution. Qt, GTK, JavaFx, wxWidgets, none of them are very good. Electron at least has the advantage of being fully cross-platform and not having to learn a whole new universe if you're already familiar with the web.

Re: Electron considered harmful

#15

If electron apps had a smarter way to manage chrome core as a dependency, the file size would be peanuts. Every apps is download on the same bundled core. Once this happens you won't have 100mb sizes. An intelligent installer could check core, if not installed download and install otherwise use what's on the system.

What if there was a centralized way of accessing HTML + CSS + JS applications? Instead of installing apps, you could just... "download" the necessary files to execute them? Perhaps even on demand from centralized.. "servers"?

Re: Electron considered harmful

#16
I think the points raised are solid, but at this point it seems like Electron is the best worst solution for cross platform UI. Having worked with Qt I never wanna do that again. There's also a much more significant portion of developers who can work on Electron based apps. Part of picking the best tool for the job involves considering maintainability and ease of development after all.

Re: Electron considered harmful

#18
I can understand the author's frustration with popular tools being very simple and somewhat overkill underneath, but I almost take it as a sense of frustration with himself.

Electron was built to ship products as soon as possible. Most of the time, no one gives a flying fuck if the tech stack is the "right" choice and as efficient as it can be. I'd be willing to bet my net worth your users don't care at all how you built it, just that it does what they want it to do.

In the end, for most companies, it's more about shipping product that sells than spending 5x more time writing it in C# because "you're an engineer so you should act like an engineer." That's not how the world works. And until you figure that out, you'll constantly be left behind by others who made compromises to capitalize on the market.

Early optimization is the root of all evil.

Re: Electron considered harmful

#19
I look at Electron apps the same way I used to look at Adobe Air apps. Any League of Legends player knows how bad the launcher is - 80% the fault of Adobe Air.

Sure it was easier to build, but your users suffer for it. Electron apps are pretty terrible performance wise, and you can immediately tell it's an Electron app.

- Atom

- Slack

- GitKraken

All of these apps have 'tells'.

Re: Electron considered harmful

#20
post #7
post #4

See, I totally agree with this essay. But what are the alternatives? Getting started with Qt/GTK isn't nearly as easy, for example. Maybe someone should write an intro to native GUI programming for JS devs.

What's wrong with JavaFX? I don't ever see it recommended, but a lot of us can do Java, and from my experience, it's way better than swing or awt.

JavaFX is fairly decent, and I agree that it's more pleasant than Swing or AWT. It's a fairly good choice for places where you can mandate or ensure that Java will be present on the client (e.g. internal line-of-business apps), but also in places where you don't need to have some ancient version to support some ancient application instead -- which cuts down on the pool a bit.

Unfortunately, most users know Java from years ago and never understood the difference between an applet or desktop application, and in the minds of some users it's still falsely stereotyped as slow or insecure.

In most shops I know, Java is being extensively used on the back-end, but almost no custom Java apps with GUIs. Most shops (and people) who could do Java on the frontend have gone to learn Mono or WinForms or WPF instead, which gives you results that feel nicer to most users.

Post reply on HN