5 ms·

Please stop. What a nonsense. JS is a dynamic language where everything is a Hashtable. It will never be really fast as your structs won’t be in single cachelin

Please stop. What a nonsense. JS is a dynamic language where everything is a Hashtable. It will never be really fast as your structs won’t be in single cacheline, you won’t be able to calculate field address during compile time by pointer offsets. There’s no simd, no multithreading, no real arrays. JS is such a simple, dynamic language. It should just stay this way. Please stop bloating it with every feature that’s trendy this year. We already have classes that we didn’t need. We don’t need structs for sure.

tantalor 2y ago
High performance applications are already being written that depend on features like shared memory, but because the language has poor support for them then developers have to use ugly workarounds. This proposal solves that with built-in support. >It should just stay this way Counterpoint: JS has been evolving significantly, look at ES6 and ES8 in particular if you need help finding examples.
- rty32 2y ago
  Exactly. Without new features and syntaxes people would still be doing MyClass.prototype.method = function () { } like idiots. Such a meaningless argument for preventing progress.
  - szastamasta 2y ago
    Nobody needs classes nor prototypes in JS. Objects + functions is more than enough. I stopped using these few years ago and miss nothing.
    - rty32 2y ago
      IDE support is often hit or miss with these, I have seen too much of it. Don't use vscode or never bother to write jsdoc/do any strict typing? Never mind. Good luck with your codebase.
    - jitl 2y ago
      You and "anybody" are actually two different sets of people with different needs and desires
    - wruza 2y ago
      It is enough, but not more than. Collecting functions in a group by operating on a shared context is naturally useful and convenient. Pretending otherwise leads to all sorts of “a method, but I see it as a function with an accidental first parameter in a homonimous namespace because having a function name prefix is ugly, and it’s all ugly, but at least it’s not a class”. import * as fooNs from './foo' fooNs.barBazQuuxFoo(foo, …) vs foo.barBazQuux(…)
- szastamasta 2y ago
  I just mean you won’t write a video codec or a 3d renderer in JS. It will never get there. Just leave these things to WebAssembly where needed and leave JS as a slow, dynamic language we use for web apps.
  - tantalor 2y ago
    It's a false dichotomy. Computers are fast. You should be able to write fast computer programs in any language. The limiting factor on a program's performance should be the design of algorithms and data structures, not the programmer's choice of language or runtime.
  - wiseowise 2y ago
    > I just mean you won’t write a video codec or a 3d renderer in JS. Not with the attitude, you don’t. > Just leave these things to WebAssembly where needed and leave JS as a slow, dynamic language we use for web apps. The ship has sailed when they made V8 and performance race has started.
  - meheleventyone 2y ago
    3D renderers have existed in JS for ages so that seems more like a failure of imagination on your part. The nice thing about fixed layout structs is that it leans in to optimizations people are already doing based on the behavior of JS engines where 'shapes' of objects are important and properties can be looked up by offset if you keep your code monomorphic. It can be a bit of a headache to enforce this and you can accidentally fall off a performance cliff if you end up with many 'shapes' for the same thing. By making this a language feature it codifies and blesses what was essentially a hack relying on the implementation of the underlying engine that could change at any time. There are also TypedArray's that do provide a bunch of cache friendly (but slightly unergonomic) ways to organize data. A good resource for the sorts of things people are doing to write high-performance JS is here: https://romgrk.com/posts/optimizing-javascript https://romgrk.com/posts/optimizing-javascript
wiseowise 2y ago
> Please stop bloating it with every feature that’s trendy this year. Trendy structs. Did I return to 1980? (wipes happy tear)
wruza 2y ago
Javascript implementations do not use hash tables for objects. Yes, it is surprising. https://stackoverflow.com/questions/6586670/how-does-javascript-vm-implements-object-property-access-is-it-hashtable https://stackoverflow.com/questions/6586670/how-does-javascr... And when jit kicks in, it does all the usual calculate-the-offset things in generated code.

tantalor 2y ago

High performance applications are already being written that depend on features like shared memory, but because the language has poor support for them then developers have to use ugly workarounds. This proposal solves that with built-in support. >It should just stay this way Counterpoint: JS has been evolving significantly, look at ES6 and ES8 in particular if you need help finding examples.

rty32 2y ago
Exactly. Without new features and syntaxes people would still be doing MyClass.prototype.method = function () { } like idiots. Such a meaningless argument for preventing progress.
- szastamasta 2y ago
  Nobody needs classes nor prototypes in JS. Objects + functions is more than enough. I stopped using these few years ago and miss nothing.
  - rty32 2y ago
    IDE support is often hit or miss with these, I have seen too much of it. Don't use vscode or never bother to write jsdoc/do any strict typing? Never mind. Good luck with your codebase.
  - jitl 2y ago
    You and "anybody" are actually two different sets of people with different needs and desires
  - wruza 2y ago
    It is enough, but not more than. Collecting functions in a group by operating on a shared context is naturally useful and convenient. Pretending otherwise leads to all sorts of “a method, but I see it as a function with an accidental first parameter in a homonimous namespace because having a function name prefix is ugly, and it’s all ugly, but at least it’s not a class”. import * as fooNs from './foo' fooNs.barBazQuuxFoo(foo, …) vs foo.barBazQuux(…)
szastamasta 2y ago
I just mean you won’t write a video codec or a 3d renderer in JS. It will never get there. Just leave these things to WebAssembly where needed and leave JS as a slow, dynamic language we use for web apps.
- tantalor 2y ago
  It's a false dichotomy. Computers are fast. You should be able to write fast computer programs in any language. The limiting factor on a program's performance should be the design of algorithms and data structures, not the programmer's choice of language or runtime.
- wiseowise 2y ago
  > I just mean you won’t write a video codec or a 3d renderer in JS. Not with the attitude, you don’t. > Just leave these things to WebAssembly where needed and leave JS as a slow, dynamic language we use for web apps. The ship has sailed when they made V8 and performance race has started.
- meheleventyone 2y ago
  3D renderers have existed in JS for ages so that seems more like a failure of imagination on your part. The nice thing about fixed layout structs is that it leans in to optimizations people are already doing based on the behavior of JS engines where 'shapes' of objects are important and properties can be looked up by offset if you keep your code monomorphic. It can be a bit of a headache to enforce this and you can accidentally fall off a performance cliff if you end up with many 'shapes' for the same thing. By making this a language feature it codifies and blesses what was essentially a hack relying on the implementation of the underlying engine that could change at any time. There are also TypedArray's that do provide a bunch of cache friendly (but slightly unergonomic) ways to organize data. A good resource for the sorts of things people are doing to write high-performance JS is here: https://romgrk.com/posts/optimizing-javascript https://romgrk.com/posts/optimizing-javascript

wiseowise 2y ago

> Please stop bloating it with every feature that’s trendy this year. Trendy structs. Did I return to 1980? (wipes happy tear)

wruza 2y ago

Javascript implementations do not use hash tables for objects. Yes, it is surprising. https://stackoverflow.com/questions/6586670/how-does-javascript-vm-implements-object-property-access-is-it-hashtable https://stackoverflow.com/questions/6586670/how-does-javascr... And when jit kicks in, it does all the usual calculate-the-offset things in generated code.