4 ms·

>Seriously? You are going to call the hyperbole in this thread "legitimate criticism"? The overwhelming majority of it? Yes. >In this case you have a literal

>Seriously? You are going to call the hyperbole in this thread "legitimate criticism"? The overwhelming majority of it? Yes. >In this case you have a literal webapp that they also want to bundle as a desktop application. Turns out Electron is the most convenient way to do this. That's just it, though: Developer convenience; at the expense of the user's experience and resources. So many developers digging-in their heels, refusing to use any other GUI framework because they can't be bothered to learn or use anything beyond JavaScript. If that isn't the excuse then it's because an MVP is needed and, because the market is replete with JavaScript developers, Electron was chosen as the platform on which to build. But after the project is green-lit, surely the product will be built using a more performant, lower-weight framework, right? Well, no, because that only benefits the end user.

jlkuester7 5y ago
I get what you are saying. I recently watched this presentation from DevGAMM 2019: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk. The TLDR is that software is experiencing reverse evolution such that we are regressing in terms of most metrics that we care about (user experience, performance, reliability, etc), most of which I agree with. If what you are trying to build is a low-level portable system utility, then sure Electron is the "wrong" choice. But this feels a lot like the argument around low vs high level languages. Sure, coding in assembly has the potential to be more efficient, but it does not make sense in every (most?) cases. There are valid use case for high-level languages. For open source projects in particular it seems like having a tech-stack that many people are familiar with and like to code, is easy to "hack", and publish to multiple platforms in is a clear benefit. Edit: And, yes, the performance for the end user suffers because of these concessions to the developer. But in my experience with open source projects, these trade-offs can make the difference between having a viable application and not. I would love efficient, optimized, native apps, but given the choice between an Electron app and nothing, I would rather have the Electron app.

jlkuester7 5y ago

I get what you are saying. I recently watched this presentation from DevGAMM 2019: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk. The TLDR is that software is experiencing reverse evolution such that we are regressing in terms of most metrics that we care about (user experience, performance, reliability, etc), most of which I agree with. If what you are trying to build is a low-level portable system utility, then sure Electron is the "wrong" choice. But this feels a lot like the argument around low vs high level languages. Sure, coding in assembly has the potential to be more efficient, but it does not make sense in every (most?) cases. There are valid use case for high-level languages. For open source projects in particular it seems like having a tech-stack that many people are familiar with and like to code, is easy to "hack", and publish to multiple platforms in is a clear benefit. Edit: And, yes, the performance for the end user suffers because of these concessions to the developer. But in my experience with open source projects, these trade-offs can make the difference between having a viable application and not. I would love efficient, optimized, native apps, but given the choice between an Electron app and nothing, I would rather have the Electron app.