There's a lot of discussion in the comments here about Electron vs. native apps. But last year's Catalyst project, which allows you to ship iOS-based projects on the Mac, opens an important new path. I've been surprised not to see many people discuss it!
In particular, this means that you can use React Native to build native macOS apps. You still get live reloading, hot code push, pleasant abstractions, etc. Most importantly, though, these apps can use straight-up AppKit controls on macOS and straight-up UIKit controls on iOS. Better still, you can use react-native-web to ship such projects on the web too.
You will+should, of course, have many platform-specific branches. But I find that the vast majority of my code is shared, and there's a _world_ of difference in being able to use the same development tools to ship polished software on desktop, mobile, and web.
My most recent project builds to macOS, iOS, Android, and web out of the same Typescript project. There was certainly some toolchain chicanery involved in this, but now that it's set up, it's delightful.
Many of the companies shipping Electron apps on desktop are shipping React Native apps on mobile. I would very much like to see React Native-based desktop apps replace Electron apps.
As a user I don't want a React app. I want a native app.
I can understand why you as a developer don't have time to maintain the different platforms, but for a UI app running on my laptop or desktop I care about one platform and that is macOS.
React app is a native app. JS performance is ~the same in UI part - just declare what you want to display and native part will do the rest. It is much much easier to write slow AppKit code than RN one. Actually it is really hard to achieve decent performance with AppKit.
Yeah, but let's be honest. Most users don't want a specific app. They want functionality. They'll pay for functionality in a React App while eschewing a native app without the functionality. The practice of this means solving the problem the fastest is the most important part. And if someone can rapidly build a native app so be it, but if they can only rapidly build React apps that's what they should do.
> Yeah, but let's be honest. Most users don't want a specific app. They want functionality
True, but they also want to be able to run it without bringing their crappy laptop to a crawl. Devs excuse their inefficient code with "modern hardware is fast enough", but it ceases to be fast enough when the majority of your apps are inefficient. Try running Slack, Discord, Skype, Spotify and a couple Chrome tabs on a last-gen laptop. And now try to run something actually useful (Office, a game, whatever). You can't.
I've seen completely non-technical users say "ugh, another web app". Alternatives are few, so users won't use something else, true, but that's not an excuse to keep making inefficient apps.
(I realize this doesn't apply nearly as much to React Native, but only React was mentioned above and this is a rant I've had prepared for a while now...)
Thanks for the comment - I wasn't aware of Catalyst, or that React Native is now actively integrating with it to support building native apps that run on iOS + macOS.
Here's the most prominent issue I found that's tracking progress:
It does require macOS 10.15, so I imagine it will take time for the late majority and laggards (I am one) to catch up to the latest goodness.
---
As much flak as Electron gets, I think it serves/served a purpose by opening up cross-platform app development to a wider audience, lowering the bar for better or worse. Commonly raised complaints about CPU/memory usage, file size, non-native UI, seem unavoidable due to the need of bundling Chromium. (Unless someone figures out a standard way to use a single shared install of the runtime.)
With React Native, it's also paving the way for a huge audience of developers who otherwise might not have been able to build cross-platform mobile apps. I'm one of them, very excited for the opportunities.
> ..live reloading, hot code push, pleasant abstractions.. apps can use [native UI] controls..
> ..use the same development tools to ship polished software on desktop, mobile, and web.
> builds to macOS, iOS, Android, and web out of the same Typescript project
Ah, but what I like about React Native for desktop is that I can render native AppKit controls and create an application which looks truly at home on macOS. Flutter, as I understand it, doesn't aim to provide access to native controls. Just as an example, it would be quite challenging to duplicate the effect of the blurring effect view used by macOS sidebars and the hyper-saturated "vibrancy effects" of controls on top of it: https://developer.apple.com/design/human-interface-guideline...
There was a recent article from FB about the performance improvements of going native:
https://news.ycombinator.com/item?id=22466462. I don't know what they were using before and I don't write React Native apps so I don't know how these two pieces of information intersect. But, if they were using React Native before and saw such big gains from moving away is it worth moving away from Electron to something that is still less performant than fully native?
Xamarin Forms is another brilliant option. Out of the box it can target Android, iOS and Windows. If you use catalyst then the iOS app can be ported to MacOS. C# is a nice language to use too.
Reading the comments here, I find it very distressing that people in our industry can simultaneously say the following two things:
1. Consistency is extremely important for UX and one of the cornerstones of user-friendliness
2. Users who aren't developers probably don't care too much about "native look and fell".
If users, indeed, don't care if some applications don't look and can't be handled like other applications, maybe it's time we judged designs more in terms of innovation and usability, and less in terms of compliance. I haven't seen a new icon set, application theme or website that didn't look like any other icon set, application theme or website in years.
If they do actually care, then maybe let's admit that. I'm not advocating for burning all JavaScript to the ground, but it would certainly help if we'd treat inconsistencies as bugs, so that we could use frameworks like Electron to write better (i.e. more consistent) applications, rather than hand-waving them as unimportant, except in topics about UX rather than Electron, in which case they're totally important.
I think that there is a way these two points can live in the same universe. One the one hand users expect a consistent UI, especially on mobile. While apps are free to define their own user interface and style, they should follow certain patterns that other apps in the past have established.
When I hear the other point that users dont care about UX what that boils down for me is they don't see all the little things that we see. They still expect a consistent user interface but seeing a menu not render exactly where it should, an animation that stutters for one frame or other small things. These are all things that we as developers scrutinize but the user doesn't notice all that often.
Now we should still scrutinize those little things. I feel like the thing that makes some apps feel more "magical" than others is how polished those little details are.
> They still expect a consistent user interface but seeing a menu not render exactly where it should, an animation that stutters for one frame or other small things. These are all things that we as developers scrutinize but the user doesn't notice all that often.
I find it's the other way around. Quite often it's the developers who don't care if a menu is out of place or if an animation stutters.
The users, however, do see these things. They might not be able to articulate it, but they will see it. And call your app slow (animation stutters), unpolished (menu not rendered where it should) etc.
That's why, for example, MacOS has been getting so much flak these past years: they've stopped sweating the little details, and people noticed.
I think that makes a lot of sense. When people say users don't care about UI - that always leaves me wondering - have they tried releasing a little toy website or something to their friends that didn't have a hamburger menu on mobile? Even with all the blog posts I remember a while back about how those are suboptimal - I got question after question of "how do you navigate?" And this isn't like a rhetorical question by the way, not am I saying everyone would be like that for every app, I'm just curious if there are different social circles that react differently.
My sor of laypersons intuition about UX has been that it's just about reducing cognitive effort for new adopters. For things that don't really matter to functionality, make it consistent with what they'd expect given their context so they don't have to think about it. Hamburger menus aren't "intuitive," give them to a tech naive person and they'll be confused, but they sure feel that way today because of how everyone has been thoroughly trained in how to use them to navigate them, so why not take advantage of that social training to lower the adoption activation energy? I would think that I would rather people spend effort figuring out the parts that have to be different for the new functionality. I'm curious to hear from someone with actual design training if that's a reasonable approach, or if there might actually be some reason that the opposite is actually empirically true (like a unique UX makes people feel like power users and locks then into the platform or something?)
The reason that icon sets are similar is probably because they are quite ingrained into our memory. The save icon, although younger people have no idea what it's supposed to represent, is evident to them to be the save function. And since icons are generally meant to guide the user, then you opt to use something they already know. After all they do not have much agency compared to the main content of an app or site.
Another way to combine those points: Consistency is good, but its value degrades gracefully. Especially in a simple app, you can mess it up a fair bit and users will tolerate it provided they can still manage the result. But following the local human interface guidelines does make the app more usable, and the more complex your app is the more that matters. Unless, of course, your application is such a big deal that it can set its own standards and users will learn it unto itself (EMACS and Photoshop come to mind); that isn't free, but as long as you're internally consistent it at least just comes to up front cost.
> I haven't seen a new icon set, application theme or website that didn't look like any other icon set, application theme or website in years.
Probably because you only visit mainstream sites, use mainstream software or you just don't look hard enough. That said I tend to agree that there's lots of similarity.
> Native Mac apps feel like a dying breed that are succumbing to janky web views
Yeeaaahhhh, not really. I was a diehard "native" person until recently and I can't believe just how much better developing for web technologies is than writing native Mac.
If you're experienced enough to write a polished Mac app (and that is a non-trivial undertaking) you're experienced enough to write a polished front end in Electron.
Use a lightweight framework (e.g., Vue), be sensible about what you're asking Chromium to draw for you and unless you're doing something really simple -- be ready to write a backend in C++ or equiv.
I'm not saying that is easy, but in terms of complexity it's a wash. The upsides are substantial:
1. Multi-platform with very little additional work
2. Modern web standards + a good IDE are so much fucking better to work with, really
3. Easy to drop into WebGL if you need it
4. Less vendor lock-in
The only place I see it making sense is if you're only working with a single platform -- of course, you have to ask yourself how good of a business decision that is.
This is a judgement on cost, and you're advocating for cheap app development for you.
But what about the cost for the users of your app?
* Huge memory impact for your app
* Non-native look and feel (no, neither Vue nor anything else give a native app experience)
* Possible security holes, as Electron is patched behind Chrome, and your app therefore behind Electron
* and more.
What you're asking is that to ease your job, you give your customers a non-native UX (subjectively "bad", but that judgement is something I think most HN readers would agree with); and you value their computer resources very little (ie you don't respect your users' computers and are happy to waste their computing memory and CPU.)
Electron is the solution when a developer values themselves over their customers. Now, you can make an argument for that, such as getting your minimum viable product out to market quickly. Over time, as the app develops, the attitude of happily giving your user lower UX quality and wasteful applications is harder and harder to justify ethically, though I admit that's only true if predicated on a foundation that you should respect your customer or have pride in your work.
My laptop has about 32 gigs of ram so its less of a concern. That said, I find electron apps to be a huge drain on my Battery life.
As a developer, (with a lot of js experience) I sympathize with devs trying to build a product that works seamlessly crossplatform. Electron is a great value when you want to push out a product fast that serves a lot of users accross all devices and you have limited resources.
But I'm calling out slack specifically. you have millions in funding and profit. You can afford to hire a few more devs to make a polished native platform optimized version for each platform that is resource efficient. Slack runs on my desktop all day so having it run fast and not take up too many resources would be a huge win.
I also don't understand this. What makes it even worse is that someone has already done this. I've been using Ripcord [0] for a few months for Discord and Slack, and it performs way better (it's native, written in Qt 5), and supports nearly all of those platform's features [1]. It is unfortunately proprietary (although I think the dev has open sourced the theming engine).
it doesn't look as beautiful (if you care about that), but it has most of the features. This is all done by 1 guy. Imagine what Slack and Discord could do themselves.
The real solution is to drop these proprietary solutions that don't respect their users. Unfortunately, while I love Matrix and Signal, the large majority of my social circle would never move to those.
Edit: I should also add, there's a very promising, open-source Discord client being developed called gtkcord3 [2], it's still very early in development, but it looks great and already supports the essential features, excluding voice chat.
Mine has 8GB, and I'm a developer and photographer. A "normal" user won't even have that.
In the course of my "computer-janitorial duties" that the extended family expects from a relative who "works with computers", I have only seen >8GB in one teenager's gaming PC. All their laptops (some rather recent) have 4GB and low-power mobile chips. Skype, Spotify and Discord (in the background!) will bring their computer to a crawl. Add one or two Chrome tabs and all the computer is good for is a space heater.
Electron is a great value, true, but that's mostly because JS developers are plenty and therefore cheap. As a mostly web developer with little C++ experience, I was able to pick up QtQuick in a week and I've gotten actual user feedback saying they prefer that over the previous otherwise-identical Electron versions.
I downloaded an app named Clicker for Netflix that was an Electron app. It wasn’t very bad, but it also wasn’t good. The dev rewrote it as a native Mac app. It kicks ass. It’s so much more responsive that it’s night and day different. It also gained a bunch of native controls (touchbar and such).
Building for the platform demonstrates that you care about your app and users.
Your concerns about security with regard to Electron apps is real. So much so that for the new project I'm working on, I spent a few months building https://github.com/reZach/secure-electron-template, which is an OSS secure electron template that fixes up the security holes so you don't have to worry about it.
> Electron is the solution when a developer values themselves over their customers. Now, you can make an argument for that, such as getting your minimum viable product out to market quickly. Over time, as the app develops, the attitude of happily giving your user lower UX quality and wasteful applications is harder and harder to justify ethically, though I admit that's only true if predicated on a foundation that you should respect your customer or have pride in your work.
You're entitled to hold this opinion but preaching it as if it is an objective truth and thereby disrespecting other developers is just obnoxious. Luckily the users can decide for themselves what is unethical or not. I have 5 electron apps open right now (Spotify, Slack, Figma, VS Code and Notion) and I find it absolutely absurd calling the devs unethical because of their choice. They have provided me with some fantastic value. Is it great that they take up ~100MB of memory each? No but it's not even close to as big of a problem as some devs try to make it out to be. 8 gigs of RAM is around 30 bucks. Get off your high horse.
The RAM thing is disingenous. Even on a desktop it could be more expensive than that to add more RAM, say if all your memory slots are populated. If you have a Macbook with soldered RAM, it could cost you a new laptop and thousands of dollars to get more RAM. But I guess Spotify is worth it.
Nowhere did I mention upgrading. The example was meant to give a general estimation of how much RAM costs and establish a frame of reference for statements like "huge memory impact". If RAM still cost say $100 per GB the situation would be entirely different.
I don't see how that's relevant. Upgrading is the point - previously the user's PC was sufficient, and now it is not as it is runing slow. Now the user has to buy a new computer. In the past they might have to do this to use the lastest games or such. Now it's necessary in order to run Spotify and Slack.
I'll ignore the "obnoxious" and "Get off your high horse" comments. Despite your tone I think you have a good point that's worth addressing.
> Luckily the users can decide for themselves what is unethical or not. ... They have provided me with some fantastic value. Is it great that they take up ~100MB of memory each? No but it's not even close to as big of a problem as some devs try to make it out to be.
Right now I have Slack running on my Mac. The Slack processes and memory usage are:
* Slack Helper (Renderer): 384.5 MB
* Slack Helper (Renderer): 168.4 MB
* Slack: 134.2MB
That's a sum total of 687.1MB for a chat client.
Now, my memory resources are limited. Sure, I have virtual memory etc etc, but there are costs using anything paged out. Importantly, there are apps that I want to have memory available for: multiple virtual machines where taking several gigabytes is expected and a _good_ use of memory; image editors that genuinely require a lot of RAM. The key here is (a) resources are finite; (b) some apps genuinely need memory; (c) some apps are valued (by the user) in terms of memory higher than others. My machine is for me to use, not a third party to misuse or squander.
So why should I be happy with 687.1MB of _my_ memory used by a chat client, when a competent development team writing a native app could use a fraction of that and give me a better native user experience?
One point you may not have realised is that yes, memory has grown and is cheap, but the advantage of having more resources is to do more. I'll repeat that: _having more resources should allow us to do more_. Imagine that an app on my modern Nvidia graphics card with, say, 8GB of RAM used all that RAM and GPU power to achieve the graphics from my Riva TNT from 1999. Would you expect me to be happy with that, or would you expect me to not be impressed by the graphics apps using that card?
More, while memory is cheap for us, and many HN readers can probably drop thousands of USD on a new 16 or 32GB latest-model MBP, not everyone can. Many people use old computers, cheap computers, ones that cost $300 and come with 3GB of RAM and a 32-bit copy of Windows. Or they're using their laptop from 2011, because it still runs and money doesn't flow. They use those as best they can. And it's... privileged? I can't quite find the word, but I think we as developers should write our apps for them too.
There is also the matter of professional pride or self-respect. Could I, as a developer, be satisfied and feel I was doing a good job with my work on Slack? Did I "do it right", can I be proud of my work? Maybe, because it's useful and polished, but to feel I'd done a good job I'd have to have a very different set of values in terms of how I thought of my customers.
I use Slack because it's a team tool and they got to market with a cross-platform app early and/or with good marketing, and are now the default. Years later, they still use the same client. Someone in Slack HQ has made the decision that the improved user experience and respect for their user's resources is not worth the financial and support cost of developing a macOS native client. That's their prerogative, but you shouldn't expect me to like it. I'd have a lot more respect for Slack and Slack development (or management) team if they produced an app that 'Did It Right', that was built on the principle that the machine Slack runs on belongs to their customer, not to them.
> I'll ignore the "obnoxious" and "Get off your high horse" comments. Despite your tone I think you have a good point that's worth addressing.
You just blatantly declared a large number of developers as unethical for a technology choice so maybe learn to take it if you're gonna dish it out.
> That's a sum total of 687.1MB for a chat client.
I'll admit I was entirely wrong on the amount of memory here. Taking the renderers into account it's a lot more like you say. However the base footprint of Electron is less than 100 and the amount that gets used depends heavily on implementation details regardless of underlying framework.
> So why should I be happy with 687.1MB of _my_ memory used by a chat client, when a competent development team writing a native app could use a fraction of that and give me a better native user experience?
The fact that there is currently no other chat application implemented natively that brings you the same set of functionality should tell you something. This is the problem with reducing technology choices down to this narrow idea that only one thing matters. In reality there are many factors that comes into play such as the core competency of the employees you have at hand, team scalability, maintainability, time to market, etc. Slack may never have existed for all we know if they had to build it natively. You don't need to be happy about their product but you seem to be blindly assuming something better can be created with native technology when there is no evidence to support this case. Yes it can in theory, but in reality there are practical constraints.
> One point you may not have realised is that yes, memory has grown and is cheap, but the advantage of having more resources is to do more.
I'd argue we ARE doing more. That's the problem right there. People get so wound up about something like memory consumption that they forget the innovation that some of these apps have brought that perhaps justifies the extra cost. VS Code has IMO taken the place as the number 1 IDE. Would it have had the same improvement rate and rich ecosystem of add-ons if it wasn't using web tech? Probably not. Slack was a groundbreaking product when it came out. There has never been a product that offered the same feature set. Discord is another amazing piece of technology (I'd argue outperforms Slack). Again, you can claim all day long that these products would be better if they had UIs implemented from ground up in C++ or Objective-C but until someone actually does that the onus is on you to prove that it in practice can be done.
It supports both Discord and Slack, is lighter, customizable and almost at feature parity with the official clients (except for a few things the dev refuses to do for philosophical reasons or whatever). If Slack hired this guy, I bet he'd be able to crush the official client within a month.
It'll take time for the landscape to develop, but I'd like to add some additional arguments for a web-based application stack.
Websites from the 1990s still render and function just fine in modern browsers. How many software applications from the 90s can you still use effectively on your laptop or smartphone?
If we collectively want to create and share data that will be accessible to older and younger generations, and build applications which stand the test of time, it'd help if the foundations we're building on (i.e. native SDKs, APIs, file formats, and platforms) stop shifting every few years.
I'd argue that even with the evolution of web/JS frameworks, the underlying HTML+JS+CSS stack remains more stable than most native development platforms (with the possible exception of the Win32 API which has been impressively maintained, and automake which has done great things to make Unix software portable).
Performance/memory impact is a good area to investigate further, as are any remaining areas where there's a gap between native and web-foundation user experiences. I totally agree with your criticisms there.
Since many applications are built using web technology I'd expect the stack has developed (and will continue to develop) good resilience against security vulnerabilities.
Driving down developer costs seem to me like a beneficial goal and I don't necessarily think that criticizing a desire for low-cost tooling and application delivery is a positive standalone argument.
There may be a few developers who see themselves as more important than their users, but that will become apparent to users over time. Given low-cost development tools there can easily be alternative applications for people to switch to which better respect user needs and goals.
That's only part of what keeps developer costs down.
First of all, unless you're on a Mac, every other system can run old applications from the ninetees
Secondly, web is a moving target, you spend less now (maybe) but rewrite every 6 months, even if you don't want to (that library is not updated anymore, now we use this one instead)
Last but not least, electron is not a stable platform, a native API is
> Secondly, web is a moving target, you spend less now (maybe) but rewrite every 6 months...
Isn't this the point? A lot of these devs who support using web tech seem to only be concerned with writing apps, not maintaining them. They also seem to have a fixation on, "Ohh! Shiney!"
> If we collectively want to create and share data that will be accessible to older and younger generations, and build applications which stand the test of time, it'd help if the foundations we're building on (i.e. native SDKs, APIs, file formats, and platforms) stop shifting every few years.
Except everything requires a remote server nowadays which likely won't be there to "stand the test of time", so that point is moot..
The right trade off between business and customer is a business lead’s call IMO, even though it has a lot of software technicality to the decision.
Giving the most fitting (absolutely not the best) service to the customer is the job of whoever owns the interest in the business. Would a customer rather pay more for the features you talk about? The features are either free and easy and there’s no cost to pass around, or the customer is ultimately paying for it. Most people working on a product are just the sideshow to the intersection between business interests and customers.
> What you're asking is that to ease your job, you give your customers a non-native UX (subjectively "bad", but that judgement is something I think most HN readers would agree with); and you value their computer resources very little (ie you don't respect your users' computers and are happy to waste their computing memory and CPU.)
Frequently the "customer" is a client and not the end user of the app. Assuming that someone doesn't respect someone else's computer because they use a tech that you don't approve of is ludicrous.
> Electron is the solution when a developer values themselves over their customers.
Nope. When you have limited resources i.e. small development teams you have to choose where the effort is going to go. Cross platform tech like Electron allows you to deliver to more customers with (theorectically) less effort, which can be put into many other things that might benefit the customer e.g. cost savings or more features.
> Over time, as the app develops, the attitude of happily giving your user lower UX quality and wasteful applications is harder and harder to justify ethically, though I admit that's only true if predicated on a foundation that you should respect your customer or have pride in your work.
There is so much wrong here. The whole premise makes a lot of assumptions that may not be true. Any Engineering Discipline is about producing a product that adheres to a specific set of specifications. This frequently requires making decisions dependent on budget, technology etc. Unless you have an unlimited budget you will have to make a trade offs. Claiming someone is unethical or doesn't respect their customers / end user because they used a technology you dislike is quite pompous.
I'll try to counter your arguments, even though I share your sentiments against Electron:
* Huge memory impact for your app
The same is true for native macOS applications.
* Non-native look and feel (no, neither Vue nor anything else give a native app experience)
Agreed.
* Possible security holes, as Electron is patched behind Chrome, and your app therefore behind Electron
Security holes with respect to what kind of threat? That is, for an application that gets installed on a computer and runs with user privileges (), what is the kind of threat that could break Chrome/Electron but not a native macOS application?
() If we are talking about sandboxed applications, the thread could alternatively be the application breaking out of its sandbox. A different analysis is obviously needed here.
* (...) you value their computer resources very little (...)
This seems to contradict the suggestion to write a native c/c++ backend. Such a backend can easily optimize the performance-critical parts. Premature optimisation isn't the same as valueing your user's resources.
* Electron is the solution when a developer values themselves over their customers.
This is a false dichotomy. A developer who makes his/her life easier has more time to work on things that matter, including optimization.
> what is the kind of threat that could break Chrome/Electron but not a native macOS application?
This isn't abstract; it isn't about whether Electron is theoretically vulnerable to more vulnerabilities than a native app. It is about Electron's history of CVEs.
> This seems to contradict the suggestion to write a native c/c++ backend.
I’d much rather use an app with a native UI and a JS backend (like React Native) than one with a web-view UI and a C++ backend.
After all, the problem isn’t JavaScript. JavaScript may be easy to abuse, but it can be a reasonably fast language if used well. The main problem, in terms of both usability and performance, is HTML rendering itself.
That's worse than Rails back in the 2000s. It's a bad pattern and a code smell.
Electron doesn't contain a toolkit of components. Last time I check, Atom's UI wasn't broken apart into its own package (it might be now). That's part of why all electron apps look entirely different .. and bundling each set of HTML components with an electron web browser involves insane amount of packing tools.
I rewrite that app and others in PyQT5. Here's one of them:
So much cleaner. The code in the project is almost all my code. There's very little boiler plate. The dependencies can easily be updated. The Qt5 layer is entirely abstracted by its Python packages or the system Qt5 packages.
I like Qt5 but I can understand the frustration. Your model isn't tied to your data. You have to tell Qt when your data has changed and emit those changes because it's all Retained Mode. Web web browser frameworks like React/Vue and others, you get system where the data is updated with the model (thanks to Shadowdoms or other tricks) and that is something missing in the native toolkit space. Most of the immediate mode GUI toolkits are minimalist and meant for games.
Divinci Resolve is made in Qt5 and is cross platform (I think they even have a Linux port now).
I know Qt5 has its own issues with portability and packaging, but I still prefer to build Qt5 apps over anything in electron. There's no reason to package an entire fucking web browser and rendering image for each application you build. Electron is cancer.
> If you're experienced enough to write a polished Mac app (and that is a non-trivial undertaking) you're experienced enough to write a polished front end in Electron.
Yeeaaahhhh, not really. Number 1, they're different skillsets. You can be experienced enough to do one, and know relatively little about the other. They're related insofar as they both involve programming and UI/UX but the relationship's far from linear.
> Use a lightweight framework (e.g., Vue)
Just the shallowness of this statement belies the overall point being missed in this comment. There's so many things wrong with this statement:
- What is a "lightweight" framework?
- Is Vue really lightweight?
- Does using a lightweight framework make your app lightweight?
- Does everyone use Vue the same way?
- Is the UI framework even the main performance bottleneck in Electron apps?
The rest (being sensible about drawing and prepared to write some C++) are also such vague advice. It's possible to write a very performant pure-JS electron backend. Most don't manage to, and even if they do there are other unrelated bottlenecks. There's plenty of people writing bad C++ too.
> Easy to drop into WebGL if you need it
I really feel you're understating the migration cost of DOM UI to WebGL here... just a tad.
> Less vendor lock-in
That really depends how deep your npm dependency tree goes. Migrating off a bunch of no-longer-maintained JS deps you've intertwined into the core scaffolding of your app isn't going to be particularly different from a platform framework change for a large complex product.
He said polished, like VS Code. That's the only Electron application I run so it's my only example, but it's totally possible to make the end result good.
People acting as if "native apps" don't ever customise their UI or draw their own controls. Hell, even look at Apple's first party apps and you'll see they're full of "non-native" controls - Final Cut Pro has its own entire custom UI library that it uses.
VSCode and the Github App I think are fairly good examples of good UIs that don't use the default OS widget appearances.
Does it have to feel like a native app? Depending on the audience you're targeting, I'd argue that most people don't even care, as long as its a good user experience.
It uses different UI paradigms, doesn't even try to look like native controls let alone use them, and isn't fully system-integrated with the behaviour you'd get from a native app. I just opened, and saw:
* Has an expand/collapse panel on the left, using large icons. Not Mac-ish, very Google though.
* Title bar isn't integrated with the system (eg can't right-click on the filename to access locations.)
* General look and feel uses different controls. For example, the Problems/Output/Debug Console tabs: they aren't rendered like macOS tabs. They're capitalized text, and the UI is completely different.
* Cmd+, to open Preferences opens a tab, not a Preferences dialog. This is text (which is nice, good for a dev environment) but even the headings and collapse/expand controls are custom. There is no UI here that behaves like a Mac app.
I could continue for hours. There's almost _nothing_ in the app that is built in an Apple or macOS-congruent style. Now, it's a good app. Absolutely. But it's not a Mac-ish app.
With a native app, all of these things could be done in just as clean (and very similar in layout) UI, but in a Mac style and with what you, as a Mac user, have grown to expect as Mac app behaviour.
I'm not sure how much non-developers care about "native look and feel". In the arena of iOS apps, extremely popular ones like Snapchat, Discord, Gmail, GroupMe, and Facebook (to an extent) use non-native-looking controls and different user interface paradigms. All of them are cross-platform as well.
That's mobile. Single-small-screen use patterns are quite obviously very different than desktop use.
I care very much when normal Macintosh facilities are ignored, widgets don't act like they should, etc. etc. The entire point of the Mac is that seamlessness.
I wonder how many of these folks claiming nobody cares about desktop consistency will turn around and say the reason why Linux on the desktop isn't popular is because of lack of desktop consistency.
Part of the burden of building a cross platform desktop application is making sure the experience is consistent across platforms as users may need to be moving between them.
For example, most CG/VFX applications are multi-platform to various degrees. None of them are native by your standards as that would be an obscene amount of complexity to develop, maintain, and more importantly support. However, all of the applications behave identically on all the platforms they run on (sans some specific host platform features like D3D support, RTX/Optix, macOS menu bar, etc), which makes supporting vast user bases simpler, and enabling mixed OS environments without introducing cognitive load just to understand what’s different about the app.
We have our own gripes with UI/UX of these apps because they are complex, but not because they are not "native". Building a "native" application only works when you choose to target a single platform (like the Chime Go text editor), or if you have the reasonable ability and resources to have and support separate teams for each platform and the organization to coordinate roadmaps and priorities across them.
From my experience, the only group I really see complain about "native" appearance is macOS users. Windows users really don’t seem to care, and on Linux (there are some vocal people) I guess you could say GTK is the native toolkit above X/Wayland, but it’s really up to the DE/WM for determine what the "native" context is.
This is hardly a new argument. I personally remember Mac users complaining about the Microsoft Word/Mac 4 -> 5 transition back in the early 90s, when big gray pseudo-3D button bars invaded.
And you're right, Mac users are mainly the only ones to complain. That's because we do have a fairly consistent, unified experience and like it that way.
Which is why I don't use apps that don't play nice on the Mac. If I wanted inconsistent, I'd use another platform. Developers have to make their own choices, of course.
> but not because they are not "native".
This is incorrect, and contradicted by your next paragraph. On my work machine, I use two non-native apps because I have to (Chrome is installed but only used for troubleshooting Chrome-specific issues). My home mac has zero.
Adobe left a market gap for a few independent shops to step into on the graphics side, MS on the office app side. Here's hoping more do elsewhere. I like indies.
> This is incorrect, and contradicted by your next paragraph.
I’m not seeing the contradiction. In one section I’m talking about UI/UX gripes with a particular type of applications because of complexity required by workload, not based on host nativeness. The next about general platform user sentiments. The two are not the same. I almost never see anyone on any platform for these workhorse applications, that are essentially they’re own environments, ask for more "native" UI/UX outside of file dialogs. Because, for 98% of these users, it’s not important and has no effect on them getting their job done.
> This is hardly a new argument.
It will remain old, yet valid, as long as there are limited developer resources and multiple differently structured platforms to support. Hence toolkits and frameworks like Qt or Electron exist to make the developers lives easier. Are they perfect? No, but they do a heck of a great job in allowing developers to build applications that have a shared experience for all users within their business constraints.
If that’s something you don’t enjoy dealing with and want to maintain a pristine, full native environment, then that’s good for you. But that puts you in an extremely selective minority of an already minority environment.
I give credit where credit is due, Apple has done a great job of setting style guidelines and creating interfaces for developers wanting that native feel. Compared to Electron/web apps and cross-platform framework apps, though, that’s a very small slice of the pie.
Nova is another new addition, that while not a fully fledged IDE, is a an amazing Mac experience (still in private beta, unfortunately: https://panic.com/nova/).
Have you tried Nova yourself? Any ETA on when will it be available?
I've been using Coda for a decade or so now and would really like to see another Mac-native code editor that solves some of Coda's jankiness while preserving its good things (most drastically, IMO, vertical splitting. Why do so many other editors not support that?).
I have, and genuinely the only thing I’d like to see included at this stage is vim-keybindings, which I realise aren’t important for the vast majority of people.
Everything else is great, it looks and feels like a very high quality Cocoa app. You’ll be happy to know that Both horizontal and vertical splitting are included. While everything has been moved around compared to Coda, I think there haven’t really been any feature regressions (though I was never a heavy Coda user).
The list of macOS IDEs that do not feel native is larger. The Jetbrains one, likely due to Java, are to me fairly horrendous. Love the language breadth and features, really dislike the lack of care for UI.
> > Native Mac apps feel like a dying breed that are succumbing to janky web views
> Yeeaaahhhh, not really. I was a diehard "native" person until recently and I can't believe just how much better developing for web technologies is than writing native Mac.
He argues that web apps are janky; you argue that they are easier for developers. Both things can be true (I certainly agree that web apps are janky, and it may be sadly true that it's easier to build one than a real app).
We've heard the same argument for a good decade and a half now.
It's still 80% theoretical, 20% real. Meaning that 20% of the time it's fine and you get a decent enough result, but 80% of the time you're fighting the edges and yielding a sub-par user experience.
I mean, if we're at the point where VS Code is a "good IDE" and say XCode or Visual Studio isn't, we're in a very bad place where it seems like idealized visions or dogma conflict with reality.
Higher level abstractions and cross platform solutions make a lot of sense for certain things in certain situations, but it is a developer convenience that always yields a compromise for the user. That's when someone else comes in with user-first solution and eats your lunch.
Shameless plug: I did a similar thing for browser extensions to have a fully functional browser extension with Vue and Tailwind in under 30 seconds: https://gumroad.com/l/XUPxA
I actually like the idea of opinionated starter kits a lot, especially when built out of experience over multiple projects they show a lot of maturity, tailored for a specific workflow. Depending on the developers, these kinds of kits are mostly made for specific use-cases, and they pick the technologies already so that once the project is kicked off most of the non-crucial decisions are already made. Most of the time I have found myself thinking about which database library to use, what Docker image to deploy, which UI framework to use and all these kinds of decisions that have not much value add if all the other alternatives are getting the job done as well. If I were to start building a native macOS app, I'd definitely go for something like this because I just want to get to the core of the thing, not spending time on choosing libraries or thinking about where to put files.
Overall I enjoy it a lot, it gave me a big productivity boost. Everytime someone talks about Tailwind there is a huge discussion going on here, but I just gave it a try a couple months ago and I really enjoyed it. The thing I love the most is, I can get something going without thinking about what padding to use, how to align things, what color palette to use and all that kind of stuff, while also having all the flexibility to change things at the end. YMMV, but I think you wouldn't lose much by trying that out, the worst case is you spend couple of hours and you don't like it, but a better outcome is you spend couple of hours to save yourself tens of hours, so I think it's a good bet.
Welp, if we're gonna do the same tired arguments (Electron, etc), I guess I'll go ahead and inject another HN-meme into this thread. Let's talk about Rust.
I, like many, want to write the same code across platforms. I do not want to use the JS toolchain (the modern one, Webpack & co). I don't want to use C, because writing C feels contrarian outside of certain cases given the options available today. I want something that's fast, safe and mostly cross-platform.
So I started porting AppKit to Rust. There's an example you can see here - it's meant to feel similar to writing native UI in Swift.
I plan to put this in a longer blog post, but effectively I don't think write-once-run-anywhere UI works for the class of products I want to build. I don't mind rebuilding the app UI using GTK, AppKit, or what have you... provided I'm not running some ridiculous setup just to get code shared across platforms. Rust and Cargo do incredibly well with this.
I'm building my next product in this as a way to dogofood and force the functionality in. If you're interested in following along, you can check out the repo below - note that it's still experimental, the example app (Subatomic) has not been updated for recent changes yet, and the main repo doesn't have docs being built just yet (though I'll probably have this later this week).
Anyway, that's my bit - wondering if there's a better way to achieve cross platform code without the headache, so consider this another foray into getting there.
Tangential: we've been using xcodegen (https://github.com/yonaskolb/XcodeGen) to generate our projects from a simple yaml file. Don't need to muck around with Xcode toggles, easily repeatable, and .xcodeproj literally stays in .gitignore. Never know why Apple consistently shyes away from more programmatic generation of stuff.
The fact that we need such boilerplate solution to start building a simple Mac app without having XCode in the way in 2020 means a lot about the current state of native app development.
Eeehhh, this kind of comment erases a lot of the default things you get with Cocoa/AppKit (document handling, system integration, etc). These concepts aren't as widely understood as the concepts in web-dev-land because they're implementation specific, but they're pretty well designed and genuinely very powerful once you use them.
Is there anything like this default app framework maintained for GTK or TCL or whatever the native KDE / GNOME framework is available for desktop Linux? I exclusively use Ubuntu as my OS for three computers, and I'm building out some front-ends for myself, and native desktop clients aren't cheap to make (in time and effort).
While it certainly works for me and serves as the basis for all of my apps, I don’t know yet if it will work well for others the way my PHP framework has over the years.
It will definitely work better for people if the source code isn't all tagged "All rights reserved", in conflict with the MIT license. :)
While it's confusing, "All rights reserved" isn't actually a license and doesn't conflict with MIT; it's effectively just a (now-redundant) part of the copyright notice. It's been redundant for a long time (since the Berne convention), but doesn't strictly speaking do any harm.
Tyler! I knew I recognized that name/company. I bought VirtualHostX eons ago and it helped me out a lot. This sounds like a great project, this guy makes good stuff.
I've been toying around with a macOS app idea for awhile. This looks like a great starting point for someone like me with no macOS native dev experience. Thanks!
I do the same.
I have my own for flask website setup with SQLite with user signups etc all configured. I also have some JavaScript SPA projects configured. I can clone the git repo and start doing something useful in a few minutes and all my scaffolding work is done.
While there are scaffolding tools already available sometimes those scaffolds are a bit too bare bones and you need to add some other common bits and pieces.
I have something similar I use in Visual Studio - it's a module file full of useful functions, that saves me rewriting the same code over and over again for each new app.
For example, I have GetFile() and SaveFile() functions which I use ALL the time, also as I'm on windows, I've wrapped up a bunch of Registry code into nice 'SaveRegValue' and 'GetRegValue' functions.
All in all there's about 50 or so functions in the module. Personally, I thought every coder did this?
Edit: I'm not dissing the OP, just surprised that there's value in sharing these things.
That seems to be a very different thing. You’re talking about a utils file / module you’re carrying around, OP is about a ready-made application template (à la cookicutter).
Did you read the article? It mentions "Two helper classes that make building a typical macOS source list easy." which is exactly what OP is talking about. So helpers classes, while not being all the project presented here, are an important part of it.
Native apps beat Electron/Web Apps anyday. There are many areas where Native apps have the upper hand w.r.t Electron.
Memory Usage
A few years ago while trying to figure out why I was running out of RAM, I stumbled upon chrome’s task manager. Gmail was using up 700MB of RAM and all I had open was the Inbox. No fancy search box or Compose, the Inbox was taking up 700MB of RAM to display lines of text in a Tabular format. I’ve been a heavy user of Email clients and if you pick any of the native clients (Thunderbird, Outlook, Apple Mail) and open a bunch of searches and compose windows the memory usage will still stay below 100MB. I used mIRC a few decades ago to connect to multiple chat servers, run my own bots, serve files over DCC and run scripts all while staying under 20MB of Ram. These days to send a text message over Slack I need over 1GB of RAM. Even basic apps with all of their trackers, external javascript scripts and doms take up 100s of MBs in memory. And the most common solution to running out of memory is to close chrome windows.
Battery/CPU Usage
DOM is slow. Updating layout and repainting is even slow. Javascript being a dynamic language is slow. Web apps are anything but simple these days and since they have to work under the limitations of all the slow components, the CPU ends up making up for it. Chrome is almost always present in my Macbook’s ‘Using significant energy’ tab. On the other hand, I rarely if ever see native apps in the battery bar unless I’m doing something which should actually consume a lot of CPU cycles like running multiple synths in Ableton or Compiling.
When apps are built for mobile, battery usage is a major area to optimize on. But nobody even gives it a thought for web apps
60 FPS
Mobile apps run on 60fps, Native desktop apps run at 60fps, Games run ( or at least are designed to) run at 60fps. Instagram on chrome starts at 2-3 fps and usually hovers around 30fps. My laptop which is supposed to be more powerful than my mobile phone is only able to churn out half the frame rate even though they are both running at the same resolution! Web apps are not buttery smooth and can be jerky at times. Sure somebody can work really hard and optimize a website to run at 60fps at all times, but it needs a lot of effort. Mobile apps run at 60fps out of the box without much effort.
Mobile and native apps use the GPU a lot more efficiently. Since they have a lot more information about which controls are being used, they can recycle items a lot better and do a much better job at hardware acceleration via the GPU. Not to mention that you have access to raw graphics APIs in case you want to push UI performance even further.
Runtime Environment
You can build desktop apps in a plethora of languages and even for mobile apps you have many cross-platform frameworks. But building for the web(and electron) forces you to HTML/Javascript(and derivates). Javascript is a dynamic prototypical language that was not designed for the scale of apps that are being built in it today. It has no type safety, memory leaks are common and it’s slow due to its dynamic nature. While there have been many efforts to improve performance like V8s JIT, it still lags behind a lot of major languages. WASM seems promising, but it’s still has a long way to go.
And it’s laughable how weak the browser platform itself is. SQLite is available on raspberry pi, embeddable systems, mobile platforms and just about every other platform on the planet. You can store data, run complex relational queries and do more with so less. But it is not available on the most widely used platform on the planet, the browser.
With the rise of electron apps, big and bulky web apps have started making their way onto the Desktop. There are some who are even trying to get the same apps on mobile via PWAs. While the web has the advantage of easy accessibility, IMO we have sacrificed too much in terms of user experience for that one convenience. If you built an app with the same UI and functionality in a native language and as a web app, the native app will run circles around it.
OP here. I think we're aiming for the same thing - though with slightly different priorities.
Of your list of minimums that DefaultApp omits:
Not every app adheres to a Document-based pattern. The apps I personally build typically fall into a "shoebox" style where explicit documents aren't used.
And there are other data layers than CoreData, which is why I didn't add that - especially since even with CoreData everyone has their own favorite library/framework. So that's easy enough to drop-in for those who want it. (That said: probably 95% of the apps I write use CoreData, so )
A customized NSToolbar would be great, but, again, there are so many implementations out there, which one would you pick that would satisfy the majority of apps/developers?
Anyway, like the accompanying blog post says, this project is "highly opinionated". It's just what I've cobbled together over the years. I'm not going to die on a hill for any of my particular choices. Do what works best for you.
I think the real sentiment I see in the comments about "using web tech instead of native is selfish/unethical/etc" is:
why isn't there a desktop technology that can compete with the ease of development as using web technology?
I feel this very much. I'm building a reeealy simple app and I'm looking at Svelte Native (Svelte + Nativescript) to get things going. But even that's not quite native. But Android and iOS development are also a mess.
In particular, this means that you can use React Native to build native macOS apps. You still get live reloading, hot code push, pleasant abstractions, etc. Most importantly, though, these apps can use straight-up AppKit controls on macOS and straight-up UIKit controls on iOS. Better still, you can use react-native-web to ship such projects on the web too.
You will+should, of course, have many platform-specific branches. But I find that the vast majority of my code is shared, and there's a _world_ of difference in being able to use the same development tools to ship polished software on desktop, mobile, and web.
My most recent project builds to macOS, iOS, Android, and web out of the same Typescript project. There was certainly some toolchain chicanery involved in this, but now that it's set up, it's delightful.
Many of the companies shipping Electron apps on desktop are shipping React Native apps on mobile. I would very much like to see React Native-based desktop apps replace Electron apps.