4 ms·

I do not know how many developers use VS code, but all of them are using electron and it seems to be fast enough for them. I agree with the spirit of what you

I do not know how many developers use VS code, but all of them are using electron and it seems to be fast enough for them. I agree with the spirit of what you imply: what a waste. On the other hand we do not use titanium everywhere, only where needed. There is best for a specific usecase.

grayhatter 3y ago
It's what everyone else is using so it's fine. Isn't the convincing argument you might hope it is.
- jabradoodle 3y ago
  It is relatively convincing when there are plentiful free alternatives and no one is telling you what to use (This from an emacs user).
- mejutoco 3y ago
  My argument is: engineering is not about best in absolute terms, but about best given constraints. Some nuance and examples of traditional engineering (titanium as material) were given, if you want to rebuke them. I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are. Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem. In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender.
  - grayhatter 3y ago
    > My argument is: engineering is not about best in absolute terms, but about best given constraints. I usually agree. But laziness as the primary constraint should feel appalling to anyone who would willingly call themselves an engineer. Perhaps I actually mean to use a different word for engineer but I don't know what it should be > I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are. I think you are, indirectly or inadvertently, citing electron and arguing in defense of it as a reasonable choice/option does do that. > Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem. Laziness is a choice. There are known better options, but software engineers *DID* choose to make it slow. The common axiom good, fast, or cheap; pick two. If you choose ease of development over fast you chose to make it slow. The people who build in python over C because they can write python faster, chose to make runtime slow. I guess you could argue for ignorance as a reason, but once you realize your software is slow, and refuse to do the work needed to fix it. You've also made the choice for it to be slow. > In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender. Good engineers are willing to make the right trade offs. and I still believe that laziness is a positive trait in software engineers. But great engineers find a way to have both/everything, and people acting ethically don't prioritize their comfort or convenience over what's in the best interest of users. The problem isn't if we can or can't make it fast, or correct, or user friendly. 55GiB/s fizzbuzz proves if you care enough, anything can be fast. The problem is people don't care, and that others who also don't care throw up their hands and say good enough is acceptable. And sure by definition it is acceptable. But I'd argue everything is awful, on fire, trash, user hostile, bad because too many people go ehh good enough you can stop trying.
    - mejutoco 3y ago
      I think we basically agree. Let me address what I think is the main difference. It seems the difference is what we each are including in the "universe" of the problem. To me, it looks like you start and end with the developer (maybe developer + user), and assign laziness to them (aka you turn it into a moral problem). On my argument, I am including the company, the users, and the whole economy. In that context, it is not about what the developer wants, but about the economical incentives, and it is not a moral problem but an optimization one.
actionfromafar 3y ago
From what I heard VS Code is a really optimised and well designed piece of code. Not sure what I’m going with this except I know VS code is touted as some kind of counter example a lot. But I also know such care didn’t go into most Electron codebases.
- dspillett 3y ago
  But is that Electron's fault? Is there no chance that at least some of those code-bases would be inefficient in other frameworks too? And no chance that the projects would have taken longer to release, or wouldn't exist at all because it was deemed too much faf, if another framework were used? Other than running separate node and chromium instances for every instance of an app, what does Electron do to encourage the inefficiency that is attributed to it?
pkolaczk 3y ago
I noticed people have very low expectations about modern application performance. My mom finds it completely reasonable that her TV or car audio need 5-10 seconds to boot. I guess that because almost everything is a web-page now (including web-pages wrapped in a window like electron apps), people simply got used to seeing a lag every time they click. And I remember how my jaw has almost dropped when in 2022 I saw an operator of a POS that used a 80x25 TUI coming from a dinosaur era coded probably with Borland TurboVision... Man, how fast that was! Some windows literally appeared on the screen for a fraction of a second (the operator obviously memorized the sequence of actions). The fact that I found it unusual, when in fact it should be a norm, also speaks something about the performance of today software.
- tentacleuno 3y ago
  Web pages aren't laggy by design. It's a combination of using libraries which don't optimise it, not using tools to optimise it, and the lack of a well-engineered system.
PragmaticPulp 3y ago
> I do not know how many developers use VS code, but all of them are using electron and it seems to be fast enough for them. At this point, I think the debate about slow apps is more ideological than reality. I also think a lot of people are mistaking backend/network latency for front-end slowness. Slack isn’t going to load your scroll back history any faster if the backend is spending all of that time searching the database. People are too quick to blame the front end. Either that, or some of these posters are running 10-year old hardware and wonder why it’s slow
bluedino 3y ago
They use it because it works. They use it for everything. All of our interns: "How do I use this with VS code?" They ssh using it, everything. They don't know anything else. They don't know that they are using ssh, they have a VS code terminal window open. It's kind of sad. Meanwhile, I'm trying VS code on my 5 year old Mac, and it's like a slideshow. Open a file...wait for syntax highlighting to fill in, the keyboard response is laggy. It's so terrible. Sublime Text is a Tesla Plaid in comparison.

grayhatter 3y ago

It's what everyone else is using so it's fine. Isn't the convincing argument you might hope it is.

jabradoodle 3y ago
It is relatively convincing when there are plentiful free alternatives and no one is telling you what to use (This from an emacs user).
mejutoco 3y ago
My argument is: engineering is not about best in absolute terms, but about best given constraints. Some nuance and examples of traditional engineering (titanium as material) were given, if you want to rebuke them. I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are. Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem. In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender.
- grayhatter 3y ago
  > My argument is: engineering is not about best in absolute terms, but about best given constraints. I usually agree. But laziness as the primary constraint should feel appalling to anyone who would willingly call themselves an engineer. Perhaps I actually mean to use a different word for engineer but I don't know what it should be > I am not appealing to popularity. I am offering a counterexample. It seems electron is not the problem (I showed a counter-example), but priorities are. I think you are, indirectly or inadvertently, citing electron and arguing in defense of it as a reasonable choice/option does do that. > Software engineers did not wake up and decide to make programs slow. The economic incentives decided that it was not "worth it". For that to change, the incentives need to change. Just claiming it "should" be like this is not as insightful as it may seem. Laziness is a choice. There are known better options, but software engineers *DID* choose to make it slow. The common axiom good, fast, or cheap; pick two. If you choose ease of development over fast you chose to make it slow. The people who build in python over C because they can write python faster, chose to make runtime slow. I guess you could argue for ignorance as a reason, but once you realize your software is slow, and refuse to do the work needed to fix it. You've also made the choice for it to be slow. > In the same way we could complain about programs not being formally verified for correctness, instead of not being as fast as possible. Probably that is a worse offender. Good engineers are willing to make the right trade offs. and I still believe that laziness is a positive trait in software engineers. But great engineers find a way to have both/everything, and people acting ethically don't prioritize their comfort or convenience over what's in the best interest of users. The problem isn't if we can or can't make it fast, or correct, or user friendly. 55GiB/s fizzbuzz proves if you care enough, anything can be fast. The problem is people don't care, and that others who also don't care throw up their hands and say good enough is acceptable. And sure by definition it is acceptable. But I'd argue everything is awful, on fire, trash, user hostile, bad because too many people go ehh good enough you can stop trying.
  - mejutoco 3y ago
    I think we basically agree. Let me address what I think is the main difference. It seems the difference is what we each are including in the "universe" of the problem. To me, it looks like you start and end with the developer (maybe developer + user), and assign laziness to them (aka you turn it into a moral problem). On my argument, I am including the company, the users, and the whole economy. In that context, it is not about what the developer wants, but about the economical incentives, and it is not a moral problem but an optimization one.

actionfromafar 3y ago

From what I heard VS Code is a really optimised and well designed piece of code. Not sure what I’m going with this except I know VS code is touted as some kind of counter example a lot. But I also know such care didn’t go into most Electron codebases.

dspillett 3y ago
But is that Electron's fault? Is there no chance that at least some of those code-bases would be inefficient in other frameworks too? And no chance that the projects would have taken longer to release, or wouldn't exist at all because it was deemed too much faf, if another framework were used? Other than running separate node and chromium instances for every instance of an app, what does Electron do to encourage the inefficiency that is attributed to it?

pkolaczk 3y ago

I noticed people have very low expectations about modern application performance. My mom finds it completely reasonable that her TV or car audio need 5-10 seconds to boot. I guess that because almost everything is a web-page now (including web-pages wrapped in a window like electron apps), people simply got used to seeing a lag every time they click. And I remember how my jaw has almost dropped when in 2022 I saw an operator of a POS that used a 80x25 TUI coming from a dinosaur era coded probably with Borland TurboVision... Man, how fast that was! Some windows literally appeared on the screen for a fraction of a second (the operator obviously memorized the sequence of actions). The fact that I found it unusual, when in fact it should be a norm, also speaks something about the performance of today software.

tentacleuno 3y ago
Web pages aren't laggy by design. It's a combination of using libraries which don't optimise it, not using tools to optimise it, and the lack of a well-engineered system.

PragmaticPulp 3y ago

> I do not know how many developers use VS code, but all of them are using electron and it seems to be fast enough for them. At this point, I think the debate about slow apps is more ideological than reality. I also think a lot of people are mistaking backend/network latency for front-end slowness. Slack isn’t going to load your scroll back history any faster if the backend is spending all of that time searching the database. People are too quick to blame the front end. Either that, or some of these posters are running 10-year old hardware and wonder why it’s slow

bluedino 3y ago

They use it because it works. They use it for everything. All of our interns: "How do I use this with VS code?" They ssh using it, everything. They don't know anything else. They don't know that they are using ssh, they have a VS code terminal window open. It's kind of sad. Meanwhile, I'm trying VS code on my 5 year old Mac, and it's like a slideshow. Open a file...wait for syntax highlighting to fill in, the keyboard response is laggy. It's so terrible. Sublime Text is a Tesla Plaid in comparison.