> 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.
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.
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.
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.
> I seem to be on a website where nobody can picture doing anything without taking money from someone else.
And by the way, I'm not remotely capitalist, but I don't have the privilege of expecting the rest of the world to operate like I wish it would. In the US, unless you're independently wealthy, you've got to work to eat and feed your family, as I do, living together in a tiny apartment in a modestly priced city. Unless you're well-supported enough to spend a ton of time volunteering, which I am currently not, you've got to pull in money for what you do far more often than you give it away. Ignoring the realities of resource distribution in our society means you're more interested in patting yourself on the back for political and ethical purity than actually making a difference in people's lives. I've met a lot of people like that in political circles: their parents supported them and they were more interested in 'cred' and feeling cool than progress.
After years of hoping volunteer-driven FOSS would revolutionize our world, I now realize that the preponderance of developers are way more interested in coding as an intellectual exercise than solving real people's problems with their code. Think I'm wrong? Try putting in a PR, or heck, even a comment on an issue proposing some way to make something easier for non-technical users, and if anybody even responds, it will be to flame it into outerspace while essentially saying "they should just RTFM," or reflexively bikeshed it into oblivion. But what about all of those amazing well-loved heavily used FOSS apps popular among non-technical users, you might ask? Blender? Signal? Tally up the ones that aren't grant-funded and managed by people tasked with making the biggest impact possible with the resources they've got. I'd be pretty surprised if any of them had the luxury of choosing their tech stack completely independent of the resources required to develop with it.
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.
> 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.