17 ms·

This would be sooo much worse from a UI point of view. All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) w

This would be sooo much worse from a UI point of view. All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window. I also don't think Godot is inherently more performant for any random UI than Electron is. It happens that most Godot apps are performant because they're made by the type of people who want to use videogame engines and thus care about performance. Electron can definitely have great performance when the developers care about performance (VSCode). I say all this as someone who's worked on game engines before.

lolinder 3y ago
Exactly. People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most developers choose Electron because it requires the lowest amount of effort. When you start with that as your single reason for choosing a tech stack, it's unsurprising that optimizing performance never happens. VSCode works because they chose Electron for the advantages that web tech has when it comes to building a plugin ecosystem. They were then willing to put in the effort to make performance decent.
- integricho 3y ago
  I think it's very subjective what is considered performant. I for one don't think about VSCode as a performant app, for me it is a resource hog, not at all that responsive app, there's always a slight delay / lag in input reaction, simply not a fast application.
  - lolinder 3y ago
    So that the rest of us can calibrate, what text editors do you use that you consider to be performant?
    - allan_s 3y ago
      Sublime text or neovim for me (even with all debugger, language server, tabnine etc installed so to be also a full 2024 ide )
    - integricho 3y ago
      SublimeText, Notepad++, CudaText and LiteXL have acceptable performance, memory footprint and responsiveness for my taste (but this is certainly not a benchmark, just another subjective viewpoint :) )
    - trealira 3y ago
      Lite XL, although I usually use Emacs
- z3phyr 3y ago
  VSCode is slow as heck and a needless memory hog. Something like VS6.0 or Code Warrior with crisper fonts would be my first choice on a graphical interface.
- Gormo 3y ago
  > People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most developers choose Electron because it requires the lowest amount of effort. When you start with that as your single reason for choosing a tech stack, it's unsurprising that optimizing performance never happens. Which amounts to a strong argument in favor of using a tech stack that has superior default performance, and therefore requires less dev effort for optimization.
  - whstl 3y ago
    The problem is that Electron is superior to something like a Godot UI in absolutely everything else. Sure Godot can be ok for trivial apps, but extracting performance out of Electron is also not that difficult for trivial apps in the first place.
    - forrestthewoods 3y ago
      > The problem is that Electron is superior to something like a Godot UI in absolutely everything else. Why? What capabilities does Electron provide that Godot doesn’t and can’t? I’m genuinely asking. I don’t know.
      - homarp 3y ago
        Electron allows you can do webdev stuff, so you don't need custom knowledge of anything special. That's the 'superiority'. Doing UI in Godot means either their pythonish custom language or C# (and via GDExtension technology, C and C++ ).
      - whstl 3y ago
        Electron has literally thousands and thousands of very, very complex UI/UX features offered by the OS, plus thousands and thousands of very, very complex UI/UX features offered by a browser engine. Godot has barely nothing compared to that, as it's not an UI toolkit and never tried to be. Even basic things like "rendering text correctly in multiple languages, with emojis, while making it selectable with the mouse or with the keyboard" are super hard to get right, but it's a problem already solved by your OS, in a way that is not only better optimized and has less unseen bugs than a hypothetical bespoke implementation: it also looks and feels more familiar. Then there's the whole accessibility part, which has different native APIs depending on the OS. Some other people have written detailed answers: https://news.ycombinator.com/item?id=38953558 https://news.ycombinator.com/item?id=38953558 https://news.ycombinator.com/item?id=38954455 https://news.ycombinator.com/item?id=38954455 https://news.ycombinator.com/item?id=38954087 https://news.ycombinator.com/item?id=38954087 EDIT: You asked "doesn't and can't". Here's something: there is no can't if you have a turing complete language. But you need a large team to re-do it from scratch, as you're throwing away 40 years of work.
- pjmlp 3y ago
  VSCode works, because Microsoft has written a ton of C++, C# and Rust code to make it work in a usable manner. Exactly what most devs reaching out to Electron don't want to do, only cozy JavaScript.
vcg3rd 3y ago
> All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window. Could you explain this to someone who doesn't program and knows nothing about how os internals? My naive question is wouldn't the OS/DE/WM still take care of the above for an application?
- ladberg 3y ago
  To give an example comparing a text field in a native OR webview-based macOS app with a hypothetical Godot-based one, the Godot version would need to reimplement (or likely just omit): - Copy/paste - Emacs/readline keybindings (Ctrl-A, Ctrl-E, etc.) - User's preferred text size and font as selected in System Preferences - Spellcheck - Nice features for non-latin text (e.g. built in pinyin keyboard) - Crisp text rendering - Dictation support - Screen reader support - Autofill - Automatically updated with OS updates (e.g. HiDPI, all Java UIs had looked almost-native but were now stuck looking pixelated) - And hundreds more features I'm forgetting... This is all possible to do in Godot (e.g. the Godot Editor does a lot of these) but with a lot of work required. It's completely built in to any native or web-based text field and doesn't need any additional work.
- rkangel 3y ago
  From an "interfacing with the OS" point of view, a game engine interacts differently. Most desktop apps ask the OS "please render this text here, with this font" and the OS takes care of that. A game engine just asks the OS "here is a canvas I have drawn, please just put these pixels on the screen". The OS doesn't know that a chunk of pixels is text, so you can't select it, copy and paste it, or screen reader it by default. This is the same difference between an system like Flutter and native App toolkits (I'm going to talk about Flutter because I know more about it). It has massive advantages on portability - Flutter rendering is very predictable on different phones because the only thing that can vary is screen size. The subtle variations between OS versions and phone manufacturer UI skins don't screw things up. There are downsides: You need to implement all the common stuff that you'd normally get for free. This includes native look and feel - Flutter has to have all the Android and Apple widgets. It also includes text rendering accessibility, etc. etc.
- 3y ago
corethree 3y ago
No it's better for an os UI. A web page UI is better with electron where you click on a link an open a page. But floating windows with resizeable and highly dynamic UIs Godot is likely easier, better and much more well suited. HTML was never intended for dynamic interfaces. Whenever you diverge beyond what it does best which is hypertext, things become more and more hacky and awkward. If you wanted to design an os UI in electron, you would use a framework called react, and you would use a language called JavaScript that compiles down into typescript and you'd need a whole build ecosystem and connect everything together, then you might find HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg... In both cases you miss the text rendering from HTML. If you stick with HTML then you'd be using css to move shit around and create windows which is also incredibly awkward. People use electron because it's easy. The reason why it's easy is because of familiarity not because of actual superiority. Web UI is one of the most hacked together technology stacks ever. Developers with nothing better to do keep coming up with new abstractions trying to build for a moving target. It's not unique in this regard but it doesn't change the reality. Godot has the benefit of a very specific design implementation for a target that is highly dynamic and likely will never change. Plus it's new so you don't have armies of developers trying to "abstract" shit on it over years and years of horizontal progress.
- arshxyz 3y ago
  > HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg HTML is replaceable by WebGL which is replaceable by SVG? > JavaScript that compiles down into typescript JS compiles down to TS? I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/ https://winxp.vercel.app/ Here's one that mocks macOS - https://macos-web.app/ https://macos-web.app/
  - corethree 3y ago
    >JS compiles down to TS? It's called a typo. >I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL I think you're smart enough to recognize it's a typo. The primary issue with your comment is hiliteing issues as if it weren't typos but actual lapses in experience. It's like saying someone misspelled a word and claiming they therefore have no experience with the English language. If someone did that, the intent is 100% malice, not a misunderstanding. Don't be malicious. Don't debate and use malice to prove a point. What you should do is Make a point and change your stance based off of evidence. Also I never said it can't be done. I said it's awkward. It certainly can be done. WebGL is low level. Same with WebGPU, it means you have to use shaders. Godot has a library for UI. Which makes it less awkward. I'm saying it's JUST as awkward to build these things with webGL then with other web front end technologies. >Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/ https://winxp.vercel.app/ >Here's one that mocks macOS - https://macos-web.app/ https://macos-web.app/ What do these examples prove? That it can be done? Did I say it can't be done? Again I didn't. It's obvious these examples exist, everyones seen them. Heck you can probably do the whole thing with CSS and no JS. The gist of my comment is that it's awkward to do, not that it can't be done. You can construct a house out of toothpicks and glue. I'm sure it CAN be done. But bricks are the less awkward tool.
brucethemoose2 3y ago
> I don't think Godot is inherently more performant for any random UI than Electron It probably depends on the app? Electron will obviously excel at things that resemble an oldschool web page, but one would think Godot would excel at more dynamic OS UIs? If something is already sluggish or GPU heavy in Electron, I would think its right up Godot's alley. Accessibility of course is a seperate and huge concern.
bufio 3y ago
I have never encountered an Electron app that can even display the results of keystrokes in a timely manner, and that includes vscode. All Electron apps waste system resources to an obscene degree. Also, Electron apps have already thrown away OS conventions to the point that user interface consistency has become a thing of the past. I don't believe that either choice is ideal, but if Godot were ubiquitous instead of Electron, applications would probably at least be less laggy and more memory-efficient.
- skydhash 3y ago
  Sublime Text and Blender (and I guess the majority of CAD applications) creates their own UI engine. That would be better than the current state of electron apps, but most UI engines I encounter have support for custom elements. The issue is more wanting access to lots of cheap developer resources than branding.
  - JeffSnazz 3y ago
    I'm not sure about Sublime Text, but I can't imagine Blender is very accessible. As it's such a visual app that's perhaps not surprising, but this approach wouldn't work for other app styles.
- then4p 3y ago
  VS Code ID top laggy for you? Honestly asking because I think it performs adequately when compared to like IntelliJ.
  - alpaca128 3y ago
    According to one benchmark intelliJ can reach an average latency of 3ms on an i5 3427U from 2012 [0]. In a 2022 Github issue someone profiled VS Code which resulted in 12ms latency on an i7-12700KF released in 2021 [1]. If those results are even remotely representative of real-world scenarios then VS Code can't come close to intelliJ performance. [0] https://pavelfatin.com/typing-with-pleasure/#windows https://pavelfatin.com/typing-with-pleasure/#windows [1] https://github.com/microsoft/vscode/issues/161622#issuecomment-1287528213 https://github.com/microsoft/vscode/issues/161622#issuecomme...
dartharva 3y ago
You are overlooking a massive point that invalidates your concerns from a homebrew developer's POV: it is _easier_ on the mind to make apps using low-code graphical interfaces than with full-code.
Gormo 3y ago
> This would be sooo much worse from a UI point of view. All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window. This is what is already happening with people using sandboxed-runtime containers (like Flatpak) and webapp wrappers (like Electron). Desktop UX is becoming a hodgepodge of siloed runtimes and inconsistent interface paradigms. I don't think Godot would be a great alternative to developing a conventional desktop app, relying on the OS-provided runtime environment, but if you're already deviating away from that, it might still be much better than Flatpak or Electron. > Electron can definitely have great performance when the developers care about performance (VSCode). But most Electron applications do not have great performance because they're not being developed this way. Using Godot would provide an easy-to-learn frontend environment (with a scripting language that might even be simpler than using web-derived JS) while still providing the performance of a game engine under the hood. So non-Microsoft developers who would otherwise use Electron might still stand a chance of releasing decent software.
- wk_end 3y ago
  > This is what is already happening with people using sandboxed-runtime containers (like Flatpak) and webapp wrappers (like Electron). Desktop UX is becoming a hodgepodge of siloed runtimes and inconsistent interface paradigms. Flatpak and Electron don't sabotage any of these things. Flatpak usage is entirely orthogonal, and Electron actually has best-in-class accessibility, i18n, text rendering, keyboard navigation, RTL support, hi-DPI support, etc.; its widgets feel by default as-or-more-native than anything Qt or GTK produce. Without massive engineering work, handcrafting your GUI in Godot is going to suck for anyone using a screen reader, anyone who reads Arabic, anyone who can't use a mouse, etc.
  - strix_varius 3y ago
    Trying to come up with a way to open this without "well, actually..." Godot UI components are keyboard accessible by default and do support Arabic. I haven't tested them with a screen reader so I have no data there. The Godot editor itself is made in Godot, and it doesn't feel particularly snappy when compared to vscode, so I agree with the general premise that it wouldn't be a huge step forward. That said, it is more accessible out of the box than you might expect.
alfalfasprout 3y ago
VSCode is super laggy even on a $4000 MBP. Compared to something like IntelliJ sure, but that's a super low bar on responsiveness.
- fauntle 3y ago
  I keep seeing this complaint but I have never reproduced it locally. VSCode runs at a buttery smooth 120hz on my MBP. What are you doing that causes such poor performance?
  - IshKebab 3y ago
    It's extensions. Some of them can drag a machine to its knees, with unbounded CPU usage. The worst is the C++ extensions. Gets stuck at 100% CPU if you open a file it doesn't like, which is most of them. VSCode with no extensions is very fast and light. VSCode with 30 extensions you've accumulated? Not so much. I think that's why you see such conflicting experiences - people have different extensions.
    - mardifoufs 3y ago
      I think I have like, 50 extensions though not all of them are active at the same time (that's how vscode works I think) and I don't really see the lag. I have a high refresh rate screen, I'm pretty used to differentiating between laggy and non laggy graphics, etc and still nothing stands out. Maybe some extensions are resource hogs but I think vscode provides stats about extension resource usage and how much an extension slows down the editor so people can easily check what is causing their slowdowns.
    - depressedpanda 3y ago
      I regularly must sit and wait for vscode to catch up rendering the text I just typed. I suspect the main culprit is the vim extension, but unfortunately that's one of the few extensions I cannot go without.
      - IshKebab 3y ago
bigstrat2003 3y ago
Except VSCode most certainly does not have great performance. I can open the same set of files in VSCode and Sublime, and Sublime will use a few hundred MB of memory while VSCode uses well over 1 GB. That's not acceptable.
computershit 3y ago
Adobe Air, anyone?

lolinder 3y ago

Exactly. People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most developers choose Electron because it requires the lowest amount of effort. When you start with that as your single reason for choosing a tech stack, it's unsurprising that optimizing performance never happens. VSCode works because they chose Electron for the advantages that web tech has when it comes to building a plugin ecosystem. They were then willing to put in the effort to make performance decent.

integricho 3y ago
I think it's very subjective what is considered performant. I for one don't think about VSCode as a performant app, for me it is a resource hog, not at all that responsive app, there's always a slight delay / lag in input reaction, simply not a fast application.
- lolinder 3y ago
  So that the rest of us can calibrate, what text editors do you use that you consider to be performant?
  - allan_s 3y ago
    Sublime text or neovim for me (even with all debugger, language server, tabnine etc installed so to be also a full 2024 ide )
  - integricho 3y ago
    SublimeText, Notepad++, CudaText and LiteXL have acceptable performance, memory footprint and responsiveness for my taste (but this is certainly not a benchmark, just another subjective viewpoint :) )
  - trealira 3y ago
    Lite XL, although I usually use Emacs
z3phyr 3y ago
VSCode is slow as heck and a needless memory hog. Something like VS6.0 or Code Warrior with crisper fonts would be my first choice on a graphical interface.
Gormo 3y ago
> People hate on Electron because they have bad experiences with many Electron apps, but that's not because Electron is inherently terrible, it's because most developers choose Electron because it requires the lowest amount of effort. When you start with that as your single reason for choosing a tech stack, it's unsurprising that optimizing performance never happens. Which amounts to a strong argument in favor of using a tech stack that has superior default performance, and therefore requires less dev effort for optimization.
- whstl 3y ago
  The problem is that Electron is superior to something like a Godot UI in absolutely everything else. Sure Godot can be ok for trivial apps, but extracting performance out of Electron is also not that difficult for trivial apps in the first place.
  - forrestthewoods 3y ago
    > The problem is that Electron is superior to something like a Godot UI in absolutely everything else. Why? What capabilities does Electron provide that Godot doesn’t and can’t? I’m genuinely asking. I don’t know.
    - homarp 3y ago
      Electron allows you can do webdev stuff, so you don't need custom knowledge of anything special. That's the 'superiority'. Doing UI in Godot means either their pythonish custom language or C# (and via GDExtension technology, C and C++ ).
    - whstl 3y ago
      Electron has literally thousands and thousands of very, very complex UI/UX features offered by the OS, plus thousands and thousands of very, very complex UI/UX features offered by a browser engine. Godot has barely nothing compared to that, as it's not an UI toolkit and never tried to be. Even basic things like "rendering text correctly in multiple languages, with emojis, while making it selectable with the mouse or with the keyboard" are super hard to get right, but it's a problem already solved by your OS, in a way that is not only better optimized and has less unseen bugs than a hypothetical bespoke implementation: it also looks and feels more familiar. Then there's the whole accessibility part, which has different native APIs depending on the OS. Some other people have written detailed answers: https://news.ycombinator.com/item?id=38953558 https://news.ycombinator.com/item?id=38953558 https://news.ycombinator.com/item?id=38954455 https://news.ycombinator.com/item?id=38954455 https://news.ycombinator.com/item?id=38954087 https://news.ycombinator.com/item?id=38954087 EDIT: You asked "doesn't and can't". Here's something: there is no can't if you have a turing complete language. But you need a large team to re-do it from scratch, as you're throwing away 40 years of work.
pjmlp 3y ago
VSCode works, because Microsoft has written a ton of C++, C# and Rust code to make it work in a usable manner. Exactly what most devs reaching out to Electron don't want to do, only cozy JavaScript.

vcg3rd 3y ago

> All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window. Could you explain this to someone who doesn't program and knows nothing about how os internals? My naive question is wouldn't the OS/DE/WM still take care of the above for an application?

ladberg 3y ago
To give an example comparing a text field in a native OR webview-based macOS app with a hypothetical Godot-based one, the Godot version would need to reimplement (or likely just omit): - Copy/paste - Emacs/readline keybindings (Ctrl-A, Ctrl-E, etc.) - User's preferred text size and font as selected in System Preferences - Spellcheck - Nice features for non-latin text (e.g. built in pinyin keyboard) - Crisp text rendering - Dictation support - Screen reader support - Autofill - Automatically updated with OS updates (e.g. HiDPI, all Java UIs had looked almost-native but were now stuck looking pixelated) - And hundreds more features I'm forgetting... This is all possible to do in Godot (e.g. the Godot Editor does a lot of these) but with a lot of work required. It's completely built in to any native or web-based text field and doesn't need any additional work.
rkangel 3y ago
From an "interfacing with the OS" point of view, a game engine interacts differently. Most desktop apps ask the OS "please render this text here, with this font" and the OS takes care of that. A game engine just asks the OS "here is a canvas I have drawn, please just put these pixels on the screen". The OS doesn't know that a chunk of pixels is text, so you can't select it, copy and paste it, or screen reader it by default. This is the same difference between an system like Flutter and native App toolkits (I'm going to talk about Flutter because I know more about it). It has massive advantages on portability - Flutter rendering is very predictable on different phones because the only thing that can vary is screen size. The subtle variations between OS versions and phone manufacturer UI skins don't screw things up. There are downsides: You need to implement all the common stuff that you'd normally get for free. This includes native look and feel - Flutter has to have all the Android and Apple widgets. It also includes text rendering accessibility, etc. etc.
3y ago

corethree 3y ago

No it's better for an os UI. A web page UI is better with electron where you click on a link an open a page. But floating windows with resizeable and highly dynamic UIs Godot is likely easier, better and much more well suited. HTML was never intended for dynamic interfaces. Whenever you diverge beyond what it does best which is hypertext, things become more and more hacky and awkward. If you wanted to design an os UI in electron, you would use a framework called react, and you would use a language called JavaScript that compiles down into typescript and you'd need a whole build ecosystem and connect everything together, then you might find HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg... In both cases you miss the text rendering from HTML. If you stick with HTML then you'd be using css to move shit around and create windows which is also incredibly awkward. People use electron because it's easy. The reason why it's easy is because of familiarity not because of actual superiority. Web UI is one of the most hacked together technology stacks ever. Developers with nothing better to do keep coming up with new abstractions trying to build for a moving target. It's not unique in this regard but it doesn't change the reality. Godot has the benefit of a very specific design implementation for a target that is highly dynamic and likely will never change. Plus it's new so you don't have armies of developers trying to "abstract" shit on it over years and years of horizontal progress.

arshxyz 3y ago
> HTML to awkward so you have to switch to webgl which is too low level or you might switch to svg HTML is replaceable by WebGL which is replaceable by SVG? > JavaScript that compiles down into typescript JS compiles down to TS? I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/ https://winxp.vercel.app/ Here's one that mocks macOS - https://macos-web.app/ https://macos-web.app/
- corethree 3y ago
  >JS compiles down to TS? It's called a typo. >I am not sure if anything in this comment indicates you have any experience with developing for the web but that is not my primary issue with this comment. My gripe is claiming that things are "awkward" or can't be done without even looking around. None of the examples below use WebGL I think you're smart enough to recognize it's a typo. The primary issue with your comment is hiliteing issues as if it weren't typos but actual lapses in experience. It's like saying someone misspelled a word and claiming they therefore have no experience with the English language. If someone did that, the intent is 100% malice, not a misunderstanding. Don't be malicious. Don't debate and use malice to prove a point. What you should do is Make a point and change your stance based off of evidence. Also I never said it can't be done. I said it's awkward. It certainly can be done. WebGL is low level. Same with WebGPU, it means you have to use shaders. Godot has a library for UI. Which makes it less awkward. I'm saying it's JUST as awkward to build these things with webGL then with other web front end technologies. >Here's a WinXP UI clone that runs in your browser with floating, resizable windows. - https://winxp.vercel.app/ https://winxp.vercel.app/ >Here's one that mocks macOS - https://macos-web.app/ https://macos-web.app/ What do these examples prove? That it can be done? Did I say it can't be done? Again I didn't. It's obvious these examples exist, everyones seen them. Heck you can probably do the whole thing with CSS and no JS. The gist of my comment is that it's awkward to do, not that it can't be done. You can construct a house out of toothpicks and glue. I'm sure it CAN be done. But bricks are the less awkward tool.

brucethemoose2 3y ago

> I don't think Godot is inherently more performant for any random UI than Electron It probably depends on the app? Electron will obviously excel at things that resemble an oldschool web page, but one would think Godot would excel at more dynamic OS UIs? If something is already sluggish or GPU heavy in Electron, I would think its right up Godot's alley. Accessibility of course is a seperate and huge concern.

bufio 3y ago

I have never encountered an Electron app that can even display the results of keystrokes in a timely manner, and that includes vscode. All Electron apps waste system resources to an obscene degree. Also, Electron apps have already thrown away OS conventions to the point that user interface consistency has become a thing of the past. I don't believe that either choice is ideal, but if Godot were ubiquitous instead of Electron, applications would probably at least be less laggy and more memory-efficient.

skydhash 3y ago
Sublime Text and Blender (and I guess the majority of CAD applications) creates their own UI engine. That would be better than the current state of electron apps, but most UI engines I encounter have support for custom elements. The issue is more wanting access to lots of cheap developer resources than branding.
- JeffSnazz 3y ago
  I'm not sure about Sublime Text, but I can't imagine Blender is very accessible. As it's such a visual app that's perhaps not surprising, but this approach wouldn't work for other app styles.
then4p 3y ago
VS Code ID top laggy for you? Honestly asking because I think it performs adequately when compared to like IntelliJ.
- alpaca128 3y ago
  According to one benchmark intelliJ can reach an average latency of 3ms on an i5 3427U from 2012 [0]. In a 2022 Github issue someone profiled VS Code which resulted in 12ms latency on an i7-12700KF released in 2021 [1]. If those results are even remotely representative of real-world scenarios then VS Code can't come close to intelliJ performance. [0] https://pavelfatin.com/typing-with-pleasure/#windows https://pavelfatin.com/typing-with-pleasure/#windows [1] https://github.com/microsoft/vscode/issues/161622#issuecomment-1287528213 https://github.com/microsoft/vscode/issues/161622#issuecomme...

dartharva 3y ago

You are overlooking a massive point that invalidates your concerns from a homebrew developer's POV: it is _easier_ on the mind to make apps using low-code graphical interfaces than with full-code.

Gormo 3y ago

> This would be sooo much worse from a UI point of view. All nice OS features (good text rendering, uniform text editing interface, accessibility, transparency) would all get chucked out the window. This is what is already happening with people using sandboxed-runtime containers (like Flatpak) and webapp wrappers (like Electron). Desktop UX is becoming a hodgepodge of siloed runtimes and inconsistent interface paradigms. I don't think Godot would be a great alternative to developing a conventional desktop app, relying on the OS-provided runtime environment, but if you're already deviating away from that, it might still be much better than Flatpak or Electron. > Electron can definitely have great performance when the developers care about performance (VSCode). But most Electron applications do not have great performance because they're not being developed this way. Using Godot would provide an easy-to-learn frontend environment (with a scripting language that might even be simpler than using web-derived JS) while still providing the performance of a game engine under the hood. So non-Microsoft developers who would otherwise use Electron might still stand a chance of releasing decent software.

wk_end 3y ago
> This is what is already happening with people using sandboxed-runtime containers (like Flatpak) and webapp wrappers (like Electron). Desktop UX is becoming a hodgepodge of siloed runtimes and inconsistent interface paradigms. Flatpak and Electron don't sabotage any of these things. Flatpak usage is entirely orthogonal, and Electron actually has best-in-class accessibility, i18n, text rendering, keyboard navigation, RTL support, hi-DPI support, etc.; its widgets feel by default as-or-more-native than anything Qt or GTK produce. Without massive engineering work, handcrafting your GUI in Godot is going to suck for anyone using a screen reader, anyone who reads Arabic, anyone who can't use a mouse, etc.
- strix_varius 3y ago
  Trying to come up with a way to open this without "well, actually..." Godot UI components are keyboard accessible by default and do support Arabic. I haven't tested them with a screen reader so I have no data there. The Godot editor itself is made in Godot, and it doesn't feel particularly snappy when compared to vscode, so I agree with the general premise that it wouldn't be a huge step forward. That said, it is more accessible out of the box than you might expect.

alfalfasprout 3y ago

VSCode is super laggy even on a $4000 MBP. Compared to something like IntelliJ sure, but that's a super low bar on responsiveness.

fauntle 3y ago
I keep seeing this complaint but I have never reproduced it locally. VSCode runs at a buttery smooth 120hz on my MBP. What are you doing that causes such poor performance?
- IshKebab 3y ago
  It's extensions. Some of them can drag a machine to its knees, with unbounded CPU usage. The worst is the C++ extensions. Gets stuck at 100% CPU if you open a file it doesn't like, which is most of them. VSCode with no extensions is very fast and light. VSCode with 30 extensions you've accumulated? Not so much. I think that's why you see such conflicting experiences - people have different extensions.
  - mardifoufs 3y ago
    I think I have like, 50 extensions though not all of them are active at the same time (that's how vscode works I think) and I don't really see the lag. I have a high refresh rate screen, I'm pretty used to differentiating between laggy and non laggy graphics, etc and still nothing stands out. Maybe some extensions are resource hogs but I think vscode provides stats about extension resource usage and how much an extension slows down the editor so people can easily check what is causing their slowdowns.
  - depressedpanda 3y ago
    I regularly must sit and wait for vscode to catch up rendering the text I just typed. I suspect the main culprit is the vim extension, but unfortunately that's one of the few extensions I cannot go without.
    - IshKebab 3y ago

bigstrat2003 3y ago

Except VSCode most certainly does not have great performance. I can open the same set of files in VSCode and Sublime, and Sublime will use a few hundred MB of memory while VSCode uses well over 1 GB. That's not acceptable.

computershit 3y ago

Adobe Air, anyone?