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?
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.
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.
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?
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.
>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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
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 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 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.
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.
> 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.
[+] [-] weejewel|3 years ago|reply
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!
[+] [-] tapoxi|3 years ago|reply
[+] [-] ravenstine|3 years ago|reply
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.
[+] [-] jenscow|3 years ago|reply
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.
[+] [-] drcongo|3 years ago|reply
[+] [-] me_me_mu_mu|3 years ago|reply
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.
[+] [-] holbrad|3 years ago|reply
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.
[+] [-] duxup|3 years ago|reply
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.
[+] [-] NicoJuicy|3 years ago|reply
[+] [-] forgotpwd16|3 years ago|reply
[+] [-] SureshG|3 years ago|reply
You should check out compose multi platform - https://www.jetbrains.com/lp/compose-mpp/
[+] [-] ushakov|3 years ago|reply
[deleted]
[+] [-] tinus_hn|3 years ago|reply
[+] [-] rsstack|3 years ago|reply
[+] [-] criddell|3 years ago|reply
For Windows, I'm not counting games because that feels like its own thing.
[+] [-] city41|3 years ago|reply
https://flathub.org
[+] [-] ryanmcbride|3 years ago|reply
[+] [-] ninkendo|3 years ago|reply
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.
[+] [-] vikeri|3 years ago|reply
[+] [-] sgt|3 years ago|reply
[+] [-] lacrosse_tannin|3 years ago|reply
I'd prefer electron even it wasn't cross platform. I could write the app 4 times in electron faster than installing xcode.
[+] [-] Shadonototra|3 years ago|reply
People who say such thing have no idea what they are talking about
Debugging with VSCode is a joke, and there is no GUI preview for Cocoa/UIKit/SwiftUI
XCode has many flaws, but it's properly integrated and helps you to make beautiful native apps
VSCode is a UX nightmare
[+] [-] 1123581321|3 years ago|reply
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.
[+] [-] sirwhinesalot|3 years ago|reply
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.
[+] [-] embirico|3 years ago|reply
> 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.
https://dropbox.tech/mobile/the-not-so-hidden-cost-of-sharin...
[+] [-] exfascist|3 years ago|reply
[+] [-] finiteseries|3 years ago|reply
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.
[+] [-] nicolas_t|3 years ago|reply
[+] [-] endisneigh|3 years ago|reply
[+] [-] viktorcode|3 years ago|reply
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.
[+] [-] rbanffy|3 years ago|reply
[+] [-] mc4ndr3|3 years ago|reply
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.
[+] [-] atonse|3 years ago|reply
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.
[+] [-] jbverschoor|3 years ago|reply
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
[+] [-] yboris|3 years ago|reply
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.
https://videohubapp.com/en/ & https://github.com/whyboris/Video-Hub-App (MIT open source)
[+] [-] aejae|3 years ago|reply
[+] [-] interleave|3 years ago|reply
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).
[+] [-] jonpurdy|3 years ago|reply
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.
[+] [-] treve|3 years ago|reply
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.
[+] [-] mattgreenrocks|3 years ago|reply
I do think that we're starting to understand the costs of "write-once-run-anywhere," better, too.
[+] [-] duxup|3 years ago|reply
There are endless amounts of developer chatter about using / not using Electron.
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.
[+] [-] zorr|3 years ago|reply
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.
[+] [-] howon92|3 years ago|reply
[+] [-] StillBored|3 years ago|reply
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.
[+] [-] seba_dos1|3 years ago|reply
[+] [-] smoldesu|3 years ago|reply
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.
[+] [-] evanmoran|3 years ago|reply
[+] [-] rubyist5eva|3 years ago|reply
[+] [-] watermelon0|3 years ago|reply
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.