10 ms·

If you put every company that needs/has an app on a spectrum, there is a line somewhere that roughly divides them into two groups: where Electron/React Native/e

If you put every company that needs/has an app on a spectrum, there is a line somewhere that roughly divides them into two groups: where Electron/React Native/etc. makes sense or not. It's just a normal engineering decision: solving problems given limited resources. Companies have different problems and different resources. I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. There's some magical thinking borne from ignorance that everyone just ought to go native or that React Native is the best thing ever to be used everywhere or that AI makes this line disappear entirely. I think these takes serve little value and distract from what’s interesting, and what the subtitle to this article says: that this line is moving due to AI. And I think that’s probably right.

paxys 6d ago
And the “makes sense or not” part can change based on a bunch of factors. It’s actually pretty common for a new company to start fully native (only iOS, few features, limited scope), then switch ro react native/electron (need to support more surfaces, features are being developed too quickly), then back to fully native (can afford individual dev teams for each platform).
- embedding-shape 6d ago
  Yeah, massive parts of our community and ecosystem miss that something can be right today, and wrong tomorrow, and having to change along with your users and needs is OK. You'll never be able to anticipate what the business needs in the future, so stop pretending your software design can be done once and then just coast on that, because that's typically not how a software project should be run long-term or even medium-term.
  - collabs 6d ago
    In my experience it comes from the business and people who think if we need to touch the same code twice in the same month it is somehow a moral failing of some kind.
  - bluGill 6d ago
    The problem with tomorrow is sunk costs. There are many places I wish we had made a difference decision in the past - but we need to balance that with cost to make changes when what we have works okay.
    - rafaelmn 6d ago
      There's also a recency bias, where you ignore how valuable some decision was in the past and ignore the fact that you maybe wouldn't even get to the place you are if "you made a different decision in the past".
      - bluGill 6d ago
        I can't count how many times I've said "this is really bad, I it is worth rewriting to fix all the issues", only to discover that there were good reasons for all the past decisions and so we end up with the same mess as before - except that now I know what it must be that way. Not always, but very often people in the past had good reason for what they did.
        edoceo 6d ago
        Those are the comments that should persist in the code. I hate when the AI edits and removes my "why" comments. I want the refactor to make it less messy but keep why it's that kind of mess.
        bluGill 6d ago
        Too Soon often we thought those were obvious and didn't comment. Meanwhile there are detailed comments about things nobody cares about.
        tisdadd 6d ago
        I just put a comment in yesterday for this very reason - there was a flag I had set to false, and then looking at the library docs for something else thought maybe it should be true but that doesn't work how I would have implemented it if I had created the library and written the docs how I did. It is a very capable library, and when I first started using it the docs were more Oracle docs looking - but I could find what I wanted easily. Now, it is much more annoying to delve through but looks more modern.
- nfw2 6d ago
  The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync. I am very bullish on coding agents but would be wary of this turning into a mess.
  - nightpool 6d ago
    This is a great point that I wish the Shopify article went into in more depth! Would love to hear if they considered this
    - ninju 6d ago
      I believe they have a more in-depth posting that talks about it https://shopify.engineering/shop-app-migration https://shopify.engineering/shop-app-migration
      - canucker2016 6d ago
        The blog post doesn't mention the personnel-related challenges with having two native platform teams working on the app. The post DOES give more information as to why they looked at switching from React Native to native Platform APIs. React Native is forcing a major refactor of React Native apps in switching to the React Native "New Architecture" (see https://reactnative.dev/architecture/landing-page https://reactnative.dev/architecture/landing-page). So if Shopify had to do major refactors of all their React Native apps, maybe they could look at what it would take to go back to native Platform APIs. from https://shopify.engineering/shop-app-migration https://shopify.engineering/shop-app-migration For the Shop App, this coincided with our next major React Native investment: adopting the New Architecture. That work would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code. Before committing to this investment, we tested whether coding agents could help us build directly in SwiftUI and Jetpack Compose while keeping product behavior aligned across platforms. The result of that native platform APIs side project involving six devs converting the app's major user workflows? - startup time reduced: iOS by 23%, Android by 50% - crashes - 10x reduction - app size - iOS increased by 1MB (67MB -> 68MB), Android reduced by 109MB (37.2%) - build time - Android release build time fell ~75%. - runtime perf - Android builds could draw at 120fps while scrolling feed and switching screens
- whstl 6d ago
  Another factor is design. A lot of companies go to React Native, etc, because they want one single non-native design on both platforms. Which IMO can be a mistake most of the time, especially from the POV of a user.
  - moomoo11 5d ago
    most users can’t even use their phones properly it is always the nerds (i’m a nerd, but also run a company and led teams before at a unicorn that IPOd) who obsess over things that normal people would probably not even come to given 100 years case in point: even some of apples own apps don’t follow their design language. also some of the most popular apps in the world like tiktok or x don’t use ios glass. my bank app doesn’t use it and opts for a single theme across platforms. and you know what? i don’t give a fuck. i just want my money transferred properly, my memes consumed on demand, and that’s about it.
stickfigure 6d ago
These takes are also a bit premature. Wait until the new apps have rolled out and users are happy. Most likely this will work out fine, but big rewrites like this have a big enough chance of going off the rails that I wouldn't shout success from the rooftops just yet. I'm sure Digg engineering was proud of their rewrite too.
- Waterluvian 6d ago
  There’s risk to doing anything. There’s risk to doing nothing. A bit off topic but my perception is that organizations bias towards doing something more often than they should.
deleted 6d ago
[deleted]
wwalexander 6d ago
Using cross-platform web technology is absolutely a nuanced engineering decision that is the right one for many businesses. What is categorically bad is bundling a standalone browser runtime for every single service, wasting user’s storage and memory when you could just have a website in a browser. Is there any major browser now that doesn’t support saving websites as apps? Electron is simply a suboptimal and incorrect way of producing web apps.
- Waterluvian 6d ago
  Is everyone wrong, or is there more to it than you can see from where you stand? I don't want to spend much time on this comment so I risk not making a sufficient point, but something I notice is that you're appraising the situation from a purely technical point of view. The technical component is just one piece of what makes a whole product. I think Apple is probably a good example: they regularly make decisions that bother the hell out of tech-centered minds.
- user43928 6d ago
  That decision is easy: do users leave bad reviews for bundling a few hundred MB of Chromium? Do they leave bad reviews if your app malfunctions due to the system webview behaving differently than the Chromium version you tested with? Forget about saving websites as apps, no one does that. Not sure if it works on Desktop Safari, it certainly doesn't on iOS Safari. Not even persistent storage is offered for PWAs. Apple likes the billions in AppStore fees they rake in every quarter.
  - TheRealPomax 6d ago
    It's funny how folks can't even get that number right. Depending on how much you care to optimize, Electron adds 50 to 80 MB to your application. Those multi hundreds of megabyte apps? Yeah that's not because of electron, that's things like "we couldn't be bothered to actually think about the assets we bundled in". 100 uncompressed 16 bit PNG? Sure why not. 20MB worth of fonts because we don't like the built in ones and no we've never heard of subsetting? Let's go. 50MB worth of .json data files that we couldn't be bothered to gzip first? Who's going to notice! Electron is way bigger than an app needs to be, of course, but those giant apps that you hate, 250MB just for a health tracker? That's not electron being the problem.
kelnos 6d ago
> I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. I don't think that's necessarily true. Nuance is a thing. These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are). But that doesn't mean I can't understand or even agree with a company for using them. Building the same native application for more than one platform is expensive and time-consuming. Most of the time I'm happy to prefer an app built with a cross-platform framework vs. not having one at all. (To be fair, though, if there's a webapp, 90% of the time I'll prefer that over an Electron app. But nothing meets a well-built native app.)
- danisth 6d ago
  I think you contradicted yourself. If a tool provides better value for the time spent for a company, I don’t understand how you can call it objectively bad. You can say it’s objectively bad from a technical perspective, but clearly that’s only one part of the equation.
  - ToucanLoucan 6d ago
    It's objectively bad because of how hot my phone is. It's subjectively bad because it's an embarrassment. Like you're seriously going to tell me something like Discord, worth 15 BILLION, cannot afford native apps? Spare me.
    - 0cf8612b2e1e 6d ago
      What really grinds my gears is Microsoft replacing native apps with Electron. Trillion dollar company who is so cash strapped they have no choice but to punt to the easy development path.
      - ToucanLoucan 6d ago
        What's extra egregious there is I do understand the logic because developing for Windows is such a fucking nightmare, that they're also responsible for.
afavour 6d ago
Agreed. I felt the same way when a long time ago when Airbnb made a big deal of going back to native. For companies the size of Shopify and Airbnb that makes sense. But that doesn’t mean a small ten person startup should do the same thing.
deleted 6d ago
[deleted]
Aurornis 6d ago
> I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced. The slightly lighter version of this was having near-absolute convictions but leaving a tiny exception for extreme cases to try to demonstrate that you weren’t being unreasonable. These would usually follow trends when something would spread like a meme. Recent examples include “Everyone should use SQLite for everything” and the ironically closely related “Just use PostgreSQL for everything”. The typical pseudo-nuance would be “unless you have FAANG scale” to imply that there is no nuance until your user base includes most of the developed world.
- Waterluvian 6d ago
  Strong opinions considered harmful
  - weakfish 6d ago
    Strong opinions tightly held I try as hard as I can to have strong opinions, loosely held
  - Aurornis 6d ago
    Blind conviction without nuanced considered harmful.
- chasd00 6d ago
  > For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced this was every DBA in the late 90's and early 2000s when talking about their pet RDBMS. To me, it was a signal to avoid that person unless absolutely necessary.
mannyv 6d ago
Absolute opinions are simple and travel better on media. "The right tool for the job" is too complicated for a lot of people to understand. Tradeoffs? Tradeoffs require understanding. "XYZ is the best, just use it" is much easier, especially if you don't know how to make decisions and don't really care. Then you defend your non-decision by parroting what you read. I remember a product manager talking crap about Kafka years ago, and I started digging in as to why he didn't like it, and all of his reasons were marketing FUD from competitors. It was odd, his understanding of it was a Potemkin village. All tools presumably solve a problem. If you understand that envelope you can figure out if it works for you and your envelope.
ls-a 6d ago
[dead]
prisonguard 6d ago
its sad that the only reason warranting this switch is AI. I would have loved to see some performance benchmarks on some critical app flow.
sghiassy 6d ago
Well written and good perspective
Fr0styMatt88 6d ago
I think this is something we’ll see AI very meaningfully impact — the threshold needed for “Get this thing working on a tech stack we might not be familiar with” has gone waaaaaaay down.
- fishfasell 6d ago
  It's worrying to say the least. Today it's "get this working", tomorrow it's "can it also do XYZ?", next week it's "we have a 40% spike in crashes, you MUST resolve this IMMEDIATELY!" Meanwhile the devs are furiously asking AI how to fix it, every flavor of every model will give you a different diagnosis, GH Copilot will throw a million high/critical at you, and you still have no idea if it's fixed or not. It's the exact reason why you still need to know the languages you're using despite what leadership/product teams demand.
  - Fr0styMatt88 6d ago
    Yeah. It’s also far too tempting and far too easy to keep adding features if you don’t make yourself disciplined about it (which is okay if you’re in a position to control that, not so good if it’s the higher-ups demanding it).
doginasuit 5d ago
It is funny how the experience of finding a tool/platform that you love can be a little bit like joining a cult. You probably have experience using other things that were frustrating and this one seems like the answer. Each platform has its own tradeoffs and philosophies and embracing one can make the others seem backwards. Its also funny how reality sometimes validates or punishes these loyalties, and that is reaching a fever pitch in the era of LLMs. Platforms that offer familiarity at the expense of complex or inefficient framework will naturally lose ground when familiarity is no longer at a premium. It is a good thing, all of the hard parts are a little easier and it is less tempting to take the shortcut that you know has a dead end somewhere.

paxys 6d ago

And the “makes sense or not” part can change based on a bunch of factors. It’s actually pretty common for a new company to start fully native (only iOS, few features, limited scope), then switch ro react native/electron (need to support more surfaces, features are being developed too quickly), then back to fully native (can afford individual dev teams for each platform).

embedding-shape 6d ago
Yeah, massive parts of our community and ecosystem miss that something can be right today, and wrong tomorrow, and having to change along with your users and needs is OK. You'll never be able to anticipate what the business needs in the future, so stop pretending your software design can be done once and then just coast on that, because that's typically not how a software project should be run long-term or even medium-term.
- collabs 6d ago
  In my experience it comes from the business and people who think if we need to touch the same code twice in the same month it is somehow a moral failing of some kind.
- bluGill 6d ago
  The problem with tomorrow is sunk costs. There are many places I wish we had made a difference decision in the past - but we need to balance that with cost to make changes when what we have works okay.
  - rafaelmn 6d ago
    There's also a recency bias, where you ignore how valuable some decision was in the past and ignore the fact that you maybe wouldn't even get to the place you are if "you made a different decision in the past".
    - bluGill 6d ago
      I can't count how many times I've said "this is really bad, I it is worth rewriting to fix all the issues", only to discover that there were good reasons for all the past decisions and so we end up with the same mess as before - except that now I know what it must be that way. Not always, but very often people in the past had good reason for what they did.
      - edoceo 6d ago
        Those are the comments that should persist in the code. I hate when the AI edits and removes my "why" comments. I want the refactor to make it less messy but keep why it's that kind of mess.
        bluGill 6d ago
        Too Soon often we thought those were obvious and didn't comment. Meanwhile there are detailed comments about things nobody cares about.
        tisdadd 6d ago
        I just put a comment in yesterday for this very reason - there was a flag I had set to false, and then looking at the library docs for something else thought maybe it should be true but that doesn't work how I would have implemented it if I had created the library and written the docs how I did. It is a very capable library, and when I first started using it the docs were more Oracle docs looking - but I could find what I wanted easily. Now, it is much more annoying to delve through but looks more modern.
nfw2 6d ago
The main cost of two engineering teams shipping identical products in my opinion isn't the cost of those extra engineers, it is in the product and organizational challenges of keeping those two products that need to be identical in sync. I am very bullish on coding agents but would be wary of this turning into a mess.
- nightpool 6d ago
  This is a great point that I wish the Shopify article went into in more depth! Would love to hear if they considered this
  - ninju 6d ago
    I believe they have a more in-depth posting that talks about it https://shopify.engineering/shop-app-migration https://shopify.engineering/shop-app-migration
    - canucker2016 6d ago
      The blog post doesn't mention the personnel-related challenges with having two native platform teams working on the app. The post DOES give more information as to why they looked at switching from React Native to native Platform APIs. React Native is forcing a major refactor of React Native apps in switching to the React Native "New Architecture" (see https://reactnative.dev/architecture/landing-page https://reactnative.dev/architecture/landing-page). So if Shopify had to do major refactors of all their React Native apps, maybe they could look at what it would take to go back to native Platform APIs. from https://shopify.engineering/shop-app-migration https://shopify.engineering/shop-app-migration For the Shop App, this coincided with our next major React Native investment: adopting the New Architecture. That work would have required us to revisit native module integrations, rendering, and the boundaries between shared and platform-specific code. Before committing to this investment, we tested whether coding agents could help us build directly in SwiftUI and Jetpack Compose while keeping product behavior aligned across platforms. The result of that native platform APIs side project involving six devs converting the app's major user workflows? - startup time reduced: iOS by 23%, Android by 50% - crashes - 10x reduction - app size - iOS increased by 1MB (67MB -> 68MB), Android reduced by 109MB (37.2%) - build time - Android release build time fell ~75%. - runtime perf - Android builds could draw at 120fps while scrolling feed and switching screens
whstl 6d ago
Another factor is design. A lot of companies go to React Native, etc, because they want one single non-native design on both platforms. Which IMO can be a mistake most of the time, especially from the POV of a user.
- moomoo11 5d ago
  most users can’t even use their phones properly it is always the nerds (i’m a nerd, but also run a company and led teams before at a unicorn that IPOd) who obsess over things that normal people would probably not even come to given 100 years case in point: even some of apples own apps don’t follow their design language. also some of the most popular apps in the world like tiktok or x don’t use ios glass. my bank app doesn’t use it and opts for a single theme across platforms. and you know what? i don’t give a fuck. i just want my money transferred properly, my memes consumed on demand, and that’s about it.

stickfigure 6d ago

These takes are also a bit premature. Wait until the new apps have rolled out and users are happy. Most likely this will work out fine, but big rewrites like this have a big enough chance of going off the rails that I wouldn't shout success from the rooftops just yet. I'm sure Digg engineering was proud of their rewrite too.

Waterluvian 6d ago
There’s risk to doing anything. There’s risk to doing nothing. A bit off topic but my perception is that organizations bias towards doing something more often than they should.

deleted 6d ago

[deleted]

wwalexander 6d ago

Using cross-platform web technology is absolutely a nuanced engineering decision that is the right one for many businesses. What is categorically bad is bundling a standalone browser runtime for every single service, wasting user’s storage and memory when you could just have a website in a browser. Is there any major browser now that doesn’t support saving websites as apps? Electron is simply a suboptimal and incorrect way of producing web apps.

Waterluvian 6d ago
Is everyone wrong, or is there more to it than you can see from where you stand? I don't want to spend much time on this comment so I risk not making a sufficient point, but something I notice is that you're appraising the situation from a purely technical point of view. The technical component is just one piece of what makes a whole product. I think Apple is probably a good example: they regularly make decisions that bother the hell out of tech-centered minds.
user43928 6d ago
That decision is easy: do users leave bad reviews for bundling a few hundred MB of Chromium? Do they leave bad reviews if your app malfunctions due to the system webview behaving differently than the Chromium version you tested with? Forget about saving websites as apps, no one does that. Not sure if it works on Desktop Safari, it certainly doesn't on iOS Safari. Not even persistent storage is offered for PWAs. Apple likes the billions in AppStore fees they rake in every quarter.
- TheRealPomax 6d ago
  It's funny how folks can't even get that number right. Depending on how much you care to optimize, Electron adds 50 to 80 MB to your application. Those multi hundreds of megabyte apps? Yeah that's not because of electron, that's things like "we couldn't be bothered to actually think about the assets we bundled in". 100 uncompressed 16 bit PNG? Sure why not. 20MB worth of fonts because we don't like the built in ones and no we've never heard of subsetting? Let's go. 50MB worth of .json data files that we couldn't be bothered to gzip first? Who's going to notice! Electron is way bigger than an app needs to be, of course, but those giant apps that you hate, 250MB just for a health tracker? That's not electron being the problem.

kelnos 6d ago

> I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. I don't think that's necessarily true. Nuance is a thing. These tools are bad, objectively! They give inferior user experiences, and waste resources (ever more important now with RAM prices what they are). But that doesn't mean I can't understand or even agree with a company for using them. Building the same native application for more than one platform is expensive and time-consuming. Most of the time I'm happy to prefer an app built with a cross-platform framework vs. not having one at all. (To be fair, though, if there's a webapp, 90% of the time I'll prefer that over an Electron app. But nothing meets a well-built native app.)

danisth 6d ago
I think you contradicted yourself. If a tool provides better value for the time spent for a company, I don’t understand how you can call it objectively bad. You can say it’s objectively bad from a technical perspective, but clearly that’s only one part of the equation.
- ToucanLoucan 6d ago
  It's objectively bad because of how hot my phone is. It's subjectively bad because it's an embarrassment. Like you're seriously going to tell me something like Discord, worth 15 BILLION, cannot afford native apps? Spare me.
  - 0cf8612b2e1e 6d ago
    What really grinds my gears is Microsoft replacing native apps with Electron. Trillion dollar company who is so cash strapped they have no choice but to punt to the easy development path.
    - ToucanLoucan 6d ago
      What's extra egregious there is I do understand the logic because developing for Windows is such a fucking nightmare, that they're also responsible for.

afavour 6d ago

Agreed. I felt the same way when a long time ago when Airbnb made a big deal of going back to native. For companies the size of Shopify and Airbnb that makes sense. But that doesn’t mean a small ten person startup should do the same thing.

deleted 6d ago

[deleted]

Aurornis 6d ago

> I think people in the tech community have probably also noticed that it's rather popular to have an absolute opinion on the goodness or badness of these tools. For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced. The slightly lighter version of this was having near-absolute convictions but leaving a tiny exception for extreme cases to try to demonstrate that you weren’t being unreasonable. These would usually follow trends when something would spread like a meme. Recent examples include “Everyone should use SQLite for everything” and the ironically closely related “Just use PostgreSQL for everything”. The typical pseudo-nuance would be “unless you have FAANG scale” to imply that there is no nuance until your user base includes most of the developed world.

Waterluvian 6d ago
Strong opinions considered harmful
- weakfish 6d ago
  Strong opinions tightly held I try as hard as I can to have strong opinions, loosely held
- Aurornis 6d ago
  Blind conviction without nuanced considered harmful.
chasd00 6d ago
> For a while it seemed that having deeply held, nuance-free opinions about technologies was a sign of being wise and experienced this was every DBA in the late 90's and early 2000s when talking about their pet RDBMS. To me, it was a signal to avoid that person unless absolutely necessary.

mannyv 6d ago

Absolute opinions are simple and travel better on media. "The right tool for the job" is too complicated for a lot of people to understand. Tradeoffs? Tradeoffs require understanding. "XYZ is the best, just use it" is much easier, especially if you don't know how to make decisions and don't really care. Then you defend your non-decision by parroting what you read. I remember a product manager talking crap about Kafka years ago, and I started digging in as to why he didn't like it, and all of his reasons were marketing FUD from competitors. It was odd, his understanding of it was a Potemkin village. All tools presumably solve a problem. If you understand that envelope you can figure out if it works for you and your envelope.

ls-a 6d ago

[dead]

prisonguard 6d ago

its sad that the only reason warranting this switch is AI. I would have loved to see some performance benchmarks on some critical app flow.

sghiassy 6d ago

Well written and good perspective

Fr0styMatt88 6d ago

I think this is something we’ll see AI very meaningfully impact — the threshold needed for “Get this thing working on a tech stack we might not be familiar with” has gone waaaaaaay down.

fishfasell 6d ago
It's worrying to say the least. Today it's "get this working", tomorrow it's "can it also do XYZ?", next week it's "we have a 40% spike in crashes, you MUST resolve this IMMEDIATELY!" Meanwhile the devs are furiously asking AI how to fix it, every flavor of every model will give you a different diagnosis, GH Copilot will throw a million high/critical at you, and you still have no idea if it's fixed or not. It's the exact reason why you still need to know the languages you're using despite what leadership/product teams demand.
- Fr0styMatt88 6d ago
  Yeah. It’s also far too tempting and far too easy to keep adding features if you don’t make yourself disciplined about it (which is okay if you’re in a position to control that, not so good if it’s the higher-ups demanding it).

doginasuit 5d ago

It is funny how the experience of finding a tool/platform that you love can be a little bit like joining a cult. You probably have experience using other things that were frustrating and this one seems like the answer. Each platform has its own tradeoffs and philosophies and embracing one can make the others seem backwards. Its also funny how reality sometimes validates or punishes these loyalties, and that is reaching a fever pitch in the era of LLMs. Platforms that offer familiarity at the expense of complex or inefficient framework will naturally lose ground when familiarity is no longer at a premium. It is a good thing, all of the hard parts are a little easier and it is less tempting to take the shortcut that you know has a dead end somewhere.