6 ms·

I am not sure how you come to this conclusion. JS and the DOM are fast. Aside from arithmetic JS is just as fast as Java now and only 2-4x slower than C++. The

I am not sure how you come to this conclusion. JS and the DOM are fast. Aside from arithmetic JS is just as fast as Java now and only 2-4x slower than C++. The two big limitations from a pure processing perspective are the garbage collector and massive repaints of large data on large layouts.

pjmlp 3y ago
As fast as Java?!? Better tell Google to dump Android and focus on ChromeOS then.
- austin-cheney 3y ago
  Yes. This has been the case for at least the last 5 years. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - Xeamek 3y ago
    Synthetic benchmarks for some algorithms have little to do with actual performance of real life applications
    - cuu508 3y ago
      What method do you propose to compare the performance of different programming languages?
      - Xeamek 3y ago
        While still far from perfect, benchmarks comparing actual, practical usage, like the ammount of request served by webservers for example, are much better indicators imo. https://web-frameworks-benchmark.netlify.app/result https://web-frameworks-benchmark.netlify.app/result
        oldpersonintx 3y ago
        [dead]
    - d3w4s9 3y ago
      Yeah everyone says that and stops there which is absolutely useless. Benchmarks are at least objective ways to measure something. And there are no "correct" benchmarks. Unless you have better metrics or another way to prove things, please stop repeating these meaningless words
      - Xeamek 3y ago
        I've literally pasted benchmarks measuring actual job (webserver request per second) in a comment below. But besides, the critique isn't meaningless even without providing a better one; If your benchmark is measuring things that are trivial no matter the language (like stack-based operations), but ignores things that actually differ meaningfully (like handling of heap objects), then criticizing such aproach is perfectly fair and valid objection
  - trust_bt_verify 3y ago
    These benchmarks include startup time _and_ processing time when comparing languages. I don’t believe that is telling a very compelling story given JS is still slightly slower than most of the Java metrics unless you are looking for a new language to write your lambdas.
  - pjmlp 3y ago
    I only see random Java in synthetic benchmarks, without testing all variations of JIT and AOT compilers available throughout the ecosystem. OpenJDK, GraalVM, OpenJ9, Azul, PTC, Aicas, ART, JikesRVM,.... Not to mention the optimizations that a dynamic language like JavaScript will never be able to take advantage of.
    - igouy 3y ago
      ? openjdk, GraalVM, Corretto https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java-graalvm.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
      - pjmlp 3y ago
        Correcto is OpenJDK with Amazon branding, I left it out on purpose. Still, a dynamic language winning out a strongly typed one, only for those that don't have a clue about how compilers work, or how to write winning micro benchmarks.
- oldpersonintx 3y ago
  [dead]
troupo 3y ago
> I am not sure how you come to this conclusion. By knowing and working with more technologies than just web tech. "The most the most powerful layouting system and rendering engine" struggles to render even a few dozen elements on screen without junk, tearing and consuming as many resources as a mid-sized game. > JS and the DOM are fast. DOM is slow as molasses. There's a reason why all frameworks are going to great lengths to touch DOM as little as possible. A few billion dollars of development and hundreds of thousands of man-hours have optimized it beyond any reasonable expectations, but it's still unbelievably slow because of many architectural decisions rooted back in the 90s. It's a system designed to render a page of text with a couple of images in one rendering pass at the core, and no amount of hacks on top of it will make it a high-perfromant layout and rednering engine. > Aside from arithmetic JS is just as fast as Java now This has nothing to do with either layout or rendering > The two big limitations from a pure processing perspective are the garbage collector Has nothing to do with either layout or rendering > massive repaints of large data on large layouts. Where "large data" is measly thousands of elements. Massive repaints in DOM happen basiclly on any and all layouts and layout changes. And these changes are triggered by almost anything that happens in the DOM. There's a reason why any reasonable animation you can reliably do with DOM is to literally rip the element out of the layout context and render it independently because "the most powerful layout and re-rendering engine" cannot cope with re-calculating and re-rendering the layout for the entire page when you move elements around. Edit. Slightly more on this: - Rendering performance https://web.dev/articles/rendering-performance https://web.dev/articles/rendering-performance - Linked article, Stick to Compositor-Only Properties and Manage Layer Count https://web.dev/articles/stick-to-compositor-only-properties-and-manage-layer-count https://web.dev/articles/stick-to-compositor-only-properties... From the last article: there are only two properties that can be handled by the compositor alone, all others trigger either a re-flow+re-paint or a re-paint.
- austin-cheney 3y ago
  Please, don't guess at performance. My biggest learning about performance is that developers don't know how to measure it. The training is absent, the effort is too great, and then objectivity just isn't there. So, they guess, which typically just means making things up to qualify an unfounded assumption. Guessing at performance is wrong more than 80% of the time and when it is wrong there a decent chance it is wrong by one or more orders of magnitude. This is one of the key things that separates developers from product stake holders. The DOM is an in-memory object accessed via a standard API. Let's not over think this. The interesting thing about DOM access is that Firefox has held stable for at least the last 6 years showing no significant performance loss or increase. Chrome on the other hand less than 40% as fast as it used to be, but its execution of access via string parsing mechanisms, like query selectors, is several times faster than it used to be. To run your own tests see this micro-benchmark test: https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc
croes 3y ago
Could it be you forgot how fast native GUIs are? Every WebGUI I used lacks the snappiness of old school native ones.
- TuringTest 3y ago
  Native GUIs are fast, but they are not powerful. You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. The web browser gives you a full package with standardized commands to control all those aspects, which is also portable between different implementations. If your rendering needs are limited to a few buttons and a canvas on a fixed size, sure, go native GUI. But if you need to support multiple devices and resolutions, on-the-fly resizing, and layout of multiple complex screen sections, the browser is an unbeatable platform.
  - nvm0n2 3y ago
    Fixed resolution and size? Manual layout calculations? What was the last native GUI toolkit you used, Win32?
  - devbent 3y ago
    > You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. Even Java UIs supported dynamic layouts 20 years ago. C# had a flex box based layout (called flow layout) since 2006.
    - h4x0rr 3y ago
      Worse developer experience and worse style options though
      - bananaboy 3y ago
        I strongly disagree with that. WinForms is imho very easy to use.

pjmlp 3y ago

As fast as Java?!? Better tell Google to dump Android and focus on ChromeOS then.

austin-cheney 3y ago
Yes. This has been the case for at least the last 5 years. https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/javascript.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
- Xeamek 3y ago
  Synthetic benchmarks for some algorithms have little to do with actual performance of real life applications
  - cuu508 3y ago
    What method do you propose to compare the performance of different programming languages?
    - Xeamek 3y ago
      While still far from perfect, benchmarks comparing actual, practical usage, like the ammount of request served by webservers for example, are much better indicators imo. https://web-frameworks-benchmark.netlify.app/result https://web-frameworks-benchmark.netlify.app/result
      - oldpersonintx 3y ago
        [dead]
  - d3w4s9 3y ago
    Yeah everyone says that and stops there which is absolutely useless. Benchmarks are at least objective ways to measure something. And there are no "correct" benchmarks. Unless you have better metrics or another way to prove things, please stop repeating these meaningless words
    - Xeamek 3y ago
      I've literally pasted benchmarks measuring actual job (webserver request per second) in a comment below. But besides, the critique isn't meaningless even without providing a better one; If your benchmark is measuring things that are trivial no matter the language (like stack-based operations), but ignores things that actually differ meaningfully (like handling of heap objects), then criticizing such aproach is perfectly fair and valid objection
- trust_bt_verify 3y ago
  These benchmarks include startup time _and_ processing time when comparing languages. I don’t believe that is telling a very compelling story given JS is still slightly slower than most of the Java metrics unless you are looking for a new language to write your lambdas.
- pjmlp 3y ago
  I only see random Java in synthetic benchmarks, without testing all variations of JIT and AOT compilers available throughout the ecosystem. OpenJDK, GraalVM, OpenJ9, Azul, PTC, Aicas, ART, JikesRVM,.... Not to mention the optimizations that a dynamic language like JavaScript will never be able to take advantage of.
  - igouy 3y ago
    ? openjdk, GraalVM, Corretto https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/java-graalvm.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - pjmlp 3y ago
      Correcto is OpenJDK with Amazon branding, I left it out on purpose. Still, a dynamic language winning out a strongly typed one, only for those that don't have a clue about how compilers work, or how to write winning micro benchmarks.
oldpersonintx 3y ago
[dead]

troupo 3y ago

> I am not sure how you come to this conclusion. By knowing and working with more technologies than just web tech. "The most the most powerful layouting system and rendering engine" struggles to render even a few dozen elements on screen without junk, tearing and consuming as many resources as a mid-sized game. > JS and the DOM are fast. DOM is slow as molasses. There's a reason why all frameworks are going to great lengths to touch DOM as little as possible. A few billion dollars of development and hundreds of thousands of man-hours have optimized it beyond any reasonable expectations, but it's still unbelievably slow because of many architectural decisions rooted back in the 90s. It's a system designed to render a page of text with a couple of images in one rendering pass at the core, and no amount of hacks on top of it will make it a high-perfromant layout and rednering engine. > Aside from arithmetic JS is just as fast as Java now This has nothing to do with either layout or rendering > The two big limitations from a pure processing perspective are the garbage collector Has nothing to do with either layout or rendering > massive repaints of large data on large layouts. Where "large data" is measly thousands of elements. Massive repaints in DOM happen basiclly on any and all layouts and layout changes. And these changes are triggered by almost anything that happens in the DOM. There's a reason why any reasonable animation you can reliably do with DOM is to literally rip the element out of the layout context and render it independently because "the most powerful layout and re-rendering engine" cannot cope with re-calculating and re-rendering the layout for the entire page when you move elements around. Edit. Slightly more on this: - Rendering performance https://web.dev/articles/rendering-performance https://web.dev/articles/rendering-performance - Linked article, Stick to Compositor-Only Properties and Manage Layer Count https://web.dev/articles/stick-to-compositor-only-properties-and-manage-layer-count https://web.dev/articles/stick-to-compositor-only-properties... From the last article: there are only two properties that can be handled by the compositor alone, all others trigger either a re-flow+re-paint or a re-paint.

austin-cheney 3y ago
Please, don't guess at performance. My biggest learning about performance is that developers don't know how to measure it. The training is absent, the effort is too great, and then objectivity just isn't there. So, they guess, which typically just means making things up to qualify an unfounded assumption. Guessing at performance is wrong more than 80% of the time and when it is wrong there a decent chance it is wrong by one or more orders of magnitude. This is one of the key things that separates developers from product stake holders. The DOM is an in-memory object accessed via a standard API. Let's not over think this. The interesting thing about DOM access is that Firefox has held stable for at least the last 6 years showing no significant performance loss or increase. Chrome on the other hand less than 40% as fast as it used to be, but its execution of access via string parsing mechanisms, like query selectors, is several times faster than it used to be. To run your own tests see this micro-benchmark test: https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc https://jsbench.github.io/#b39045cacae8d8c4a3ec044e538533dc

croes 3y ago

Could it be you forgot how fast native GUIs are? Every WebGUI I used lacks the snappiness of old school native ones.

TuringTest 3y ago
Native GUIs are fast, but they are not powerful. You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. The web browser gives you a full package with standardized commands to control all those aspects, which is also portable between different implementations. If your rendering needs are limited to a few buttons and a canvas on a fixed size, sure, go native GUI. But if you need to support multiple devices and resolutions, on-the-fly resizing, and layout of multiple complex screen sections, the browser is an unbeatable platform.
- nvm0n2 3y ago
  Fixed resolution and size? Manual layout calculations? What was the last native GUI toolkit you used, Win32?
- devbent 3y ago
  > You have to specify a fixed resolution, fixed size, and more often than not calculate the layout yourself, or use very limited auto-layout features. Even Java UIs supported dynamic layouts 20 years ago. C# had a flex box based layout (called flow layout) since 2006.
  - h4x0rr 3y ago
    Worse developer experience and worse style options though
    - bananaboy 3y ago
      I strongly disagree with that. WinForms is imho very easy to use.