Hacker News Reader

Comment by h4il_s4t4n | Hacker News Reader

> 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.

View on HN

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.

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.

> 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.

> 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.

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.

> How many software applications from the 90s can you still use effectively on your laptop [...]

I run Windows, so most of them.

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

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

> 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..

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.

> 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.

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.

> 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.

> Luckily the users can decide for themselves what is unethical or not

Do we? I run Slack and Spotify, but it's not like I have a choice since there's no native version for Linux.

Exactly.

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.

VCScode has, as much, taken the place of Emacs and VI.

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.

> but until someone actually does that the onus is on you to prove that it in practice can be done.

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.

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.

> But I'm calling out slack specifically...

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

> My laptop has about 32 gigs of ram

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.

This is completely accurate.

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.

Electron is cancer.

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.

> 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.

There’s a difference between development and usability - the “janky” here refers to the end user experience, not yours a developer.

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.

Even VSCode does not feel like a native Mac app. It's a good app - but it does not feel like one written with the platform in mind.

What makes you say that?

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.

Which anywhere decent IDE does feel like a native Mac app?

XCode?

RemObjects Fire, too.

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.

XCode.

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).

Panic has done a great job, imo.

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.

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.

The difference is that custom platform widgets can get platform behaviors if the developers care enough, which they do.

> > 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).

I agree with most of your points, but there is still a lingering question, IMO:

Why isn't React-Native for desktop a thing yet?

I feel like it'd be the best of both worlds.

Something like that is being attempted with https://github.com/hecrj/iced

It is. There's react-native-windows by Microsoft.

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 know these projects exist, but it doesn't look like they're getting as much traction as the mobile version, unfortunately.

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.

Microsoft is rewriting react-native-windows from C# to C++.

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.

That's great to hear; I hope they get traction (and Lunix support) and become a viable alternative to Electron on the desktop.

You can already use React Native to deploy to macOS, via Catalyst. I'm doing it now.

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.

I've written and shipped complex web frontends since the ~IE6 days, and I've written and shipped native macOS applications in that time too.

I vastly, vastly prefer the native approach.

>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.

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.

Reply on news.ycombinator.com