4 ms·

> I can never see the point of comments like these. Not one person who reads that will have his mind changed. I wasn't expecting to change anyone's mind with t

by Ianvdl 10y ago

> I can never see the point of comments like these. Not one person who reads that will have his mind changed. I wasn't expecting to change anyone's mind with that. There are more robust programming languages that don't have the same inconsistencies and idiosyncrasies and encourages better practices in general (even though it is true than you can write terrible code in any language). > No it doesn't. Either the developer benefits or doesn't benefit from "refusing". There's only so much time in the day. I'll refuse to to learn Qt or gtk+, unless there is some overwhelming benefit for me to learn it. That is true, but consider that the end product is not necessarily meant to be most convenient for the developer. Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives. I have read in the past that Electron also posed some difficulties for screen readers, for example (although I'm not sure if that is still the case), which might not be something that impacts you as the developer, but which can make it harder for someone to make use of your software.

jeremiep 10y ago
This means absolutely nothing. Otherwise everyone would be using Haskell, Coq or Agda. I'm willing to bet your favorite language has an insane amount of flaws as well (hint - they ALL do, otherwise we'd have converged to the "one true language" as an industry long, long ago.) You can make an argument to say C++ is terrible, Java is, Ruby is, Python is, and it means absolutely nothing other than showing of your own insecurities. You can build great and mediocre things in any language and any platform. People do every day. Also, if the developer is not one of the users of the software, you've already thrown a good chunk of quality out the window right there. You're simply not going to have the vision required to build the optimal user experience.
always_good 10y ago
> but consider that the end product is not > necessarily meant to be most convenient > for the developer. Sorry, but life isn't fair. Everything including software involves trade-offs, and perhaps ones that you would not have made yourself. For that reason, your post along with the blog post comes off as a tantrum. And if users really cared about these things, then surely you'd be able to swoop in and capitalize on it. But we both know that's not happening.
chr1 10y ago
> Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives Usually the choice for the user is between "have an electron app in a month" and "have native app in a year", most users prefer to not wait, and when native app comes in a year, electron app will have much more polish, and run acceptably on new hardware. The issue is not about 'protecting poor users'. Most electron apps are quick experiments, to test out an idea without spending too much resources on it. If idea is great, and performance is an issue, and there are enough users to get a team of highly skilled developers to work on it, they'll create native app, replace electron version (and then embed js vm to support plugins:).

by Ianvdl 10y ago

jeremiep 10y ago

This means absolutely nothing. Otherwise everyone would be using Haskell, Coq or Agda. I'm willing to bet your favorite language has an insane amount of flaws as well (hint - they ALL do, otherwise we'd have converged to the "one true language" as an industry long, long ago.) You can make an argument to say C++ is terrible, Java is, Ruby is, Python is, and it means absolutely nothing other than showing of your own insecurities. You can build great and mediocre things in any language and any platform. People do every day. Also, if the developer is not one of the users of the software, you've already thrown a good chunk of quality out the window right there. You're simply not going to have the vision required to build the optimal user experience.

always_good 10y ago

> but consider that the end product is not > necessarily meant to be most convenient > for the developer. Sorry, but life isn't fair. Everything including software involves trade-offs, and perhaps ones that you would not have made yourself. For that reason, your post along with the blog post comes off as a tantrum. And if users really cared about these things, then surely you'd be able to swoop in and capitalize on it. But we both know that's not happening.

chr1 10y ago

> Keeping the user in mind when making these decisions may make you consider more native and less resource-intensive alternatives Usually the choice for the user is between "have an electron app in a month" and "have native app in a year", most users prefer to not wait, and when native app comes in a year, electron app will have much more polish, and run acceptably on new hardware. The issue is not about 'protecting poor users'. Most electron apps are quick experiments, to test out an idea without spending too much resources on it. If idea is great, and performance is an issue, and there are enough users to get a team of highly skilled developers to work on it, they'll create native app, replace electron version (and then embed js vm to support plugins:).