Proposal: JavaScript Structs

I am not sure how to really refine this thought I have had, but I have this fear that every language eventually gets so bloated and complicated that it has a huge barrier to entry.<p>The ones that stand out the most to me are C# and Typescript.<p>Microsoft has a large team dedicated towards improving these languages constantly and instead of exclusively focusing on making them easier to use or more performant, they are constantly adding features. After all, it is their job. They are incentivized to keep making it more complex.<p>The first time I ever used C# was probably version 5? Maybe? We&#x27;re on version 12 now and there&#x27;s so much stuff in there that sometimes modern C# code from experts looks unreadable to me.<p>One of the reasons I have so much fun working in node&#x2F;Javascript these days is because it is simple and not much has changed in express&#x2F;node&#x2F;etc for a long time. If I need an iterable that I can simply move through, I just do `let items = [];`. It is so easy and hasn&#x27;t changed for so many years. I worry that we eventually come out with a dozen ways to do an array and modern code becomes much more challenging to read.<p>When Typescript first came out, it was great. Types in Javascript are something we&#x27;ve always wanted. Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it&#x27;s overwhelming. And nobody uses most of it!<p>This is probably just old man ranting, but I think there&#x27;s something there. The old version I used to debate about was C vs C++. Now look at modern C++, it&#x27;s crazy powerful but so jam packed that many people have just gone back to C.

<p><pre><code> 𝅘𝅥𝅮𝅘𝅥𝅮𝅘𝅥𝅮𝅘𝅥𝅮 They&#x27;ve got decorators, record tuples, shadow realms, and rich rekeying Dynamic imports, lazy modules, async contexts now displaying JSON parsing, destructure privates, string dedenters, map emplacers Symbols pointing, pipe operators, range iterators, code enhancers Eager asyncs, resource tracking, strict type checks, and error mapping Phase imports, struct layouts, buffering specs for data stacking Temporal zones, buffer edges, chunking calls for nested fragments Explicit locks, throw expressions, float16s for rounding segments Base64 for typed arrays, joint collections, parsing pathways Atomic pauses, void discarding, module scopes for seamless relays Math precision, tuple locking, module imports, code unlocking Source phase parses, regex bounds, iterators kept from blocking Iterating, winding modules, atomic gates with locks unbound Helper methods, contexts binding, async helpers, code aligning Soffit panels, circuit brakers, vacuum cleaners, coffee makers Calculators, generators, matching salt and pepper shakers I can&#x27;t wait, (no I) I can&#x27;t wait (oh when) When are they gonna open the door? I&#x27;m goin&#x27; (yes I&#x27;m) goin&#x27;, I&#x27;m a-goin&#x27; to the ECMAScript Store</code></pre>

The general idea of types with a fixed layout seems great, but I&#x27;m a lot more dubious about the idea of unsafe blocks. The web is supposed to be a sandbox where we run untrusted code and with pretty good certainty expect that it can&#x27;t crash the computer. Allowing untrusted code to specify &quot;hey let me do stuff that can cause data races if not done correctly&quot; is just asking for trouble, and also exploits. If shared structs are going to be adopted I think they probably need to be immutable after creation, or at the very least only modified with atomic operations.

Huh, I thought that most work that used to use workers switched to Webassembly.<p>Talking about JS proposals, I&#x27;m looking forward to this one: <a href="https:&#x2F;&#x2F;github.com&#x2F;tc39&#x2F;proposal-record-tuple">https:&#x2F;&#x2F;github.com&#x2F;tc39&#x2F;proposal-record-tuple</a><p>Records and tuples can make a lot of logic much more easier to read, and way less fragile. Not sure how they would play together with the shared structs though.

I feel conflicted. Working with multithreaded stuff in JS is a huge PITA. This would go some way to making things easier. But it also feels like it would radically complicate JS. Unsafe blocks? Wow-eee.<p>With the rise of WASM part of me feels like we shouldn&#x27;t even <i>try</i> to make JS better at multithreading and just use other languages better suited to the purpose. But then I&#x27;m a pessimist.

A better title &quot;A proposal for Shared Memory Multi-threading&quot;. The term &quot;struct&quot; has a meaning in the C language that is somewhat misleading since the purpose here is not organization, but rather to enable shared memory.<p>In my experience, the positive of JavaScript over other languages I have used- COBOL, Fortran, assembly, C, C++, Java - is the fine balance it has between expressibility and effectiveness.<p>I am not opposed to shared memory multi-threading, but question the cost&#x2F;benefit ratio of this proposal. As many comments suggest, maintaining expressibility is a high priority and there are plenty of gotchas in JavaScript already.<p>As an example, I find the use of an upfront term like &quot;async&quot; to work quite well. If I see that term I can easily switch hats and look at code differently. Perhaps we could look at other mechanisms, using the term &quot;shm&quot;, over a new type, but what do I know?<p>[edit for clarity since I think faster than I can type]

I don&#x27;t understand the need for the ever-growing list of &quot;enhancements&quot; to JS. Take Class for example.<p>Class is entirely unnecessary and, essentially, tries to turn JS into a class-oriented language from its core which is object-oriented.<p>I never create classes. I always create factory functions which, when appropriate, can accept other objects for composition.<p>And I don&#x27;t use prototypes, because they are unnecessary as well. Thus sparing me the inconvenience, and potential issues, of using &#x27;this&#x27;.<p>In my dreams those who want to turn JS into c# or Java should just create a language they like and stop piling on to JS.<p>But, at least so far, the core of JS has not been ruined.<p>That said, there are some new features I like. Promises&#x2F;async&#x2F;await, Map, Set, enhancements to Array being among them. But to my way of thinking they do not change the nature of the language in any way.

Huh, no types. So every field is 8 bytes I guess?<p>I suppose if you want a defined&#x2F;packed memory layout you can already use SharedArrayBuffer and if you want to store objects in it you can use this BufferBackedObjects library they linked. <a href="https:&#x2F;&#x2F;github.com&#x2F;GoogleChromeLabs&#x2F;buffer-backed-object">https:&#x2F;&#x2F;github.com&#x2F;GoogleChromeLabs&#x2F;buffer-backed-object</a><p>I also expect that in browsers this will have the same cross-origin isolation requirements as SharedArrayBuffer that make it difficult to use.

Most of the JavaScript developers I&#x27;ve encountered recently refuse to use Map, and if you dare use it, they will say that it&#x27;s complicated code and premature optimisation before even making an attempt to understand it.<p>I feel like trying to add fast data structures into JavaScript is futile, I think at this point it would be better to make it easier for JavaScript and the browser to interface with faster languages.<p>The only thing I would add to JavaScript at this point is first class TypeScript support so that we can ditch the transpilers.

&#x2F;&#x2F; Step 1: Convert JSON object to string const jsonObject = { name: &quot;John&quot;, age: 30 }; const jsonString = JSON.stringify(jsonObject);<p>&#x2F;&#x2F; Step 2: Convert the string to binary data const encoder = new TextEncoder(); const encodedJson = encoder.encode(jsonString);<p>&#x2F;&#x2F; Step 3: Create a SharedArrayBuffer and a Uint8Array view const sharedArrayBuffer = new SharedArrayBuffer(encodedJson.length); const sharedArray = new Uint8Array(sharedArrayBuffer);<p>&#x2F;&#x2F; Step 4: Store the encoded data in the SharedArrayBuffer sharedArray.set(encodedJson);<p>Now you can use Atomics, no?<p><a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;JavaScript&#x2F;Reference&#x2F;Global_Objects&#x2F;Atomics" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;JavaScript&#x2F;Refe...</a>

Not sure this is a good idea or not, for one it&#x27;d be awesome for doing performance oriented and threaded code in JS&#x2F;runtimes, the idea seems related to how C# struct&#x27;s already work (and tuples under the hood). Interop with WASM code might also be simplified if struct-like access was a built-in.<p>The bad is that people wouldn&#x27;t necessarily be prepared for their semantics (are they value or reference based?), how to shared prototypes between environments (mentioned as problem in the proposal itself), not entirely sure if this proposal would add to the complexity vs security for spectre like attacks.<p>It&#x27;d be useful, but worth it is another question? (And would all major players see interest in it? esp considering that it&#x27;d need to be &quot;JSzero&quot; level propsal if they go in that direction. (There was a post here a few days ago about layering runtimes with JS0 being the core with everything else being syntax transforms on top).

I thought it said &quot;Proposal: JavaScript Sucks&quot; and was not surprised by the number of upvotes from HN

Fixed layout structs seem like a no brainer and a natural extension of the typed arrays. It’s strange that both Java and Jacascript went so long without them. Interacting with many APIs (webgpu, FFI, …) quickly becomes really unpleasant if you can’t control data layout.

My head is spinning after skimming the sections on shared memory, locks, mutexes, etc. Implementation and adoption would probably be a decade-long saga. Not to mention teaching folks when to use these and how to use them correctly.<p>In e.g. Elixir these are non-issues. Please, just give us declarative structs that are immutable by default (if they’re really needed, make constructors and mutability opt-in). Isn’t the trend already toward more FP in JS?

JS devs - do everything but write in another language challenge level: Impossible.

I initially didn&#x27;t like the high level idea, but I warmed up to it. My only concern is that the constructor isn&#x27;t guaranteed to define the same fields with the same types, which kind of defeats the point.<p>I&#x27;d improve this proposal in two ways:<p>1. Explicitly define the layout with types. It&#x27;s new syntax already, you can be spicy here.<p>2. Define a way for structs to be directly read into and out of ArrayBuffers. Fixed layout memory and serialization go hand in hand. Obviously a lot of unanswered questions here but that&#x27;s the point of the process.<p>The unsafe block stuff, frankly, seems like it should be part of a separate proposal.

When reading the proposal title, I thought that this is for interop with WASM. Having fixed-size structs where every field has a wasm-related type would be beautiful for interop. Just a wasm function can just return or receive an instance of a typed struct. No more reading the result using a DataView or something like that. We have to use something like BufferBackedObject for that.

The thing I like about this is when I get a heap dump I could get names for things instead of &quot;object shapes&quot;, which would be cool.

Happy to see this effort.<p>When applying ReactJS in webdev after doing all kinds of engineering in all kinds of (mostly typed) languages in many runtimes, I was so surprised that JS did not actually had a struct&#x2F;record as seen in C&#x2F;Pascal. Everything is a prototype that pretends its an object, but without types and pointers, and abstraction layers that added complexity to gain backwards compatibility.<p>Not even some object hack that many OO and compiled languages had. ES did not add it either, and my hopes where in WebAsm.<p>This proposal however seems like the actual plan that i’d like to use a lot.<p>A lot of the code complexity was to get simple guarantees for data quality. The alternative was to not care, either a feature or caveat of the used prototype model.

This looks like it&#x27;s going to be a great fit for emscripten, especially multithreaded.

@syg If you happen around to answer more questions: Why going with only Sealed prototypes for structs? Personally, I would assume that with static initializer blocks we could well go with &quot;initially Sealed&quot; with &quot;Frozen once class initialization completes&quot;. ie. Make the last step of &quot;StructDefinitionEvaluation&quot; AO &quot;SetIntegrityLevel(F, FROZEN)&quot;.<p>This way I&#x27;d assume eg. decorators would be usable on struct fields and methods, but engines would be safe to cache prototype method lookup result values without any validity cell mechanics. I would assume this could make prototype method calls on structs very fast indeed.

A stricter, faster subset of JS would be very welcome, which seems to be what the unshared struct part of this proposal provides.<p>By the way, doesn&#x27;t V8&#x27;s optimizer already do something like this internally? I read one of their tech blogs back in the day that explained how they analyze the structure of objects and whenever possible, compile it to the equivalent of a C++ class.<p>I guess doing it explicitly makes the optimizer&#x27;s job much easier -- the more guarantees you give it about what <i>won&#x27;t</i> happen, the more optimizations it&#x27;s free to make.

I thought we were done shoehorning all possible CS concepts into javascript?

Can see &quot;why&quot;, but I can&#x27;t really see why a new syntax is warranted. This feature is expected to be used infrequently and probably has to be defined as an ECMAScript extension only in order to put it into WebAssembly. A &quot;fake&quot; prototype that indicates strictness should be enough for implementations (and polyfills). There are many other issues but that is glaring enough to be pointed out.

The similarity with CL&#x27;s divide between structs and classes is uncanny; especially with ((:type vector) :named).

What a mess this language is becoming.

I love JavaScript! It’s such an exciting development experience loaded with surprises! I was just thinking the other day how cool it would be if it had unsafe blocks like in Rust. What an exciting time to be alive!

Maybe I&#x27;m missing something, but this seems to add very little. Please correct me if I am missing something.<p>1) Struts are encouraging a coding style that restricts what you can do. This inflexibility is then negated by adding unsafe blocks?<p>2) Struts don&#x27;t, as far as I can see, address any of the _actual_ weaknesses of js classes- such as not being able to create aysnc constructors.<p>3) The cited performance benefits seem a bit strange. JS has no access to pointers or memory by design, so I don&#x27;t understand why struts will automatically make things faster. Surely it makes more sense to refine the v8 engine, or even focus on WASM rather than adding syntactic sugar to vanilla js.<p>That said- props to people who care enough to write a proposal- and if I am missing the point of struts, sorry for the negativity.

I mean.. After ES6 with classes what is JavaScript anyway? Just bring Structs too, the more the merrier.

I just want structs (in regards to impact on the garbage collector).

Is there a way to &quot;vote&quot; on these types of proposals? (Just asking for a friend who sees this as bloat and does not want to deal with other people&#x27;s code which uses this unnecessarily)

what

personally I&#x27;m super excited to see this -- have been wanting something along these lines for quite some time.

Needs a re-entrant mutex?

The scope of this proposal is too large. If it comes down to preference, I&#x27;m not a rust rust fanboy but I think they got the struct&#x2F;impl paradigm right.

Nahhh

Leave. The. Language. Alone.

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.<p>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.

They should just go write golang, if this is what they want.

It&#x27;s hard to take anyone concerned about the &#x27;performance ceilings&#x27; in javascript object creation seriously at this point.