6 ms·

Add more fuel to the "write once, run anywhere" dumpster fire. Let's peek in there - I see C, C++, Java, JavaScript, stored procedures, wxWidgets, RubyMotion, G

Add more fuel to the "write once, run anywhere" dumpster fire. Let's peek in there - I see C, C++, Java, JavaScript, stored procedures, wxWidgets, RubyMotion, GTK, QT, object oriented programming, functional programming, PhoneGap, React Native, Flutter, ... It is getting full in there. What's that about the definition of insanity? Doing the same thing over and over and expecting a different result? Sever side rendered HTML is the closest we've come, but that's not cool anymore.

timw4mail 7y ago
wxWidgets does actually get close to that mark. But regardless of the library/programming environment, there will always be platform-specific code you have to deal with.
- shaggyfrog 7y ago
  I don't think wxWidgets is a strong example for cross-platform success. While admittedly I haven't touched wxWidgets in years, back when I used it, I marvelled that it worked at all, as the source code was such an utter mess. For example, I found a bug where a class constructor would raise lifecycle change events before the constructor even finished, and the issue was brushed away on the mailing list. Argh.
rtpg 7y ago
Electron. It works pretty well if you're OK with the huge resource usage.
- JustSomeNobody 7y ago
  > It works pretty well if you're OK with the huge resource usage. Isn't that an oxymoron?
  - NateEag 7y ago
    No. If the user interface is usable and snappy, it is probably fine that it consumes twice as many resources as a similar native app would require for the same result. Example: Slack.app is a huge memory hog (though not as bad as it was before their rewrite), but it fits decently into OS X and does not lag on me. I have lots of RAM, so the extra consumption is fine. Sure, it annoys some programmers that it could be more efficient, but other than them, who cares? Those guys are probably using Emacs or a CLI program as their client anyway. (I must be a rare breed, since I do email, writing, and programming in Emacs, but not chat)
    - ad404b8a372f2b9 7y ago
      I think it's a bit of an unfair characterization. I don't use emac or CLI as my client, I enjoy a beautiful UI as much as the next guy but electron is a real bother to me. I switched from Sublime to VS Code and went from 20MB of RAM usage to 500. Add slack, add discord, you now have GBs of RAM getting eaten up just for the UIs. Most mid-range laptops still only have 8GB of RAM, add a browser to the mix and it's a constant battle to have everything running smoothly, the programs frequently crash due to memory issues. It's a real problem and not solely programmer efficiency-OCD.
      - ryacko 7y ago
        Electron is also using an old version of Chromium, and most electron apps are slow to update, making it more insecure than running the web app.
        itsananderson 7y ago
        While it's fair to assume most Electron apps are probably running old Electron (and thus Chromium), Electron itself has done a bunch of work to get caught up. Their 6.0 release was the first release to be shipped on the same day as the equivalent Chrome release https://electronjs.org/blog/electron-6-0 https://electronjs.org/blog/electron-6-0 their plan is to stay at most one version behind https://electronjs.org/blog/12-week-cadence https://electronjs.org/blog/12-week-cadence
- rkagerer 7y ago
  I really despise Electron apps. They always seem bloated and antagonistic toward the native user experience on my platform (eg. inferior keyboard support, hard to integrate with custom tooling like AutoHotkey, etc.). Have I just not used the right ones?
  - cc81 7y ago
    Visual Studio Code is probably one of the best received Electron applications. Tried it?
    - leadingthenet 7y ago
      I'm not him, but yes. It's certainly nowhere near a native Mac app, and apparently that's the absolute best Electron has to offer.
  - rtpg 7y ago
    I'm not a fan of them, but they do make desktop linux a bit more viable insofar as you will have desktop binaries for a lot more services than you otherwise would without electron
neetdeth 7y ago
You've listed a lot of technologies that people have used to create successful products with long life-cycles. In particular C, C++, Java, JavaScript, Qt, OOP... if anything is notably missing from your dumpster it's probably Adobe AIR. Nothing in this industry lasts forever. I'd certainly rather inherit a Java/Swing or Qt app from the early '00s than an MFC or Carbon dinosaur.
- seabrookmx 7y ago
  > MFC or Carbon dinosaur Oof. Yeah MFC was something else. I hated Swing the bit that I worked with it.. but I'm always blown away when I see the Jetbrains IDE's in the wild (I'm a VS Code guy but a few people I work with prefer the Jetbrains stuff). They managed to make a really slick, and pretty performant (if you ignore startup time) app with it. I guess you could say VS Code is a similar exception to the rule in Electron land.
mleonhard 7y ago
I'm using Flutter successfully. It has the potential to become a really great platform. Java is a good language, as long as you rarely use implementation inheritance. I would not recommend using React Native or C++ for any project.
- mk89 7y ago
  Could you tell why you would not recommend react native?
  - leppr 7y ago
    Pretty certain it's the unstability. In my experience, while Flutter may not be elegant because of Dart, it more or less just works. Developing in React Native is mostly just debugging the framework itself and browsing through React Native Github issues.
    - realusername 7y ago
      I had the opposite experience with Flutter personally, the problem is that Dart is a niche language with limited exposure (Flutter is basically the only big project in Dart realistically) and it's also a new project as well, it makes a bad combination.
      - mk89 7y ago
        Could you describe your experience more in details? What exactly didn't work out? I would like to know to understand whether it makes sense for me to invest my time in Flutter/Dart instead of a more mature solution like React Native.
        verttii 7y ago
        Actually, I don't think we should consider React Native more mature. It's been around for longer sure, but it's significantly more fragile, keeps releasing with regressions, has poor tooling around it except for as far as React is concerned etc. I don't know what you are trying to build on mobile but I'd definitely learn Flutter instead of RN, which I have. Others here have said you should just go full native instead, and they're probably right.
blub 7y ago
Dropbox was able to ship two mobile applications for 5-6 years using this strategy, so it's premature to dismiss it. Furthermore, it looks like their team changed a lot and they were unable to retain the C++ talent that implemented the original strategy, nor were they able to find interested developers. The mobile landscape has also changed enormously during those 5 years, even the official programming languages have changed.

timw4mail 7y ago

wxWidgets does actually get close to that mark. But regardless of the library/programming environment, there will always be platform-specific code you have to deal with.

shaggyfrog 7y ago
I don't think wxWidgets is a strong example for cross-platform success. While admittedly I haven't touched wxWidgets in years, back when I used it, I marvelled that it worked at all, as the source code was such an utter mess. For example, I found a bug where a class constructor would raise lifecycle change events before the constructor even finished, and the issue was brushed away on the mailing list. Argh.

rtpg 7y ago

Electron. It works pretty well if you're OK with the huge resource usage.

JustSomeNobody 7y ago
> It works pretty well if you're OK with the huge resource usage. Isn't that an oxymoron?
- NateEag 7y ago
  No. If the user interface is usable and snappy, it is probably fine that it consumes twice as many resources as a similar native app would require for the same result. Example: Slack.app is a huge memory hog (though not as bad as it was before their rewrite), but it fits decently into OS X and does not lag on me. I have lots of RAM, so the extra consumption is fine. Sure, it annoys some programmers that it could be more efficient, but other than them, who cares? Those guys are probably using Emacs or a CLI program as their client anyway. (I must be a rare breed, since I do email, writing, and programming in Emacs, but not chat)
  - ad404b8a372f2b9 7y ago
    I think it's a bit of an unfair characterization. I don't use emac or CLI as my client, I enjoy a beautiful UI as much as the next guy but electron is a real bother to me. I switched from Sublime to VS Code and went from 20MB of RAM usage to 500. Add slack, add discord, you now have GBs of RAM getting eaten up just for the UIs. Most mid-range laptops still only have 8GB of RAM, add a browser to the mix and it's a constant battle to have everything running smoothly, the programs frequently crash due to memory issues. It's a real problem and not solely programmer efficiency-OCD.
    - ryacko 7y ago
      Electron is also using an old version of Chromium, and most electron apps are slow to update, making it more insecure than running the web app.
      - itsananderson 7y ago
        While it's fair to assume most Electron apps are probably running old Electron (and thus Chromium), Electron itself has done a bunch of work to get caught up. Their 6.0 release was the first release to be shipped on the same day as the equivalent Chrome release https://electronjs.org/blog/electron-6-0 https://electronjs.org/blog/electron-6-0 their plan is to stay at most one version behind https://electronjs.org/blog/12-week-cadence https://electronjs.org/blog/12-week-cadence
rkagerer 7y ago
I really despise Electron apps. They always seem bloated and antagonistic toward the native user experience on my platform (eg. inferior keyboard support, hard to integrate with custom tooling like AutoHotkey, etc.). Have I just not used the right ones?
- cc81 7y ago
  Visual Studio Code is probably one of the best received Electron applications. Tried it?
  - leadingthenet 7y ago
    I'm not him, but yes. It's certainly nowhere near a native Mac app, and apparently that's the absolute best Electron has to offer.
- rtpg 7y ago
  I'm not a fan of them, but they do make desktop linux a bit more viable insofar as you will have desktop binaries for a lot more services than you otherwise would without electron

neetdeth 7y ago

You've listed a lot of technologies that people have used to create successful products with long life-cycles. In particular C, C++, Java, JavaScript, Qt, OOP... if anything is notably missing from your dumpster it's probably Adobe AIR. Nothing in this industry lasts forever. I'd certainly rather inherit a Java/Swing or Qt app from the early '00s than an MFC or Carbon dinosaur.

seabrookmx 7y ago
> MFC or Carbon dinosaur Oof. Yeah MFC was something else. I hated Swing the bit that I worked with it.. but I'm always blown away when I see the Jetbrains IDE's in the wild (I'm a VS Code guy but a few people I work with prefer the Jetbrains stuff). They managed to make a really slick, and pretty performant (if you ignore startup time) app with it. I guess you could say VS Code is a similar exception to the rule in Electron land.

mleonhard 7y ago

I'm using Flutter successfully. It has the potential to become a really great platform. Java is a good language, as long as you rarely use implementation inheritance. I would not recommend using React Native or C++ for any project.

mk89 7y ago
Could you tell why you would not recommend react native?
- leppr 7y ago
  Pretty certain it's the unstability. In my experience, while Flutter may not be elegant because of Dart, it more or less just works. Developing in React Native is mostly just debugging the framework itself and browsing through React Native Github issues.
  - realusername 7y ago
    I had the opposite experience with Flutter personally, the problem is that Dart is a niche language with limited exposure (Flutter is basically the only big project in Dart realistically) and it's also a new project as well, it makes a bad combination.
    - mk89 7y ago
      Could you describe your experience more in details? What exactly didn't work out? I would like to know to understand whether it makes sense for me to invest my time in Flutter/Dart instead of a more mature solution like React Native.
      - verttii 7y ago
        Actually, I don't think we should consider React Native more mature. It's been around for longer sure, but it's significantly more fragile, keeps releasing with regressions, has poor tooling around it except for as far as React is concerned etc. I don't know what you are trying to build on mobile but I'd definitely learn Flutter instead of RN, which I have. Others here have said you should just go full native instead, and they're probably right.

blub 7y ago

Dropbox was able to ship two mobile applications for 5-6 years using this strategy, so it's premature to dismiss it. Furthermore, it looks like their team changed a lot and they were unable to retain the C++ talent that implemented the original strategy, nor were they able to find interested developers. The mobile landscape has also changed enormously during those 5 years, even the official programming languages have changed.