5 ms·

Nobody thinks Electron applications are lightweight. Maybe you have heard someone refer to PWAs as lightweight applications surrogates

alpaca128 2y ago
I’ve seen multiple VS Code users claim it’s lightweight and fast. And to be fair compared to many other Electron apps it is, but many editors still run circles around it.
- vv_ 2y ago
  > but many editors still run circles around it Could you provide an example?
  - alpaca128 2y ago
    Last time I looked at benchmarks, editors like Sublime, Emacs, gVim etc and even some IDEs had lower input latency. Zed is probably the most comparable editor that’s both faster and more power efficient. Anecdotally on my previous laptop from 2016 it was often laggy and took longer to process a single key input than Vim took to start up and load plugins, and natively compiled editors like Emacs and Sublime tend to be noticeably snappier. Whether that matters to you or not is subjective, but I don’t like editors pretending to be IDEs anyway.
    - vv_ 2y ago
      It's not surprising that editors / IDEs supporting less features are going to be faster. For example, https://github.com/zed-industries/zed/issues/5065 https://github.com/zed-industries/zed/issues/5065, according to that issue Zed doesn't support Build/Debug actions, which makes it a no-go for embedded development immediately. At that point I'd rather just use nvim with plugins. When I had an old computer that couldn't deal with the indexing done by JetBrain's CLion or Microsoft's Visual Studio Code - I used nvim. It was a pleasant experience, however it lacked support for visual debugging (and please don't talk about GDB TUI as if it is an option). Now that I have a computer that can deal with the indexing, Visual Studio Code is just fine. In fact, it is considerably more lightweight than JetBrain's CLion IDE and is very easy to setup. For example, https://code.visualstudio.com/docs/devcontainers/create-dev-container https://code.visualstudio.com/docs/devcontainers/create-dev-..., allows you to setup development inside a container. In practice this allows anyone to quickly pull the repository and start working on the code, including building and debugging without having to worry about setting up toolchains or environment as it'll be done automatically for you.
      - alpaca128 2y ago
        > It's not surprising that editors / IDEs supporting less features are going to be faster True, though performance is often completely unrelated to the amount of features. The build/debug actions you mentioned should not have any impact on text editing speed.
        vv_ 2y ago
        Supporting additional features generally introduces complexity. This is why people drift towards using larger platforms (e.g. Electron) to build their applications as it reduces the complexity of introducing new features. As it stands today, Zed is unusable for my use-case due to a lack of support for features I need.
high_na_euv 2y ago
Vs Code?
- gw2 2y ago
  I find VS Code to be unmanageable for anything beyond a medium sized project. Maybe the LSPs I use are to be blamed, but I find nvim less problematic in this regard.
rahen 2y ago
Here is a quick example of an application labeled as lightweight, which turns out to be a 500MB+ Electron monstrosity: "MarkText is a lightweight, user-friendly Markdown editor that serves as a free and open-source alternative to Typora. It’s designed for everyday users who want a clean, intuitive experience." https://myownsys.com/2024/11/24/everyone-should-have-a-free-and-open-source-markdown-editor-handy-with-5-recommendations/ https://myownsys.com/2024/11/24/everyone-should-have-a-free-...
- gw2 2y ago
  If the application is free (with no strings attached), I would not really complain. But the main offenders are apps by large companies that have revenues in billions. The problem is that most of the userbase do not complain.

alpaca128 2y ago

I’ve seen multiple VS Code users claim it’s lightweight and fast. And to be fair compared to many other Electron apps it is, but many editors still run circles around it.

vv_ 2y ago
> but many editors still run circles around it Could you provide an example?
- alpaca128 2y ago
  Last time I looked at benchmarks, editors like Sublime, Emacs, gVim etc and even some IDEs had lower input latency. Zed is probably the most comparable editor that’s both faster and more power efficient. Anecdotally on my previous laptop from 2016 it was often laggy and took longer to process a single key input than Vim took to start up and load plugins, and natively compiled editors like Emacs and Sublime tend to be noticeably snappier. Whether that matters to you or not is subjective, but I don’t like editors pretending to be IDEs anyway.
  - vv_ 2y ago
    It's not surprising that editors / IDEs supporting less features are going to be faster. For example, https://github.com/zed-industries/zed/issues/5065 https://github.com/zed-industries/zed/issues/5065, according to that issue Zed doesn't support Build/Debug actions, which makes it a no-go for embedded development immediately. At that point I'd rather just use nvim with plugins. When I had an old computer that couldn't deal with the indexing done by JetBrain's CLion or Microsoft's Visual Studio Code - I used nvim. It was a pleasant experience, however it lacked support for visual debugging (and please don't talk about GDB TUI as if it is an option). Now that I have a computer that can deal with the indexing, Visual Studio Code is just fine. In fact, it is considerably more lightweight than JetBrain's CLion IDE and is very easy to setup. For example, https://code.visualstudio.com/docs/devcontainers/create-dev-container https://code.visualstudio.com/docs/devcontainers/create-dev-..., allows you to setup development inside a container. In practice this allows anyone to quickly pull the repository and start working on the code, including building and debugging without having to worry about setting up toolchains or environment as it'll be done automatically for you.
    - alpaca128 2y ago
      > It's not surprising that editors / IDEs supporting less features are going to be faster True, though performance is often completely unrelated to the amount of features. The build/debug actions you mentioned should not have any impact on text editing speed.
      - vv_ 2y ago
        Supporting additional features generally introduces complexity. This is why people drift towards using larger platforms (e.g. Electron) to build their applications as it reduces the complexity of introducing new features. As it stands today, Zed is unusable for my use-case due to a lack of support for features I need.

high_na_euv 2y ago

Vs Code?

gw2 2y ago
I find VS Code to be unmanageable for anything beyond a medium sized project. Maybe the LSPs I use are to be blamed, but I find nvim less problematic in this regard.

rahen 2y ago

Here is a quick example of an application labeled as lightweight, which turns out to be a 500MB+ Electron monstrosity: "MarkText is a lightweight, user-friendly Markdown editor that serves as a free and open-source alternative to Typora. It’s designed for everyday users who want a clean, intuitive experience." https://myownsys.com/2024/11/24/everyone-should-have-a-free-and-open-source-markdown-editor-handy-with-5-recommendations/ https://myownsys.com/2024/11/24/everyone-should-have-a-free-...

gw2 2y ago
If the application is free (with no strings attached), I would not really complain. But the main offenders are apps by large companies that have revenues in billions. The problem is that most of the userbase do not complain.