Live data from Hacker News

Electron considered harmful

drewdevault.com

201–210 of 256 posts

Re: Electron considered harmful

#201
post #185

Earlier quoted context omitted.

> Not for the HN purists. Is that necessarily a bad thing? I'll throw a great counter-example to you, Mattermost. It's a great open source project that uses Electron to build a client app for just about every single platform. Have you maintained a cross-platform app for Windows, OSX, and all the various flavor of linux? I have, it's hell. You have compiler differences, ui semantic differences and a litany of per-plat…

I also have, and would keep on using Java, Qt, wxWidgets than bothering with Electron, and I do have my share of web projects. Also for all the kids out there, Electron is the second coming of the MSHTML ActiveX engine. I didn't like it then, surely don't like it now.

>Electron is the second coming of the MSHTML ActiveX engine.

Really? I've always thought of it as the "blinders-on dev's XULRunner".

Re: Electron considered harmful

#202
post #29
post #7

Earlier quoted context omitted.

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.

You need to write it in Java? Which is the considered one of the worst language of the new generation.

I write Java, and I enjoy it.

Re: Electron considered harmful

#203

Earlier quoted context omitted.

> it does not look native and the devs don't care this is not valid. no need to limit our use case to devs, either. at worst, users don't care. at best, users prefer it. see Spotify, Discord, Skype, Sublime, Chrome, Steam... should i keep going? whenever i open an app that uses entirely native controls i just expect the author didn't want to invest any time into making their app look good.

Native with minimal custom styled accents can be good looking, polished, and professional, and it doesn't throw platform conventions and features out the window to boot. Native looks bad only when the developer doesn't care. I really don't think its such a great idea to reinvent the UI wheel, throwing the decades of research and refinement represented by native UI toolkits under the bus for the sake of branding and a…

> I really don't think its such a great idea to reinvent the UI wheel, throwing the decades of research and refinement represented by native UI toolkits under the bus for the sake of branding and aesthetics, unless you have a good reason

It's a romantic thought, but that boat sailed a long time ago. Users got used to the web that had a very inconsistent UI between websites and on the website over time; before bootstrap, you would be hardpressed to find 2 websites with the same button styling. The last time the web used unstyled OS-controls was the 90s (with that default grey background - blech).

Re: Electron considered harmful

#204
Honestly I think this is a symptom of the lack of really good GUI toolkits that let you define the UI in an easy-to-use and powerful language. There's Qt & QML, but that's about it, and to be honest QML is still pretty immature (try doing a custom control with text, or any kind of text editor in QML).

I really hope Rust or Go get great native GUI toolkits soon with nice declarative layout languages, but until that happens it is hard to get too angry at people using the wrong tool for the job because the right tools just aren't that great.

Re: Electron considered harmful

#205

Earlier quoted context omitted.

Dropbox itself takes 200Mb and its a simple python app. Google drive takes 300Mb. VSCode takes about 100Mb of ram with a project opened right now. Even my Emacs takes 250Mb and I literally live inside it. All of them have at least 2Gb of virtual memory being mapped to them. Yet I still have 9Gb of free ram. If you want to go against bloat, you might just as well uninstall every single software from your computer, inc…

Meanwhile my webserver that serves 8 websites (some static sites, some sophisticated web apps) sites at 80 MB used RAM. For everything. You can't make this up.

Your web server also doesn't run X11 or any window managers nor any gui apps.

Re: Electron considered harmful

#206
I'm a bit late to the party, but there are active React Native ports for both OSX and Windows.

Using them could be a good solution for targeting OSX and Windows and reusing logic from your web React app without having to deal with the overhead of Electron.

Re: Electron considered harmful

#207

Earlier quoted context omitted.

Hello again, qwerty'. Thanks for stepping up on the JS issue :-) There are many good languages out there, "when used as directed". Alas, out here in the flyover country of Sacramento, there is really only demand for 3 kinds of jobs: Java, C#.NET (falling off), and some Javascript, ignoring the long tail of one-of-a-kind shops. Given those choices, I'll take the Javascript. Java 8 lambdas are clumsy to use to assemble…

I couldn't agree more with this. Just the fact that functions are a first class type in JS already makes it better than many other languages. Another thing that JS is great at is the flexibility it provides: objects are very general and you can do almost anything with them. Anyone would care to explain why does JS take so much hate?

I can handle that.

First off, it gets a lot of (undeserved) hate from the Java-type people who think they know what OO is, but don't (because Java isn't OO, or so says Kay, and even if it is, there's a whole lot of rubbish mixed in. For that matter, I don't think JS qualifies either, by Kay's definition, but it's closer). These are the people who say things like, "How can it be OO if it doesn't have classes?" and, "where are my Refactoring tools?" or "Design Patterns!" and implement a bunch of java-esque "classes," and proceed to write IteratorStrategyFactoryManagerService (speaking of which, if you have any actual "classes" in JS with the word "Strategy" in the name, indicating they implement the GoF Strategy pattern, you should stop now. And feel bad about yourself. But that's another story).

With ES6, we have "classes," so these people can stop complaining, but it's still bad, because they're actually syntactic surgar over prototypes, so you still need to understand prototypes (to say nothing of how "this" works, a genunine mess in JS, but a necessary one), but it's no longer obvious that that's what's happening, so you might think that you don't.

The more significant complaints are about Javascript's famous weak typing (quick, what's []+""? What about ""+[]? And {}+[]?), ASI (which is why if you're returning an object/array, you can't put the openbrace or openbracket on the next line, and why semicolons only sometimes matter), and general quirkiness (the aforementioned this, and so on).

These are actually legitimate reasons to dislike JS, but in my experience, they're not as severe issues as they're made out to be. If you really can't take it, though, TS or Flow can help you.

Re: Electron considered harmful

#208

Earlier quoted context omitted.

Oh, good. The repo's current documentation indicates that it's deeply unstable, which is why I drew that conclusion.

It could probably stand to be updated. I'll do a pass on the readme now.

Thanks.

Re: Electron considered harmful

#209

Earlier quoted context omitted.

Yep, all the native toolkits failed, that's worthy of ranting about, but that is not what OP was doing.

The only native toolkit I've ever tried that I thought could compete with web is wpf. It was slow and cludgy but way ahead of its time, and the web is only now starting to approach its power.

Perhaps WPF was the Electron of its time, in terms of being a resource hog. I remember how one particular WPF-based application hastened the obsolescence of my brother's laptop some years ago. [1]

[1]: https://news.ycombinator.com/item?id=8444494

Re: Electron considered harmful

#210

The argument that the only advantage of Electron is cross platform portability is not true. Electron tries to duplicate what is already a main stream approach for deploying backend services. The only reliable and sane way do have a stable backend is to explicitly control and isolate all dependencies of the backend services by using virtual environments, Docker or virtual machines. Most people no longer think that it…

We've been doing self-contained app distributions, with all third-party dependencies bundled, for well over a decade, especially on Windows. But Electron does make it quite easy to package an app that way.
Post reply on HN