9 ms·

Game developers know how to make smooth and performant UI, to say nothing of the rest of what goes into writing a game engine, particularly a fast GPU-accelerat

Game developers know how to make smooth and performant UI, to say nothing of the rest of what goes into writing a game engine, particularly a fast GPU-accelerated engine. I’m starting to think it’s primarily a cultural thing, where it’s just become acceptable in the web dev and Electron app world to ship sluggish, resource-intensive apps. I also feel like more corners are cut and performance issues swept under the rug when devs are not staring down the barrel of the hardware on a daily basis.

arethuza 6y ago
VS Code uses Electron and I can't say I've noticed any performance problems with it - indeed it is quite a bit faster for me than its native-code relative Visual Studio. So responsive Electron apps are certainly possible.
- baybal2 6y ago
  Vs code is an antiexample here. The whole point for then from the start was to not to repeat the Atom fiasco. The entirety of the project was running around of making Webkit not suck. They spent ennormous effort on that.
  - e_proxus 6y ago
    That being said, I immediately notice when switching from Sublime to VS Code. It’s something in the key presses... I think it’s only noticeable if you’ve used a native application for a while. It’s not enough to go from VSC to Sublime and back to VSC again for five minutes. Make an effort to use a native app for a week or a month and then switch back.
    - disgruntledphd2 6y ago
      I noticed this a bunch when I moved from emacs to Jupyter notebook. Emacs will sometimes become slower (especially remote emacs), but it will always buffer your keypresses and do them in the correct order. Jupyter (for whatever reason), doesn't do this with the result that I ended up wanting to create a new code block, but that keypress got lost and then i end up ruining my original code block. I 100% noticed the difference, and it was super frustrating (fortunately I left that job, and have managed to avoid Jupyter in the new gig).
      - pdimitar 6y ago
        I am using Spacemacs and have spent days trying to make it work faster (I am on macOS). Took a while and some effort but with a few strange tweaks I managed to make it more responsive. Emacs/Spacemacs can still be weirdly slow sometimes but UI responsiveness is generally miles ahead of all Electron-based software still. Which makes it even funnier. Emacs is decades old and still uses quite a few ancient techniques that are only hampering it. Even with that, it's still so much better in terms of speed! Funny.
    - deleted 6y ago
      [deleted]
  - schmorptron 6y ago
    Wait, what is the atom fiasco?
    - foldr 6y ago
      Atom (https://atom.io/ https://atom.io/) is another Electron-based text editor release by GitHub (before it was acquired by Microsoft). I think it predated VSCode. It certainly had more mindshare in the early days. But whereas VSCode has always been quite snappy, Atom acquired a reputation for poor performance.
      - zwirbl 6y ago
        Pretty much like that, I tried Atom once (when I found platform.io and wanted to have a look) and it was just wild how slow it felt. On the upside, it made using those crappy Eclipse forks MCU manufacturers release (like CCC, Dave, etc.) fell a lot less painful
      - Rapzid 6y ago
        > another Electron-based text editor Well electron used to be called "atom shell" :)
        foldr 6y ago
        Ah good point. I didn't know that.
      - WorldMaker 6y ago
        > I think it predated VSCode Yes, and no. They have a really interesting tale of convergent evolution. Atom was the original Electron app (as pointed out Electron was even originally named "atom-shell"), so it predates VSCode as an Electron app. But the extremely performant "Monaco code editor" that VSCode was built on top of (that forms the heart of VSCode) was started at Microsoft years before to be a code editor in parts of the Azure Portal, and also it was the code editor in IE/Edge dev tools from as far back as IE 9 or 10 I think it was (up until the Chromium Edge). It wasn't packaged into an Electron app until after Atom, but it has an interesting heritage that predates Atom and was built for some of the same reasons that GitHub wanted to build Atom. (ETA: Monaco's experience especially in IE Dev Tools and the wild west of minified JS dumps it had to work with from day one in that environment is where a lot of its performance came from that led VSCode to jumping Atom on performance out of the gate.)
- tonyedgecombe 6y ago
  VS Code has a lot of native code and VS is particularly bloated. I'm not sure this is a good comparison.
  - sime2009 6y ago
    VS Code has very little native code outside Electron itself.
    - WorldMaker 6y ago
      Depends on which languages you work with. Many language servers are written in their own languages so it is possible to work with a lot of native code when using VS Code day to day even if most of VS Code itself isn't native code. VS Code also used to have far more native code earlier on in its development life, but seems to be transitioning a lot of it to WASM (paralleling the Node ecosystem as a whole moving a lot of performance heavy stuff from native NAPI plugins to WASM boxes; as one example: the major source maps support library moved from JS native to Rust to WASM compiled from Rust, IIRC).
- robenkleene 6y ago
  I'm very interested in the general perception of VS Code being fast, because for me it's slow enough that it's the main reason I use other editors. Here are a couple of examples: 1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993 https://twitter.com/robenkleene/status/1285631026648276993 2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889 https://twitter.com/robenkleene/status/1257724392458661889 Both of the above examples revolve around opening files for the first time, and I suspect a lot of the slowness I perceive is because I open a lot of different projects and source code files when I'm working, and this is a bad use of VS Code. In practice, VS Code behaves more like a multi-language IDE than a text editor. Slow startup times are generally acceptable in IDEs because you're exchanging speed for power. A programmer should ideally be proficient in both an IDE and a text editor, because they're tools applicable to different problems. E.g., VS Code is a terrible choice for things like analyzing log output, formatting large files, testing isolated snippets of code, or working on source code files that aren't part of the same project. I find this to be a shame because VS Code is flexible enough that it would otherwise be excellent for all of these tasks if it were just more performant for some operations that it struggles with now.
  - arethuza 6y ago
    Out of interest do you mean starting a new instance of VS Code for those things or using an existing one. I would agree that VS Code isn't the fastest thing when the editor is starting up, though I find it fine when started. I pretty much always have VS Code running so I don't find this a problem.
    - robenkleene 6y ago
      VS Code is already running in both examples. A lot of the overhead seems to come from making a new window (even though the app itself is already running), although notably most of the time spent in the Prettier example seems to be spent syntax highlighting the JavaScript. If you want to try a direct comparison of opening a file vs. a window, you can see the difference between opening a new file in an existing window (on Mac, `⌘N` / `File > New File`) or new window (on Mac, `⌥⌘N` / `File > New Window`). For me the latter is far slower than the former.
skohan 6y ago
Given the state and culture of web development, it's honestly a travesty that most software is consumed via the web currently. I mean the web stack itself was never designed per se. HTML is essentially a text annotation format, which has been abused to support the needs of arbitrary layouts. The weakness of CSS is evident by how difficult it has been to properly center something within a container until relatively recently. And Javascript was literally designed in a week. And then in terms of deploying web content, you have this situation where you have multiple browsers which are moving targets, so you can't even really just target raw HTML+CSS+JS if you want to deploy something - you need a tool like webpack to take care of all the compatibility issues, and translate a tool which is actually usable like React into an artifact which will behave predictably across all environments. I don't blame web developers for abusing libraries, because it's almost impossible to strip it all down and work with the raw interfaces. The whole thing is an enormous hack. If you view your job as a programmer as writing code to drive computer hardware - which is what the true reality of programming is - then web development is so far divorced from that. I think it's a huge problem.
- grishka 6y ago
  What about those weirdos who deliberately choose to use the abomination that the web stack is for desktop apps? To me it feels like they're trying to write real GUI apps in Word macros. I don't think I'll ever understand why.
  - skohan 6y ago
    In some ways I can I understand it, because if you want to deploy a GUI application which mostly consists of text and pictures across multiple platforms, this is probably most viable option in a lot of cases, but the fact that this is the case is a failure of the market and the industry
    - josephg 6y ago
      Yep. Native software development houses never invested enough in making a cross platform app toolkit as good as the web. There’s no technical reason why we don’t have something like electron, but lightweight and without javascript. But native-feeling cross platform UI is really hard (like $100M+ hard) and no individual company cares enough to make it happen. I’m sure it would be a great investment for the industry as a whole, but every actor with the resources is incentivised to solve their problems using different approaches. It’s pretty disappointing.
jiggawatts 6y ago
I used to write 4K demos and the like in assembly, and I wrote a 3D engine in the era where you still thought hard about making something a function call or not because... you know... those fractions of a microseconds add up, and next thing you know you've blown your 16.6ms frame time budget! These days I see people casually adding network hops to web applications like it's nothing. These actually take multiple milliseconds in common scenarios such as cloud hosting on a PaaS. (I measured. Have you?) At that point it's not even relevant how fast your CPUs are, you're blowing your "time budget" in just a handful of remote function calls. If you stop and think about it, the "modern" default protocol stack for a simple function consists of: - Creating an object graph scattered randomly on the heap - Serialising it with dynamic reflection ...to a *text* format! ...written into a dynamically resizing buffer - Gzip compressing it to another resizing buffer - Encrypting it to stop the spies in the data centre - Buffering - Kernel transition - Buffering again in the NIC - Router(s) - Firewall(s) - Load balancer and then the reverse of the above for the data to be received! then the forward -- and -- backwards stack -- again -- for the response If this isn't insanity, I don't know what is...
- baybal2 6y ago
  Hello, Can you tell what is your occupation? Are you dealing with assembler level programming regularly?
  - jiggawatts 6y ago
    Not any more, these days I do various kinds of systems integration work and I still dabble in development, but mostly with high-level languages like C#. It just grinds me gears that we have all these wonderfully fast computers and we're just throwing the performance away. My analogy to customers where I consult is this: What you're doing is like buying a dozen sticks of RAM, and then throwing ten of them into the trash. It's like pouring superglue into all but a couple of the switch ports. It's like buying a 64-core CPU and disabling 63 of those cores. It's like putting some of the servers on the Moon instead of next to each other in the same rack. Said like that, modern development practices and infrastructure architectures suddenly sound as insane as they truly are.
moron4hire 6y ago
I've started noticing a weird counter effect. If you make a web app that is snappy and responsive, people just assume your app is trivial. Users have effectively been trained into thinking things like list pagination are "difficult" operations.
- sidpatil 6y ago
  Maybe that's like the tech equivalent of enjoying a loud vehicle because it sounds more powerful than a quieter one. (In reality, the quieter one is more efficient than the louder one.)
lewispollard 6y ago
You'd be surprised how many games up until recently used Flash (Scaleform GFx), and now in some cases HTML5 (edit: Coherent GT/Hummingbird/Gameface) content for game UI. Rendering hundreds or thousands of meshes and doing complicated 3D math for physics is no problem, UI is still extremely hard and complex, especially if you are supporting multiple arbitrary resolutions for example. Godot, for example, has a full UI toolkit built in (the Godot editor was made using Godot components). However to actually get it working the way you want in most cases is a horrendous struggle, a struggle with ratios, screen sizes, minimum and maximum UI control sizes, size/growth flags, and before it gets any more complicated please just throw me a Tailwind flex/grid box model instead, because HTML/CSS has solved these problems repeatedly already.

arethuza 6y ago

VS Code uses Electron and I can't say I've noticed any performance problems with it - indeed it is quite a bit faster for me than its native-code relative Visual Studio. So responsive Electron apps are certainly possible.

baybal2 6y ago
Vs code is an antiexample here. The whole point for then from the start was to not to repeat the Atom fiasco. The entirety of the project was running around of making Webkit not suck. They spent ennormous effort on that.
- e_proxus 6y ago
  That being said, I immediately notice when switching from Sublime to VS Code. It’s something in the key presses... I think it’s only noticeable if you’ve used a native application for a while. It’s not enough to go from VSC to Sublime and back to VSC again for five minutes. Make an effort to use a native app for a week or a month and then switch back.
  - disgruntledphd2 6y ago
    I noticed this a bunch when I moved from emacs to Jupyter notebook. Emacs will sometimes become slower (especially remote emacs), but it will always buffer your keypresses and do them in the correct order. Jupyter (for whatever reason), doesn't do this with the result that I ended up wanting to create a new code block, but that keypress got lost and then i end up ruining my original code block. I 100% noticed the difference, and it was super frustrating (fortunately I left that job, and have managed to avoid Jupyter in the new gig).
    - pdimitar 6y ago
      I am using Spacemacs and have spent days trying to make it work faster (I am on macOS). Took a while and some effort but with a few strange tweaks I managed to make it more responsive. Emacs/Spacemacs can still be weirdly slow sometimes but UI responsiveness is generally miles ahead of all Electron-based software still. Which makes it even funnier. Emacs is decades old and still uses quite a few ancient techniques that are only hampering it. Even with that, it's still so much better in terms of speed! Funny.
  - deleted 6y ago
    [deleted]
- schmorptron 6y ago
  Wait, what is the atom fiasco?
  - foldr 6y ago
    Atom (https://atom.io/ https://atom.io/) is another Electron-based text editor release by GitHub (before it was acquired by Microsoft). I think it predated VSCode. It certainly had more mindshare in the early days. But whereas VSCode has always been quite snappy, Atom acquired a reputation for poor performance.
    - zwirbl 6y ago
      Pretty much like that, I tried Atom once (when I found platform.io and wanted to have a look) and it was just wild how slow it felt. On the upside, it made using those crappy Eclipse forks MCU manufacturers release (like CCC, Dave, etc.) fell a lot less painful
    - Rapzid 6y ago
      > another Electron-based text editor Well electron used to be called "atom shell" :)
      - foldr 6y ago
        Ah good point. I didn't know that.
    - WorldMaker 6y ago
      > I think it predated VSCode Yes, and no. They have a really interesting tale of convergent evolution. Atom was the original Electron app (as pointed out Electron was even originally named "atom-shell"), so it predates VSCode as an Electron app. But the extremely performant "Monaco code editor" that VSCode was built on top of (that forms the heart of VSCode) was started at Microsoft years before to be a code editor in parts of the Azure Portal, and also it was the code editor in IE/Edge dev tools from as far back as IE 9 or 10 I think it was (up until the Chromium Edge). It wasn't packaged into an Electron app until after Atom, but it has an interesting heritage that predates Atom and was built for some of the same reasons that GitHub wanted to build Atom. (ETA: Monaco's experience especially in IE Dev Tools and the wild west of minified JS dumps it had to work with from day one in that environment is where a lot of its performance came from that led VSCode to jumping Atom on performance out of the gate.)
tonyedgecombe 6y ago
VS Code has a lot of native code and VS is particularly bloated. I'm not sure this is a good comparison.
- sime2009 6y ago
  VS Code has very little native code outside Electron itself.
  - WorldMaker 6y ago
    Depends on which languages you work with. Many language servers are written in their own languages so it is possible to work with a lot of native code when using VS Code day to day even if most of VS Code itself isn't native code. VS Code also used to have far more native code earlier on in its development life, but seems to be transitioning a lot of it to WASM (paralleling the Node ecosystem as a whole moving a lot of performance heavy stuff from native NAPI plugins to WASM boxes; as one example: the major source maps support library moved from JS native to Rust to WASM compiled from Rust, IIRC).
robenkleene 6y ago
I'm very interested in the general perception of VS Code being fast, because for me it's slow enough that it's the main reason I use other editors. Here are a couple of examples: 1. It takes nine times as long as Vim to open a minified JavaScript file, and then format it with Prettier: https://twitter.com/robenkleene/status/1285631026648276993 https://twitter.com/robenkleene/status/1285631026648276993 2. It takes 14 times as long to open an empty text file than BBEdit: https://twitter.com/robenkleene/status/1257724392458661889 https://twitter.com/robenkleene/status/1257724392458661889 Both of the above examples revolve around opening files for the first time, and I suspect a lot of the slowness I perceive is because I open a lot of different projects and source code files when I'm working, and this is a bad use of VS Code. In practice, VS Code behaves more like a multi-language IDE than a text editor. Slow startup times are generally acceptable in IDEs because you're exchanging speed for power. A programmer should ideally be proficient in both an IDE and a text editor, because they're tools applicable to different problems. E.g., VS Code is a terrible choice for things like analyzing log output, formatting large files, testing isolated snippets of code, or working on source code files that aren't part of the same project. I find this to be a shame because VS Code is flexible enough that it would otherwise be excellent for all of these tasks if it were just more performant for some operations that it struggles with now.
- arethuza 6y ago
  Out of interest do you mean starting a new instance of VS Code for those things or using an existing one. I would agree that VS Code isn't the fastest thing when the editor is starting up, though I find it fine when started. I pretty much always have VS Code running so I don't find this a problem.
  - robenkleene 6y ago
    VS Code is already running in both examples. A lot of the overhead seems to come from making a new window (even though the app itself is already running), although notably most of the time spent in the Prettier example seems to be spent syntax highlighting the JavaScript. If you want to try a direct comparison of opening a file vs. a window, you can see the difference between opening a new file in an existing window (on Mac, `⌘N` / `File > New File`) or new window (on Mac, `⌥⌘N` / `File > New Window`). For me the latter is far slower than the former.

skohan 6y ago

Given the state and culture of web development, it's honestly a travesty that most software is consumed via the web currently. I mean the web stack itself was never designed per se. HTML is essentially a text annotation format, which has been abused to support the needs of arbitrary layouts. The weakness of CSS is evident by how difficult it has been to properly center something within a container until relatively recently. And Javascript was literally designed in a week. And then in terms of deploying web content, you have this situation where you have multiple browsers which are moving targets, so you can't even really just target raw HTML+CSS+JS if you want to deploy something - you need a tool like webpack to take care of all the compatibility issues, and translate a tool which is actually usable like React into an artifact which will behave predictably across all environments. I don't blame web developers for abusing libraries, because it's almost impossible to strip it all down and work with the raw interfaces. The whole thing is an enormous hack. If you view your job as a programmer as writing code to drive computer hardware - which is what the true reality of programming is - then web development is so far divorced from that. I think it's a huge problem.

grishka 6y ago
What about those weirdos who deliberately choose to use the abomination that the web stack is for desktop apps? To me it feels like they're trying to write real GUI apps in Word macros. I don't think I'll ever understand why.
- skohan 6y ago
  In some ways I can I understand it, because if you want to deploy a GUI application which mostly consists of text and pictures across multiple platforms, this is probably most viable option in a lot of cases, but the fact that this is the case is a failure of the market and the industry
  - josephg 6y ago
    Yep. Native software development houses never invested enough in making a cross platform app toolkit as good as the web. There’s no technical reason why we don’t have something like electron, but lightweight and without javascript. But native-feeling cross platform UI is really hard (like $100M+ hard) and no individual company cares enough to make it happen. I’m sure it would be a great investment for the industry as a whole, but every actor with the resources is incentivised to solve their problems using different approaches. It’s pretty disappointing.

jiggawatts 6y ago

I used to write 4K demos and the like in assembly, and I wrote a 3D engine in the era where you still thought hard about making something a function call or not because... you know... those fractions of a microseconds add up, and next thing you know you've blown your 16.6ms frame time budget! These days I see people casually adding network hops to web applications like it's nothing. These actually take multiple milliseconds in common scenarios such as cloud hosting on a PaaS. (I measured. Have you?) At that point it's not even relevant how fast your CPUs are, you're blowing your "time budget" in just a handful of remote function calls. If you stop and think about it, the "modern" default protocol stack for a simple function consists of: - Creating an object graph scattered randomly on the heap - Serialising it with dynamic reflection ...to a *text* format! ...written into a dynamically resizing buffer - Gzip compressing it to another resizing buffer - Encrypting it to stop the spies in the data centre - Buffering - Kernel transition - Buffering again in the NIC - Router(s) - Firewall(s) - Load balancer and then the reverse of the above for the data to be received! then the forward -- and -- backwards stack -- again -- for the response If this isn't insanity, I don't know what is...

baybal2 6y ago
Hello, Can you tell what is your occupation? Are you dealing with assembler level programming regularly?
- jiggawatts 6y ago
  Not any more, these days I do various kinds of systems integration work and I still dabble in development, but mostly with high-level languages like C#. It just grinds me gears that we have all these wonderfully fast computers and we're just throwing the performance away. My analogy to customers where I consult is this: What you're doing is like buying a dozen sticks of RAM, and then throwing ten of them into the trash. It's like pouring superglue into all but a couple of the switch ports. It's like buying a 64-core CPU and disabling 63 of those cores. It's like putting some of the servers on the Moon instead of next to each other in the same rack. Said like that, modern development practices and infrastructure architectures suddenly sound as insane as they truly are.

moron4hire 6y ago

I've started noticing a weird counter effect. If you make a web app that is snappy and responsive, people just assume your app is trivial. Users have effectively been trained into thinking things like list pagination are "difficult" operations.

sidpatil 6y ago
Maybe that's like the tech equivalent of enjoying a loud vehicle because it sounds more powerful than a quieter one. (In reality, the quieter one is more efficient than the louder one.)

lewispollard 6y ago

You'd be surprised how many games up until recently used Flash (Scaleform GFx), and now in some cases HTML5 (edit: Coherent GT/Hummingbird/Gameface) content for game UI. Rendering hundreds or thousands of meshes and doing complicated 3D math for physics is no problem, UI is still extremely hard and complex, especially if you are supporting multiple arbitrary resolutions for example. Godot, for example, has a full UI toolkit built in (the Godot editor was made using Godot components). However to actually get it working the way you want in most cases is a horrendous struggle, a struggle with ratios, screen sizes, minimum and maximum UI control sizes, size/growth flags, and before it gets any more complicated please just throw me a Tailwind flex/grid box model instead, because HTML/CSS has solved these problems repeatedly already.