7 ms·

The native side of this has long been addressed by cross-platform toolkits including but not limited to: Qt, GTK, FLTK, WxWidgets (note: all FLOSS, at least opt

The native side of this has long been addressed by cross-platform toolkits including but not limited to: Qt, GTK, FLTK, WxWidgets (note: all FLOSS, at least optionally). Alas, web development "decided" to completely reinvent the wheel for all this stuff, leading to a new generation of heading-to-native toolkits derived from browser-based technologies, such as Electron, React Native and Flutter. Unless you believe there is any mechanism to force a single cross-platform GUI toolkit on all developers - a belief that would make you basically insane - the reality is there will always be N different options for cross-platform development, depending on (a) which platforms you intend to cover (b) your own development history (c) subjective preferences (d) specific functionality that may be limited to specific toolkits. Does it matter if N is 10 instead of (say) 5 ? I don't know. Does it matter if the N is segmented into "derived from 90s widget models" versus "derived from 2010's web models" ? I don't know. Is there any chance of a single toolkit that covers native desktop environments (which continue to be important for creative apps, high performance apps, browsers etc.), native mobile and browser based apps? I don't know, but it seems ... unlikely.

scarface74 4y ago
The native side of things has been address very badly by cross platform tools. I don’t want lowest common denominator shitty cross platform apps.
- PaulDavisThe1st 4y ago
  So what do you want? "Highest common denominator" doesn't make much sense in this context - it's functionally equivalent to lowest common denominator. You want N different implementations, 1 per platform? You think the cross-platform toolkits could be better? Do you have an explanation for why they are not?
  - scarface74 4y ago
    I want native apps on my platform of choice that leverage the native capabilities of that platform. That’s the entire reason I chose one platform over the other. Mac users complained about Word 6 forever ago when MS tried to use a cross platform toolkit and Apple’s Windows app were just as bad.
    - PaulDavisThe1st 4y ago
      So you don't actually want cross-platform apps at all, but either single-platform apps, or apps developed independently for both platforms (because otherwise you're just talking about some in-house cross-platform toolkit).
      - scarface74 4y ago
        Why do I as a Mac user care about cross platform apps? Even as a long time Windows user, why would I care about cross platform apps? I chose a platform because the platform and the apps meet my set of priorities. As far as how that affects Linux users, even if I did prefer Linux as a developer platform, why make it my daily driver instead of running it in a VM or with something like WSL2?
        PaulDavisThe1st 4y ago
        Well, you're obviously welcome to do whatever you want, but I personally regard this as backwards. I believe in libre software, because I believe it is ultimately going to be better for users (over what timescale, I can't say for sure, but longer rather than shorter), and better for developers and better for technology. So I want to work on a libre platform, to some extent regardless of the applications I need/want to use, and thus I pick Linux first and apps second. When the app is not there (e.g. a DAW), I merely choose to spend a few decades of my life developing it, thus destroying my ability to do what I originally wanted to :) As for why would you prefer Linux as the daily driver, that would depend a lot on what you were doing/needed. It is a technically superior in almost every respect (not every, but close). It has better audio latency performance, should that matter, better bandwidth for most things, is generally more customizable to your own preferences (though obviously other platforms may be customizable enough). Upgrades and maintainance is generally simpler and smoother. I like being in control of my technology in a way that Microsoft and Apple increasingly do not allow me to be. I'm not saying that you have to care about any of that. I do, that's all.
        schrectacular 4y ago
  - klodolph 4y ago
    There are multiple explanations for why cross-platform toolkits are kind of awful. I'm treating "cross-platform toolkits are kind of awful" as an observation here, because I've used them, I've worked with them. And my measurement for awful is poor UX, relative to native apps. Different platforms are just slightly too different from each other to make it work well. So you end up with a bunch of cross-platform apps which are built on things like Electron. You more or less reject platform expectations for how apps should work, how they should look, or how they interact with other apps / other parts of the system. You end up with stuff like Spotify or Discord. Thing is--if I'm getting work done with this app, if I get paid for working with it, I'm going to pay for a better experience. Instead of using GIMP, I'll use Procreate, Photoshop, Pixelmator, whatever. Maybe I'll use Notepad++ or BBEdit. Maybe I'll buy Pro Tools despite its cost, or maybe I'll buy a Mac just so I can use Logic. It is costly to just reimplement your UI for multiple platforms, but that's where the "closed ecosystems" come in. React Native is kind of a compromise between the Qt-style approach (cross-platform UX) and the native approach. You're given a framework which works with multiple native toolkits, and you can have a mix of cross-platform UI code and platform-specific UI code.
    - PaulDavisThe1st 4y ago
      > It is costly to just reimplement your UI for multiple platforms, but that's where the "closed ecosystems" come in. React Native is kind of a compromise between the Qt-style approach (cross-platform UX) and the native approach. You're given a framework which works with multiple native toolkits, and you can have a mix of cross-platform UI code and platform-specific UI code. I don't understand this claim at all. Qt (or GTK) let's you "escape out" to the "native" toolkit on Windows or macOS as needed. There are not multiple "native toolkits" on Windows or macOS. > Different platforms are just slightly too different from each other to make it work well. So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position.
      - catiopatio 4y ago
        > So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position. Can you name a single cross-platform application that is indistinguishable from a native application?
  - culi 4y ago
    Look at WebGPU. Still a WIP, but it shows that you really CAN provide a performant cross-platform... platform if you're really thoughtful about performance
    - PaulDavisThe1st 4y ago
      WebGPU doesn't offer any facilities relevant to GUI development except a method of putting pixels on the screen. If you're suggesting WebGPU, you're really suggesting a drawing technology, not a GUI toolkit.
      - culi 4y ago
        No I didn't mean to imply its utilization for GUI development. I meant for it as an example of cross-platform technology that maintains good performance while being extremely cross-platform
        PaulDavisThe1st 4y ago
        Plenty of examples of that. I could name dozens outside the web space.
    - scarface74 4y ago
      And will it look and act like a native app? Will it support all of Apple’s built in accessibility affordances that a developer can get for free by using Apple’s native toolkits (and Microsoft’s)?
      - PaulDavisThe1st 4y ago
        a11y is definitely a critical and often overlooked issue. And this is one area where I find myself in 110% agreement with the title of TFA: Stop Building Closed Ecosystems. If the Apple and MS a11y frameworks were not so distinct from one another, wrapping them in a cross-platform layer would be much easier. But they couldn't be bothered, largely because they both have enough users whose priorities match your own: are the apps on the platform good enough for them. The incentives to standardize a11y at the API level across OS platforms is a tiny fraction of the incentive to standardize e.g. WebGPU.
- gjsman-1000 4y ago
  Then, on the other hand, you'll rarely see Linux ports. Lowest Common Denominator apps have been a blessing for Linux users - we would have never had Visual Studio Code, Slack, Postman, and who knows what else otherwise; and you can't tell me any of their developers would've done the work to port everything to GTK or Qt otherwise.
  - scarface74 4y ago
    Isn’t that a problem that Linux only has crappy cross platform apps that are not as good as native apps? Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps?
    - klodolph 4y ago
      I mean, it depends on how much time you're spending in great, polished native apps. For work, I spend all of my time in VS Code, Chrome, Slack, and the terminal. It's hard to justify any platform as being better if those are the apps you use, since they basically work the same on any platform. And then there are the people who spend day in, day out in programs like Photoshop, InDesign, Pro Tools, etc.
      - PaulDavisThe1st 4y ago
        At least two of the final three you mentioned run on Windows and macOS, meaning that somewhere there's a cross-platform layer for the GUI. And yet apparently, that works. There's a lesson there, though I'm not sure what it is.
        scarface74 4y ago
        Adobe and Microsoft both have spent 30 years optimizing their development around supporting both Macs and Windows. But how much of the GUI is actually cross platform? Adobe famously used Apple’s Carbon API and was very upset that it wasn’t ported to 64 bit. There is a lot of Cocoa in both products. Microsoft use to brag that they had more Mac developers than Apple did.
Devasta 4y ago
If quality mattered then maybe the other toolkits would have a chance, but no one is looking at the web for that, they are looking to the one advantage that the web has that the others cannot hope to beat: They work around bureaucrats. At least in the enterprise, with desktop applications you need to deal with IT security losers who freak out when you ask that computers actually have useful applications, and god help you if you need to get a port opened. Forget that, just shove everything down port 443 and download the application over and over again until the end of time.
- RodgerTheGreat 4y ago
  This is also one reason why users in corporate environments solve so many problems with Excel: it's a powerful, easy-to-use tool for making custom "applications" (within certain constraints) that is already installed on your work machine. No approval process, no procurement, no IT staff involvement; just users getting things done with what they have.
- ttttt444yeak 4y ago
  How did things end up this way? I'm massively frustrated by the stupidity of our security team and it gets worse each year. And I've tried to explain this stuff about web apps exactly like you just did but it never quite gets through, and when it does it gets a response like "well, we should probably find a way to restrict web apps as well". I know for a fact that none of the people doing systems administration that install this junk endpoint management software actually want to install it. And it's laughable that corporations can simultaneously claim to be implementing zero trust, while at the same time giving crowdstrike software more trust than anything ever had before everybody decided they wanted to chase buzzwords. It can take weeks for me to get a new hire set up with WSL right now. If I didn't like the people I work with I would have jumped ship a long time ago. Security teams have managed to threaten and bully their way into having more power than anybody else in IT. All the big stories about hacking is certainly part of it, but honestly I don't think that fully explains it. If I was a CIO paying an enormous amount of money for endpoint management and then saw something like solar winds happen, I'd probably have fired everybody on the security team that advocated those sorts of security strategies. In my mind, security is something that should happen deep in the backend and be handled mostly by programmers, DBAs, and the admins that handle application servers. Once the data has left those environments with somebody it shouldn't have you have already lost. No hacker has ever said "I breached the database, but then got stopped from exfiltrating data because somebody made it so the USB sticks don't work".
Waterluvian 4y ago
I don’t necessarily disagree with any of this. But the toolkits first listed are all pretty poor if you care about aesthetics and UX. It’s like making furniture with framing lumber and OSB. It’ll work fine and be durable. But it just always feels not great. They generally feel, to me, a semitone sharper than portability with 90s Java applications.
- PaulDavisThe1st 4y ago
  For some classes of applications, all the developers want is a 2D surface (call it a canvas if you like) to draw on and then they do everything else themselves. This leaves several notable areas of UI/UX to address: 1. menus 2. file browsers 3. text entry 4. notification/tray integration 5. window management These are where "the native experience" (i.e behaving according to guidelines or rules laid down by the platform controller) is really felt. Yet they have very little to do with the "interior" (in-window) behavior of the app at all, despite being critically important. If we're going to continue with the construction metaphor, I'd say it's more like creating a lovely house that has unusual door handles, windows that open in strange ways, and a different LED lighting temperature than you're used to.
  - Waterluvian 4y ago
    As you say, I think you’re right for many classes. But in other classes, apps are entirely widgets. I’m looking at the first Electron app in my quick bar: Spotify, and thinking about how to make it portable without being Web. It’s all widgets, no canvas. If you made it in any of the above it won’t feel Spotify it’ll feel Qt or whatnot. For Linux and FOSS types this is usually fine. It’s sure fine for me. But for the vast majority of users it isn’t. And I don’t think anyone wants to write the application natively thrice. When it comes to “mostly canvas” applications I find myself thinking about using game engines. They’re portable and basically that: a canvas with some basic UI support.
    - throwaway290 4y ago
      Downside of game engines is lacking accessibility, I think, are there any that don’t?
k__ 4y ago
Every now and then I meet a Qt dev who's whining about how Electron stole their lunch. If something like Electron stole your lunch, Qt obviously had serious problems.
- spion 4y ago
  There is still an opportunity for Qt to win in this area - they should make it really easy to create (well documented) bindings for new languages (that integrate with their runtimes)
- bombolo 4y ago
  Do you also meet chefs complain about how mcdonald takes work away?
hsn915 4y ago
> Unless you believe there is any mechanism to force a single cross-platform GUI toolkit on all developers - a belief that would make you basically insane - the reality is there will always be N different options for cross-platform development, depending on (a) which platforms you intend to cover (b) your own development history (c) subjective preferences (d) specific functionality that may be limited to specific toolkits. The problem is not forcing people to do this or use that. The problem is the quality and development experience is just _so bad_ that people are resorting to other options. Don't get me wrong, the dev experience for web is terrible, but it's still light years ahead of legacy toolkits like qt/gtk/etc.
- camgunz 4y ago
  I think they're roughly the same in terms of dev experience. Major toolkits have good bindings for dynamic languages like JS and Python so C++ isn't a barrier. I think mostly what happened was Electron's pitch of "turn your web app into a desktop app almost for free" meant that web devs could stick with React rather than learning wx or Qt. There were a lot of web devs and web companies so this meant a lot of Electron apps where once there might have been native apps.

scarface74 4y ago

The native side of things has been address very badly by cross platform tools. I don’t want lowest common denominator shitty cross platform apps.

PaulDavisThe1st 4y ago
So what do you want? "Highest common denominator" doesn't make much sense in this context - it's functionally equivalent to lowest common denominator. You want N different implementations, 1 per platform? You think the cross-platform toolkits could be better? Do you have an explanation for why they are not?
- scarface74 4y ago
  I want native apps on my platform of choice that leverage the native capabilities of that platform. That’s the entire reason I chose one platform over the other. Mac users complained about Word 6 forever ago when MS tried to use a cross platform toolkit and Apple’s Windows app were just as bad.
  - PaulDavisThe1st 4y ago
    So you don't actually want cross-platform apps at all, but either single-platform apps, or apps developed independently for both platforms (because otherwise you're just talking about some in-house cross-platform toolkit).
    - scarface74 4y ago
      Why do I as a Mac user care about cross platform apps? Even as a long time Windows user, why would I care about cross platform apps? I chose a platform because the platform and the apps meet my set of priorities. As far as how that affects Linux users, even if I did prefer Linux as a developer platform, why make it my daily driver instead of running it in a VM or with something like WSL2?
      - PaulDavisThe1st 4y ago
        Well, you're obviously welcome to do whatever you want, but I personally regard this as backwards. I believe in libre software, because I believe it is ultimately going to be better for users (over what timescale, I can't say for sure, but longer rather than shorter), and better for developers and better for technology. So I want to work on a libre platform, to some extent regardless of the applications I need/want to use, and thus I pick Linux first and apps second. When the app is not there (e.g. a DAW), I merely choose to spend a few decades of my life developing it, thus destroying my ability to do what I originally wanted to :) As for why would you prefer Linux as the daily driver, that would depend a lot on what you were doing/needed. It is a technically superior in almost every respect (not every, but close). It has better audio latency performance, should that matter, better bandwidth for most things, is generally more customizable to your own preferences (though obviously other platforms may be customizable enough). Upgrades and maintainance is generally simpler and smoother. I like being in control of my technology in a way that Microsoft and Apple increasingly do not allow me to be. I'm not saying that you have to care about any of that. I do, that's all.
        schrectacular 4y ago
- klodolph 4y ago
  There are multiple explanations for why cross-platform toolkits are kind of awful. I'm treating "cross-platform toolkits are kind of awful" as an observation here, because I've used them, I've worked with them. And my measurement for awful is poor UX, relative to native apps. Different platforms are just slightly too different from each other to make it work well. So you end up with a bunch of cross-platform apps which are built on things like Electron. You more or less reject platform expectations for how apps should work, how they should look, or how they interact with other apps / other parts of the system. You end up with stuff like Spotify or Discord. Thing is--if I'm getting work done with this app, if I get paid for working with it, I'm going to pay for a better experience. Instead of using GIMP, I'll use Procreate, Photoshop, Pixelmator, whatever. Maybe I'll use Notepad++ or BBEdit. Maybe I'll buy Pro Tools despite its cost, or maybe I'll buy a Mac just so I can use Logic. It is costly to just reimplement your UI for multiple platforms, but that's where the "closed ecosystems" come in. React Native is kind of a compromise between the Qt-style approach (cross-platform UX) and the native approach. You're given a framework which works with multiple native toolkits, and you can have a mix of cross-platform UI code and platform-specific UI code.
  - PaulDavisThe1st 4y ago
    > It is costly to just reimplement your UI for multiple platforms, but that's where the "closed ecosystems" come in. React Native is kind of a compromise between the Qt-style approach (cross-platform UX) and the native approach. You're given a framework which works with multiple native toolkits, and you can have a mix of cross-platform UI code and platform-specific UI code. I don't understand this claim at all. Qt (or GTK) let's you "escape out" to the "native" toolkit on Windows or macOS as needed. There are not multiple "native toolkits" on Windows or macOS. > Different platforms are just slightly too different from each other to make it work well. So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position.
    - catiopatio 4y ago
      > So basically, you're denying that it's possible to do excellent cross-platform apps at all. OK. I'm not sure I agree with that, but it's a position. Can you name a single cross-platform application that is indistinguishable from a native application?
- culi 4y ago
  Look at WebGPU. Still a WIP, but it shows that you really CAN provide a performant cross-platform... platform if you're really thoughtful about performance
  - PaulDavisThe1st 4y ago
    WebGPU doesn't offer any facilities relevant to GUI development except a method of putting pixels on the screen. If you're suggesting WebGPU, you're really suggesting a drawing technology, not a GUI toolkit.
    - culi 4y ago
      No I didn't mean to imply its utilization for GUI development. I meant for it as an example of cross-platform technology that maintains good performance while being extremely cross-platform
      - PaulDavisThe1st 4y ago
        Plenty of examples of that. I could name dozens outside the web space.
  - scarface74 4y ago
    And will it look and act like a native app? Will it support all of Apple’s built in accessibility affordances that a developer can get for free by using Apple’s native toolkits (and Microsoft’s)?
    - PaulDavisThe1st 4y ago
      a11y is definitely a critical and often overlooked issue. And this is one area where I find myself in 110% agreement with the title of TFA: Stop Building Closed Ecosystems. If the Apple and MS a11y frameworks were not so distinct from one another, wrapping them in a cross-platform layer would be much easier. But they couldn't be bothered, largely because they both have enough users whose priorities match your own: are the apps on the platform good enough for them. The incentives to standardize a11y at the API level across OS platforms is a tiny fraction of the incentive to standardize e.g. WebGPU.
gjsman-1000 4y ago
Then, on the other hand, you'll rarely see Linux ports. Lowest Common Denominator apps have been a blessing for Linux users - we would have never had Visual Studio Code, Slack, Postman, and who knows what else otherwise; and you can't tell me any of their developers would've done the work to port everything to GTK or Qt otherwise.
- scarface74 4y ago
  Isn’t that a problem that Linux only has crappy cross platform apps that are not as good as native apps? Why would I run a Linux box as my daily driver instead of a my Mac that is real Unix, has a 16 hour battery life and I can get great polished native apps?
  - klodolph 4y ago
    I mean, it depends on how much time you're spending in great, polished native apps. For work, I spend all of my time in VS Code, Chrome, Slack, and the terminal. It's hard to justify any platform as being better if those are the apps you use, since they basically work the same on any platform. And then there are the people who spend day in, day out in programs like Photoshop, InDesign, Pro Tools, etc.
    - PaulDavisThe1st 4y ago
      At least two of the final three you mentioned run on Windows and macOS, meaning that somewhere there's a cross-platform layer for the GUI. And yet apparently, that works. There's a lesson there, though I'm not sure what it is.
      - scarface74 4y ago
        Adobe and Microsoft both have spent 30 years optimizing their development around supporting both Macs and Windows. But how much of the GUI is actually cross platform? Adobe famously used Apple’s Carbon API and was very upset that it wasn’t ported to 64 bit. There is a lot of Cocoa in both products. Microsoft use to brag that they had more Mac developers than Apple did.

Devasta 4y ago

If quality mattered then maybe the other toolkits would have a chance, but no one is looking at the web for that, they are looking to the one advantage that the web has that the others cannot hope to beat: They work around bureaucrats. At least in the enterprise, with desktop applications you need to deal with IT security losers who freak out when you ask that computers actually have useful applications, and god help you if you need to get a port opened. Forget that, just shove everything down port 443 and download the application over and over again until the end of time.

RodgerTheGreat 4y ago
This is also one reason why users in corporate environments solve so many problems with Excel: it's a powerful, easy-to-use tool for making custom "applications" (within certain constraints) that is already installed on your work machine. No approval process, no procurement, no IT staff involvement; just users getting things done with what they have.
ttttt444yeak 4y ago
How did things end up this way? I'm massively frustrated by the stupidity of our security team and it gets worse each year. And I've tried to explain this stuff about web apps exactly like you just did but it never quite gets through, and when it does it gets a response like "well, we should probably find a way to restrict web apps as well". I know for a fact that none of the people doing systems administration that install this junk endpoint management software actually want to install it. And it's laughable that corporations can simultaneously claim to be implementing zero trust, while at the same time giving crowdstrike software more trust than anything ever had before everybody decided they wanted to chase buzzwords. It can take weeks for me to get a new hire set up with WSL right now. If I didn't like the people I work with I would have jumped ship a long time ago. Security teams have managed to threaten and bully their way into having more power than anybody else in IT. All the big stories about hacking is certainly part of it, but honestly I don't think that fully explains it. If I was a CIO paying an enormous amount of money for endpoint management and then saw something like solar winds happen, I'd probably have fired everybody on the security team that advocated those sorts of security strategies. In my mind, security is something that should happen deep in the backend and be handled mostly by programmers, DBAs, and the admins that handle application servers. Once the data has left those environments with somebody it shouldn't have you have already lost. No hacker has ever said "I breached the database, but then got stopped from exfiltrating data because somebody made it so the USB sticks don't work".

Waterluvian 4y ago

I don’t necessarily disagree with any of this. But the toolkits first listed are all pretty poor if you care about aesthetics and UX. It’s like making furniture with framing lumber and OSB. It’ll work fine and be durable. But it just always feels not great. They generally feel, to me, a semitone sharper than portability with 90s Java applications.

PaulDavisThe1st 4y ago
For some classes of applications, all the developers want is a 2D surface (call it a canvas if you like) to draw on and then they do everything else themselves. This leaves several notable areas of UI/UX to address: 1. menus 2. file browsers 3. text entry 4. notification/tray integration 5. window management These are where "the native experience" (i.e behaving according to guidelines or rules laid down by the platform controller) is really felt. Yet they have very little to do with the "interior" (in-window) behavior of the app at all, despite being critically important. If we're going to continue with the construction metaphor, I'd say it's more like creating a lovely house that has unusual door handles, windows that open in strange ways, and a different LED lighting temperature than you're used to.
- Waterluvian 4y ago
  As you say, I think you’re right for many classes. But in other classes, apps are entirely widgets. I’m looking at the first Electron app in my quick bar: Spotify, and thinking about how to make it portable without being Web. It’s all widgets, no canvas. If you made it in any of the above it won’t feel Spotify it’ll feel Qt or whatnot. For Linux and FOSS types this is usually fine. It’s sure fine for me. But for the vast majority of users it isn’t. And I don’t think anyone wants to write the application natively thrice. When it comes to “mostly canvas” applications I find myself thinking about using game engines. They’re portable and basically that: a canvas with some basic UI support.
  - throwaway290 4y ago
    Downside of game engines is lacking accessibility, I think, are there any that don’t?

k__ 4y ago

Every now and then I meet a Qt dev who's whining about how Electron stole their lunch. If something like Electron stole your lunch, Qt obviously had serious problems.

spion 4y ago
There is still an opportunity for Qt to win in this area - they should make it really easy to create (well documented) bindings for new languages (that integrate with their runtimes)
bombolo 4y ago
Do you also meet chefs complain about how mcdonald takes work away?

hsn915 4y ago

> Unless you believe there is any mechanism to force a single cross-platform GUI toolkit on all developers - a belief that would make you basically insane - the reality is there will always be N different options for cross-platform development, depending on (a) which platforms you intend to cover (b) your own development history (c) subjective preferences (d) specific functionality that may be limited to specific toolkits. The problem is not forcing people to do this or use that. The problem is the quality and development experience is just _so bad_ that people are resorting to other options. Don't get me wrong, the dev experience for web is terrible, but it's still light years ahead of legacy toolkits like qt/gtk/etc.

camgunz 4y ago
I think they're roughly the same in terms of dev experience. Major toolkits have good bindings for dynamic languages like JS and Python so C++ isn't a barrier. I think mostly what happened was Electron's pitch of "turn your web app into a desktop app almost for free" meant that web devs could stick with React rather than learning wx or Qt. There were a lot of web devs and web companies so this meant a lot of Electron apps where once there might have been native apps.