Hacker News Reader

Comment by deedubaya | Hacker News Reader

It's moot if you're an established company with deep pockets moving slowly. If you're starting from scratch with limited funds, it is definitely not a moot point. Would Slack have been as wildly successful if they had to implement native apps on all 3 platforms + iOS + Android + etc? I'd have a hard time believing so.

View on HN

You don't have to rebuild your app for all platforms. Desktop widget toolkits (Qt, GTK+, wxWidgets, ...) have bindings out to most languages. If you can run Python, you can run a desktop app on all platforms from a single codebase. Also, all major platforms have C and C++ runtimes; if you write portable C or C++, your codebase should run on any of the big three.

It's ridiculous to pretend that you have to write 3 distinct codebases to get a multiplatform application. Are there 3 Firefoxes? 3 Chromiums? 3 VLCs? Back in the day, applications like Banshee, which written in C#, were the rage and were distributed as core parts of GNOME.

Why is there this belief that we have to use JavaScript for multiplatform?

This is a tangent, but CMake is incredible for building cross-platform C++. I had a project a year or two ago that was developed as a .so for Linux, using CMake simply because I like it.

When I went to go build a Windows .dll, I rolled up my sleeves and expected to have a bad day. `cmake -G "Visual Studio 14 2015 Win64"` just went ahead and made a Visual Studio project from my source tree, and that project built and worked first try. I was using all C++14 stuff like std::lock, std::thread, etc, and there wasn't a single #ifdef required in the entire project. Amazing!

If you target the native OS widget set, you must have a separate code base for each platform's native widgets. Things like Swing and Qt don't cut it.

Macintosh users in particular are sensitive to things like the placement of and spacing between UI elements; if anything is "off" from the gold standard set forth by Apple, they will scream and bitch at you because perfect UI consistency is paramount with this crowd.

Web-based apps get something of a pass because they look and feel like Web-based apps (though not always; witness the grousing in this thread about the new Mac Spotify client). But things like Qt and the XUL-based Firefox, which try to look native but miss subtle details, fall into a sort of UI uncanny valley and are roundly rejected by the Mac community.

Overall, that sounds like an argument to exclude Mac support, if anything. But I would suggest that if it's so difficult to get the widgets exact, it's better to use a toolkit that can provide widget portability as well as precise implementations that pass through to native OS windowing.

>If you target the native OS widget set, you must have a separate code base for each platform's native widgets.

I want to clarify the subtle distinction here. If your code's concerns are separated, having to directly provide native widgets on some platforms means a different "codebase" for windowing and widgets only, not for everything. You'd still compile your normal code, and use an #ifdef or equivalent to include the appropriate windowing/widget library.

No, and that's fine. I don't think anyone is going to begrudge a small team the power of developing a 'desktop' application using cross-platform tools like that. It's great that the barrier to developing an application in that way is lowered.

But that doesn't excuse the abuse of that platform. Spotify used to have a pretty convincing native Mac app, which was spiked in favour of their current abomination, and I've watched performance plummet.

Using Electron as a cost-cutting measure is fine, but it's not good for user experience and it's OK to be honest about that.

Electron is great for user experience. Compare to something like JetBrains' IDEs which are written in Java and are much less native feeling than Atom (and just as resource-hungry).

But JetBrains's IDEs are a fair bit more powerful than Atom. The resource-hungriness is taken up by functionality, not UI.

To be fair though, Java and Swing which JetBrains IDEs use are also not exactly native.

Comparing Atom and IntelliJ is like comparing a BB gun to a 155mm howitzer.

Reply on news.ycombinator.com