5 ms·

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 abstrac

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.
- esprehn 6y ago
  > [...] the browser runtime environment which includes a slow and complex DOM Counter to this narrative the DOM is very fast, and compared to many other platforms it's much faster at displaying a large number of views and then resizing and reflowing them. ex. Android warns when there's more than 80 Views, meanwhile Gmail is 3500 DOM elements and the new "fast" Facebook is ~6000 DOM elements. Neither of those apps spends the majority of their time in the browser code on load, it's almost entirely JS. Facebook spends 3 seconds running script on page load on my $3k Macbook Pro. That's not because the DOM is slow, that's because Facebook runs a lot of JS on startup. If you cut down to the metal browsers can be quite fast, ex. https://browserbench.org/MotionMark/ https://browserbench.org/MotionMark/

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.
esprehn 6y ago
> [...] the browser runtime environment which includes a slow and complex DOM Counter to this narrative the DOM is very fast, and compared to many other platforms it's much faster at displaying a large number of views and then resizing and reflowing them. ex. Android warns when there's more than 80 Views, meanwhile Gmail is 3500 DOM elements and the new "fast" Facebook is ~6000 DOM elements. Neither of those apps spends the majority of their time in the browser code on load, it's almost entirely JS. Facebook spends 3 seconds running script on page load on my $3k Macbook Pro. That's not because the DOM is slow, that's because Facebook runs a lot of JS on startup. If you cut down to the metal browsers can be quite fast, ex. https://browserbench.org/MotionMark/ https://browserbench.org/MotionMark/