3 ms·

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.

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.
progmetaldev 3y ago
I'm in complete agreement here. These are businesses, and are not run by development teams. Sure, the developers could leave because they don't believe in the ethics of the business, but they they are going to get more Electron developers. For most people, the software is "good enough." That doesn't mean that it's engineered in the best way possible. That just means that the business concentrates on other concerns (some simply about gaining more market share and profit). I'm always in pursuit to write the best quality code that I can, with performance in mind. I also work for a small software company where I have that luxury, and also the drive to practice outside of my salaried hours (because I enjoy it, not because I feel I need to). I would feel terrible if my clients were complaining about slow performance, and I would find a solution that works within my constraints of having other client work to perform. Not having to support thousands or millions of users with my software makes it a lot easier to work on a rewrite than needing to worry about every operating system and configuration that is out there, along with new bug reports that need to be addressed.

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.

progmetaldev 3y ago

I'm in complete agreement here. These are businesses, and are not run by development teams. Sure, the developers could leave because they don't believe in the ethics of the business, but they they are going to get more Electron developers. For most people, the software is "good enough." That doesn't mean that it's engineered in the best way possible. That just means that the business concentrates on other concerns (some simply about gaining more market share and profit). I'm always in pursuit to write the best quality code that I can, with performance in mind. I also work for a small software company where I have that luxury, and also the drive to practice outside of my salaried hours (because I enjoy it, not because I feel I need to). I would feel terrible if my clients were complaining about slow performance, and I would find a solution that works within my constraints of having other client work to perform. Not having to support thousands or millions of users with my software makes it a lot easier to work on a rewrite than needing to worry about every operating system and configuration that is out there, along with new bug reports that need to be addressed.