Hacker News Reader

Comment by VyseofArcadia | Hacker News Reader

I just want to say, I really miss for-real native desktop apps. As an old-school desktop app developer, everything about web dev feels awkward and unnatural to me, and I'm not too keen on the performance of the end result.

I appreciate that Photino at least is lighter in terms of install footprint and RAM use, but it is still as CPU hungry.

View on HN

Gtk4 does not really do Macos these days, Qt costs a leg when you go commercial, Wxwidgets might be the only one left but its community is still quite small. Others(C# based, Flutter based) are not that great either. So yes for cross platform commercial desktop GUIs, Electronjs really has no competitor.

Qt is 500 a year for small businesses, thats basically creative cloud pricing. Could we really solve the current state of desktop ui by just convincing devs to pay 40 dollars a month?

It's way more complex than that in fact, just looked at the license page again and gave up again.

I mean, if you make under 1mil a year and arent shipping physical products, just software, the licensing doesnt seem that complicated. Its pretty draconian of course, but it also doesnt seem prohibitively expensive was my point.

You can't build a "for-real native desktop app" without building half of a browser anyway. Can't use a font without FreeType or HarfBuzz, can't use a secure socket without OpenSSL. Can't afford to redraw the entire screen each frame, so you need a DOM of some kind to cache rendered boxes. The OS doesn't do anything it didn't do 20 years ago. Stack's a mess rn. imo

Thankfully, JavaFX does all of that (fonts, SSL, scene graph), but it's an unpopular option.

Yea, it's not native, but its more the native dev experience, and its actually quite portable.

No, I'm pretty sure OSes provide text rendering, SSL, and some analog of MVC.

You might be romanticizing the past. The old desktop world was full of custom toolkits --- remember how Word would style itself with Windows.next controls even when running downlevel? Remember Athena and Motif? Even today, we're split between Qt/Gtk. The mobile world is only slightly better. (Flutter.) We've never really had consistent appearance or behavior.

So, I just don't get the Electron hate. It's just another GUI toolkit. That it's based on web stuff inside is an implementation detail. Electron wasn't the first GUI toolkit and it won't be the last. IME, speed, memory use, and so on are all adequate.

My only real gripe is that it's cumbersome to theme the things and that you have to jump through a million hoops to inject your own JS as a user. .(GTK4 is also trending theme-hostile though, so this gripe isn't specific to Electron.)

It'd also be nice to use web technologies with a language other than JavaScript. I'm sure the WASM people will come up with adequate multi-language interop eventually.

It is true that as a GUI toolkit Electron as at least as complicated and quirky as everything that came before. I would argue more, but I'm willing to chalk that up to unfamiliarity. The thing about apps, though, is that the frontend isn't the only end, and in web dev your backend is also radically different and likely more complex.

Now it's a good thing that there is an architectural boundary between the frontend and backend. God knows not every desktop app is good about that. But the problem in web dev is that it is a complex architectural boundary that has its own footguns. Suddenly you have to do everything concurrently and securely. And on the backend, you can no longer just serialize to a file in a known directory. You have to learn securely connect to a database, be competent in a query language, and be able to manage all the infrastructure or sysadmin work that comes with databases. Oh, and you can no longer just distribute your application as a binary or with an installer. Now you have to be a master of all the sysadmin and process work that comes with deploys and cloud infrastructure. Debugging is no longer just gdb and depends on competent logging, you're likely to have to finagle calls to several REST APIs (all with slightly different auth) instead of just linking in a library, you have a hell of a lot more things to mock when you're testing...

The list of added complexity goes on and on and on, and all of this is on top of whatever complexity is inherent in the problem domain to begin with. Web dev adds just adds a ton of complexity.

I'm not sure what point you're making about backend complexity. We're talking about Electron as a toolkit for desktop apps. You can distribute it as a binary with an installer. That's a big part of the Electron value proposition.

Is using web APIs for things like networking and storage really more burdensome than using the corresponding POSIX APIs? It's the same stuff with a different spelling.

If we are comparing a desktop app to a web app, an apples to apples comparison has to include frontend and backend.

>Is using web APIs for things like networking and storage really more burdensome than using the corresponding POSIX APIs?

Yes. Absolutely it is. If nothing else, you don't have an auth step. Not to mention the infrastructural and management overhead of web APIs. I don't have to worry about the care and feeding of a customer's hard drive the same way I do my service's database. Or pay Amazon for the privilege of using something more convenient.

Electron apps don't have to be remotely hosted. It is entirely possible to write a completely local Electron app (and in fact, desirable!)

Reply on news.ycombinator.com