5 ms·

Of course if a snappier UI came "for free" nobody would be mad about it. But how many people would actually switch chat apps because of it? Discord and Slack ar

by mjr00 3y ago

Of course if a snappier UI came "for free" nobody would be mad about it. But how many people would actually switch chat apps because of it? Discord and Slack are valued at $15b and $27b respectively; if you could get people to switch to a more efficient program written in native code, you'd become extremely wealthy.

dylan604 3y ago
WARNING: PERSONAL OPINIONS AHEAD!!! If you're a company with a $27b valuation releasing an Electron app, then you're just a shite company. How do you have any self respect at that point. I get being a small team without subject experts in native apps and just need to get something going. If you are a $27b valuation small company we might continue the is Electron still the right choice conversation. I'd also be very curios what your app is doing that a small team can operate it and still be valued so highly. Otherwise, you're just a shite company making shite decisions and have no self respect.
- HalcyonicStorm 3y ago
  While I agree with you in that we should have more native applications that are more conscious of how much resources they're using, making that transition from Electron to Native is probably not easy and riddled with pitfalls. Unless there's a standard path, how do you sell that to your superiors in the company in terms of opportunity cost?
- progmetaldev 3y ago
  Would they have gotten there if they started off native? Most definitely it would have taken longer to get to market. If they were to rewrite as a native app, then they would need to at least keep the same features their current user base are used to. Then you're going to start all over with new bugs being found.
  - dylan604 3y ago
    when slack started off, were they a $27b valuation company? no, they were smaller and yes, needed something to get to MVP for getting there. you're saying that after reaching the point of receiving a $27b valuation that they can not afford to hire subject matter experts into delivering a much better tool than the bloated PoC released as a product? seriously?
    - JohnFen 3y ago
      Sure, they could, but if they're making money on a substandard implementation, then why would they bother making a good one? This sort of thing is another example of our collective race to the bottom.
    - progmetaldev 3y ago
      One, a valuation is just that, a value of the company. Not the company holdings. Also, that doesn't address that a rewrite comes with stalled features (often), as well as new bugs introduced. How much of a business value is there in that rewrite? We're talking about a business. These are tools that are usually forced upon people by management, and if it works but is a little slow or taking large amounts of memory, management will either do nothing because they got a discount or upgrade machines. At the end of the day, for most it's "good enough". To be clear, I'm not saying that a developer culture shouldn't strive for this, but these are large businesses and are out for that dollar, and neither seem to be run by developers that would call for a rewrite.
      - dylan604 3y ago
        >and neither seem to be run by developers that would call for a rewrite. No, but they seem to be run UI people. They can justify doing a rewrite of the UI, but not the core? Not one person that I interact with using Slack appreciated the UI changes
        progmetaldev 3y ago
        In my experience, which may not be common, UI people tend to be more social than backend developers. In reality, and this is not a judgment as to what is right and wrong, but who is more readily able to push for change? Someone that is deep into the software, or someone who is closer to management and able to communicate more effectively (as far as socializing and building a rapport?). Again, I'm not saying it is right, I'm just going by the reality of how software works. This is a good reason for independent software developers to exist! I agree that there is huge business value in writing correct software that is performant, and gets the job done properly. I agree with you that Slack's UI could be improved drastically. The problem is that it's driven by money rather than productivity. I'm pretty sure you and I both agree on how software SHOULD be, but that is not how software actually is, and I don't think it will be until it gets out of the grips of large software developers, or we start to write for performance in an attempt to make software that is environmentally performant. I'm not sure if we ever get to the point where developers need to start worrying about performance for environmental purposes, that we'll survive if the performance impacts have been measured properly. I'm not trying to be depressing, but I just don't think that it would ever happen until it was too late. Maybe there would be a minority left of society to do this, but that would be building back society. Doomsday scenario. I don't think "we" are smart enough to deal with any catastrophic situation until it's too late.
  - manmal 3y ago
    They could just allow the iOS app to be used on macOS (Apple Silicon), I‘d happily use that. But for some reason, they don’t.
    - coldtea 3y ago
      Based on that their iOS app isn't just a shell for a web view?
    - Jtsummers 3y ago
      > But for some reason, they don't. It's not that complicated. That's a new-ish capability and was not an option when the apps being discussed chose Electron (for their desktop incarnations). It's also not applicable to all macOS systems (as you already noted) out there given that it requires M1-M3 Apple devices. They'd still need to support the older macOS systems while also working out the issues on newer systems. Or they could maintain one solution that works on both.
  - PH95VuimJjqBqy 3y ago
    MS just rewrote teams to move off of electron onto their own version of it (forget the name of it, it comes with windows nowadays).
- dasil003 3y ago
  If it makes you feel better to unilaterally condemn decision makers at big companies for not hewing to your priorities, then be my guest, it's a fun past-time. However if you're interested in why this happens you need to acknowledge there are legitimate tradeoffs between going full native and Electron at any scale. Specifically, feature/UI parity and speed of development is higher with Electron. Deciding to retool your whole engineering org to optimize for highly polished native apps is actually a pretty risky decision once you get into this position at scale, regardless of how much engineering cred it generates HN and other highly technical/UX focused circles.
  - JohnFen 3y ago
    This reads to me like "at a certain scale, it's too risky to develop an application that is actually good."
    - dasil003 3y ago
      Yes of course, if your reading comprehension is low and you prefer to apply your own personal black and white definition about what constitutes “good”, then it makes perfect sense for you to put these words in my mouth and ignore what I actually said.
      - JohnFen 3y ago
        Well, since I'm such a simpleton, perhaps you can ELI5. But rereading what you wrote, I do think that my paraphrase -- while certainly harsh -- is not inaccurate. You were pointing out, quite correctly, that choosing to use something like Electron is choosing a particular tradeoff. That tradeoff is to reduce development costs at the expense of product quality. I'm not saying that's always an inappropriate tradeoff, but we should at least be clear about what the tradeoff is actually about.
        dasil003 3y ago
        The keyword you missed is "retool". Completely rewriting your clients at scale as is always a big risk, it's especially risky when you're rewriting from one to many, and you need a much broader set of skills to boot. This specifically refers to overhauling the technical approach (see: Second System Effect), it doesn't preclude that a large company "develop an application that is actually good", in fact every company I've founded or work in has full native clients. On a more nuanced point, tradeoff is not strictly cost vs quality, it's also about velocity and consistency. The latter especially can have a huge impact on the perceived quality for common users, so the tradeoff is not as black and white as you want to make it.
- trobor 3y ago
  Electron is an established technology, offers acceptable performance for most users and doesn't - for the most part - require specific technical skills. You basically webdev with it and have a native looking app. Those could - but don't have to be - valid arguments for using it while still retaining self respect, e.g. making an informed choice on what is best for the project one is working on.
  - dylan604 3y ago
    Is app development only a 2 party system: native vs Electron? You seem to imply that it is. I disagree.
  - coldtea 3y ago
    >You basically webdev with it and have a native looking app. That's a description of the problem.
    - sockgrant 3y ago
      It’s also a description of why native wasn’t chosen from the get go. This thread is people who ship products vs people who ship engineering.
      - coldtea 3y ago
        This thread is people who ship BS products, that the rest of the population is then stuck with using, and which hold the practice decades back (not to mention being bad for the environment).
        deleted 3y ago
        [deleted]
  - deleted 3y ago
    [deleted]
  - alpaca128 3y ago
    > offers acceptable performance for most users Most users accept it because they have no better choice. If an app is terribly slow but a lot of online communities and friends use it, what are they gonna do, just not interact with others? You want to play recent Nintendo games but don't want to regularly replace the controllers due to an unfixed issue that affects roughly 50 million people and has a perfectly working solution for over 20 years? Too bad. But I guess Nintendo calls it acceptable for most users because it's not quite bad enough that people stop using a product they paid for.
- pixl97 3y ago
  Let's reverse the comparison.... How many companies have $27billion+ valuation and are not 'shite' software companies? I'm just wondering about this, because almost all the big companies I know write shite software... in fact it seems has nothing to do with how 'shite' your application is, but if it has the features the users want. Is there a reverse correlation? That if you're an investor you should shy away from companies writing 'non-shite' software because they aren't focusing on deliveries?
- justinclift 3y ago
  > How do you have any self respect at that point. Because they have CFOs and other bean counters at that point, and there's just no good way to convince those people to approve spinning up new teams (or reskilling the existing one) to rewrite the application "properly" across several platforms. It's like comparing "$$ for new feature development" (will move us forward) with "$$$$ for rewriting the application to be more efficient" (with uncertain benefits).
- DANmode 3y ago
  > How do you have any self respect at that point. Usually looking at their last paycheck. I don't personally agree with it, but, to some degree, this comment seems tone-deaf. People keep paying them to be so-so.

by mjr00 3y ago

dylan604 3y ago

WARNING: PERSONAL OPINIONS AHEAD!!! If you're a company with a $27b valuation releasing an Electron app, then you're just a shite company. How do you have any self respect at that point. I get being a small team without subject experts in native apps and just need to get something going. If you are a $27b valuation small company we might continue the is Electron still the right choice conversation. I'd also be very curios what your app is doing that a small team can operate it and still be valued so highly. Otherwise, you're just a shite company making shite decisions and have no self respect.

HalcyonicStorm 3y ago
While I agree with you in that we should have more native applications that are more conscious of how much resources they're using, making that transition from Electron to Native is probably not easy and riddled with pitfalls. Unless there's a standard path, how do you sell that to your superiors in the company in terms of opportunity cost?
progmetaldev 3y ago
Would they have gotten there if they started off native? Most definitely it would have taken longer to get to market. If they were to rewrite as a native app, then they would need to at least keep the same features their current user base are used to. Then you're going to start all over with new bugs being found.
- dylan604 3y ago
  when slack started off, were they a $27b valuation company? no, they were smaller and yes, needed something to get to MVP for getting there. you're saying that after reaching the point of receiving a $27b valuation that they can not afford to hire subject matter experts into delivering a much better tool than the bloated PoC released as a product? seriously?
  - JohnFen 3y ago
    Sure, they could, but if they're making money on a substandard implementation, then why would they bother making a good one? This sort of thing is another example of our collective race to the bottom.
  - progmetaldev 3y ago
    One, a valuation is just that, a value of the company. Not the company holdings. Also, that doesn't address that a rewrite comes with stalled features (often), as well as new bugs introduced. How much of a business value is there in that rewrite? We're talking about a business. These are tools that are usually forced upon people by management, and if it works but is a little slow or taking large amounts of memory, management will either do nothing because they got a discount or upgrade machines. At the end of the day, for most it's "good enough". To be clear, I'm not saying that a developer culture shouldn't strive for this, but these are large businesses and are out for that dollar, and neither seem to be run by developers that would call for a rewrite.
    - dylan604 3y ago
      >and neither seem to be run by developers that would call for a rewrite. No, but they seem to be run UI people. They can justify doing a rewrite of the UI, but not the core? Not one person that I interact with using Slack appreciated the UI changes
      - progmetaldev 3y ago
        In my experience, which may not be common, UI people tend to be more social than backend developers. In reality, and this is not a judgment as to what is right and wrong, but who is more readily able to push for change? Someone that is deep into the software, or someone who is closer to management and able to communicate more effectively (as far as socializing and building a rapport?). Again, I'm not saying it is right, I'm just going by the reality of how software works. This is a good reason for independent software developers to exist! I agree that there is huge business value in writing correct software that is performant, and gets the job done properly. I agree with you that Slack's UI could be improved drastically. The problem is that it's driven by money rather than productivity. I'm pretty sure you and I both agree on how software SHOULD be, but that is not how software actually is, and I don't think it will be until it gets out of the grips of large software developers, or we start to write for performance in an attempt to make software that is environmentally performant. I'm not sure if we ever get to the point where developers need to start worrying about performance for environmental purposes, that we'll survive if the performance impacts have been measured properly. I'm not trying to be depressing, but I just don't think that it would ever happen until it was too late. Maybe there would be a minority left of society to do this, but that would be building back society. Doomsday scenario. I don't think "we" are smart enough to deal with any catastrophic situation until it's too late.
- manmal 3y ago
  They could just allow the iOS app to be used on macOS (Apple Silicon), I‘d happily use that. But for some reason, they don’t.
  - coldtea 3y ago
    Based on that their iOS app isn't just a shell for a web view?
  - Jtsummers 3y ago
    > But for some reason, they don't. It's not that complicated. That's a new-ish capability and was not an option when the apps being discussed chose Electron (for their desktop incarnations). It's also not applicable to all macOS systems (as you already noted) out there given that it requires M1-M3 Apple devices. They'd still need to support the older macOS systems while also working out the issues on newer systems. Or they could maintain one solution that works on both.
- PH95VuimJjqBqy 3y ago
  MS just rewrote teams to move off of electron onto their own version of it (forget the name of it, it comes with windows nowadays).
dasil003 3y ago
If it makes you feel better to unilaterally condemn decision makers at big companies for not hewing to your priorities, then be my guest, it's a fun past-time. However if you're interested in why this happens you need to acknowledge there are legitimate tradeoffs between going full native and Electron at any scale. Specifically, feature/UI parity and speed of development is higher with Electron. Deciding to retool your whole engineering org to optimize for highly polished native apps is actually a pretty risky decision once you get into this position at scale, regardless of how much engineering cred it generates HN and other highly technical/UX focused circles.
- JohnFen 3y ago
  This reads to me like "at a certain scale, it's too risky to develop an application that is actually good."
  - dasil003 3y ago
    Yes of course, if your reading comprehension is low and you prefer to apply your own personal black and white definition about what constitutes “good”, then it makes perfect sense for you to put these words in my mouth and ignore what I actually said.
    - JohnFen 3y ago
      Well, since I'm such a simpleton, perhaps you can ELI5. But rereading what you wrote, I do think that my paraphrase -- while certainly harsh -- is not inaccurate. You were pointing out, quite correctly, that choosing to use something like Electron is choosing a particular tradeoff. That tradeoff is to reduce development costs at the expense of product quality. I'm not saying that's always an inappropriate tradeoff, but we should at least be clear about what the tradeoff is actually about.
      - dasil003 3y ago
        The keyword you missed is "retool". Completely rewriting your clients at scale as is always a big risk, it's especially risky when you're rewriting from one to many, and you need a much broader set of skills to boot. This specifically refers to overhauling the technical approach (see: Second System Effect), it doesn't preclude that a large company "develop an application that is actually good", in fact every company I've founded or work in has full native clients. On a more nuanced point, tradeoff is not strictly cost vs quality, it's also about velocity and consistency. The latter especially can have a huge impact on the perceived quality for common users, so the tradeoff is not as black and white as you want to make it.
trobor 3y ago
Electron is an established technology, offers acceptable performance for most users and doesn't - for the most part - require specific technical skills. You basically webdev with it and have a native looking app. Those could - but don't have to be - valid arguments for using it while still retaining self respect, e.g. making an informed choice on what is best for the project one is working on.
- dylan604 3y ago
  Is app development only a 2 party system: native vs Electron? You seem to imply that it is. I disagree.
- coldtea 3y ago
  >You basically webdev with it and have a native looking app. That's a description of the problem.
  - sockgrant 3y ago
    It’s also a description of why native wasn’t chosen from the get go. This thread is people who ship products vs people who ship engineering.
    - coldtea 3y ago
      This thread is people who ship BS products, that the rest of the population is then stuck with using, and which hold the practice decades back (not to mention being bad for the environment).
      - deleted 3y ago
        [deleted]
- deleted 3y ago
  [deleted]
- alpaca128 3y ago
  > offers acceptable performance for most users Most users accept it because they have no better choice. If an app is terribly slow but a lot of online communities and friends use it, what are they gonna do, just not interact with others? You want to play recent Nintendo games but don't want to regularly replace the controllers due to an unfixed issue that affects roughly 50 million people and has a perfectly working solution for over 20 years? Too bad. But I guess Nintendo calls it acceptable for most users because it's not quite bad enough that people stop using a product they paid for.
pixl97 3y ago
Let's reverse the comparison.... How many companies have $27billion+ valuation and are not 'shite' software companies? I'm just wondering about this, because almost all the big companies I know write shite software... in fact it seems has nothing to do with how 'shite' your application is, but if it has the features the users want. Is there a reverse correlation? That if you're an investor you should shy away from companies writing 'non-shite' software because they aren't focusing on deliveries?
justinclift 3y ago
> How do you have any self respect at that point. Because they have CFOs and other bean counters at that point, and there's just no good way to convince those people to approve spinning up new teams (or reskilling the existing one) to rewrite the application "properly" across several platforms. It's like comparing "$$ for new feature development" (will move us forward) with "$$$$ for rewriting the application to be more efficient" (with uncertain benefits).
DANmode 3y ago
> How do you have any self respect at that point. Usually looking at their last paycheck. I don't personally agree with it, but, to some degree, this comment seems tone-deaf. People keep paying them to be so-so.