131–140 of 289 posts
Earlier quoted context omitted.
What other PC OSs are there that actually gets used? BSDs?
What other PC OSs are there that actually gets used? BSDs? Yes. Or Linux on non-x86 platforms.
Earlier quoted context omitted.
What other PC OSs are there that actually gets used? BSDs?
If you're bothering to include Linux in your list of Desktop platforms at all you may as well include the BSDs. Besides, Java works fine on BSDs. Why is it that when modern developers reinvent the wheel they so often manage to do it worse than the last time?
Portable GUI code is harder than portable code without a GUI.
Earlier quoted context omitted.
What other PC OSs are there that actually gets used? BSDs?
If you're bothering to include Linux in your list of Desktop platforms at all you may as well include the BSDs. Besides, Java works fine on BSDs. Why is it that when modern developers reinvent the wheel they so often manage to do it worse than the last time?
I guess, but the amount of people I know that use BSDs are even fewer than the amount that use Linux. Given that Linux is a hard enough sell to support for most apps I doubt that BSD support would be offered even if the framework supports it.
> Besides, Java works fine on BSDs. Why is it that when modern developers reinvent the wheel they so often manage to do it worse than the last time?
Speak for yourself, I would MUCH rather use an Electron app than a Java app. No need to make sure you have a proper JVM installed AND the apps don't look hideous like 99% of the Java apps I've ever used do.
I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE,…
If only each OS would ship an abstraction layer that guaranteed "at least modern browser X" that one could ship into. I want to ship an electron app but I want it to be 100kb and start in 0.1s and take almost no memory because the libs are shared. I don't want each little chat app or music player to gobble up half a gig of ram and take 3 seconds to start.
I'm bullish on Electron. I think it's just a couple of technical advancements away from being the ultimate desktop toolkit. For context, I love and have worked a ton with Qt, and I much prefer Qt UIs as a user. But Electron has brought true cross-platform development to all platforms (Including Linux!). If it weren't for Electron, I wouldn't even have a bunch of the apps I use today. Hell, I wouldn't have a good IDE,…
I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That’s 6 different binaries. I’m a solo founder. I know people like to rag on Electron, but without it, I wouldn’t be using something else, my apps just wouldn’t exist . It allows more people to try building more thing and that is a net positive. The speed problems and bloat issues of Electron is just shoddy programming on t…
I doubt this is entirely true. VSCode is frequently cited as an example of a good, performant Electron application. Its performance is generally acceptable (I use it as my primary text editor), but it absolutely chugs sometimes. Sublime is light-years ahead in terms of performance.
Earlier quoted context omitted.
If you have hungry mouths to feed, and whether or not they get fed depends on whether your app makes enough to justify the time and expense it takes to develop it, tell me you would have made a different decision. When development is your livelihood, you target the platforms that make money and only the platforms that make money. That pretty much means Windows and maybe Mac. Anything else is throwing money away.
tell me you would have made a different decision Sure. As a developer I would've used Qt (or Gtk) because even on the platforms that Electron provides, both provide a much higher quality user experience. You may not care about Linux on non-x86 or QNX or BSDs now, but you've ruled out ever caring enough to consider them. As a user I loathe Electron apps. They're slow, don't respect native mannerisms (e.g. VS Code for…
The fact that they eventually put it there tells me that it wasn't a fault of Electron in the first place, but fault of the designers/devs. Electron allows you to do all those nice things you love if you want to, so I don't see how it is Electron's and not designers'/devs' fault.
Every time Electron is mentioned I bust out the popcorn for the inevitable hate spewed towards it: "Javascript is a terrible language and no one should use it" "Separate instances of chrome for every app is dumb and consumes too much memory" "Qt is amazing and elegant and desktop-native. Why isn't everyone just using Qt?"
The problem with Qt I have is how incredibly expensive it is. Sure it's free if you want to build something open source, but you know some of us have to also make money to pay for being alive and it's hard to bootstrap an application if you have to pay $5,508 up front, per developer, and then again on an annual basis.
Are you really surviving on $5,500 annually?
Earlier quoted context omitted.
tell me you would have made a different decision Sure. As a developer I would've used Qt (or Gtk) because even on the platforms that Electron provides, both provide a much higher quality user experience. You may not care about Linux on non-x86 or QNX or BSDs now, but you've ruled out ever caring enough to consider them. As a user I loathe Electron apps. They're slow, don't respect native mannerisms (e.g. VS Code for…
>VS Code for ages didn't put titles on windows you minimized The fact that they eventually put it there tells me that it wasn't a fault of Electron in the first place, but fault of the designers/devs. Electron allows you to do all those nice things you love if you want to, so I don't see how it is Electron's and not designers'/devs' fault.
That's not something a native MacOS application dev would ever have to think about. If Electron requires extra work to make your app behave like a normal app that's absolutely a fault with Electron and means that Electron apps will often present poor the user with a experience.
Earlier quoted context omitted.
Is that really possible? I feel like it would only work with considerable engineering effort, and even then, probably only if the bundled Chrome instances were all exactly the same version.
This is literally how every gui library on planet earth works. Developers all build against a particular recent released version with all apps in the system expected to build against a small number of recent versions. If this is hard maybe its because the browser isn't a very good runtime to build against.
The expectation with Electron has always been that you bundle a copy of it with your app, so that you're always targeting exactly that version.
Earlier quoted context omitted.
I release two apps, across 3 OSes, in somewhat of a bimonthly cadence with a low defect rate. That’s 6 different binaries. I’m a solo founder. I know people like to rag on Electron, but without it, I wouldn’t be using something else, my apps just wouldn’t exist . It allows more people to try building more thing and that is a net positive. The speed problems and bloat issues of Electron is just shoddy programming on t…
>The speed problems and bloat issues of Electron is just shoddy programming on the maker’s part - Electron itself isn’t slow. I doubt this is entirely true. VSCode is frequently cited as an example of a good, performant Electron application. Its performance is generally acceptable (I use it as my primary text editor), but it absolutely chugs sometimes. Sublime is light-years ahead in terms of performance.
If you do it the way I do and use Electron as a skin / thin client to a compiled binary within the package, you remove that bottleneck. That way, you get both cross-OS capabilities, a familiar UI toolkit (JavaScript, I use Vue) and native binary speed and real multi-thread capabilities.