4 ms·

Worse for users than nothing? IT shouldn't be a default, but if it's that or nothing-- as it often is when it comes down to limited resources-- I think it's bet

Worse for users than nothing? IT shouldn't be a default, but if it's that or nothing-- as it often is when it comes down to limited resources-- I think it's better than nothing. If you're looking to make a useful tool for a broad audience that must run locally, you have to support windows because that's where 80% of the users are. You should support OSX because that's where 15% of the users are. That's two codebases with dramatically diminishing returns. You need a damn good reason to justify adding ANOTHER codebase on there to scoop up the remaining handful of users on Linux. Also, aside from startup time, I don't have any trouble with electron apps running slow on my machines. I think many developers are conceptually annoyed with the absurd, bloated architectural underpinnings rather than the experience that translates into when using them. Perception means a lot when judging performance, and I'll bet with most end users using, say, slack, the speed of their internet connection affects the speed of their work more than the speed of the application.

prmoustache 3y ago
Your postulate that it is electron or nothing is wrong from the very start.
- chefandy 3y ago
  You postulate that I said that, which is wrong. > IT shouldn't be a default, but if it's that or nothing-- as it often is when it comes down to limited resources-- I think it's better than nothing. Sometimes it is. Sometimes it's not. It's certainly an option that's very efficient for dev resources, which is often the primary limiting factor. It's certainly the only real option if you've already got a team of web developers, which is very common. The current state of commercial software supporting linux with native apps is a pretty good indicator of how companies are viewing this equation. The amount of resources it takes to make a native java app is vastly different than the amount of resources it takes to make a native electron app. If you don't understand how that would be something that would open the possibility of supporting linux in many cases, I'm not sure what to tell you.
  - zlg_codes 3y ago
    Look, business is about maximizing profits and minimizing costs. Business should absolutely not be looked to as an example of an entity that makes sane or suitable tech decisions over the long term. Their goals are different from everyday users, and both are different from power users and programmers. Why should normies suffer through worse software than those that know what they're doing? Web-based "native apps" are that worse thing.
    - chefandy 3y ago
      Reread what I wrote. I'm not saying they're sane technical decisions and I'm definitely not saying that electron is an objectively good architecture for user-facing apps, and I'm definitely not saying that profit is a good way to determine an ideal engineering strategy. But trying to discuss the viability of an option in real-word software creation without acknowledging that profits are often the driving factor in these decisions means you're not really discussing it.
      - zlg_codes 3y ago
        Part of that is because profit should not take precedence when making a technical decision unless you are a business. The other part is that if we accept only things that lead to easy profit, we'll avoid all sorts of things that take more initiative but become better products. Short-term stock price chasing is not a way to make tech decisions. It's a way to make profit decisions. I seem to be on a website where nobody can picture doing anything without taking money from someone else.
        chefandy 3y ago
        I'm betting you haven't actually had to make decisions like this in a role where you were responsible for getting the most out of a limited set of resources. It doesn't even have to be commercial: even in well-funded non-profits that I worked with, maximizing the impact of your work is more important than maximizing the quality. If we were talking about shaving 5% off labor costs to put the extra trim on the shareholders' Lamborghinis, that's one thing. If good-enough quality will make triple the impact per grant dollar spent, the correct answer is pretty clear. If technical purity means the project isn't feasible with the allotted budget, it's even clearer. It's about how much you can do with the amount you have. Nobody who gives you money to promote childhood STEM education is going to care how much more technically correct your solution is if you run out of money before you can ship, and they certainly aren't going to give their new cancer-research grant a haircut because you wanted to save on end-users' ram usage. Using the existing giant labor pool of web developers to make an electron application isn't just a little less resource intensive than making a Java application for nearly any purpose-- it's vastly less resource intensive. That's just plain old reality. I'm not saying it's good, or worth praising; it's just the way our world works outside of volunteer-driven FOSS. When I got paid by a nonprofit to work on MIT-Licensed FOSS full-time for years, these questions were as important as anywhere else where resources aren't free. If I had my choice, I'd have chosen Elixir and Phoenix to do many of our web projects because BEAM had built-in tools to solve a lot of the odd architectural problems we had. But if you suddenly had to hire a few Elixir developers to do something that would work fine with Node.js, just not as elegantly, that grant isn't going to get any bigger just because I'm making sound technical decisions. At the end of the day, your software is valuable for what it does for people-- not what it is. And really, how much does using electron limit the actual utility of the tool itself among people with limited compute resources? I don't mean what's the difference in the memory footprint, I mean how often are people unable to solve their problem using an electron app because their computer can't run it? You obviously don't need bleeding edge hardware to run an electron application as hyperbolically suggested-- it's not much different from using, well, Chrome. Projects that work with really really under-resourced populations, such as the houseless, don't make desktop applications anyway-- one that I can think of off-the-top of my head used SMS because it was so much more readily available than a computer you can install an app on. Developers like to focus on things like memory and compute resources because they know how to address them. Hammers looking for nails. But if you really dig into users' biggest frustrations with software, as I have in my interface design work, performance is almost never mentioned. When it is, they're almost exclusively dealing with shitty internet access, not slow local application execution. If FOSS projects wanted to do more good in the world rather than having a hobby project to nerd out about, they'd actively solicit designers to figure out what problems real users are actually running into trying to solve their problems rather than just assuming the solution is more technical correctness. They could be one of the few volunteer-driven FOSS projects isn't solely usable by people who already have a working mental model of software development.
zlg_codes 3y ago
I'm really not swayed by "we must use this turd because the alternative is nothing". "Nothing", to me, is a technical challenge and a sign I should probably start writing the thing myself. Yes, not everyone has the skill or time to do that, but it's also no reason to accept half-baked solutions that don't take the user's system resources into account. Compute may be cheap but it's still a resource we need to use wisely. Not everyone is running a system like the developer's Macbook Pros on 5GHz wifi hooked up to fiber.
- chefandy 3y ago
  If you only care about the best technical solution, and don't care about economics, then you almost, by definition, only care about what existing FOSS users are doing, and I don't find that scope limitation useful in any way. I love FOSS. I've been a regular contributor to FOSS for decades. But the impact user-facing FOSS apps have on the overwhelming majority of users is miniscule, as is the comparative number of regular FOSS users. Server apps? Apps developers use to make the apps everyone else uses? Absolutely. A music player? A chat app? Nope. Software that makes a visible impression on users is commercial. That's just reality. And companies that don't consider ROI on the products they create aren't companies very long. The most popular as-is FOSS app for users is probably Firefox with a browser market share neck-and-neck with Opera and Samsung Internet, and everything less popular might as well not exist among probably 99% of users. Why? It's certainly not performance, I assure you. It's because it's poorly designed and users find it infuriating to use. Sure, you can find people complaining about their bloated slack client being slow on their machine. You think that's bad, find a professional photographer and ask them about the one time they tried to use Gimp. I spend a lot of time talking about how FOSS could be a lot more usable to end users, and technical supremacy isn't it. If you showed your average end user an electron app with an intuitive, professional design that gets the job done well enough, and then you show them the blazing fast linux native version with a typically awkward homespun interface, I will eat my hat if they don't choose the electron version. Sure, in a perfect world, all tools would be forged specifically for their intended purpose. In reality, you are in a miniscule percentage of people that would rather have nothing than something which doesn't perform optimally because of it's bonkers architecture. But if you actually want to maximize the usability of any giving tool, the only reason developers automatically go to performance is because to a hammer, everything looks like a nail.

prmoustache 3y ago

Your postulate that it is electron or nothing is wrong from the very start.

chefandy 3y ago
You postulate that I said that, which is wrong. > IT shouldn't be a default, but if it's that or nothing-- as it often is when it comes down to limited resources-- I think it's better than nothing. Sometimes it is. Sometimes it's not. It's certainly an option that's very efficient for dev resources, which is often the primary limiting factor. It's certainly the only real option if you've already got a team of web developers, which is very common. The current state of commercial software supporting linux with native apps is a pretty good indicator of how companies are viewing this equation. The amount of resources it takes to make a native java app is vastly different than the amount of resources it takes to make a native electron app. If you don't understand how that would be something that would open the possibility of supporting linux in many cases, I'm not sure what to tell you.
- zlg_codes 3y ago
  Look, business is about maximizing profits and minimizing costs. Business should absolutely not be looked to as an example of an entity that makes sane or suitable tech decisions over the long term. Their goals are different from everyday users, and both are different from power users and programmers. Why should normies suffer through worse software than those that know what they're doing? Web-based "native apps" are that worse thing.
  - chefandy 3y ago
    Reread what I wrote. I'm not saying they're sane technical decisions and I'm definitely not saying that electron is an objectively good architecture for user-facing apps, and I'm definitely not saying that profit is a good way to determine an ideal engineering strategy. But trying to discuss the viability of an option in real-word software creation without acknowledging that profits are often the driving factor in these decisions means you're not really discussing it.
    - zlg_codes 3y ago
      Part of that is because profit should not take precedence when making a technical decision unless you are a business. The other part is that if we accept only things that lead to easy profit, we'll avoid all sorts of things that take more initiative but become better products. Short-term stock price chasing is not a way to make tech decisions. It's a way to make profit decisions. I seem to be on a website where nobody can picture doing anything without taking money from someone else.
      - chefandy 3y ago
        I'm betting you haven't actually had to make decisions like this in a role where you were responsible for getting the most out of a limited set of resources. It doesn't even have to be commercial: even in well-funded non-profits that I worked with, maximizing the impact of your work is more important than maximizing the quality. If we were talking about shaving 5% off labor costs to put the extra trim on the shareholders' Lamborghinis, that's one thing. If good-enough quality will make triple the impact per grant dollar spent, the correct answer is pretty clear. If technical purity means the project isn't feasible with the allotted budget, it's even clearer. It's about how much you can do with the amount you have. Nobody who gives you money to promote childhood STEM education is going to care how much more technically correct your solution is if you run out of money before you can ship, and they certainly aren't going to give their new cancer-research grant a haircut because you wanted to save on end-users' ram usage. Using the existing giant labor pool of web developers to make an electron application isn't just a little less resource intensive than making a Java application for nearly any purpose-- it's vastly less resource intensive. That's just plain old reality. I'm not saying it's good, or worth praising; it's just the way our world works outside of volunteer-driven FOSS. When I got paid by a nonprofit to work on MIT-Licensed FOSS full-time for years, these questions were as important as anywhere else where resources aren't free. If I had my choice, I'd have chosen Elixir and Phoenix to do many of our web projects because BEAM had built-in tools to solve a lot of the odd architectural problems we had. But if you suddenly had to hire a few Elixir developers to do something that would work fine with Node.js, just not as elegantly, that grant isn't going to get any bigger just because I'm making sound technical decisions. At the end of the day, your software is valuable for what it does for people-- not what it is. And really, how much does using electron limit the actual utility of the tool itself among people with limited compute resources? I don't mean what's the difference in the memory footprint, I mean how often are people unable to solve their problem using an electron app because their computer can't run it? You obviously don't need bleeding edge hardware to run an electron application as hyperbolically suggested-- it's not much different from using, well, Chrome. Projects that work with really really under-resourced populations, such as the houseless, don't make desktop applications anyway-- one that I can think of off-the-top of my head used SMS because it was so much more readily available than a computer you can install an app on. Developers like to focus on things like memory and compute resources because they know how to address them. Hammers looking for nails. But if you really dig into users' biggest frustrations with software, as I have in my interface design work, performance is almost never mentioned. When it is, they're almost exclusively dealing with shitty internet access, not slow local application execution. If FOSS projects wanted to do more good in the world rather than having a hobby project to nerd out about, they'd actively solicit designers to figure out what problems real users are actually running into trying to solve their problems rather than just assuming the solution is more technical correctness. They could be one of the few volunteer-driven FOSS projects isn't solely usable by people who already have a working mental model of software development.

zlg_codes 3y ago

I'm really not swayed by "we must use this turd because the alternative is nothing". "Nothing", to me, is a technical challenge and a sign I should probably start writing the thing myself. Yes, not everyone has the skill or time to do that, but it's also no reason to accept half-baked solutions that don't take the user's system resources into account. Compute may be cheap but it's still a resource we need to use wisely. Not everyone is running a system like the developer's Macbook Pros on 5GHz wifi hooked up to fiber.

chefandy 3y ago
If you only care about the best technical solution, and don't care about economics, then you almost, by definition, only care about what existing FOSS users are doing, and I don't find that scope limitation useful in any way. I love FOSS. I've been a regular contributor to FOSS for decades. But the impact user-facing FOSS apps have on the overwhelming majority of users is miniscule, as is the comparative number of regular FOSS users. Server apps? Apps developers use to make the apps everyone else uses? Absolutely. A music player? A chat app? Nope. Software that makes a visible impression on users is commercial. That's just reality. And companies that don't consider ROI on the products they create aren't companies very long. The most popular as-is FOSS app for users is probably Firefox with a browser market share neck-and-neck with Opera and Samsung Internet, and everything less popular might as well not exist among probably 99% of users. Why? It's certainly not performance, I assure you. It's because it's poorly designed and users find it infuriating to use. Sure, you can find people complaining about their bloated slack client being slow on their machine. You think that's bad, find a professional photographer and ask them about the one time they tried to use Gimp. I spend a lot of time talking about how FOSS could be a lot more usable to end users, and technical supremacy isn't it. If you showed your average end user an electron app with an intuitive, professional design that gets the job done well enough, and then you show them the blazing fast linux native version with a typically awkward homespun interface, I will eat my hat if they don't choose the electron version. Sure, in a perfect world, all tools would be forged specifically for their intended purpose. In reality, you are in a miniscule percentage of people that would rather have nothing than something which doesn't perform optimally because of it's bonkers architecture. But if you actually want to maximize the usability of any giving tool, the only reason developers automatically go to performance is because to a hammer, everything looks like a nail.