> I curse Slack every day I have to use their Electron app

I did that too for the last couple of years, but recently switched to this client: https://cancel.fm/ripcord/ Found the link in comments here on HN.

Works well so far. There’re couple minor UX issues, e.g. hard to react to messages with these modern hieroglyphs, also images are loaded in web browser, but I can live with them. The upsides (ability to setup font faces and sizes, resource usage, GUI latency) are far more important for me.

It's been a couple years since my workplace migrated away from slack, but I found weeslack [1], a plugin for weechat, to be sufficient.

The real reason is that the people making electron apps don't know how to make stuff in C++ and don't want to try. This might be a little more excusable before C++11 or if trying to avoid MFC and/or doing everything with win32, but modern C++ and GUI libraries like FLTK, Juce, Qt, etc. are a pretty great way to make something. A FLTK program can start at 100KB without dependencies.

The nice thing about this question for old-timers is that we can recycle the answers we already heard about using Java for cross-platform desktop development from 20+ years ago. Or the rationale for using a cross-platform toolkit with C++ from 30+ years ago.

You get substandard desktop applications that tend to frustrate people who are deeply immersed in any one ecosystem and expect native applications to have deep integration with each platform and comply with each platform’s design sensibilities.

But history shows that applications written against cross-platform toolkits have done just fine, as have applications that completely embraced “going native” on particular platforms.

I’m left with the thought that either strategy works if you go “all in,” the mistakes come from:

1. Going cross-platform but then doing ridiculous back-flips to try to make the app feel really, really native. Just take what the platform gives you, and accept that you’re giving people a web-like experience that happens to have some native affordances. Learn to live with the few complaints from retro-grouches.

Or, 2. Going native, but skimping on deep integration and fully embracing the look and feel of each platform. This is one of those “penny-wise, pound-foolish’ strategies: You ship faster, but you lose the big benefits of a cross-platform tool, and you don’t satisfy the users that appreciate what a native app offers in look, feel, and integration.

- you want to make sure that people respect the importance of your app by not running it along with everything else because it needs 10x the amount of resources a native app would

Yea, these are poor reasons imho. Relying on mommy Chrome and the hellscape of ECMA transpilers seems like the opposite of "cross platform" since you rely on a much more unstable foundation...

> other than some middle manager's desire to buy a new boat.

Good enough for me to consider tech. Means you can have acceptable result without spending more money.

Microsoft understands the value of being able to develop once and run everywhere. That's why both Java and the web almost upended their business.

It's not just a monetary/time/effort value to Microsoft or other developers either. It has value to me a user. I prefer applications that I can take with me anywhere I go and they'll be exactly the same on every type of desktop that I use them on.

The list of native desktop applications which can actually do this well for me is pretty short.

I'm not the OP but even the demos with the actual software are kinda stuttery. Like the one where you move the outlined spotify window, it's just not great. It's cool that you were able to make it simple to do, and not worry about it, and it's really impressive work, but I guess still feels off a little.

I don’t think that's entirely correct. While you can't ask the OS to tween the values, nothing prevents you from doing that, other than likely a reduced frame rate.

See this demo: http://stewd.io/pong/

It's still not 100% smooth, but it seems slightly better and demonstrates the ability to manually tween values. Similar performance in both Chrome and Safari.

On Windows, you can update these as often as you want to and the compositor will handle it fine - you can do a lot of cool animations/demos with it.

Is this a macOS specific issue, or is the JS API these guys are providing not able to catch up quickly enough?

It's curious to me, because I've seen compositors in both Linux and Windows handle it perfectly, but I admittedly haven't played with MacOS more than I'm forced to. I'm not very familiar with Quartz, I sorta assumed it would cover x11 functionality by default.