8 ms·

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

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

ojame 7y ago
There’s a difference between development and usability - the “janky” here refers to the end user experience, not yours a developer.
- frosted-flakes 7y ago
  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.
  - vintagedave 7y ago
    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.
    - apatheticonion 7y ago
      What makes you say that?
      - vintagedave 7y ago
        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.
        snazz 7y ago
        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.
        deleted 7y ago
        [deleted]
        _jal 7y ago
        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.
    - solarkraft 7y ago
      Which anywhere decent IDE does feel like a native Mac app?
      - leadingthenet 7y ago
        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/ https://panic.com/nova/).
        Cyberdog 7y ago
        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?).
        leadingthenet 7y ago
        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.
      - gbear605 7y ago
        XCode?
        vintagedave 7y ago
        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.
    - moooo99 7y ago
      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.
    - madeofpalk 7y ago
      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.
      - saagarjha 7y ago
        The difference is that custom platform widgets can get platform behaviors if the developers care enough, which they do.
vintagedave 7y ago
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.
- cultofmetatron 7y ago
  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.
  - ivanfon 7y ago
    > 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/ https://cancel.fm/ripcord/ [1] https://dev.cancel.fm/service_features https://dev.cancel.fm/service_features [2] https://github.com/diamondburned/gtkcord3 https://github.com/diamondburned/gtkcord3
endorphone 7y ago
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.
- deleted 7y ago
  [deleted]
zeveb 7y ago
> > 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).
macspoofing 7y ago
>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.
emilecantin 7y ago
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.
- anchpop 7y ago
  Something like that is being attempted with https://github.com/hecrj/iced https://github.com/hecrj/iced
- s_y_n_t_a_x 7y ago
  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/ https://ult.dev/
  - emilecantin 7y ago
    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.
    - s_y_n_t_a_x 7y ago
      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.
      - emilecantin 7y ago
        That's great to hear; I hope they get traction (and Lunix support) and become a viable alternative to Electron on the desktop.
deleted 7y ago
[deleted]
djsumdog 7y ago
Electron is cancer. The last time I tried vue+electron was about two years ago: https://gitlab.com/djsumdog/tagster https://gitlab.com/djsumdog/tagster Over half, HALF of that code is electon boiler plate: https://github.com/SimulatedGREG/electron-vue 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 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.
lucideer 7y ago
> 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.
Klonoar 7y ago
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.

ojame 7y ago

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

frosted-flakes 7y ago
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.
- vintagedave 7y ago
  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.
  - apatheticonion 7y ago
    What makes you say that?
    - vintagedave 7y ago
      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.
      - snazz 7y ago
        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.
        deleted 7y ago
        [deleted]
        _jal 7y ago
        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.
  - solarkraft 7y ago
    Which anywhere decent IDE does feel like a native Mac app?
    - leadingthenet 7y ago
      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/ https://panic.com/nova/).
      - Cyberdog 7y ago
        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?).
        leadingthenet 7y ago
        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.
    - gbear605 7y ago
      XCode?
      - vintagedave 7y ago
        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.
  - moooo99 7y ago
    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.
  - madeofpalk 7y ago
    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.
    - saagarjha 7y ago
      The difference is that custom platform widgets can get platform behaviors if the developers care enough, which they do.

vintagedave 7y ago

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.

cultofmetatron 7y ago
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.
- ivanfon 7y ago
  > 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/ https://cancel.fm/ripcord/ [1] https://dev.cancel.fm/service_features https://dev.cancel.fm/service_features [2] https://github.com/diamondburned/gtkcord3 https://github.com/diamondburned/gtkcord3

endorphone 7y ago

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.

deleted 7y ago
[deleted]

zeveb 7y ago

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

macspoofing 7y ago

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

emilecantin 7y ago

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.

anchpop 7y ago
Something like that is being attempted with https://github.com/hecrj/iced https://github.com/hecrj/iced
s_y_n_t_a_x 7y ago
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/ https://ult.dev/
- emilecantin 7y ago
  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.
  - s_y_n_t_a_x 7y ago
    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.
    - emilecantin 7y ago
      That's great to hear; I hope they get traction (and Lunix support) and become a viable alternative to Electron on the desktop.

deleted 7y ago

[deleted]

djsumdog 7y ago

Electron is cancer. The last time I tried vue+electron was about two years ago: https://gitlab.com/djsumdog/tagster https://gitlab.com/djsumdog/tagster Over half, HALF of that code is electon boiler plate: https://github.com/SimulatedGREG/electron-vue 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 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.

lucideer 7y ago

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

Klonoar 7y ago

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.