Javascript is not simple AT ALL.

It has 3 ways to declare functions, multiple variations on arrow functions syntax, a weird prototyping inheritance system, objects you can create out of "new" on functions, object literals that can act an pseudo-classes, classes, decorators, for-i loop + maps + filter + for-in loop (with hasOwn) + forEach, async / await + promises and an invisible but always-on event loop, objects proxies, counter-intuitive array and mapping manipulations, lots of different ways to create said arrays and mappings, very rich destructuring, so many weirdnesses on parameter handling, multiple ways to do imports that don't work in all contexts, exports, string concatenation + string interpolation, no integer (but NaN), a "strict mode", two versions of comparison operators, a dangerous "with" keyword, undefined vs null, generators, sparse arrays, sets...

It also has complex rules for:

- scoping (plus global variables by default and hoisting)

- "this" values (and manual binding)

- type coercion (destroying commutativity!)

- semi-column automatic insertion

- "typeof" resolution

On top of that, you execute it in various different implementations and contexts: several browser engines and nodejs at least, with or without the DOM, in or out web workers, and potentially with WASM.

There are various versions of the ECMA standard that changes the features you have access to, unless you use a transpiler. But we don't even touch the ecosystem since it's about the language. There would be too much to say anyway.

There are only two reasons to believe JS is simple: you know too much about it, or you don't know enough.

    function x() {/* ... */}
    const x = function() {/* ... */}
    const x = function foo() {/* ... */}
    const x = (function() {/* ... */}).bind(this)
    const x = (function foo() {/* ... */}).bind(this)
    const x = () => {/* ... */}
    const x = () => /* ... */

  () => { return 1; }
  () => 1

  const foo = (function() {}).bind(this);
  const foo = () => {};

I think in this specific case it's JavaScript's requirement for backwards compatibility that bloats it... but there's a lot you can ignore. Like, you can declare a variable with var, let or const but there's absolutely no reason to use var any more. I feel similarly about the proposals to introduce records and tuples: https://github.com/tc39/proposal-record-tuple... in most scenarios you'll probably be better off using records rather than objects, and maybe that's what folks will end up doing.

But boy does it all get confusing.

> Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it!

I'm not so sure about that. I think we end up consuming a lot of these features in the TS types that get published alongside libraries. We just don't know it, we just get surprisingly intuitive type interfaces.

    // Why var? It avoids TDZ checks in the runtime which can be costly.
    // See: https://github.com/microsoft/TypeScript/issues/52924
    /* eslint-disable no-var */
    var deferredDiagnosticsCallbacks: (() => void)[] = [];

  var x: NodeJS.Dict<any> = {}

  x[key] = ...

I've been meaning to write a longer essay on this for years, but I believe the reason for this observation is different cohorts.

Imagine you are a C# programmer just as C# 1.0 is released. C# is a fairly simple language at that time (and similar to other languages you already know), so you can get caught up on it fairly easily and quickly. A few years later, C# 2.0 comes out. It's got a handful of features, but not too much for you to absorb. Likewise C# 3.0, 4.0, etc. As long as you stay on the C# train, the rate of new features does not exceed the rate that you can learn them.

Years later, another person comes along and is new to C#, which is now at version 5.0. They are presented with a huge sprawling language and they have to learn nearly all of it at once to deal with codebases they are contributing to. It's a nightmare. They long for a language that's actually, you know simple.

So maybe they find some other newer language, Foo, which is at 1.0. It's small and they learn the whole thing. After a couple of years of happy productive use, they realize they would be a little more happy and productive if Foo had just one or two extra little features. They put in a request. The language team wants happy users so they are happy to oblige. The user is easily able to learn those new features. And maybe some other Foo users want other new things. 2.0 comes out, and they can keep up. They can stay on the train with 3.0, 4.0, etc.

They never explicitly asked for a complex language, but they have one and they're happy, because they've mastered the whole thing over a period of years. They've become part of the problem that bothered them so much years ago.

Fundamentally, the problem is that existing users experience a programming language as the delta between the latest version and the previous one. New users experience a programming language as the total sum of all of its features (perhaps minus features it has in common with other languages you already know). If you assume users can absorb information at a certain fixed rate, it means those two cohorts have very different needs and different experiences.

I don't think there's a silver bullet. The best you can hope for is that a language at 1.0 has as few bad ideas as possible. But no one seems to have perfect skill at that.

> When Typescript first came out, it was great. Types in Javascript are something we've always wanted. Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it!

TypeScript today can be written the same way that TypeScript was when it first started to become popular. Yes there are additions all the time, but most of them are, as you observe, irrelevant to you. They're there to make it possible to type patterns that would otherwise be untypeable. That matters for library developers, not so much for application developers.

To the extent there's a barrier to entry, it seems largely one that can be solved with decent tutorials pointing to the simple parts that you're expected to use in your applications (and a culture of not overcomplicating things in application code).

> The first time I ever used C# was probably version 5? Maybe? We're on version 12 now and there's so much stuff in there that sometimes modern C# code from experts looks unreadable to me.

That's funny given many of the changes were made to make C# look more like JavaScript!

C# 6 introduced expression-bodied members for simplified syntax (like JavaScript), null-conditional operators, and string interpolation. C# 7 brought pattern matching, tuples, deconstruction, and local functions. C# 8 introduced nullable reference types for better null safety, async streams, and a more concise switch expression syntax. C# 9 to C# 12 added records, init-only properties, with expressions, and raw string literals, global using directives, top-level statements, list patterns, and primary constructors.

In C#, if you need a string list you can do:

    List<string> items = [];  // Not as concise as JS but type safe.

As for TypeScript, nobody is supposed to use most of it -- unless you're authoring a library. You benefit from it's features because somebody else is using them.

Languages draw inspiration from each other -- taking the good parts and incorporating them in. C# is a vastly better, easier, and safer language than it used to be and so is JavaScript.

This is why always say the true beginner programming language is C.

Stupid easy to learn, have some loops, have some conditions, make some memory allocations. You will learn about the fundamentals of computing as well, which you might as well ignore (unknowingly) if you start with something like JavaScript (where is this data living in my computer?).

> And nobody uses most of it!

Everybody who does Express, React, or any other popular advanced libraries with TypeScript is using these features. Some things are simply more useful to libraries than line of business code - that's fine. The line of business code is much better thanks to it.

What did Bjarne Stroustrup supposedly say? There are two kinds of programming languages: the ones everybody complains about, and the ones nobody uses.

I'll put on my Scheme hat and say "with hygienic macros, people can add whichever language features they want." Maybe Rust is a good experiment along those lines: C++ with hygienic macros.

Everything that people keep using grows into a monster of complexity: programming languages, software, operating systems, law. You must maintain backward compatibility, and the urge to add a new feature is too great. There's a cost with moving to the new thing -- let's just put the new thing in the old thing.

I'm an absolute beginner when it comes to programming, and I chose C# as my first language to learn.

I've been learning steadily for 8 or so months now and at no point have I felt the language was unapproachable due to excessive features.

Looking back on what each new version added, I don't think any of the additions were damaging to the simplicity of C#.

I do likely have a biased perspective though, as I use newer C# features every day.

It doesn't help how arcane the TS documentation is. Important docs live as frozen-in-amber changelog entries; huge tracts of pages "deprecated" yet still #1 on Google.

Google "typescript interfaces." #1 is a page that has been deprecated for years. How did this happen?

Try Go. Go is really stable as a language and have a very small core feature set.

Java went through this too, although there, a lot of it is part of the ecosystem. See https://chrisdone.com/posts/tamagotchi-tooling/

> instead of exclusively focusing on making them easier to use or more performant, they are constantly adding features

I appreciate that this is mostly just a generic rant, but it's not really suitable here, because this is a feature which is being added with the sole goal of improved performance.

There's only so much you can to optimize the extremely dynamic regular objects in JS, and there's no hope of using them for shared-memory multithreading. The purpose of this proposal is to have a less dynamic kind of object which can be made more performant and which can be made suitable for shared-memory multithreading.

Do you have examples of unreadable C#? The language didn’t change much IMHO. You have new features, like records, but C# code looks pretty much like what I started with in 2009

> One of the reasons I have so much fun working in node/Javascript these days is because it is simple and not much has changed in express/node/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'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.

The let keyword didn't exist in JS when Node was first released, nor did for/of, which while unstated in your post, is probably what you are thinking of when you posted this. The language has not stayed the same, at all.

>The first time I ever used C# was probably version 5? Maybe? We're on version 12 now and there's so much stuff in there that sometimes modern C# code from experts looks unreadable to me.

The funny thing is if you used F# over a decade ago almost all the C# improvements seem familiar. They were lifted from F#, some of them badly.

And I know F# borrows a lot from OCaml. But it's hard to fathom why we need to use the badly adopted F# features in C# instead of just getting F# as a main Microsoft adopted language.

> sometimes modern C# code from experts looks unreadable to me

This is a culture issue and has always existed in C#, Java and C++ communities sadly (and I'm seeing this now with TS just as much, some Go examples are not beacons of readability either, I assume other languages suffer from this similarly).

In the past, people abused BinaryFormatter, XML-based DSLs, occasionally dynamic, Java-style factories of factories of factories, abuse of AOP, etc. Nowadays, this is supplanted by completely misplaced use of DDD, Mediatr, occasional AutoMapper use (oh god, at least use Mapperly or Mapster) and continuous spam of 3 projects and 57 file-sized back-ends for something that can be written under ~300 LOC split into two files using minimal API, records and pattern matching (with EF Core even!).

Neither is an example of good code, and the slow but steady realization that simplicity is the key makes me hopeful, but the slow pace of this, and new ways to make the job of a developer and a computer more difficult that are sometimes introduced by community and libraries surrounding .NET by MS themselves sour the impression.

Couldn't agree more. More features in a programming language makes it easier and more fun to write code, but makes it harder to read and maintain someone else's code. Considering more time is spent maintaining code as opposed to writing it (assuming the product is successful), readability is more important than writability.

> it has a huge barrier to entry

You don't have to use every feature of the language. Especially not when you are just learning.

> Now, Typescript is on version 5.6 and there is so much stuff you can do with it that it's overwhelming. And nobody uses most of it!

Exactly. But no-one seems to be arguing that typescript has a huge barrier to entry.

> Now look at modern C++, it's crazy powerful but so jam packed that many people have just gone back to C.

Geez I'd sure hope not.

If you liked C++11, you can use C++11. Every compiler, platform, and library will support it.

No one erased it and made you go back to C99.

I also don’t know how to refine my thought but it’s something along the lines of:

The people who are in a position to decide what features get added to a language are usually top experts and are unlikely to have any reasonable perspective on how complicated is too complicated for the rest of us.

If you live and breathe a language, just one more feature can seem like a small deal.

I think it becomes much more reasonable when that one more feature enables an entire set of capabilities and isn’t just something a library or an existing feature could cover.

And here is the obligatory quote from Bjarne Stroustrup:

"There are only two kinds of languages: the ones people complain about and the ones nobody uses."

Every programming language attempts to expand until it becomes C++. Those languages which cannot so expand are replaced by ones which can.

> Microsoft has a large team dedicated towards improving these languages constantly

… and the people working on these projects need to deliver, else their performance review won’t be good, and their financial rewards (merit increase, bonus, refresher) will be low. And here we are.

Edit: I realize I’m repeating what you said too, but I wanted to make it more clear what’s going on.

At least typescript tooling hasn’t changed. It was a pain to set up when it came out and it still is.

At least we moved past webpack mostly.

> or more performant

Obviously then can't make TS more performant (since it doesn't execute) but C# is very performant and even surpasses Go in the TechEmpower benchmarks.

I think part of the reason C# has changed so much as far as the language goes, not the CLR is actually because they took so many good things from Typescript and mixed them into the language. I think part of the reason Typescript has become so cumbersome to work with is because it has similarly added a lot of the good things from C#. Which may sound like a contradiction, but I actually agree with you that plain JavaScript is often great. That being said, you don’t actually have to use all the features of Typescript and it’s still much better for larger project in my opinion. Mostly because it protects developers from ourselves in a less “config on organisational level” way.

We already use regular JS for some of our internal libraries, because keeping up with how TS transpires things into JS is just too annoying. Don’t get me wrong, it gets it right 98% of the time, but because it’s not every time we have to check. The disadvantage is that we actually need/want some form of types. We get them via JSDoc which can frankly do almost everything Typescript does for us, but with much poorer IDE support (for the most part). Also more cumbersome than simply having something like structs.

I recently tried out a very simple language called Gleam. It's a functional programming language running on the BEAM vm, it may appeal to you.

C# since version 2 here, so I’m probably older. You said a lot of words, but gave no concrete examples of what’s bad about these languages. Linters will let you turn off different syntax usages based on your preference on what is readable or not, and C# is the only language I’m aware of where you can build them into the compilation chain and literally cause the compilation to halt instead of merely giving a style warning.

You don't have to use features you don't understand. "Complex" features exist for a reason. To the uninitiated something like generic types are quite inscrutable, but when you encounter the type of problem that they solve, their use becomes much more intuitive, and eventually familiarity yields an understanding and generics reveal themselves to be quite conceptually simple, they're just variables for types.

just use haxe

C23 has just been ratified, and C2y has already quite a few proposals.

Programming languages are like any other software product, evolution or stagnation.

Eventually they might implode, however whatever comes after will follow the same cycle yet again.

(Continued)

Proxy traps and symbol iterators, BigInts for calculations greater Nullish merging, optional chaining, code that's always up-to-date-ing

Temporal parsing, binary shifting, WeakRefs for memory lifting Intl APIs for global fitting, Promise.any for fastest hitting

Private fields and static blocks, top-level awaits unblock the clocks Logical assignments, numeric seps, each update brings new shocks

Array flattening, object spreading, RegExp lookbehinds not dreading Class fields, global this, and more, the features keep on threading

I can't wait, (no I) I can't wait (oh when) When will they add just one feature more? I'm coding (yes I'm) coding, I'm a-coding with the ECMAScript lore

10/10

    {
      "presets": [
        [
          "@babel/preset-env",
          {
            "targets": {
              "esmodules": true
            },
            "include": ["es.autocirc"] 
          }
        ]
      ]
    }

The ability to do unordered operations on shared memory is important in general to write performant multithreaded code. On x86, which is very close to sequentially consistent by default (it has something called TSO, not SC), there is less of a delta. But the world seems to be moving towards architectures with weaker memory models, in particular ARM, where the performance difference between ordinary operations and sequentially consistent operations is much larger.

For example, if you're protecting the internal state of some data structure with a mutex, the mutex lock and unlock operations are what ensures ordering and visibility of your memory writes. In the critical section, you don't need to do atomic, sequentially consistent accesses. Doing so has no additional safety and only introduces performance overhead, which can be significant on certain architectures.

Author here. I hear your feedback about unsafe blocks. Similar sentiment is shared by other delegates of the JS standards committee.

The main reason it is there today is to satisfy some delegates' requirement that we build in guardrails so as to naturally discourage authors from creating thread-unsafe public APIs and libraries by default. We're exploring other ideas to try to satisfy that requirement without unsafe blocks.

Isn't it really no different to what you can already do with WASM threads though? C/C++ or unsafe Rust compiled to WASM can have data races, but the worst it can do is crash the WASM instance, just like how you can have use-after-frees or out-of-bounds array accesses in WASM but the blast radius is confined to the instance.

Granted, a JS runtime is significantly more complex than a WASM runtime so there is more room for error.

SharedArrayBuffer can already do data races on the web. And they can't crash the browser or computer.

It's not unsafe as in "memory segmentation fault" unsafe.

It's unsafe as in, if you don't follow the rules, the resulting value is ~rand().

For those familiar with C/C++ terminology, this is the tame "unspecified behavior" (not the nasal demon "undefined behavior.")

That was gone with GPU access and WebAssembly.

The unsafe block doesn't actually do anything at all. It's just pointless cargo-cutling from Rust.

I don't think R&T will ever ship at this point, since the browser vendors are apparently unwilling to absorb the complexity that would be required to add new primitive types with value semantics.

  const foo = "foo", bar = "bar";
  const a = foo + bar;
  const b = foo + bar;
  a === b; // true

  v === null || typeof v !== "object" && typeof v !== "function"

I read this and think "can't we just make freezing objects less expensive?"

Otherwise, that's all this seems like to me, a class where all instances are automatically frozen. Which is a great semantic, but they expose way too much of the internals, in this proposal, to achieve that.

Modern development is so goofy.

> With the rise of WASM part of me feels like we shouldn't even try to make JS better at multithreading and just use other languages better suited to the purpose.

I think TS is a negative influence on JS, because now instead of saying "maybe we should fix the JS type system" they just say "no need to fix what's broken, people who care will just use TS anyway" (even though TS can only do so much).

On the other hand, TS mainstreamed the idea of typed JS (well, ActionScript did that decades ago, but somehow no one noticed or cared?), so it's also a positive influence?

Most people are drawn to WASM because "I can do frontend stuff without writing JS!" but for the most part that's not true, and in my experience the problems introduced by the indirection and interop, and the complexification of the mental model, and the bloating of the build system (and its fragility), were not worth it and I just switched back to TS.

So I do really wish that JS would be improved -- it remains inescapable -- especially with regard to fixing fundamental design flaws rather than just adding more shiny stuff on top.

Otoh, I create classes, use prototypes and it’s natural and useful in many of my cases.

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.

We could even share this dream if browser vendors weren’t such whos the boss iam da boss when it comes to extensions and alternatives. So we have to live in a common denominator, which surprisingly isn’t as bad as it could be, really.

Classes generally point you towards writing more performant code. Factory functions allow you to achieve the same performance, you just have to be a bit more careful not to cause a depot :)

For example,

1. field declarations [1] make sure that the fields are always initialized in the same order. That way most of your functions end up monomorphic, instead of being polymorphic [2]

2. Method declarations are also (almost) free, since you only pay for them once, during class initialization.

You also get a few other niceties such as private properties. You can emulate private properties with closures in factory functions but V8 has a hard time optimizing, unfortunately.

---

[1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[2]: https://www.builder.io/blog/monomorphic-javascript

I like JS's flexibility too, but I have to point out that your object-oriented JS code is compiled into C++ classes by the v8 optimizer! (Unless you change their structure, in which case it gives up (deoptimization).)

  return {
    functions...
  }
}

>And I don't use prototypes, because they are unnecessary as well. Thus sparing me the inconvenience, and potential issues, of using 'this'.

Eh, prototypes share, instead of create, method references. I guess you can use delegate objects too though unless you're just doing pure functions.

To be more precise, aligned to whatever size such that you can guarantee field writes that don't tear. Pointer-aligned is a safe bet. 4-byte aligned should be okay too on 64bit architectures if you use pointer compression like V8 does.

What kind of types did you have in mind? Machine integers and "any" (i.e., a JS primitive or object)?

And yes, in browsers this will be gated by cross-origin isolation.

Note that the idea isn't unique to C# structs, other GC enabled languages have similar capabilities.

(Wipes away tears of laughter) I needed that! [1] [2]

[1] just got some bad news [2] all in all, I love working in JS when I have to, but I’ve worked in it long enough to know of at least very many of the foot guns.

  Today I went for a walk (which I don't usually do), and I saw a squirrel.

Well I'm trying to make it suck less.

There's technically a proposal to add immutable lists and records floating around somewhere. I think it's kind of old at this point. I'm still hoping it makes it through, though.

There's a lot of that, certainly, but there are legitimate reason to use JS/TS.

Frontend is an obvious one but also using services like CF Workers or Deno Deploy which are optimized for V8. You're going to get better uptime and lower latency than anything else at that cost.

Lots of programmers only really feel comfortable in C++ because it's the language they were trained in.

What a bad take. If you're writing code that runs in a browser, there's no other choice. I'm not counting things like ClojureScript, as you still need to have deep knowledge of the low-level primitives, which exclusively bind to JS.

You can use other languages that compile to WebAssembly, but it's borderline as it's basically just a VM / self-contained executable that you can pipe to. It's completely isolated from the browser.

Call me when browsers support another language. What are we going to use? CSS?

Got it. Writing in Typescript.

I agree; the point of a struct type would be to allow a compact memory representation, and you're not going to get it if your constructor can do if(someArg) { a = 1; } else { a = 1; b = 2; }.

You don't strictly need known/consistent types, but it sure helps, since otherwise everything needs to be 8 bytes.

I don't think a way to read into and out of ArrayBuffers is possible, since these can have pointers in them. I think it needs a StructArray class instead, so there's a way to actually make a compact memory array out of all of this.

Not JS, but quite the same niche is where AssemblyScript sits: https://www.assemblyscript.org/

There is a very specific goal the authors want to achieve, and it's not what you seem to think from reading the title of the link.

Except for the pipeline operator

I think that there is a spilling over of financially incentivized "innovation" stemming from the companies that are involved in the browser \ web space.

If you are fairly senior or aiming for some sort of promotion this is the sort of thing that looks great on your resume.

I doubt that it is driven by a desire to help consuming devs build better quality products more quickly or easily.

I'm kind of with you on this. I probably didn't read enough details but it sounds like a library that abstracted over shared types arrays would already do all of this or at least solve the same problem.

I'd rather see binary struct views added to typed arrays. Ideally with a settable offset so you don't have to create a new view for every instance. That seems more useful than this middle ground that can already be poly-filled. I guess binary structs can also be poly-filled but it feels like a far more obvious speed win. Marshalling data in/out of WASM, in out of WebGPU/WebGL, parsing binary files, and sharing data across shared memory all get solved at once and with speed.

1. Unsafe blocks only apply to shared structs, and shared structs are basically only relevant with unsafe blocks. This is somewhat two proposals in one: Shared structs which require more restrictions to be shareable at all but are still kind of unsafe (because data races), and then unshared structs which adopt those same restrictions without being shareable. In exchange, they become much easier to optimise for engines. Unsafe blocks are there for the first part, unshared structs kind of come as a two-for-one prize on top.

2. Indeed, structs are rather an entirely different track to classes. Only the syntax is borrowed from them.

3. There's a bunch of stuff that the engine will do for you to try make your code faster. The most important thing (arguably) is inline caching: When you access `foo.bar` inside a function, your engine will remember the "shape" of the `foo` object (if it is an object, that is) and where the property `bar` was found inside of it. Unfortunately, objects tend to be pretty fluid things, so the shape of an object changes. This creates a "transition" graph of shapes, and it's pretty hairy stuff. It's also a source of memory safety bugs in browsers, as browsers want to avoid re-checking the shape of an object if it cannot have changed but this is mostly a manual optimisation, and eg. Proxies really make it so nearly everything can change an object's shape. A misapplied shape caching optimisation is easy to turn into an arbitrary read/write primitive, which is then a great way to escape the sandbox.

Imagine then that an object type existed that could be primitively guaranteed to never change it's shape? Oh, the engine would loooove that. No worries about memory safety mistakes, just cache the shape when you first see it and off to the races you go!

This applies doubly to any prototypes (which here are proposed to be only sealed; I'd personally want to see them frozen so that not only the shape can be cached but also the value): An object's shape may stay the same but the prototype may change with key deletions and additions. This means that looking up that function to call for `obj.hasOwnProperty("key")` needs to, theoretically, be redone every time. Engines of course optimise this into a fairly complex linked list of booleans, but by golly wouldn't it be easier if the engine could just statically cache that the property we're looking for is found in this particular prototype object at a particular memory offset?

Source: I lurk around in some adjacent circles, and am writing my own JavaScript engine built with potentially peculiar ideas about what makes good JavaScript.

Structs

I know, right?

Fortunately we can still aren't forced to use all the 'enhancements'.

Please don't do this. These summaries literally add nothing to the discussion.

Far too long to be a TLDR. Especially since it’s AI slop.

I’d either want one or two sentences or just read the first party source.

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.

  import * as fooNs from './foo'
  fooNs.barBazQuuxFoo(foo, …)

  foo.barBazQuux(…)

Javascript implementations do not use hash tables for objects.

Yes, it is surprising. 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.

> Please stop bloating it with every feature that’s trendy this year.

Trendy structs. Did I return to 1980? (wipes happy tear)

    Give developers an alternative to classes that favors a higher performance ceiling and statically analyzability over flexbility.

Is an entirely reasonable goal. Object shape in JS tends to go through a fixed pattern of mutation immediately after construction and although that can sometimes be analysed away by the JIT there are a lot of edge cases that can make that tricky.

You may not care, but I bet almost everybody who has actually worked on a JS engine does, and has good reasons for doing so.

why?