Proposal: JavaScript Structs

After all, you can add a `*` to any existing function without a change in the function or its callers.

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

There is only one reason to believe JS is simple: because you don't know enough.

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.

I think your model of how people use modules is flawed.

I doubt most people using those modules are using typescript to mostly interact with them, because of the perceived subjective benefit you see of typing everything.

For example, I use many typescript-written modules without using typescript in the code that uses them, and am better off for it. Because I and my R&D work does not want the advanced features of typescript. We can switch to it, or a OOP server language if that is useful later.

Exposing types to me usefully in libraries to use "with Typescript" as you claim means my own code has to be typescript. In that case, to avoid compile errors and a wall of "any" types, I reasonably have to switch my own code to use Typescript classes etc, even where this is just bloat etc. Another reason I have libraries is to do things without ever interacting with them other than input props (e.g. a drag'n'drop library with JSX components). In that case, the type (JSX Component) is irrelevant to me to include, and for experienced developers, approximately 0% are going to give something other than a JSX component as an input to a drag'n'drop library, etc.

In other words - I derive benefit from them using Typescript without having to use it myself. Pushing Typescript as "necessary" because popular libraries have interfaces is exactly the kind of thing that slows down R&D and fast processes.

I have used many languages with types for many years. I understand their value. However, much of the value is code coherence, working with other people, and domain models being embedded in the code. These benefits are not always useful in small web applications.

Typing is one of those things... you love it to make your life learning code easier and for big projects, and for certainty when you are coding boring things. For other things in life, there's more to life than writing type definitions and overloading methods. You can be much more productive just using primitives in some scenarios and make research discoveries faster and with more flexibility.

What I have seen is every generation of coders, a new type-heavy language/framework becomes popular (.NET, Java, Typescript), then it becomes "uncool" because people realize how bulky and useless most of it is - especially for anything small/research-y, then it loses adoption and is replaced by another.

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