I can appreciate the concerns about maintaining multiple codebases and dealing with different delivery mechanisms and their rules, but modern iOS/macOS and Windows APIs (at least; I cannot speak for Android and Linux) seem just as easy, let you work in arguably better languages, evolve at a faster rate, and provide a better experience for users and their machines.
If it was so easy as you said, a lot of macOS apps would've been portable to Windows years ago given the market share.
I work for a cross-platform company, Windows is a much more difficult to develop for compared to macOS. You can write a Cocoa UI but what do you do on Windows when you need to support Windows 7 and above? Win32 controls are grossly outdated but the best accessible/consistent experience across multiple versions, UWP controls is limited to Windows 10 and best under MS Store, WPF has been neglected but so far it is the fastest way to develop a GUI. Microsoft has decided to split UWP out of Microsoft Store to bring it to everyone with UWP XAML Islands etc.
The reason Slack prefers Electron is because you can just write the same HTML/CSS front-end, deploy it, and all Slack apps can simply be refreshed to show the newest UI. You cannot do that with native apps at all. You could get around with a few webviews embedded in the native apps but might as well go full Electron.
I don’t want the same “GUI experience” across platforms, I want a GUI experience that is consistent with the platform I am running.
When I was a heavy Mac user, I hated iTunes on Windows because it felt like being on a Mac instead of Windows.
Do you get notifications for new email from gmail in the browser or meeting reminders?
And all project management software on the web sucks in its own special way. That’s not something to aspire to.
As far as gsuite, I only use Google Sheets for simple stuff but can GSuite really take the place of Office for complex workloads?
People learn applications, they don't learn systems -- apps have never been consistent enough for that.
I don’t know how it is now as I haven’t used Office in about 15 years.
A giant pool? Sorry, not really. JS skills are highly sought after, and finding good, experienced front end developers is very hard. Inexperienced developers are easy to find in any language, including your favorite one, whatever that is.
The "cheap, generic, interchangeable, fully replaceable" part just sounds bitter and vindictive, no need to respond to that.
I will concede that I am a bit bitter. It’s frustrating to watch the industry push ever harder to render specialized developers unnecessary.
As for quality, correctly accessing a devs level of competence can be very tricky, regardless of the required skill-set. With web devs, its even more tricky because an "over-qualified" desktop/app devs can do just as much damage in terms of technical debt as a poor quality web dev. A webdev is also a specialized developer, but due to the low entry barrier, many don't realize this.
Android dev is messy business, no question there, especially if you care enough about experience quality to test across a broad range of phones, OS versions, launchers, etc. It’s no wonder why the average Android dev team is 2x the size of the average iOS dev team. Not much you can do there but hope Google makes an effort to clean up (and it seems they are, albeit slowly).
Even with all these platform specialists accounted for, companies like Slack and Spotify aren’t hiring any more engineers than they would otherwise. The only difference is instead of hiring specialists, they’re hiring hordes of web front end.
Qt and other GUI frameworks (like Juce and FLTK) exist and are blisteringly fast. You don't have to package an entire web browser to make something cross platform.
I think the real issue is you can't bring all of your javascript/html/css libraries and tooling over.
I tried to use the browser version and it works well enough, but it broke my workflow and was distracting. The app has its own set of problems but at least it lets me work the way I want.
At least back in the 1980s and 1990s, cross-platform toolkits tried to look native everywhere, and that’s why.
Today, web apps are getting to the point that it can functionally be called 'apps' (whatever its definition is) and we're all seeing exactly the same UI from every platform and people seem to be just fine with that.
At least N times the work for N platforms.
Fewer developers, harder to recruit.
Cross-platform options like Qt are not modern/pretty enough and sometimes aren't that much thinner than Electron (depending on how well written the app is). Java/Swing/SWT is also quite bloated and looks terrible.
Development is much slower in languages like C++. Other languages are not cross-platform or have immature/buggy cross platform support. How's ObjC on Windows? C# on Mac? They exist, but nobody uses them.
I really think we're in a UI dark age. Native UI development has gone backwards compared to the ease of WYSIWYG GUI design 10-20 years ago. Go back and use the VB.NET GUI builder from 2004 and be in awe at the incredible productivity you could achieve. Platforms are more fragmented today too. There is even fragmentation on the same platform! Do I use Qt or GTK or (insert one of a dozen others) on Linux? WPF or Windows Forms on Windows? Cocoa or UIKit on Mac? Which one will MS or Apple kill tomorrow? ... or I could just say fXXk it and use Electron and be done with it.
This is 100% the fault of vendors. If you hate the bloat blame Microsoft, Apple, and Linux developers, not people who use Electron.
Edit: mobile UI development is less fragmented but it's not really that great either. You get no choice in dev tools and the code is absolutely unportable. I see higher-level web or web-ish views/libraries/frameworks taking over there too. It's already happening.
That almost nothing like this exists today is evidence that personal computing is dying, IMO. Companies don't want to empower users, they want them to be good little content consumers who do what the ads tell them. Developers (OSS developers included) don't respect them and assume they're too stupid to be permitted to use anything but the safety scissors. After all, if they were worthy of creating things they'd be C greybeards.
Thanks for mentioning that too. I loathe that mentality.
What people don't understand is that it hobbles the developers/geeks too. It causes us to build systems that waste our time futzing around with minutia. Bad UX and bad tooling is objectively bad in that it imposes needless cognitive load.
I learned this when I (almost cliche) switched from Linux desktop to Mac. I was amazed at how much more I got done when I didn't have to futz with drivers, config options, broken packages, etc. I now probably spend an hour a month messing with my computer compared to an hour a day.
What's wrong with C# on Mac? It's basically bindings to the native API via Xamarin.Mac.
You can build a cross-platform app with Xamarin on iOS / Android / Mac, UWP on Windows, and Gtk# on Linux. Using something like MvvmCross will allow to share most of the business logic between platforms.
Only if 100% of the code is the GUI.
Somewhere out there, there's a bitter COBOL developer still complaining about that "new fangled" c++
Ah, but you see, the modern developer does not care about the user experience. "Developer time is worth more than user time", "move fast and break things", etc. Users are the cattle we feed ads to and farm for salable data.
Where are you getting the idea that it is?
You could still use a web UI but without embedding Chrome and Node.
Except for the UI of course.
Writing Slack as a native app would be a massive pain. Especially due to all the web-like features it has, the fact that it's one codebase (mainly) for desktop and web.
They also have to support Windows, Linux, Mac and mobile. Not an easy task
If it was allowed I'd write the native macOS app for them. I'm sure it'd pay off selling it for $5 or $10 in the Mac App Store
Slack APIs aren't perfect, but they're good enough to allow 3rd party clients for terminals, Emacs[0], and the like. I've never dug into it because I avoid Slack in general, but I think the biggest hurdle right now is just user authentication.
That's a pain, and does limit your audience, but maybe you'd still find some buyers on HN.
Not sure why that's an issue.
Then there are many games, which by their nature require native performance, and of course have to present the same frontend. :)
Slack is literally just a fancy messaging app.
If most Electron apps were built as "games", i.e. providing their own UI via DirectX/OpenGL/Metal etc., I wonder if they might still be more efficient and less bloated than Electron apps are now.
To say a company that has 200 MILLION in revenue can't re-write their client in Qt is indefensible nonsense.
Windows and Linux are another beast, and Telegram’s solution is to use Qt for those platforms. Again, slack like capabilities with no webviews.
The difficulty of native dev is not as high as it’s often represented.
As an aside, apparently the next version of Telegram will be a complete rewrite done in Swift, and snappier as a result.
Its entirely possible that they cannot fund 5 native development teams, while building their core features to justify their valuation, and paying their sales and marketting team to actually generate revenue.
When you're working on your own project, some time sink that you didn't anticipate may be frustrating, but other than that, I definitely prefer it to coding something I already know how to do well.
That doesn't even seem correct - the BrowserWindow emits "hide" and "show" events [1] that Slack could use to do exactly what you're describing. I'm guessing they just don't want to implement it for some reason?
[1] https://electronjs.org/docs/api/browser-window#event-show
“Additionally, on macOS, the visibility state also tracks the window occlusion state. If the window is occluded (i.e. fully covered) by another window, the visibility state will be hidden. On other platforms, the visibility state will be hidden only when the window is minimized or explicitly hidden with win.hide().”
A good example is on mobile, where playing media on the web is a hassle because you never know what the background behaviour will be, whether it’ll carry on playing when you’re on another tab, or on another app, or with the screen off, or after five minutes. It seems to be a free for all now for the browsers, not much user control.
FluidApp[0] should work great and I bet there’s even a userscript already to handle desktop notifications.
(disclosure: I work on Chrome, but not on this)
Here's hoping something deeper was broken about them that now drastically changes top-level api behaviour!