5 ms·

I wish we could just move back to native apps and stop using the pile of crap that is Electron or any other attempt at bringing web stacks to the desktop.

XCSme 4y ago
I stopped paying/using Photoshop CC, and switched to https://www.photopea.com https://www.photopea.com. It's funny that the locally installed Photoshop took about 20s to launch, while Photopea launches instantly. Native is not necessarily better if it's poorly implemented.
LeanderK 4y ago
vscode launches very fast for me and is in general quite snappy
- jansan 4y ago
  That is really awesome. But OP and parent talk about Microsoft Teams.
  - c54 4y ago
    Both are electron apps. I think the parent poster meant just to say "Here's an example of an Electron app that's quick, I'm not sure that Electron itself is the issue"
  - Entinel 4y ago
    They said Electron apps. The person is just noting that not all Electron apps run like garbage.
  - cephei 4y ago
    I believe the relevance comes from the fact that both are built on Electron.
  - sokoloff 4y ago
    VSCode uses Electron, making it entirely relevant to this thread.
  - deleted 4y ago
    [deleted]
  - explaininjs 4y ago
    OP talks about Electron, which vscode uses. The issue is in the application architecture, not the platform architecture. VSCode uses raw TS with no frameworks and all handcrafted events (manually attaching and detaching dom event listeners is commonplace, and hand wiring each event’s propagation chain is as well), Teams hops to the current flavor of the week framework when they get too far up a tree with the last rewrite’s. VSCode has also never been rewritten from the ground up, whereas this is Teams’ fourth or fifth time by my count. VSCode also has about 50 people on it, all said and done (PM, Design, etc included), teams has well over a thousand. It’s really quite an interesting case study. The lesson being, IMO: stop worrying about electron vs native vs angular vs rust vs react vs blah blah blah and just: - don’t be afraid to write good code - profile often
    - Fell 4y ago
      And yet, VSCode cannot render at 60 FPS on my 2013 laptop. Any other program does. I don't expect Teams to perform better. Electron is a waste of resources. A high price to pay for the convenience of easy multiplatform applications.
- geodel 4y ago
  The problem with electron software is it has to be fast for lot of people with varied age of computers and not just for those who upgrade machines every couple of years. Currently it is not happening and it is fast on my computer are unhelpful comments.
  - evilduck 4y ago
    Is whining about Electron somehow helpful though? It's complained about constantly and the conversation inevitably goes through the exact same discussion points for the 8th or 9th year running.
  - LeanderK 4y ago
    I am using a mid-2014 Macbook pro. It's not a recent laptop and vscode is still snappy for me.
- tobz1000 4y ago
  vscode is the best-case scenario for Electron in my experience; this suggests that you need good diligence to ensure reasonable performance with the framework. Even then, performance is only acceptable, not exceptional. Sublime Text is a great example of what performance can be like with a different toolkit. Compare it to vscode - even on a fast machine - and you'll start to notice all the little lags that can creep in.
  - LeanderK 4y ago
    hm but is it comparable? I've used sublime in the past but only as a bare-bones editor. I see vscode more in line with IDEs (it's kinda both), as there ist a lot of functionality and coding support available. Pycharm, Intellij etc are all clunkier in my experience and that's how I mostly use vscode.
- cudgy 4y ago
  Ok. A text editor can load fast. Welcome to the 1980’s.
  - LeanderK 4y ago
    that's great for 1980's editors, feel free to use them. But vscode is a different beast, a plug-and-play solution ranging from simple editor to a full blown IDE. It also stays snappy for me, as mentioned.
    - cudgy 4y ago
      “a plug-and-play solution ranging from simple editor to a full blown IDE” It’s still mainly just a text editor and not “full-blown”. There is no significant built-in user interface, gui designer/builders, or emulators for example. The plugins can be native, which could allow for this. Essentially, vscode is a text editor that allows for native plugins, which explains the high performance possible.
      - LeanderK 4y ago
        talking about vscode without its plugins or langue servers does not make sense. They provide 99% of the functionality. The plugins can create new views, from pdf-viewers to interactive coding environments with 3d plots ala plotly. Done in electron. The python language server provides all you can think of with python. Emulators are not native to IDEs, there's always glue code, you can write a plugin for it. I don't know about GUI-Builders, but in principle you can do anything. It's just a web view after all. Vscode is incredibly flexible. I have written a paper with it including live preview of the pdf. But I don't care about GUI-Builders. You only need them for apps and then you are stuck with each walled garden anyway and forced to use e.g. Xcode. Except ios/android apps, who's native anyway in the 21st century? ;)
acomjean 4y ago
Lamentably, these work on Linux. Nothing else seems to excepting a few using Java (jetbrains) and libre-office and the open source big ones: Gnu Image, Krita and Blender.
- stefan_ 4y ago
  That's funny because Teams famously abandoned its heap of crap Electron (Skype?) Linux client. And when it was working, it was peaking the CPU to play one video stream.
- waboremo 4y ago
  Good point, I'm not sure many wanting the "return to native apps" are going to be happy when many places abandon the variety of platforms they currently support just to focus on their primary platform. In the end, performance is just another piece that comes with tradeoffs.
eviks 4y ago
but then the developer velocity of having to rebuild the whole up from the ground up would suffer!
chrismorgan 4y ago
The problem isn’t web tech, but rather software (of any kind) that is designed without performance in mind from the start, and by large teams. Something functionally-similar, still using web tech, but produced by one or two developers who care about performance (and yes, I seriously suggest this would be feasible) and are given free rein to do so would be better, lighter and faster than something “native” produced by a similar team to that which has made their existing apps. Web tech is easy. This incidentally makes stuff built with it likely to be slower. Especially when you have a whole bunch of developers working on a thing. I have come to the conclusion that large teams more or less cannot produce good results by these sorts of measures. I suspect also (without ever having used it) that a good chunk of Teams’ slowness will be in communications pieces that are nothing to do with web tech.
- horsawlarway 4y ago
  > I suspect also (without ever having used it) that a good chunk of Teams’ slowness will be in communications pieces that are nothing to do with web tech. Ding ding ding. This is the winner. I have yet to see someone who is bitching about Electron actually show that the render time in the client is really what's causing the performance issues. Almost always the issue is that fetching/updating a remote resource is just slow. It's SO freaking slow compared to local access. Worse - almost every other aspect of computing is actually getting quite a bit faster, but RTT isn't going to change. --- In this case, I'm willing to bet actual money that most of the speedup is hiding in what they're calling the "Client data layer" here: https://techcrunch.com/wp-content/uploads/2023/03/new_teams_graph.png https://techcrunch.com/wp-content/uploads/2023/03/new_teams_...
- filereaper 4y ago
  Its absurd that these products whose companies get bought for Billion+ can't have a team of 3-5 engineers focused on performance. I understand that you have lots of people building features but I'm sure the performance engineering efforts can be focused on the fundamental platform layers which are seen in most flame-graphs. Its also exactly these companies that grill you on performance and leet-code type problems but ship nothing like what they interview for.
webdevver 4y ago
MS Teams feels rushed, which is probably a good thing from the point of view of what a company should prioritise (being first is probably the most important thing in any market.) Now that they've won over a large part of the instant messenger sector (every corporate place I've seen uses MS Teams), hopefully they'll chill out a bit and work on making it less clunky. Message formatting in particular does my head in. Please just let we write markdown, and stop trying to live-replace backticks with rich-text-esque code blocks that I then can't move the cursor around!
ozim 4y ago
Sorry but web stacks on electron are much less crappy than desktop UI toolkits which are dependent on Apple, Microsoft or also developer hostile QT and web stack is the only real open/standardized alternative.
jjcm 4y ago
IMO the approach MS took was actually the correct one here - use Electron for your v1, then rewrite it once things are more established. There's nothing wrong with using a slightly less performant version of something for your MVP (could be argued against for someone as large as MS, but still). Rails is perfectly acceptable, you don't need Rust as your backend from day 1. As a separate argument, this entire point might be moot. Native webviews are becoming more common (hell MS has used them for the OS for quite a while - when I was there working on the windows 10 start menu, it was actually a webview) and can be much more performant. Since you aren't bundling a full browser in the executable, the memory impact is quite low. Tauri seems to be gaining quite a bit of traction which leverages native webviews, and shows a lot of promise.
- cudgy 4y ago
  “There's nothing wrong with using a slightly less performant version of something for your MVP” Twice as slow is slightly less? What about losing to competition because your app is slow and doesn’t feel like it belongs in the operating system? Or what about the cost and potential failure of a rewrite of a more complex app requiring technology the existing team has no experience with?
horsawlarway 4y ago
Holy fuck, not me. Honestly, I wish we could just skip straight to nothing but web apps. They work, they work consistently, they work cross platform. Native apps are absolutely no guarantee you don't have performance problems, and I really don't think it's the render time for HTML/CSS in a webview that's slowing things down. Most times it's just poor consideration for performance from the get-go. Chuck in a bunch of screens that are fetching remote resources before being displayed and viola... MS Teams. ---- Trust me, the development team that fucks up performance with Electron will absolutely fuck it up with native too. This is like blaming the shitty bathroom remodel on the choice of tile instead of the poor craftsmanship.
- sershe 4y ago
  I dunno, native apps from 2000 on much worse hardware were running more or less the same features much better. Web (and electron/etc.) apps combine encouraging anti-patterns with lowering the barriers of entry too much, it's like if we allowed anyone to build bridges out of 3D printed parts. I am libertarian on most things, but I make exception for things like that... infrastructure safety, air pollution, child abuse and web scripting - these are/got so bad they need to be heavily regulated to keep idiots in line.
- drcongo 4y ago
  Out of interest, are you a Windows user? It's the only platform where native apps are even worse.
  - horsawlarway 4y ago
    I use Linux/Windows/macOS just about daily. Personally - I'd prefer to be on linux full time, but work issues macbooks, and I develop applications that run across all three, so I use all three.
    - drcongo 4y ago
      Thanks for replying.
- 4y ago
solarkraft 4y ago
Ah yes, time for my old line: You can build terrible software that is native and you can build good software on the web. Microsoft makes bad software, but this is not (at least entirely; you could argue that it encourages it) the web's fault. Look at the clusterfucks Microsoft's native apps are (they're the worst on their own platform ...). They just have extremely low standards for quality.

XCSme 4y ago

I stopped paying/using Photoshop CC, and switched to https://www.photopea.com https://www.photopea.com. It's funny that the locally installed Photoshop took about 20s to launch, while Photopea launches instantly. Native is not necessarily better if it's poorly implemented.

LeanderK 4y ago

vscode launches very fast for me and is in general quite snappy

jansan 4y ago
That is really awesome. But OP and parent talk about Microsoft Teams.
- c54 4y ago
  Both are electron apps. I think the parent poster meant just to say "Here's an example of an Electron app that's quick, I'm not sure that Electron itself is the issue"
- Entinel 4y ago
  They said Electron apps. The person is just noting that not all Electron apps run like garbage.
- cephei 4y ago
  I believe the relevance comes from the fact that both are built on Electron.
- sokoloff 4y ago
  VSCode uses Electron, making it entirely relevant to this thread.
- deleted 4y ago
  [deleted]
- explaininjs 4y ago
  OP talks about Electron, which vscode uses. The issue is in the application architecture, not the platform architecture. VSCode uses raw TS with no frameworks and all handcrafted events (manually attaching and detaching dom event listeners is commonplace, and hand wiring each event’s propagation chain is as well), Teams hops to the current flavor of the week framework when they get too far up a tree with the last rewrite’s. VSCode has also never been rewritten from the ground up, whereas this is Teams’ fourth or fifth time by my count. VSCode also has about 50 people on it, all said and done (PM, Design, etc included), teams has well over a thousand. It’s really quite an interesting case study. The lesson being, IMO: stop worrying about electron vs native vs angular vs rust vs react vs blah blah blah and just: - don’t be afraid to write good code - profile often
  - Fell 4y ago
    And yet, VSCode cannot render at 60 FPS on my 2013 laptop. Any other program does. I don't expect Teams to perform better. Electron is a waste of resources. A high price to pay for the convenience of easy multiplatform applications.
geodel 4y ago
The problem with electron software is it has to be fast for lot of people with varied age of computers and not just for those who upgrade machines every couple of years. Currently it is not happening and it is fast on my computer are unhelpful comments.
- evilduck 4y ago
  Is whining about Electron somehow helpful though? It's complained about constantly and the conversation inevitably goes through the exact same discussion points for the 8th or 9th year running.
- LeanderK 4y ago
  I am using a mid-2014 Macbook pro. It's not a recent laptop and vscode is still snappy for me.
tobz1000 4y ago
vscode is the best-case scenario for Electron in my experience; this suggests that you need good diligence to ensure reasonable performance with the framework. Even then, performance is only acceptable, not exceptional. Sublime Text is a great example of what performance can be like with a different toolkit. Compare it to vscode - even on a fast machine - and you'll start to notice all the little lags that can creep in.
- LeanderK 4y ago
  hm but is it comparable? I've used sublime in the past but only as a bare-bones editor. I see vscode more in line with IDEs (it's kinda both), as there ist a lot of functionality and coding support available. Pycharm, Intellij etc are all clunkier in my experience and that's how I mostly use vscode.
cudgy 4y ago
Ok. A text editor can load fast. Welcome to the 1980’s.
- LeanderK 4y ago
  that's great for 1980's editors, feel free to use them. But vscode is a different beast, a plug-and-play solution ranging from simple editor to a full blown IDE. It also stays snappy for me, as mentioned.
  - cudgy 4y ago
    “a plug-and-play solution ranging from simple editor to a full blown IDE” It’s still mainly just a text editor and not “full-blown”. There is no significant built-in user interface, gui designer/builders, or emulators for example. The plugins can be native, which could allow for this. Essentially, vscode is a text editor that allows for native plugins, which explains the high performance possible.
    - LeanderK 4y ago
      talking about vscode without its plugins or langue servers does not make sense. They provide 99% of the functionality. The plugins can create new views, from pdf-viewers to interactive coding environments with 3d plots ala plotly. Done in electron. The python language server provides all you can think of with python. Emulators are not native to IDEs, there's always glue code, you can write a plugin for it. I don't know about GUI-Builders, but in principle you can do anything. It's just a web view after all. Vscode is incredibly flexible. I have written a paper with it including live preview of the pdf. But I don't care about GUI-Builders. You only need them for apps and then you are stuck with each walled garden anyway and forced to use e.g. Xcode. Except ios/android apps, who's native anyway in the 21st century? ;)

acomjean 4y ago

Lamentably, these work on Linux. Nothing else seems to excepting a few using Java (jetbrains) and libre-office and the open source big ones: Gnu Image, Krita and Blender.

stefan_ 4y ago
That's funny because Teams famously abandoned its heap of crap Electron (Skype?) Linux client. And when it was working, it was peaking the CPU to play one video stream.
waboremo 4y ago
Good point, I'm not sure many wanting the "return to native apps" are going to be happy when many places abandon the variety of platforms they currently support just to focus on their primary platform. In the end, performance is just another piece that comes with tradeoffs.

eviks 4y ago

but then the developer velocity of having to rebuild the whole up from the ground up would suffer!

chrismorgan 4y ago

The problem isn’t web tech, but rather software (of any kind) that is designed without performance in mind from the start, and by large teams. Something functionally-similar, still using web tech, but produced by one or two developers who care about performance (and yes, I seriously suggest this would be feasible) and are given free rein to do so would be better, lighter and faster than something “native” produced by a similar team to that which has made their existing apps. Web tech is easy. This incidentally makes stuff built with it likely to be slower. Especially when you have a whole bunch of developers working on a thing. I have come to the conclusion that large teams more or less cannot produce good results by these sorts of measures. I suspect also (without ever having used it) that a good chunk of Teams’ slowness will be in communications pieces that are nothing to do with web tech.

horsawlarway 4y ago
> I suspect also (without ever having used it) that a good chunk of Teams’ slowness will be in communications pieces that are nothing to do with web tech. Ding ding ding. This is the winner. I have yet to see someone who is bitching about Electron actually show that the render time in the client is really what's causing the performance issues. Almost always the issue is that fetching/updating a remote resource is just slow. It's SO freaking slow compared to local access. Worse - almost every other aspect of computing is actually getting quite a bit faster, but RTT isn't going to change. --- In this case, I'm willing to bet actual money that most of the speedup is hiding in what they're calling the "Client data layer" here: https://techcrunch.com/wp-content/uploads/2023/03/new_teams_graph.png https://techcrunch.com/wp-content/uploads/2023/03/new_teams_...
filereaper 4y ago
Its absurd that these products whose companies get bought for Billion+ can't have a team of 3-5 engineers focused on performance. I understand that you have lots of people building features but I'm sure the performance engineering efforts can be focused on the fundamental platform layers which are seen in most flame-graphs. Its also exactly these companies that grill you on performance and leet-code type problems but ship nothing like what they interview for.

webdevver 4y ago

MS Teams feels rushed, which is probably a good thing from the point of view of what a company should prioritise (being first is probably the most important thing in any market.) Now that they've won over a large part of the instant messenger sector (every corporate place I've seen uses MS Teams), hopefully they'll chill out a bit and work on making it less clunky. Message formatting in particular does my head in. Please just let we write markdown, and stop trying to live-replace backticks with rich-text-esque code blocks that I then can't move the cursor around!

ozim 4y ago

Sorry but web stacks on electron are much less crappy than desktop UI toolkits which are dependent on Apple, Microsoft or also developer hostile QT and web stack is the only real open/standardized alternative.

jjcm 4y ago

IMO the approach MS took was actually the correct one here - use Electron for your v1, then rewrite it once things are more established. There's nothing wrong with using a slightly less performant version of something for your MVP (could be argued against for someone as large as MS, but still). Rails is perfectly acceptable, you don't need Rust as your backend from day 1. As a separate argument, this entire point might be moot. Native webviews are becoming more common (hell MS has used them for the OS for quite a while - when I was there working on the windows 10 start menu, it was actually a webview) and can be much more performant. Since you aren't bundling a full browser in the executable, the memory impact is quite low. Tauri seems to be gaining quite a bit of traction which leverages native webviews, and shows a lot of promise.

cudgy 4y ago
“There's nothing wrong with using a slightly less performant version of something for your MVP” Twice as slow is slightly less? What about losing to competition because your app is slow and doesn’t feel like it belongs in the operating system? Or what about the cost and potential failure of a rewrite of a more complex app requiring technology the existing team has no experience with?

horsawlarway 4y ago

Holy fuck, not me. Honestly, I wish we could just skip straight to nothing but web apps. They work, they work consistently, they work cross platform. Native apps are absolutely no guarantee you don't have performance problems, and I really don't think it's the render time for HTML/CSS in a webview that's slowing things down. Most times it's just poor consideration for performance from the get-go. Chuck in a bunch of screens that are fetching remote resources before being displayed and viola... MS Teams. ---- Trust me, the development team that fucks up performance with Electron will absolutely fuck it up with native too. This is like blaming the shitty bathroom remodel on the choice of tile instead of the poor craftsmanship.

sershe 4y ago
I dunno, native apps from 2000 on much worse hardware were running more or less the same features much better. Web (and electron/etc.) apps combine encouraging anti-patterns with lowering the barriers of entry too much, it's like if we allowed anyone to build bridges out of 3D printed parts. I am libertarian on most things, but I make exception for things like that... infrastructure safety, air pollution, child abuse and web scripting - these are/got so bad they need to be heavily regulated to keep idiots in line.
drcongo 4y ago
Out of interest, are you a Windows user? It's the only platform where native apps are even worse.
- horsawlarway 4y ago
  I use Linux/Windows/macOS just about daily. Personally - I'd prefer to be on linux full time, but work issues macbooks, and I develop applications that run across all three, so I use all three.
  - drcongo 4y ago
    Thanks for replying.
4y ago

solarkraft 4y ago

Ah yes, time for my old line: You can build terrible software that is native and you can build good software on the web. Microsoft makes bad software, but this is not (at least entirely; you could argue that it encourages it) the web's fault. Look at the clusterfucks Microsoft's native apps are (they're the worst on their own platform ...). They just have extremely low standards for quality.