4 ms·

But why would I want the risk of your environment interacting funny with my app when I can have a known environment (electron I'm assuming) with known character

But why would I want the risk of your environment interacting funny with my app when I can have a known environment (electron I'm assuming) with known characteristics?

stakhanov 3y ago
Java Swing Desktop applications solved that problem 20 years ago. Windows 11 has compatibility that enables it to run applications written 15 years ago using, say, .NET framework 3.5 and Windows Forms. Those even work on Linux with Wine, providing a more stable ABI for programming Linux desktop apps than anything that's native to the Linux world. Wine for macOS might even bring these apps to macOS too in the future. -- So, despite the fact that those developers 15 years ago were testing on Windows XP and didn't know what my environment would look like in 2023, or that I might not even be running Windows, those applications just work. And the libraries of UI components available through these tech stacks make Compose for Desktop look like a laughable toy. It was only the generations of technology that came after that had persistent compatiblity problems and made you shoot for a constantly moving target. ...all we need is to get back something we've lost, which doesn't seem like such an impossible proposition at all, at least on the engineering front. Whether there's a business-will just because there's an engineering-way is a whole other question, though.
- palata 3y ago
  I never used Swing. Is it much better than Compose for Desktop?
  - stakhanov 3y ago
    There are a lot more controls, and with JavaFX (the next generation of Java UI technology that JetBrains' own IDEs are also based on), you have even more controls (and more powerful ones). Also, those controls are actually the kinds of controls that will get you the most out of using a desktop, rather than this mobile-first stuff, where the limitations of mobile platforms are the defining constraints and they needlessly constrain also what you can do with those toolkits on desktop.
mattgreenrocks 3y ago
Conversely, I’ve had to kill -9 some Electron-based apps lately because their myriad of helper processes were hung. It is substantially easier to debug these issues when you don’t have an entire browser engine gunking up your crash reports. Between that, the RAM requirements, and the overall sluggishness of Electron-based apps, I’m not impressed. They’ve had what, a decade now to get their house in order? It’s Java on the desktop all over again. Except now there’s a hegemony demanding that all dev be as cheap and shoddy as possible, so everyone just shrugs and moves along.
- palata 3y ago
  > It’s Java on the desktop all over again. What was the problem with Java on the desktop? Maybe I was a bit too young to remember. I just remember that Java apps looked "funny". But in my experience with the JetBrains apps in the last 8 years... JVM rocks. I hate ElectronJS though.
  - mattgreenrocks 3y ago
    Java desktop apps looked and felt off, because all the windowing toolkits had to reinvent the [windowing] universe from scratch. Cold boots of apps could be painful, as the JVM didn't optimize for that, and actually deploying the apps was not pleasant (fun times guessing how much RAM the app should take as part of the CLI args). Nowadays I have few issues with JVM apps on the desktop other than non-native UI, but that ship sailed a long time ago. And yes, JetBrains is a great example of how to do this well.
  - The_Colonel 3y ago
    Computers were much slower than today and even JVM was slower. Java wasn't open source. Plus the non-native UI made Java on desktop a meh experience.

But why would I want the risk of your environment interacting funny with my app when I can have a known environment (electron I'm assuming) with known characteristics?

stakhanov 3y ago

Java Swing Desktop applications solved that problem 20 years ago. Windows 11 has compatibility that enables it to run applications written 15 years ago using, say, .NET framework 3.5 and Windows Forms. Those even work on Linux with Wine, providing a more stable ABI for programming Linux desktop apps than anything that's native to the Linux world. Wine for macOS might even bring these apps to macOS too in the future. -- So, despite the fact that those developers 15 years ago were testing on Windows XP and didn't know what my environment would look like in 2023, or that I might not even be running Windows, those applications just work. And the libraries of UI components available through these tech stacks make Compose for Desktop look like a laughable toy. It was only the generations of technology that came after that had persistent compatiblity problems and made you shoot for a constantly moving target. ...all we need is to get back something we've lost, which doesn't seem like such an impossible proposition at all, at least on the engineering front. Whether there's a business-will just because there's an engineering-way is a whole other question, though.

palata 3y ago
I never used Swing. Is it much better than Compose for Desktop?
- stakhanov 3y ago
  There are a lot more controls, and with JavaFX (the next generation of Java UI technology that JetBrains' own IDEs are also based on), you have even more controls (and more powerful ones). Also, those controls are actually the kinds of controls that will get you the most out of using a desktop, rather than this mobile-first stuff, where the limitations of mobile platforms are the defining constraints and they needlessly constrain also what you can do with those toolkits on desktop.

mattgreenrocks 3y ago

Conversely, I’ve had to kill -9 some Electron-based apps lately because their myriad of helper processes were hung. It is substantially easier to debug these issues when you don’t have an entire browser engine gunking up your crash reports. Between that, the RAM requirements, and the overall sluggishness of Electron-based apps, I’m not impressed. They’ve had what, a decade now to get their house in order? It’s Java on the desktop all over again. Except now there’s a hegemony demanding that all dev be as cheap and shoddy as possible, so everyone just shrugs and moves along.

palata 3y ago
> It’s Java on the desktop all over again. What was the problem with Java on the desktop? Maybe I was a bit too young to remember. I just remember that Java apps looked "funny". But in my experience with the JetBrains apps in the last 8 years... JVM rocks. I hate ElectronJS though.
- mattgreenrocks 3y ago
  Java desktop apps looked and felt off, because all the windowing toolkits had to reinvent the [windowing] universe from scratch. Cold boots of apps could be painful, as the JVM didn't optimize for that, and actually deploying the apps was not pleasant (fun times guessing how much RAM the app should take as part of the CLI args). Nowadays I have few issues with JVM apps on the desktop other than non-native UI, but that ship sailed a long time ago. And yes, JetBrains is a great example of how to do this well.
- The_Colonel 3y ago
  Computers were much slower than today and even JVM was slower. Java wasn't open source. Plus the non-native UI made Java on desktop a meh experience.