"The option isn't Electron vs native, it's Electron vs nothing"

Well, no. If it wasn't for , developers who want to make "apps" would actually go and learn how to make apps, you know.

Look at how native apps used to flourish on the desktop back when Electron (and the "modern" web) wasn't a thing. Look at the mobile app market, where Electron still isn't a thing.

@bugaevc I sort of agree with you, but what about Linux/FreeBSD? Most app devs ship a Win version, maybe an OSX one and then don't bother.

@SiberiaBreadFactory @bugaevc QT is pretty good, haven't heard many good things about the non-C++ bindings, also the subscription fees (to use it commercially) are pretty big so I'm no shock over why Electron is used

@bugaevc Electron isn't a thing on mobile because apps just running a WebView are a huge thing already.

@bugaevc we would never be able to afford desktop apps if it wasn't for electron or similar tech. You decide if it's for better or worse of course.

@bugaevc No, they wouldn't. Or maybe for one platform. Case in point, I know my way around GTK+ and QT. Yet, when it came to building a keyboard configurator GUI, I went with Electron, and to this day, that's still the only viable option for the app.

Both QT and GTK lack features I need (like interactive SVGs). I'd have to complement them with a cross-platform USB and serial library.

In this case, there's _tons_ of things that Electron and web-tech makes trivial, and would be PITA natively.

@bugaevc Electron _is_ terrible, indeed. But it does enable a lot of things that otherwise wouldn't be possible. Since toots are limited to 500 chars, I'll link you this blog post I wrote a year ago:

It's still as valid today as it was then.

@algernon I remember reading that post, yeah.

Apps made for a particular platform, written with love by passionate users of that platform is exactly what I wish for. Yes, that means separate apps for different platforms.

@bugaevc If I had to do that, because Electron didn't exist, then Chrysalis wouldn't exist either. A good few hundred users would be far less happy, and at least two companies building open source hardware with open source firmware would have a lot less customers.

Nobody would win anything at all.

@algernon @bugaevc this isn't necessarily true, another technology could have filled that niche, given the chance
but if we are going to keep using Electron forever, it will be at the expense of better solutions

@grainloom @bugaevc Thing is, my goal is to make something usable for my users _now_. If I don't use Electron, that's at the expense of my users, which in turn is an expense for my employer.

I will happily rewrite Chrysalis as soon as better technology comes around. I already rewrote it once (CLJS->JS, to be able to pull in more contributors), would do it again. I can't afford to add the functionality that I need to QT or GTK, but if someone else does, I'm happy to check if it fits my needs.

@bugaevc @algernon *rooting for #Guix pack cross compilation to become viable*

@grainloom @bugaevc That'd solve part of my problems (cross-compilation and distribution), but wouldn't do anything about both GTK and QT being insufficient for my needs. :(

@algernon @bugaevc well, someone should ideally port that functionality to GTK
relying on Electron for much longer is not a good prospect

For the record, what I need is interactive SVGs, because I'm not going to build the #Model01 layout from native widgets or the like. Both GTK and QT support interactive SVGs - in a webview, embedding webkit. That defeats the purpose of using native toolkits, if the core of the application will be in a webview anyway.


part of it is the cost/benefit analysis of the org that is paying the developers paychecks. if we didn't have electron to work with, my work wouldn't have an desktop app at all. honestly, the only reason we have electron and mobile apps is because we can reuse most of our application code (web-oriented javascript) across platforms by using things like nativescript and electron. personally, i hate both, but nativescript seems like the more efficient option.

either way, i don't get to make that call. i can argue for native (and i do), but at the end of the day any project has to fit into the available budget.
Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!