DefaultApp
tyler.io
tyler.io
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.
And of course, because React Native can build to web, one could ship Electron apps for platforms with lower priority for your business.
Here's the most prominent issue I found that's tracking progress:
https://github.com/react-native-community/discussions-and-pr...
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
Indeed this sounds like a delightful way forward!
Edit: I wonder, what's the story with Linux native apps? Ah, mentioned in a sibling comment, React Native Desktop: https://github.com/status-im/react-native-desktop
Actually I prefer this future instead of a JS dominated world.
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.
It's okay if it's Mac only and many apps are.
Or they can do otherwise and they'll learn.
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...)
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.
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.
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?)
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.
The most important thing for a user is how pleasing it looks, not even how easy it is to use.
https://en.wikipedia.org/wiki/Aesthetic%E2%80%93usability_ef...
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.
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.
Visit a few sites listed here:
I also find lots of odd little programs in the music production category that are very individualistic in appearance.
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.
* 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 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.
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.
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.
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.
Visual Studio for Mac, better at least.
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.
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/).
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?).
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).
Panic has done a great job, imo.
VSCode and the Github App I think are fairly good examples of good UIs that don't use the default OS widget appearances.
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.
* 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.
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.
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.
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.
I run Windows, so most of them.
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
What happens to software written today in a year?
Wil it still run the same?
I don't think it will honestly
So you have to bundle electron, for every app
Sounds not very smart to me
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!"
Except everything requires a remote server nowadays which likely won't be there to "stand the test of time", so that point is moot..
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.
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.
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.
Do we? I run Slack and Spotify, but it's not like I have a choice since there's no native version for Linux.
> 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.
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.
An IDE? It still needs to catch up with Windows IDEs from the mid-90's, let alone what something like Visual Studio Professional is capable of.
It has been done, by a single developer, in their spare time: https://cancel.fm/ripcord/ .
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.
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.
[0] https://cancel.fm/ripcord/ [1] https://dev.cancel.fm/service_features [2] https://github.com/diamondburned/gtkcord3
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.
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.
> 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).
Same. It turns out that The DOM/HTML/CSS is a really powerful and flexible way to build UIs. Much better than any native widget framework.
Why isn't React-Native for desktop a thing yet?
I feel like it'd be the best of both worlds.
MacOS via react-native thanks to Catalyst.
A mature GTK RN fork would be nice, currently Electron is the only practical solution for Linux.
I'm working on a project that glues these technologies together: https://ult.dev/
I think the core React-Native team offering an "official" solution would go a long way here, and it's kind of sad that they didn't.
It's very active and they keep up-to-date with the upstream RN fork.
After the rewrite it will be merged into react-native. There's work already done there.
Catalyst opens up the doors for react-native to work on MacOS without many changes.
The last time I tried vue+electron was about two years ago:
https://gitlab.com/djsumdog/tagster
Over half, HALF of that code is electon boiler plate:
https://github.com/SimulatedGREG/electron-vue
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:
https://gitlab.com/djsumdog/mpvbuddy
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.
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.
I vastly, vastly prefer the native approach.
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.
Great job!
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.
https://twitter.com/ryanmcgrath/status/1238285152771440640
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.
Xcode just hides them away from you, is all.
Title should mention that it's about macOS though.
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 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.
Love this though.
using: webpack, babel, sass, auto-prefixer, eslint, chai, karma, mocha
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.
I'm wondering if you did.
> It mentions "Two helper classes that make building a typical macOS source list easy."
TFA goes much further than that, it's an actual working application in a box. You can copy the template, build it, and it runs.
A template can include utilities, not the other way around.
> So helpers classes, while not being all the project presented here, are an important part of it.
They're an important but relatively minor sub-set of the whole.
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.
A default app to me as a bare minimum involves:
• Custom Application class • URI specifications • Custom NSDocument • Custom window controller • Customized NSToolbar • CoreData support • “Feature” targets / I.e. Todo target
I’ve written a script which sets and generates all this for me:
macapp new —with-ui —styles
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.
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.
Definelty easier than making divs pretty with CSS spaghetti.