Sometimes I feel teams choose Electron/webapps because nobody knows how to design a great Windows-native application.
If Windows truly had a great UI+UX equal to macOS, the investment of native apps would be much more worth. Now creating a web app for windows is almost the de facto choice because there’s nothing better!
I think Electron won out because Microsoft kept pulling the rug out from under Windows developers as they went from Win32, to Windows.Forms, to WPF, to UWP, to WinUI 3. Why take the risk on the most modern Windows framework when you could just go Electron, have a broader pool of developers, and get Mac & Linux support as well?
This. We (at Remotion) are currently evaluating what platform to build for, given our start with macOS native / Cocoa. But for Windows, what is Windows Native?
Seeming like more of a collection of half-baked ideas than robust frameworks that we'd want to bet a bunch of dev time on.
As you both mention, we might end up with a cocoa macOS app and an Electron app for Windows & Linux.
I'm not a frequent Linux user so that comment crept in there—we haven't evaluated as deeply. Any suggestions for how to best build Remotion (lightweight video chat + dock for your team) onto Linux?
I'm not a fan of Qt from my time at Dropbox (we used it for our desktop client preferences for some time), but will need to check out GTK4 and Compose. Thanks!
I used to be a big Qt fan but I have started favoring Gtk. Glade is better than any Qt designer. And being C based you tend to get better Gtk bindings in other languages. Who wants to develop in C++ these days unless they are doing systems programming?
My strategy would be Cocoa for MacOS/iOS and Gtk for Linux/Windows.
I don't really dev with Qt, but I thought a lot of folks were using QML and sometimes QtQuick these days. Seems to make it possible to hide a lot of the C++ :)
Although of course, it does mean you probably have to touch C++ sometimes.
I'd like to point out that, while that's a good reason why Electron might have won in terms of developer mindshare, that's not necessarily the reason why it won on in terms of marketshare.
I personally believe that the cause of the latter is a combination of (1) cost-saving through fewer platforms to support (2) cost-saving through a larger developer pool and (3) better branding support, but I've never worked in the business myself.
I remember having to import obscure Win32 libraries because the latest platforms were never complete. Like the fontpicker would drop you from WPF to Win32 because MS couldn't be bothered to update it.
Or just bite the bullet and use win32/COM, because its basically the API under all these newer APIs anyway, and in the cases its not there is a compatibility shim.
Of course this doesn't stop MS from simply removing functionality, like they have been doing for the past 10 years. Explorer has a fraction of the API surface it had in the past, as do large parts of the OS. Like for example the color APIs which used to describe every little part of the UI so it could be tweaked are now basically gone.
Maybe that's the contributing factor, but I really think it's more of an economic decision.
There are far more JavaScript developers out there, so it's easier to hire people to work on an Electron app and have crossover between other teams working on web-based projects. Write-once-runs-anywhere is also a part of it. JavaScript is also extremely forgiving and has possibly the easiest debugging experience of any language I'm aware of.
This isn't to say that JavaScript developers don't often do things that completely subvert the advantages of writing web-based apps, but those advantages are nevertheless on the table regardless. Writing a truly native application will always be more challenging than writing a web app (or even something like a Python-based app) and will always require some amount of specialization no matter what anyone says (as has been observed with React Native and I'm guessing that will inevitably happen with Flutter).
UI is also one of the hardest things to do right when writing cross-platform applications. Business logic is usually quite portable, but UI introduces geometry and fundamental incompatibilities between widget toolkits. The web, with some exceptions, ignores native widgets, thus the problem of writing UI code mostly goes away because there's only one toolkit to work with.
“Extremely forgiving” is what I think is worst with JavaScript and makes debugging harder. Stuff does not blow up when it should. Good debugging requires “fail fast” IMHO, not JavaScript style “keep going until it is not humanely possible to continue with broken state”
Anything that is easy can as easily have pitfalls.
> Stuff does not blow up when it should. Good debugging requires “fail fast” IMHO, not JavaScript style “keep going until it is not humanely possible to continue with broken state”
It depends on what you value. JavaScript and the rest of web technology is good at getting something on-screen and working, more or less. Many businesses, for better or worse, don't care about software architecture and developer happiness. They want something working, and ASAP, and more features to be rolled out for all platforms. Web technology, for all its faults, is going to win every time. Even better when code is written in such a way that debugging your JavaScript doesn't end up being so much of a hunt through a stack trace with layers upon layers of framework code.
Granted, I do agree in general that "fail fast" is better, and I absolutely think that it's practical to write JavaScript code in such a way, but that's not an attractive selling point for JavaScript or Electron. That's like a PSA telling people to eat their broccoli; Electron is like telling people to eat plenty of donuts, and most people are going to eat donuts because companies of all sizes are all too happy to treat the resulting diabetes (metaphorically speaking).
On Windows, the current "native" UI toolkit is WinUI.
I quoted "native", because it's not really native. It's just what's in active development by Microsoft at this point in time.
Creating a desktop-web-app is just more convenient, because of skill re-use and you know it will continue to work, not only on Windows but Linux and OSX. Web is more mature and will continue to evolve.
On Windows, no one cares anymore if your app has a "native" UI - the OS itself has conflicting UI styles, and most main-stream apps are different.
Not the way I like things, but it's the way things are.
What does “native” mean to you? WinUI is implemented in C++, contains the control set of the current design language, and is used by the Windows shell itself and even Notepad.
Yea it looks different than what you can get from CreateWindowEx with the various control styles, but those also look different than MFC, Windows Forms, etc.
I would call it almost, but not quite native. There are some things MS internal apps can do, but that WinUI 3 can't. (Until recently, creating additional Windows, but also things like blurred transparency.)
I think a real native solution would be shipped with the system, and get an updated theme and feel with an OS update. But the last version that did this was Win32/Uxtheme and to some extent WPF. Metro/UWP formally did this, but it encourages you to hardcode a lot of styles, so you have to update your app when a new Windows version comes out. But I think MS has moved away from shipping the UI library with the system.
The real native UI is what MS uses internally, and for a lot of products that is DirectUI. It is used in Explorer, the start menu used it for some time in Win10, I think the control center also used it. But also MSN messenger used it, and Office, too. Spiritually it is similar to WinUI 3 I think: implemented in native code, drawing "windowless", and using some kind of XAML.
DirectUI was a precursor to XAML and is being rapidly replaced by WinUI internally. It has janky markup and renders using non-GPU accelerated GDI.
WinUI 3 intentionally decoupled from the OS so app developers can support several versions of Windows while still using the latest GUI stuff, in the spirit of web apps.
This might be a stupid question, but is MS Teams Electron on Windows? It would strike me as weird that the maker of the operating system doesn't use their own UI toolkits?
Skype is made with Electron too and so is VSCode. They do like most developers do - if they need a cross platform app, they use Electron. Although I think they are pushing for React Native (maybe?), which can use native controls.
Teams 2.0 in Windows is moving away from Electron but still using web based technology. It's not going to use Chromium to render, it'll use Edge Webview2 that comes with the OS.
MS Teams has to work cross platform or no one would use it, they'd be "Slack except worse because part of your team can't have it."
It's not like Apple is maintaining iMessage anywhere except their own platforms. And even with that, until very recently the Mac version was second class compared to iOS, only catching up when Marzipan/Catalyst let them share one codebase between the two versions.
So that's not exactly Apple using Electron, but it's still a good example of "Even a giant company like Apple has trouble effectively maintaining separate cross platform versions of the same product."
Microsoft makes many terrific MacOS native apps (the most obvious of course being O365), idk if they have MS teams for Linux but I doubt that’d be a reason for using electron.
And likely be terrible and would get no market share. I don’t know anyone who lives in excel all day who would be ok with the jankiness of an electron app
If anybody can afford to write native apps, it's Microsoft. How many Teams users are there? Tens of millions? The cost of developing native apps spread across all those users is pretty much zero.
I think the real reason Microsoft went Electron is because they plan on extending it to eventually take control of Electron on Windows. So they need some big Electron-based applications to justify that.
It already is "Slack except worse". The Catalyst comparison is an interesting one though, Catalyst on macOS is still pretty horrible in terms of usability, but a lot better than Electron on system resources.
The Apple Music app was effectively an Electron app for a few years before the Catalyst version arrived, just a shell around webviews. And even now, there's still a bunch of webviews in the app today.
Mac Messages was comically just a plain webview for years. Again, that changed with Catalyst.
Uh no. The old client's chat transcript was using WebView for display with a bunch of custom-fed CSS/HTML/DOM that was built in code. The rest of the app was good ol' AppKit.
The whole chat transcript being a web view thing was one of the main reasons the app eventually got killed in favor of a Catalyst version. There was zero expertise in the team to make all the random new transcript features that the designers kept throwing on the iOS client and there was also no way to reuse the knowledge and code of the iOS team either. Various attempts to rewrite the mac client's chat transcript to native throughout the years failed due to lack of resources and/or corporate bullshit.
> Uh no. The old client's chat transcript was using WebView for display with a bunch of custom-fed CSS/HTML/DOM that was built in code. The rest of the app was good ol' AppKit.
Yes, I overstepped, the sidebar was probably an NSTableView and the text input looked native enough. I still find it comical that the star of the show, the transcript, was a webview.
> due to lack of resources and/or corporate bullshit
I suspected as much, and again, it's comical. Trillion dollar company. Apple, of all companies, can afford to pay Meta-level comp or higher, roll out big recruiting efforts across the US and Canada and let engineers work in more cities, and yet they've only barely started in the last couple years.
MacOS 12.3 just changed that and the difference is incredible. All the Apple music screens load much faster, especially the search one that previously was not just slow but also broken
Windows 11 shell UI seems to be mostly web. I remember how during beta testing people kept finding widgets were you could accidentally trigger Chrome's caret browsing prompt when pressing F7.
Even Microsoft's native applications can feel off. For example, I use Outlook for my email and really dislike its editor. When I type, I want the text to snap into existence immediately as I type. In Outlook it feels like it glides into being and doesn't even keep up to fast typing. Word is like this too, but fortunately I don't have to use it very often.
Because of this, I write longer emails in a text editor and paste it into Outlook when I'm done.
Every month or after a fresh install you can't start the clock or calculator app because it needs an update. It's not even an automatic update you need to open the app to get notified that there is an update. Insane.
Which parts exactly? If anything explorer.exe has never been more native (it used to have a lot of HTML elements in Win98 to XP). I think new control panel and start menu are WinUI based.
I think Electron/crossplatform tools are great at very early stages in order to test whether the product can work. You can quickly put together a working cross platform application to start testing features.
I am a noob at startups (working on some of my own ideas) but I almost always start with the most simple set ups (zapier + google forms tbh) to try some process with 5-10 people. If that seems promising I'll build a app over a weekend/5 days using flutter, and then get that into people's hands. I've not used electron, but at least my thinking is that if I can validate an idea and come up with a good business model, I can grow to a point that I can hire actually competent engineers to build the best experience for the users.
The primary goal (at least as it seems to me) is to solve some problem that people are comfortable making some tradeoffs(mostly unnoticed by normal people, let's be honest otherwise they wouldn't even want to try a bare bones google forms + email) while providing far more value to them.
Ultimately these are all tools, use the right one where it matters until it needs to be upgraded or changed.
If I wanted to make a native windows application I really wouldn't know what to use ? WPF is what I've worked with. But WPF is awful.
When I was doing some games programming using Imgui for little widgits was actually quite nice. But wouldn't want to use C++ generally for an application.
What do people actually recommend ? Electron seems to be the go to.
I’m a little offended by the comment about WPF; WPF is stuck in 2006 but at least is about as polished as you can expect from a 16 year old product. Microsoft should aspire to make their other UI offerings half as good as WPF.
UWP is like WPF, but with critical features stripped out, broken core functionality (e.g. renderers for paths/SVGs are super broken), and an 80% chance of facing a COM exception if you try to do anything remotely interesting.
I’m learning web tech so I can make a career change - I built my career on .NET client technologies and I deeply regret it.
Take it from a (former) Windows fanboy, choose Electron.
>because nobody knows how to design a great Windows-native application
In that case it is a question of resources right? Nobody in our org knows how to do that thing well, so we could have them go learn or ... use Electron and get the app out the door...
The choice for an organization with limited resources seems obvious.
They also don't lead by example in their software.
In basically every single text field/area in Windows, `CTRL Delete` deletes the current word and leaves the space before it, so if you type "Hello Hello", hit ctrl delete, and then type "Goodbye" your result will be "Hello Goodbye".
In Windows Mail, for reasons unknown, it deletes all the way to the last character of the previous word. So if you type "Hello Hello", hit ctrl delete, and type "Goodbye", you get "HelloGoodbye". It's baffling. Why make a unique UI element just for this that's inconsistent with the rest of the operating system?
If Windows was only the case we wouldn't be having a blog post explaining why they didn't chose Electron for a program running exclusively in some other platform. As that implies that Electron is very widespread even in that platform.
Is a CS grad really that much more capable of creating a native Windows UI application than a "bootcamp-graduated js-monkey?"
I certainly did not learn anything Windows related as a CS major and little to nothing about UI/UX.
Calling people "js-monkeys" is a bad look. We can have a conversation about the quality of applications on different frameworks without stereotyping an entire group of people.
This is a major reason many companies that start native, then try to scale to 100+ person eng teams often end up incorporating web views, and then switching over entirely.
Saw this happen personally for our desktop client at Dropbox.
It doesn't matter how much RAM you're saving and how much fun you're having "thinking outside the box": our company won't use your product because we won't exclude from team communication our employees that choose to use Linux, or need to use Windows for financial software. It's absurd to me to have collaboration software that excludes people just for some technical clout.
Build native for every platform. The amount of work supposedly saved by using cross platform solutions is grossly exaggerated and frequently negative.
Most development time isn’t typing code but actually architecting the solution. You will go through multiple iterations to get your UX right. Lots of things like graphics, GUI mock-ups, database design, file formats can be reused.
In cross platform development one too often ends up wasting time on problems introduced by buggy layers on top of the native frameworks.
Every time I have compare my development speed using native tools vs a lot of the cross platform web stuff, native wins hands down.
But it depends on where your skills are. If you are more skilled with web technologies then your experience will likely be different.
(Cofounder here) This is close to our thinking. Comes from seeing how at Dropbox we started with a cross-platform approach on desktop. While it meant that we could quickly achieve consistency, it also meant that we couldn’t use platform-specific tooling on any given platform, like debuggers, without a bunch of custom tooling to fight through the intermediate layers.
We want to try running small teams using the best stack for each platform.
I think many companies have a chicken-and-egg problem when it comes to cross-platform development. They already engineers for iOS/Android/Mac/Windows and there's established workflows for creating native apps for each platform, so cross-platform experiments are at an inherent disadvantage.
> You will go through multiple iterations to get your UX right.
For high-level UX flows, this is where cross-platform frameworks could have an advantage, because you can iterate without redoing the work for each platform. It might even make sense to use a web framework for the initial prototype and early user trials, and then reimplement in native for performance/details once it's finalized. As a bonus, if you're willing to maintain the web version you could use it as your browser-accessible version.
If operating system vendors wanted to, they could deliver APIs that resemble Electron, but with better OS integration capabilities without the performance problems.
HN loves blaming companies like Slack for shipping “crappy bloated electron apps”, but what we should be doing is demanding more from Apple, Microsoft, and Google to ship a sane APIs to make this work. Blaming vendors is essentially victim shaming.
Sadly I know that’s a naive optimistic pipe-dream because these corps would lose power over their user base.
Great, now make it so one code base can produce a working GUI on all platforms. Use any tricks you want — COM style binary interfaces, linking against platform libs with common headers, protocols like X11 or Wayland, a common “high level” API that can be transpiled to platform specific code and then natively compiled.
The “one code base” is allowed to have platform ifdefs, doesn’t have to be magically perfect and handle all edge cases.
Because this is table stakes for Electron, cross platform libs, and game engines. Getting Apple, Google, and Microsoft (because honestly if the others can agree Linux will just follow) to agree on something anything would be a huge milestone but I’m sure they would all see it as erasing their moat.
There are a lot of smaller companies that start off as 100% Mac shops. On the face of it, this is a smarter choice for them. Not every shop is a Fortune 500 that needs to support some nigh uncountable variety of setups.
But I do agree with you. Developing backend cloud applications is just easier on Linux. You will only succeed at prying Windows + Excel from Finance's cold, dead hands. Most companies that aspire to growth will get there. Why shoot yourself in the foot for 160 MB RAM savings?
Having built desktop software - I found doing things cross platform is hard for various reasons.
1. You can't use any specialized features or APIs in one OS unless you implement it in all others.
2. If you use Electron you're basically building a webpage, which can only be taken so far in terms of user experience. While teams like VS Code have pushed the limits, you still can't do what this app is doing.
3. Increased test/QA surface area which becomes difficult - especially supporting Linux - which have relatively fewer users but you still have to properly invest time into supporting it, something startups cannot do.
I really don't see the point of this product, but there are plenty of small to medium teams which are mac only, and it's better to be an interesting niche rather than yet another collaboration and huddle-type software.
Our team develops an Electron-based app which is released on Windows, MacOS and Linux. I only own a macbook, but so far I haven't had a single compatibility issue — everything that works on MacOS also works everywhere else.
And if we wanted to do a web app (which is a fantastic from business perspective for a lot of reasons), it would require some groundwork, of course, but nothing like doing it from scratch.
I worked at a Fortune 500 company with hundreds of thousand of employees, high five digits in an office setting. No interesting cross-functional team was pure-macOS (mostly Windows, some macOS, some Linux users in engineering centers outside the US).
I worked at a 300 person startup. No interesting cross-functional team was pure-macOS (80% macOS, mix of Windows and Linux for the rest).
I worked at smaller startups (<20), and they still weren't all macOS.
I’ll reply here so that you can also quickly have access to the counter-argument: people complain about Electron because of quality issues. OP is arguing for Electron for business reasons.
Which is why we’re generally exposed to so much mediocre software. Business is king and most companies do the minimum possible to get customers and grow. And if they for some reason do engineer to higher quality than their competitors, it’s quite likely that they will be outcompeted.
but many folks (including myself) aren't counting apps specific to a platform like this one. You should have a set of quick links to cross platform apps that are native.
It seems like macOS is the only desktop operating system that has anything interesting happening on it (I say that as a person who primarily uses Windows and Ubuntu on the desktop). Not a lot, mind you, but there appears to be at least some interesting new things popping up for macOS.
For Windows, I'm not counting games because that feels like its own thing.
Flatpak itself is kinda jank though, thing like: asking for root multiple times during installation, spewing out a bunch of CLI output I don't care about, not having ways to configure app permissions without using Flatseal.
I'll probably catch a lot of hate for this, but Snap is a much smoother experience and is well integrated with Ubuntu, even if the snap store kinda sucks...gnome software is worse.
Snap truly is awful. That's why I'm completely dumbfounded that the Flatpak developers found a way to make package management somehow more of a hassle...
Flathub is it's own can of worms, as is Flatpak. There's a number of "next-gen" Linux users who love to demonize people who are critical of new tech like Wayland, GNOME and the like, but I'm the most critical towards Flatpak. Linux doesn't need more hack-y ways to get bad software running: we need more robust ways to get software running well. Flatpak is a shotgun approach to getting an app working, where someone said "your app doesn't run? let's just containerize it!"
Needless to say, this is not a great idea in concept, practice, or it's current execution.
I think a much better idea would have been to copy what NixOS does. Yes, your developers have to do a little more work, but you can finally have reliable builds, fix your dependency graph, and actually run your software natively. I'd love for a more uniform "AppImage" style of installation, but Flatpak is definitely not it. Too many sharp edges.
NixOS might solve dependency issues but it doesn't provide isolation. Currently in a one-user system every app has access to all of user's data and hardware serial numbers. And Linux was not built with a principle of minimum privileges in mind, so for example a PDF viewer can read browser cookies or stored passwords.
This is a problem that also exists in many Flatpaks: plenty of applications get carte-blanche access to the OS filesystem, and "breaking out" with symlinks or chained attacks has proven trivial over the years. There are so many of these exploits that they simply stopped patching them after a certain point. Isolation is much better provided by other tools like Firejail.
Containers are a native technology in Linux. The issue with Flatpak is that it comes with its own bundles for underlying desktop components that add some duplication and overhead (in memory use and disk space) compared to what's provided out of the box, but that's a requirement if you want genuinely portable applications.
Which points to the root problem - unlike macOS and Windows, Linux has no native GUI. Ultimately, I don't think the options that you get with Linux help it.
Linux is a kernel—like NT or Darwin. Better comparison is with KDE and GNOME and they both have native UI toolkits as well as look&feel and design guidelines. Only major Linux-based system without native UI is Chrome OS, but that’s rather intentional.
Agreed… macOS seems to have avoided the massive fragmentation problems plaguing Linux and Windows.
It’s not perfect… the iOS ecosystem is just different enough that common frameworks don’t always go up to the UI layer (UIKit and AppKit are different, although most of their dependencies are the available on both platforms), and that sometimes manifests itself in slightly odd behaving apps in macOS (Messages, News, Stocks, etc are just UIKit apps recompiled for the mac), but it still feels like the different stacks share enough similarities, that from a developer’s perspective it doesn’t feel too jarring.
I think this can be attributed to the fact that Objective-C was such a perfect design choice for its time. While Microsoft was busy being ashamed of COM and spent a lost decade chasing .NET as the New One Way to create windows apps, only to double back and shore up COM again through the WinRT stack, Apple (post-NextStep) had that problem fully solved with Objective-C. While MS’s environment needed a separate IDL and object model to allow ABI-resilient dll’s (C++ is not ABI stable, it needs COM to do that), Objective-C solves this problem naturally through its fundamentally dynamic nature.
Examples:
- In C++, you can’t just construct an object that’s defined in another .dll. You may know its size now, but you can’t be sure that its size won’t change in the future, and you may not be in a position to recompile your code (say, when a new windows version comes out and your customer tries to install your program.) So to allocate an object, you have to ask COM to do it, which means following the relevant conventions and using COM API methods to ask the remote class to create an instance of itself (CoCreateInstance, etc), and refcounting the resulting pointer with AddRef/Release. This isn’t a bad design choice, but it’s just different from how C++ programmers are used to constructing objects.
Contrast this with ObjC, where `[[SomeClass alloc] init]` is always the way you construct objects, and there’s no jarring change between “how you allocate objects defined in another framework” and “how you always allocate objects”. And refcounts are automatically managed by ARC, which is part of the ObjC compiler.
- COM works by having objects query each other’s interfaces and exchange vtables around so that the function offsets are known, which requires special calling conventions that are different from how normal C++ code works… You’d need to call QueryInterface on a COM object to get a pointer with the right vtable, so that you can call the right methods on it, etc. Various high-level wrappers (MFC, ATL, etc) abstract this from you, but they’re imperfect, and the right wrapper depends on the use case. Not to mention, you only get access to the COM APIs which are actually exposed via these wrappers, so they won’t help you with “general purpose” COM code. I have been out of that game for a while but I’m assuming WinRT has made a lot of this simpler.
Contrast this with ObjC, which simply always uses dynamic dispatch with objc_msgSend to actually invoke methods on objects. It’s “ugly” (`[[[lots of] brackets] etc];`), and “slow” (because the method dispatch is essentially passing a string around and dynamically discovering which code will handle it) but it’s at least uniform.
COM was unwieldy to non-microsoft engineers, but Microsoft mostly “solved” this by creating friendlier programming interfaces on top of it. They didn’t really want engineers being confronted with COM’s complexity, and so technologies like MFC, ATL, (OG) Visual Basic, and then later .NET were touted as solutions that had a better developer UX. But that’s just the problem… there are too many solutions to this problem in Windows, and nobody could agree on the “right” way to write windows apps, so everyone either did some flavor of either raw win32 programming (if you’re up for doing a lot of work yourself), or some rotating framework du jour which would hide the complexity for you.
But on Apple’s platforms there was no such awkwardness, and Apple just kept innovating. ObjC’s internals were not some implementation detail to be hidden but the fundamental way you do all object-oriented programming on the system, so there’s no reason to have different conflicting wrappers on top of it. Developing for AppKit was just plain old ObjC, and you get ABI resilience for free because of its dynamic nature.
Anyway this was a long rant but I really do feel like the lowest level technologies are to blame/praise for the situation with OS software in general, and COM was such a sore spot for microsoft that their attempts to paper over it just made the platform worse and fragmented things, leaving developers to fend for themselves with how to develop applications.
Addendum:
I’m actually sorta worried about Swift as the replacement for ObjC, because it’s not as “fundamentally dynamic” as ObjC is. Apple is aware of this, and has gone to great lengths to enable library evolution/resiliency in Swift frameworks, but they’re coming at it from a totally different place from how ObjC solved it. In ObjC, it’s just `objc_msgSend` all the way down. In swift you have value witness tables, protocol witness tables, reabstraction thunks, and all this massively complex infrastructure to make it feel like objects in another Framework are the same as the objects you define locally, and it all sorta works, but… it’s just not nearly as elegant. It’s technically faster though (since method dispatch through these witness tables is likely faster than objc_msgSend), so at least it was done for a reason. But I’ll always have a special place in my heart for ObjC due to just how perfectly it fits into the problem space.
I'm neutral about Swift vs. Obj-C, I can see the advantages in Swift (especially now that the language is starting to tackle concurrency and getting closer to solving its existential issues) but I miss just having a simple set of tools that would still let me do everything I needed without thinking too much about them. Too much time spent being precious when writing Swift code...
I'm more worried about Apple's mac approach becoming Windows circa 2005, currently you can develop a mac app using AppKit, which is slowly rotting away, or using either Catalyst of SwiftUI, both of which are playing catchup with iOS and not really getting there. Too many options, none that are truly polished up anymore.
The fact that Apple's developer tooling is described as great makes me suspicious if the author has used JS tooling in a serious way. VS Code is just so much better than XCode. My experience developing native apps in SwiftUI is also that the documentation is very very lacking. And lastly I wasn't able to get a hover effect without dropping tons of frames. My lack of experience I'm sure is partly to blame for the app's poor performance, but it certainly wasn't performant out of the box. React would have been significantly more performant for my use case.
Web development is almost hell compared to developing with Apple tooling. At least that's been my experience. I primarily do web development when it comes to UI, but I dream of going back to Swift, Xcode and macOS.
I strongly disagree, XCode is so bad compared to VS Code and JetBrains I have to believe that Apple engineers are forbidden from using anything else, because they don't seem to want to improve it.
My experience was primarily driven by C/C++ development though. I've heard better things about swift, but I just can't grok how the hell xcode projects are supposed to be used at all and the tool is so slow it's unusable.
I agree that in terms of pure editor and IDE capabilities, JetBrains is better than Xcode. I am rather thinking of the actual Apple ecosystem with SDK, API's etc.
VS code feels so third-party-extension and custom-config dependent and I’m sure OP has their VS code settings _just right_ for them, but that does not make it a good editor for everyone.
I love this community, but the people who are comfy configuring Linux and cant understand why everyone doesn’t roll their own solutions generally don’t know shit about what good UX is.
Not really fair to compare the dev experiences _for macOS development_ across VSCode and XCode. I wouldn't recommend using VSCode for Cocoa/UIKit/SwiftUI dev.
I'll say that working on TS/React in VSCode is head and shoulders above Swift in XCode from a DX perspective. I had to routinely restart XCode to verify that type errors were actually there, it was incredibly slow, and the Swift compiler would give up on highly polymorphic types and red line them.
I'm not going to be objective but XCode is the single worst piece of software I ever used.
12 GB to download, more sluggish than the worst electron app, terrible UX, undocumented config files screwing up with git, terrible error messages, app upload is so unreliable even Apple had to create a third party app and tied to the OS version.
Developers have no choice, it's clear and they know it.
This product looks great. I think their instincts are correct, that an app constantly open needs to be performant or else even regular users will grow to resent it and use it less than they might’ve.
The comment about the difficulty of hiring is an interesting one. I haven’t come across a helpful, beautiful and interactive resource to teach those paradigms, as you find created for any language/framework combo used for web development. There also aren’t many huge desktop teams outside of Apple, Microsoft, AgileBits, etc., so it’s hard for someone to find a starter role where it’s okay to contribute minimally as they learn. Lots more lone wolf or tiny team programming where any kind of apprentice would just be a drag.
It's honestly not that hard for a random iOS dev to learn the macOS ropes, the principles and paradigms between UIKit and AppKit are the same and at this point both frameworks have a comparable amount of baggage and quirks. AppKit adds some complexity in some areas (window management comes to mind, which UIKit has now but no one bothers with) but helps in others (document management is still miles ahead of UIKit's).
The problem is convincing someone to try. There's a reputational issue "AppKit is haaaaard" "AppKit is baaaaad" "AppKit is dyiiiiiing". There's also a career issue as it's felt that building native mac apps is a career dead end.
For anyone thinking the tradeoff is fully native, single OS specific vs cross-platform Electron, do remember there are intermediate options, and I'm not talking Qt (though that's also an option).
You could make a minimal native app shell for each platform, with the most relevant integration points, and then host a native webview within that shell that shares its UI across platforms.
Not quite as nice as true native, not quite as fire-and-forget as Electron, but certainly more efficient and integrated than the latter and a lot more cross-platform than the former.
Would have been nice to have a real, cross-platform UI library that uses the native controls everywhere, kinda like what WxWidgets hoped to be. Unfortunately Microsoft in their push to make Windows desktop development into a Lovecraftian nightmare, made that all but impossible.
This sounds great in principle and I saw this tried for several years for Dropbox mobile. It was a failed experiment though:
> By writing code in a non-standard fashion, we took on overhead that we would have not had to worry about had we stayed with the widely used platform defaults. This overhead ended up being more expensive than just writing the code twice.
Isn't the Dropbox desktop app Electron crap these days? It's certainly not the pleasant experience it used to be.
Plus what you're talking about there is the opposite of what I'm suggesting, you wrote 2 UIs with a shared C++ logic, I'm suggesting two native platform layers with hosted webviews.
I’ll be following along, hopeful you’ll publish more specifically on hiring as time goes on.
Would also love any other recentish articles about hiring macOS developers if anyone’s got em.
I’m very bearish on native macOS after the most stereotypical “worse is better” experience in the late 2010s working on a macOS (now electron) product, but am increasingly reconsidering.
It’s too early to say and I’m too cynical to anyways, but it’s starting to feel like the release of the M1s really has injected a bit of life and taste back into the scene.
(Cofounder @ Remotion here.) One challenge with hiring macOS devs is that they don't usually come from cookie-cutter backgrounds. For example, they might have been indy devs, or consultants for a while. And those folks often fare poorly in traditional tech interviews.
Hiring for macOS led us to drop standard loops in favor of contracts, projects, or however the candidate can best demonstrate skills. We have a recent blog post about "objective-based recruiting" here: https://www.remotion.com/blog/standardized-interviews-stifle...
This is a lot like hiring for great iOS / android developers. And also great web developers, FWIW.
IME, the most value-generative and knowledgeable frontend/UI people I've worked with have all had really "weird" backgrounds and would fail a "standard" software engineering interview loop, and most would fail hard.
I've worked at a bunch of companies that tried to have the same hiring process for frontend and backend engineers, and it's never made sense to me.
> It’s too early to say and I’m too cynical to anyways, but it’s starting to feel like the release of the M1s really has injected a bit of life and taste back into the scene.
If anything, this creates a justification for using Electron. "Macs are too fast, even when using Rosetta, so who cares if we use Electron?"
I'm sure that's going to happen -- arguably, it already is, with 1Password moving from native toolkits to Electron on the Mac -- but it at least feels like there's a bit of a pushback on that in the Mac indie dev community in particular. Apple Silicon is part of that, but Catalyst's also starting to get its act together and SwiftUI is...well, arguably a couple years out from getting its act together, but promising.
I guess the question would be if a larger pool of users willing to vote for native apps with their $$$ would counteract the dynamic you mention.
After all the worst possible dev environment will get extensively used if there's money to be made using it (I'm thinking of talking with PS2 developers 20 years ago…).
No, this isn't a reason. They're Mac-only because they used Cocoa, which is exclusive to macOS. If they'd used GTK or Qt they could have shared 90% of their application code between at least the three major desktop operating systems, without using Electron.
(At Remotion) We decided against Qt partially based on my experience working on the Dropbox desktop client—Qt sounds great in principle but in practice we think you're better choosing between native or web tech.
I'm less familiar with GTK.
Qt is a particularly poor experience on macOS. Also the past few years all the new stuff in Qt was QtQuick, which seems basically like JS, and if you're into JS, why not just use Electron?
GTK is a non-starter for something professional, at least if the experiences of the GIMP and Inkscape on macOS are representative. (Also, it's C, which does avoid some ABI problems, but it's hardly suited for an object-oriented environment)
Yes, and? "How much code we get to share between platforms" is an extremely poor indicator of quality for any technology. GTK/Qt have the advantage of being very fast, having native look-and-feel, and allowing you to share code between platforms. Electron only has that last one.
If you want to maximize code-sharing, you would use webtech for all platforms, including iOS and Android. Yet most organizations don't, because they know that that gives them a poor experience, and they're willing to expend the effort to do native ports to those platforms.
Alternatively, if I'm not making a web application, I literally don't care about the fact that I could share my desktop code with it, because it doesn't exist.
> My point is that those who can’t use your app would appreciate electron
...and my point is that nothing about Electron makes it uniquely able to solve this problem. Someone who can't use my app would also appreciate GTK/Qt if it allowed them to use it.
Some people are also unable to use apps because they use Electron. My computer can't play some video games while I'm in a Discord call because of how many resources it uses, but it's perfectly fine in a Mumble call, because Mumble has a reasonably-performant, non-Electron client.
Yep, if you were making a purchasing decision for your company and you had some users on windows or linux this app is immediately crossed off the list.
Replace 'macOS' with any native platform name, and you'll get the whole reason behind Electron proliferation. It's just cheaper to make something with Electron, if you are a software development business.
One of the things I like about native apps is that they can tie into the platform’s specifics. If you build it right, a lot of your code can be platform-neutral calling into platform-specific behaviours such as, but not limited to, the UI.
But does Remotion support native Windows and Linux ports?
I've never minded the speed, expressiveness, intuition, or integration of Electron. All the value is in portability. A desktop app limited to just one operating system is near useless today.
This is kind of an Ask HN: Is there actually a trend in the grand cycle of ideas where we're returning to native apps? If so, what's causing that?
Is there some tech that's making it easier? (Maybe easier memory management, big enough market on each platform, React Native on the desktop, or many native-mapping frameworks, or Swift UI on macOS) Maybe people are tired of Electron?
I'm only talking about devs because many users won't really explicitly notice.
> I'm only talking about devs because many users won't really explicitly notice.
They notice, but "devs" tell them that software just gets more complex so they need to buy beefier machines, which is actually shitty advice in a world where you can't upgrade ram or anything.
devs are lazy, and don't care about the end users. "Works on my machine (64GB RAM and a zillion cores)"
The bigger the audience, the more impact performant software has
Exactly right. As a developer I could go further and say that a lot of devs are simply abusing trust of users by claiming their half-assed apps are the best/optimized/ergonomic solution possible.
I have a production Electron application: Video Hub App and if I had a few hundred thousand dollars to waste, I could hire developers to write me Windows, Mac, and Linux native applications. But instead I spent a few months by myself and created an application that runs on the three OSes ¯\_(ツ)_/¯
It's not even a contest: unless you're a corporation making tons of money, you either pick an OS and write a native application ignoring other OSes, or you use Electron (or some alternative).
I have 4,000 people who purchased the app and not one complained about RAM or some other nonsense people keep hurling as insults at Electron.
Pretty cool app, congrats on launching and building a userbase.
Re: Electron comments: don't take those comments on Electron personally, it is just a means to an end. Personally I avoid Electron because the JS ecosystem makes me sad every time I touch it. But that's just me. :)
I think it used to be around 130mb on Windows. I checked just now with the latest Electron 18 - and the ram seems to be around 30mb. The app consumes more RAM when it's extracting screenshots from videos (usually you do this once to build your "hub" - preview of your entire video collection).
The numbers are suspiciously low. Electron binary itself weighs about 100 Mb, although of course it need not to be fully loaded.
Are you using correct way to measure memory usage? I think that the correct way is to measure all physical memory mapped into all Electron processes (there are several of them), making discount for shared pages and adding swapped out pages (because they can potentially be loaded back into main memory).
In Linux I usually add PSS and swap usage parsed from /proc, which should give correct numbers (PSS is an additive value). For example, all processes of Skype on my system take approximately 459 Mb in RAM and swap file.
If you are only measuring one process memory instead of all and only private memory pages (excluding shared pages and swapped out) then you get the wrong number. I tried to search online what "Memory" column represents in Windows Task Manager and Mac Activity Monitor (which people often use to estimate memory usage), but couldn't find any information. So I cannot be sure that they show true values and that those values can be added to find total memory usage by several processes.
As one of the codevelopers of Remotion, I sadly don't think there's a meaningful return to native macOS.
Team communication tools like us are a non-starter if they don't support the entire team, and the vast majority of even mac-first teams have a Windows user somewhere. (E.g. Even iOS dev shop has finance person.)
I hate to say it, but I think the tradeoffs often lean in favor of Electron. Taking RAM usage as an example, even if your app will consume 100s of MBs when running, if the user only has it open when they need it, it's workable.
In our case, only the goals of building something often visible, that feels like a part of the os, usually running in background, sometimes running lightweight video & audio... gave us the rationale to build natively.
Yes, I picked up SwiftUI last year initially because Electron/JS/TypeScript just never felt fun. Yet, I wanted to build out a few desktop/work-related ideas.
Then, after going through the Apple Developer tutorials I noticed how easy and satisfying working with SwiftUI actually is.
So, oddly enough, native macOS with SwiftUI is now one of my go-to for most of what I want to build (that isn't web-first).
My personal anecdote as a long-time Mac user: there's a positive correlation between the number of Electron apps I have to use and the desire to retire from tech.
Native apps feel and fit better and consume less resources. Unfortunately for people like me, market forces mean they'll remain niche relative to cross-platform apps.
No data to back this up, but I think there's no trend back at all. Electron-like apps will continue to be dominant and people will never stop disliking them.
Building for Electron / Web is so much cheaper considering the frameworks, transferable knowledge and virtually free support for all platforms. People have never not hated on Electron though, and that's because it's also always going to be a worse experience.
I think the people writing native apps are using the native-ness as a selling point, and it resonates with HN users. I'm not sure there's a sea-change among most users, as much as I'd like that to be the case.
I do think that we're starting to understand the costs of "write-once-run-anywhere," better, too.
100%. We initially chose to write natively because we thought it was best for our users.
But now that we're putting that work in, recruiting for a less comment skillset, don't have Windows or Linux clients yet, etc... we want to make the most of that selling point.
> As a user ... I really don't care what they use, the app runs well or it doesn't and I don't care why.
Well, Facebook almost lost the game completely because they were using a hybrid app.. Users cannot articulate why something si ruining performance (maybe not their app, because it simply has a higher priority set..)
Facebook's initial offering was horrible because it was a horribly developed app, it wasn't the fault of the underlying technology whatever they claim. Lots of people have built similar apps on web views that don't suck.
PWAs, for example, can have downloadable bundle sizes < 5 MB, run in < 50MB ram, and have plenty of headroom for lots of features. You only need electron with it's own copy of a browser if the browser sandbox is unacceptable for your use case.
I made a similar observation when reading the Zas Editor thread. Lately some MacOS specific applications have been popping up here on HN and they all look really good which I think is mostly because of the polished controls that SwiftUI provides.
While I haven't used SwiftUI directly (only reviewed some code recently) it looks like it makes it simple to build good-looking native desktop apps.
Unfortunately SwiftUI is not very cross platform and the other toolkits (Gtk, Qt, Swing, etc) are lagging behind in terms of polish and controls.
My general conclusion is: Native desktop applications are not dead yet as shown by the popularity of Electron and SwiftUI shows that if the toolkit is good, developers will build native desktop apps. Now it's up to the other (cross-platform) toolkits to step up their game and we can get rid of the electron-based memory hogs.
I've been noticing a somewhat similar boom of new good-looking apps in the GTK/Gnome world. Although those are mostly smaller projects (single developer free-time pet-projects) with very small scope (doing one very small thing well), but the sheer number of those good new projects is amazing compared to the status quo of a decade or so ago.
And although you credited the MacOS specific applications boom entirely to the good toolkit, I think the GTK/Gnome app resurgence comes from a synergy of three factors:
1. The rise of more ergonomic programing languages (Rust, Go, ...) that make desktop app development more fun (GTK programing in C works, but it is like pulling teeth, soo much boilerplate).
2. The rise of new app distribution channels on Linux (e.g. Flathub)
I was going to say the downside of not being able to support the platforms other than Mac seems too big. But I think it makes sense if the experience is 10x better on Mac because of it being a native app. After you build a good fanbase, you can probably raise more money for you to recruit a team to build a native app on other platforms and maintain separate codebases. Then, you’d have 10x better experience on all platforms!
I mean, there are some companies out there that are 100% Mac only, but even then with a chat app you are extremely limiting your userbase if there are no interoperability options. The second you need one person on a Windows machine you can't use this.
I find many of the cross platform toolkits arguments somewhat bogus. Sure if you pick electron it looks nothing like a native app because they basically created their own UI interface that just happens to run on multiple OSs. Same for java.
OTOH, QT for example still tries to use native dialogs so when you click open file, you get the native OS open dialogs/etc. Sure if your an expert you can find place where they aren't quite right, but for most people they won't notice the difference. Plus, if your really OCD about it, given your in C++ you can just add your own OS shim layer (or custom components) to correct the slight differences you might see here/there by calling the OS services natively.
I've seen some bad and unresponsive native applications that looked out of place, but I've never seen an app that used Electron (or CEF) that wasn't unresponsive and looking out of place.
Fine with me, it just means I'm not going to use this. On an individual basis that's fine, but if you intend to get some B2B action by selling this app to shops and groups >25 people, you should be aware that supporting only one OS is going to make it a lot harder to pick your app.
Again though, serve whatever niche fulfills you. I don't even know what their app is/does after reading this article, so I'm going to assume it's not a life-changer so much as it is a native version of something we already have.
Agreed—and we're currently deliberating how we'll build for other OSes.
Re the article not explaining what Remotion does, we're trying to avoid plugging our app itself in our technical posts—we figure anyone who's interested can click onto the main site.
Your site asks me to fill out a form to get started. It's pretty narrow on jobs list, but only after getting me to fill it out do you tell me that NOPE, thanks for the survey data, still need to "CALL SALES" anyway like some kind of 20th century dinosaur.
Super annoying that you want to schedule a call "or" get an invite. If an invite works, people should not need a call.
> "Want to skip the call? Ask any Remotion user for an instant invite."
I'd assume you're a user. I'm asking for an invite. Email in profile. :-)
That's fine. I just don't really see much of a use for this personally, especially if it's Another Competing Standard for video calls. I've been able to get similar results by just pinning a Google Meet window at the top of my screen, but maybe I'm missing a killer feature here?
Fair enough. Many of our users used to do what you do.
Reasons they sometimes switch from long-lived Meet calls:
- Free up 200-300 MB of RAM when in call.
- Features specific to coworking (e.g. shared music DJing) or eng pairing (e.g. multi-way screen share).
- Presence when out of video calls. For example, you'd see if anyone on your team is in the Meet without having to ping each other. Leads to more unplanned hang outs.
Considering that people mostly use either webapps in a browser, or Electron-based 'native' apps, does saving 300 MB with a specific app really makes that much of difference?
I do understand that macOS APIs and libraries are easy to use, development experience is (at least in my opinion) better than with Electron + framework of your choice, and you can achieve better integration with the OS, but I don't think that saving 200-300 MB is really important to the end users.
TBH we weren't sure how much people would care. What we've found is that when we build a bucket of value props to solve for a given use case (e.g. eng coworking), different users will find different value props to resonate.
So some people are very glad to save RAM, CPU, etc. Others don't care but love shared music DJing etc...
My team is also building a native Mac app instead of electron. I used to joke that we were the last one so I’m very glad to see it isn’t so. The app looks great. Congrats Dan!
Interesting article, got me to actually check out Remotion itself too and the demo video is definitely slick. Would love to try it out but we're only a handful of developers that use macOS at my job so I'm afraid we wouldn't get much mileage out of it unfortunately.
Cofounder here. Thanks, appreciate it! What platforms are your coworkers on? You're welcome to try it if you'd like or I can let you know when we support those platforms. If interested LMK at alexander [at] remotion [dot] com
> Better AV quality thanks to direct access to low-level hardware and device APIs
Can you maybe expand a bit on what differences did you encounter between using Electron vs native APIs? That might also be a good post, if you are willing to share the details.
I'd be happy with some "nutritional" information alongside the usual app info. If I'm trying to choose between several note taking apps for instance (assuming they both claim to deliver a similar set of functionality) I might just go with the one that's not going to hog all my memory or drain my battery. Like nutritional labels on food it won't be completely accurate, but at least I'll know to choose the crackers over the chocolate cake if I'm trying to lose weight.
Something Apple could do is extend macOS’ finger-pointing at resource hogs. It already lists egregiously heavy apps in the battery status item, but if it did something more visible like show a notification (or maybe even paint a red outline around windows of offending apps, it’d increase user awareness and thus pressure on developers to do better when it comes to efficiency.
I feel your pain! I was furious when I learned that Slack disallowed running their iOS app on M1 Macs. They specifically opted out of this, so everyone would continue suffering their "desktop" client.
Ok, the discussion of MacOS vs Electron aside, I happened to check out the actual product and to me it seems like a glorified surveillance tool for remote workers. I think the best part of remote work you get is the flexibility, privacy and freedom that you don't normally get with 9-5 day jobs. To turn your desktop into a CCTV seems like solving the wrong problem for me. I don't know how employees even agree to this! "We will monitor you 24/7 via a video call on your laptop"
Why would you do that? I have never been pissed off at a product this bad.
Cofounder here: agreed that an always on CCTV would suck and is counter to our approach.
Our website does make it seem to some folks like your camera would always be on, but that’s emphatically not the case. (We need to fix this on our site.)
The only things we show when you’re not in a call is online/offline status. You can then opt in to sharing your calendar and whether you’re in a Zoom/Meet call. We chose those status automations because they’re things you can find on your coworker’s shared calendar anyways.
Suggestions for how to clarify on the site are welcome.
Ok, constructive feedback -
Why I think this product isn't for me or my company - When 7/10 team mates comply and keep it on always, the pressure is on the remaining 3 to turn on their cameras as well. I can understand the need if it's a sales or pre-sales call, but this would be a pressure even for daily/bi-weekly standup calls.
The most important point of all - when you go offline, it is now amplified in terms of visibility. For example, when I work remote, I'm not 24/7 on my desk. Heck, I may not even be on my desk for hours when others are working, but I may work at night to compensate for that when it's usually peaceful. But, a manager's perception of me might be that I'm most of the time unavailable, when it's not true. This may affect my performance reviews, etc.
IF you had pitched this as an alternative to Zoom with a privacy angle, that would be a real sweet deal for me. Perhaps, you could try to have a separate sales page for it as a pro-privacy zoom alternative, I have a feeling it may be received well by remote workers like us than what is pitched on the homepage.
Appreciate this feedback! Our site is ~6 months stale and we're working on updates next week onwards, so this is very timely.
> When 7/10 team mates comply and keep it on always, the pressure is on the remaining 3 to turn on their cameras as well.
This is our site being unclear again. Remotion coworking rooms default to audio and video muted. However, we struggling with how to represent Remotion on our site: When you're out of a call or your camera is off, we show users as "selfies" because we think those feel more human that just a green dot. Website viewers often interpret these selfies as being live video.
> when you go offline, it is now amplified in terms of visibility [...] This may affect my performance reviews
Candidly, I think that the root symptom of what you're describing is your team/manager. Let me ask you this: Do you want to work on a team that wants you to be at your desk all the time?
Our philosophy at Remotion is to be radically transparent about breaks, to the point of celebrating them. Apart from a few hours of meeting overlap in the middle of the day, we work on our own terms, including taking breaks for walks/errands/etc in the middle of the day. It goes to the point of actively posting photos of our midday breaks in an OOTO channel. Teammates react to those, making a point of saying: "Hey, prioritizing yourself is good. Being offline is good."
> When you're out of a call or your camera is off, we show users as "selfies" because we think those feel more human that just a green dot. Website viewers often interpret these selfies as being live video.
Even though in-app you encourage photos, maybe for the marketing website you could display this as avatars/cartoon-versions of the person (which presumably people can set, if they prefer)? It'd make clear that live video isn't mandated.
Depending on where you work, you maybe right and/or wrong. You're held accountable for the deliverables, not for the time stamps. I never work with companies that do time stamps, might as well go to a 9-5 for that.
Your comment made me curious about this. I found their old home page that seems much more oriented around assuring that it’s not meant to be an always-on tool. https://www.remotion.com/home-old-2
It’s important when applying for a remote job to figure out what kind of remote culture the team has. Some are reading and writing only, some like frequent short video interactions, some longer video meetings. This seems optimized for the second type of culture with the option to use it as the third type.
Looking at it, I suspect a lot would depend on the specific team/manager's expectations. The basic idea of "there's a fluid always-going video call that you can drop into whenever you want" isn't awful, and I can see how it's a reaction to not having a shared office space. But if people hassle you about not having your video always turned on, that'd be a problem...
If Windows truly had a great UI+UX equal to macOS, the investment of native apps would be much more worth. Now creating a web app for windows is almost the de facto choice because there’s nothing better!