3 ms·

Most of those problems could be avoided by using higher refresh rate. 120+Hz is pretty common in gaming and phones. In reality we render stuff with slow javasc

Most of those problems could be avoided by using higher refresh rate. 120+Hz is pretty common in gaming and phones. In reality we render stuff with slow javascript. Latency after key press may not be 16ms, but 16 seconds.

colordrops 6y ago
Hate to go down this road, but JavaScript is anything but slow. What is slow is the layer upon layer of complexity + poor coding of many web apps. That's not an exclusive problem to JavaScript.
- nikki93 6y ago
  There is some amount of overhead in the VM due to the dynamic nature of JavaScript values and the need for a GC that can't be avoided (even though VM implementations have had years of effort and optimization put in to address this). You can get around a lot of this by using WASM and having control over the data layout though. In my experiments some times the browser just kicks in and drops some frames in any case. :/ Things just feel a lot smoother in native apps always. Figma for example is doing a pretty good job with a C++ engine running in WASM and using WebGL for their canvas (https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...).
  - colordrops 6y ago
    It can be avoided to a degree if you understand how JavaScript memory allocation works for a particular VM, and use custom methods instead of built-ins for certain operations, to avoid the overhead of the generalized nature of the built-in.
    - nikki93 6y ago
      You might reduce it for sure, but you aren't going to avoid it entirely. The best is when it gets to a tracing JIT and all of the calls have a similar codepath. And the fact that you need to jump through hoops like this instead of just writing normal code and expect it to do only what you're saying instead of doing a bunch of other stuff too, is part of the problem. Like, what you are saying, is exactly the point: the default method of working introduces performance issues and makes it hard to reason about performance in a way that is predictable, requiring you to understand VM internals and just 'hope' that the runtime works it out. So you are essentially saying that the default path is slower. It's also hard to ensure that your objects have a predictable layout in memory (important for cache issues) other than by just using a `TypedArray` and re-inventing structs within that. The semantics of JS itself make certain optimizations hard. Even a simple VM can do arithmetic faster than no-JIT Node.js and JSC: https://godbolt.org/z/5GbhnK https://godbolt.org/z/5GbhnK (an example I've been working on lately) (I'm interested in no-JIT perf because that's what you're allowed to do in your own runtime on iOS). LuaJIT is the best at this, and even there Lua's semantics prevent certain optimizations--https://news.ycombinator.com/item?id=11327201 https://news.ycombinator.com/item?id=11327201 I think you can do a lot better with a bytecode that is more 'typed', like in SPIR-V: https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#OpTypeVoid https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html...
      - colordrops 6y ago
        Everything you say is correct, but I was just addressing the statement that "it can't be avoided".
        nikki93 6y ago
        For sure, I think you can mitigate it, but I would take that as being different from avoidance (simply because there are other languages / runtimes where there is clear actual avoidance). Regardless I think we have enough details in the conversation at this point to understand what each other is saying. :)
        colordrops 6y ago
        Yes, for sure :)
- jcelerier 6y ago
  > Hate to go down this road, but JavaScript is anything but slow. What is slow is the layer upon layer of complexity + poor coding of many web apps. That's not an exclusive problem to JavaScript. where are those fast javascript apps ? where ? compare the super snappiness of a Telegram Desktop with molasses $every_other_chat_client_using_electron for instance. And if you are gonna say that VSCode is fast you have no idea how truly fast software feels like - if you come across try a QNX 6 demo iso and be amazed at how fast your computer answers to literally everything.
  - colordrops 6y ago
    That doesn't contradict my statement at all. The problems you speak of are due to the browser runtime, not JavaScript.
    - jcelerier 6y ago
      What makes you say that they aren't also due to the kind of programming style that JS encourages ? Also, my anecdotal experience writing some audio algorithms in pure JS is that it's ... not an order of magnitude, but not far away, from the performance of the same code written in C++ with std::vector<double>s. Likely there's some magic that could be done to improve it, but the C++ code is written naïvely and ends up extremely well optimized.
  - pjmlp 6y ago
    VSCode seems fast until one starts Notepad++ or Sublime Text. Microsoft's React Native team has charts where it shows Electron has 300x slowdown versus native applications.
- Diggsey 6y ago
  The poor coding is one thing, but it's javascript's fault that layers of complexity inherently result in performance losses beyond those caused by leaky abstractions.
  - colordrops 6y ago
    JavaScript is just a programming language with the same constructs as any other. And it's much faster than most languages, especially dynamically typed languages. It sounds like you don't understand how a browser works. Performance issues are typically due to the browser runtime environment which includes a slow and complex DOM. JavaScript will mop up most CLI apps in performance, including python and ruby, and will get close in perf to C if written carefully.
    - rcoveson 6y ago
      > JavaScript will mop up most CLI apps in performance I'll bet half the coreutils are a minimum of 10x slower in their day-to-day use cases (i.e. small n) when re-implemented in any interpreted language like JS. Cold start overhead matters a lot for CLI programs.
    - baybal2 6y ago
      > JavaScript will mop up most CLI apps in performance, including python and ruby, and will get close in perf to C if written carefully. asm.js is what you mean? If you so, you are not better to handwriting an assembly yourself. I am kind of an involuntary webdev from time to time, and I am often the one invited to fix consequences of coding under influence, like a decision to write a GPS server with 100k+ packets per second load in Javascript. People claiming that JS can be made be as fast as C have no idea at all what they say. Even Java with hand-jacked VM is easier to scale for such load than a JS server reduced to 1k lines of vanilla JS, using all and every performance trick Nodejs provides.
      - colordrops 6y ago
        No I don't mean asm.js. You can write vanilla JS that avoids memory allocation beyond initialization as well as garbage collection, and runs certain algorithms faster than typical C due to differences such as JIT optimizations or the lack of a sentinel to terminate strings, etc. My point was never to say that JS is in general as fast as C, only that a careful dev that is familiar with the VM's operation can get close for some tasks.
- jankotek 6y ago
  Giants like Airbnb have resources to write fast and responsive apps. But it is still slow. There is no point to worry about 16ms latency, if web app refreshes 6x times just to load couple of images.

colordrops 6y ago

Hate to go down this road, but JavaScript is anything but slow. What is slow is the layer upon layer of complexity + poor coding of many web apps. That's not an exclusive problem to JavaScript.

nikki93 6y ago
There is some amount of overhead in the VM due to the dynamic nature of JavaScript values and the need for a GC that can't be avoided (even though VM implementations have had years of effort and optimization put in to address this). You can get around a lot of this by using WASM and having control over the data layout though. In my experiments some times the browser just kicks in and drops some frames in any case. :/ Things just feel a lot smoother in native apps always. Figma for example is doing a pretty good job with a C++ engine running in WASM and using WebGL for their canvas (https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...).
- colordrops 6y ago
  It can be avoided to a degree if you understand how JavaScript memory allocation works for a particular VM, and use custom methods instead of built-ins for certain operations, to avoid the overhead of the generalized nature of the built-in.
  - nikki93 6y ago
    You might reduce it for sure, but you aren't going to avoid it entirely. The best is when it gets to a tracing JIT and all of the calls have a similar codepath. And the fact that you need to jump through hoops like this instead of just writing normal code and expect it to do only what you're saying instead of doing a bunch of other stuff too, is part of the problem. Like, what you are saying, is exactly the point: the default method of working introduces performance issues and makes it hard to reason about performance in a way that is predictable, requiring you to understand VM internals and just 'hope' that the runtime works it out. So you are essentially saying that the default path is slower. It's also hard to ensure that your objects have a predictable layout in memory (important for cache issues) other than by just using a `TypedArray` and re-inventing structs within that. The semantics of JS itself make certain optimizations hard. Even a simple VM can do arithmetic faster than no-JIT Node.js and JSC: https://godbolt.org/z/5GbhnK https://godbolt.org/z/5GbhnK (an example I've been working on lately) (I'm interested in no-JIT perf because that's what you're allowed to do in your own runtime on iOS). LuaJIT is the best at this, and even there Lua's semantics prevent certain optimizations--https://news.ycombinator.com/item?id=11327201 https://news.ycombinator.com/item?id=11327201 I think you can do a lot better with a bytecode that is more 'typed', like in SPIR-V: https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html#OpTypeVoid https://www.khronos.org/registry/spir-v/specs/1.0/SPIRV.html...
    - colordrops 6y ago
      Everything you say is correct, but I was just addressing the statement that "it can't be avoided".
      - nikki93 6y ago
        For sure, I think you can mitigate it, but I would take that as being different from avoidance (simply because there are other languages / runtimes where there is clear actual avoidance). Regardless I think we have enough details in the conversation at this point to understand what each other is saying. :)
        colordrops 6y ago
        Yes, for sure :)
jcelerier 6y ago
> Hate to go down this road, but JavaScript is anything but slow. What is slow is the layer upon layer of complexity + poor coding of many web apps. That's not an exclusive problem to JavaScript. where are those fast javascript apps ? where ? compare the super snappiness of a Telegram Desktop with molasses $every_other_chat_client_using_electron for instance. And if you are gonna say that VSCode is fast you have no idea how truly fast software feels like - if you come across try a QNX 6 demo iso and be amazed at how fast your computer answers to literally everything.
- colordrops 6y ago
  That doesn't contradict my statement at all. The problems you speak of are due to the browser runtime, not JavaScript.
  - jcelerier 6y ago
    What makes you say that they aren't also due to the kind of programming style that JS encourages ? Also, my anecdotal experience writing some audio algorithms in pure JS is that it's ... not an order of magnitude, but not far away, from the performance of the same code written in C++ with std::vector<double>s. Likely there's some magic that could be done to improve it, but the C++ code is written naïvely and ends up extremely well optimized.
- pjmlp 6y ago
  VSCode seems fast until one starts Notepad++ or Sublime Text. Microsoft's React Native team has charts where it shows Electron has 300x slowdown versus native applications.
Diggsey 6y ago
The poor coding is one thing, but it's javascript's fault that layers of complexity inherently result in performance losses beyond those caused by leaky abstractions.
- colordrops 6y ago
  JavaScript is just a programming language with the same constructs as any other. And it's much faster than most languages, especially dynamically typed languages. It sounds like you don't understand how a browser works. Performance issues are typically due to the browser runtime environment which includes a slow and complex DOM. JavaScript will mop up most CLI apps in performance, including python and ruby, and will get close in perf to C if written carefully.
  - rcoveson 6y ago
    > JavaScript will mop up most CLI apps in performance I'll bet half the coreutils are a minimum of 10x slower in their day-to-day use cases (i.e. small n) when re-implemented in any interpreted language like JS. Cold start overhead matters a lot for CLI programs.
  - baybal2 6y ago
    > JavaScript will mop up most CLI apps in performance, including python and ruby, and will get close in perf to C if written carefully. asm.js is what you mean? If you so, you are not better to handwriting an assembly yourself. I am kind of an involuntary webdev from time to time, and I am often the one invited to fix consequences of coding under influence, like a decision to write a GPS server with 100k+ packets per second load in Javascript. People claiming that JS can be made be as fast as C have no idea at all what they say. Even Java with hand-jacked VM is easier to scale for such load than a JS server reduced to 1k lines of vanilla JS, using all and every performance trick Nodejs provides.
    - colordrops 6y ago
      No I don't mean asm.js. You can write vanilla JS that avoids memory allocation beyond initialization as well as garbage collection, and runs certain algorithms faster than typical C due to differences such as JIT optimizations or the lack of a sentinel to terminate strings, etc. My point was never to say that JS is in general as fast as C, only that a careful dev that is familiar with the VM's operation can get close for some tasks.
jankotek 6y ago
Giants like Airbnb have resources to write fast and responsive apps. But it is still slow. There is no point to worry about 16ms latency, if web app refreshes 6x times just to load couple of images.