It’s that time of the quarter I need to quickly (yet consciously) ship results, and gosh if my landscape of projects and libraries is fragmented these days … this story is about me unleashing the power of AI while wondering what is it that we are doing wrong, if anything!

The Pre-AI Era

We’ve all been there, and too many of us (developers) still are, the time where search engines’ answers mattered the most; the time where seniors would dig into every single detail they could through any project that had an easy to reason about or surf, to learn or use, documentation or APIs related pages, a time where “learning-before-using” was the norm, not the after-math.

During this time, choosing the best projects with the most satisfying websites, and with the best documentation out there, has been proven to be a successful strategy for both developers and AI training: caveats, edge cases, examples, the more the better to indirectly shape what came next!

During those days though, side projects or projects with not enough developers behind such documentation effort became, out of the blue, irrelevant … not because their ideas or solutions wouldn’t be the best out there for that specific project/idea, simply because SEO and/or training data wouldn’t include those projects/solutions in.

The AI Era

Please keep “this is my experience so far” as a constrain around anything I am going to tell you, but today I had a choice around a topic:

• learn how to do it the best way, ask reviews, improve my knowledge around that topic and everything else … or …
• ask AI to port one PL related thing to another PL related thing …

Due time constraints, I went for the second approach: I’ve asked AI to help me bringing something strictly JS and NodeJS related, to something strictly Python and Python only related, and it was “a few minutes in the making“: success 🥳

The Questionable

• have I learned anything new in that process? NO
• have I reviewed and tested everything produced worked at least as seamlessly as the NodeJS counter-part I’ve asked to migrate? YES
• am I satisfied about the outcome? Also YES

After all, without learning much around a topic I actually know a lot about in one PL I’m familiar with, I’ve managed to publish something for another environment and programming language I can surely read and write, but it’d take much longer for me to migrate as a whole.

The Elephant in the Room

In my quick, easy, tested and working, migration I’ve never needed to question any of this:

• what do those dependencies do?
• do I need the entirety of those dependencies for this purpose?
• is that the best way I can use such module API?
• how many things that API offers anyway?
• is it that easy to publish this module on another ecosystem?

Now, please bear with me, I am not that naive to publish something that couldn’t make sense out there, no matter the target platform or programming language, but in this whole process I’ve never needed to look at a single “beautifully documentation API related page” because AI had it all covered … and I started wondering …

• are beautiful and styled, modern, fast or efficient, documentation sites around any technology relevant in these days? AI doesn’t care about latest CSS hack to make the Web beautiful, all it cares is about API and documentation content: that’s literally it!
• as modern developers use more and more AI, does anything more complicated than a Markdown page makes sense to both show them eventually some extra content or tell AI how to fix/solve/work around a specific issue?
• is the Web, beside being the best target platform for everything out there, as it’s almost always surely available as a view for consumers, still relevant for developers, where all they need is more like an AGENT.md file, as opposite of something beautiful to read and learn from?

My Current Thoughts

The learning curve is moving from “which library would you use to solve this problem” to “which AI is best at helping you solve this problem” these days, and the answer is not trivial, the pattern is: nobody cares about beautiful documentation out there, everyone and everything cares about the availability of such documentation at least in its most valuable form, which is Markdown format, not HTML, and I wonder if we’re shifting from an “impress developers with such docs” era to an “impress AI with easy to grasp knowledge and solutions” one, where content becomes again “the King” over aestetic or “playfulness” of solutions: AI playing with that has no value, rather wasted tokens, developers using AI don’t read, surf or learn anything anymore, at least nothing they wouldn’t care about when the topic is outside their scope and already solved elsewhere with ease thanks to better AI related documentation.

Is this inevitable?

Yes, I think we’re facing times where nobody will learn anytihing extra or unnecessary and the details, caveats, edge cases, will be covered only by the most updateed AI out there, yet that knowledge and experience is (not so) slowly getting lost or irrelevant.

Nowadays it feels like a good-looking documentation site is an excercise that doesn’t bring value anymore, if not for developers coming from the pre-AI era, ’cause anyone else won’t ever even look at that website.

To me DX means helping developers, and if developers won’t look at anything online anymore, we gotta change the way we ship software: AI first or it never happened in the modern ecosystem 👋

P.S.

I am not trying to tell anyone documentation sites don’t matter, quite the opposite … I am trying to tell that the more playful is the documentation site for humans these days, the least AI in every human writing code these days would matter.

We need to understand old days are gone by all means, we should make some effort to make modern days more appealing for the new eyes of these times: AI eyes, not human anymore, I am afraid.

class A {
  #value;
  constructor(value) {
    this.#value = value;
  }
}

class B extends A {
  #value;
  constructor(value) {
    super();
    this.#value = value;
  }
}

If we create new B('secret') the instance will have 2 private fields:

• the #value that is defined through the A class, a reference that only A class definition can reach/change/read/use and that will throw if anything in B tries to reach it, as in super.#value — nope nopity nope, that will be a SyntaxError: Unexpected private field
• the #value that is defined through the B class, a reference that only B class definition can reach/change/read/use

The “wasteful” part of this specification can be described as such:

• we need accessors to eventually be able to at least read that super value but accessors fully invalidate the secret/private nature of that field, if the reason to expose these is to have a way for the inherited class to deal with its inherited internals
• the field needs to use “two private slots” instead of one, something that the protected keyword would’ve solved, something that does not exist (yet?) in the JavaScript Programming Language

// ⚠️ this does not exist/work

class A {
  // @protected meta example
  &value;
  constructor(value) {
    this.&value = value;
  }
}

class B extends A {
  log() {
    console.log(this.&value);
  }
}

new B('protected').log();
// 'protected'

A workaround for protected fields

Because only at class definition time we can access private fields, what if we wrap such access in a way that is still “private”, at least per module scope, and grants either read or write access?

// 🥳 this works wonderfully
class A {
  // #value read/write
  static value(self, ..._) {
    if (_.length) [self.#value] = _;
    return self.#value;
  }

  #value;

  constructor(value) {
    this.#value = value;
  }
}

// extract the static method and ...
const { value } = A;
// ... erase the static method !!!
delete A.value;


// ... there we go ...
class B extends A {
  log() {
    console.log(value(this));
    // change value via
    // value(this, 'change')
  }
}

new B('secret').log();
// 'secret'

… plus a quick helper …

Because forgetting to remove the static field might happen and because this pattern works also for private methods, wouldn’t be cool to use a tiny helper that helps us extracting such properties/fields?

const _protected = Class => new Proxy(Class, {
  get(Class, staticField) {
    const value = Class[staticField];
    delete Class[staticField];
    return value;
  }
});

const { value, method } = _protected(A);

Update: an even simpler approach 🥳

Huge thanks @tombl_ for pointing out there’s not even a need to delete the static field because a static block would work the same:

let value;
class A {
  static {
    // #value read/write
    value = (self, ..._) => {
      if (_.length) [self.#value] = _;
      return self.#value;
    };
  }

  #value;

  constructor(value) {
    this.#value = value;
  }
}

class B extends A {
  log() {
    console.log(value(this));
  }
}

new B('secret').log();
// 'secret'

Gotta admit I often forgot about the static block in classes, this makes the helper obsolete already, which is great!

And “that’s all folks”, if you ever need to expose internally or within a private scope private fields, now you know a little trick to do so!

Enjoy JS 👋

A TS friendly alternative that is also as fast as it can get? Sure!

/**
 * @template T,V
 * @typedef {(self: T) => V} AccessorGet
 */

/**
 * @template T,V
 * @typedef {(self: T, value: V) => V} AccessorSet
 */

/**
 * @template T,V
 * @typedef {Object} Accessor
 * @property {AccessorGet<T,V>} get
 * @property {AccessorSet<T,V>} set
 */

/**
 * @template T,V
 * @param {AccessorGet<T,V>} get
 * @param {AccessorSet<T,V>} set
 * @returns {Accessor<T,V>}
 */
const accessor = (get, set) => ({ get, set });

/** @type {Accessor<A, string>} */
let _value;

class A {
  static {
    _value = accessor(
      self => self.#value,
      (self, value) => (self.#value = value),
    );
  }

  /** @type {string} */
  #value;

  /** @param {string} value */
  constructor(value) {
    this.#value = value;
  }
}

class B extends A {
  log() {
    console.log(_value.get(this));
  }
}

new B('secret').log();
// 'secret'

With the plethora of libraries dealing with remote references and the amount of WASM targeting runtimes, I think it’s time to explain how proxies should be used to mimic in the best possible way types discrepancies across programming languages and whatnot.

Rule #1 — the 3 kind of Proxy

It doesn’t matter what you hold as proxy reference but it does matter how you hold that. Native JS APIs are able to “drill” into proxied references so that:

• typeof proxy should return either object or function
• Array.isArray(proxy) should return true if the reference is meant to be used, or behave, like a JS Array (tuples, lists, collections … in JS these are likely handled as arrays)
• both get, set and has traps should take symbol keys into account, instead of failing when symbols are checked or accessed. Please note that Object.prototype.toString.call(proxy) will access implicitly Symbol.toStringTag, as example … be sure your proxies can handle these scenarios or simply return nothing when typeof key is not string

Proxy Object

const proxy = new Proxy({ ref }, {
  get({ ref }, key, receiver) {},
  set({ ref }, key, value, receiver) {},
  has({ ref }, key) {},
});

Assuming ref is a pointer to your real value, if such pointer goal is to mimic object literals, records or dictionaries like references, proxying { ref: value } guarantees the surrounding code will handle that reference as plain object.

Proxy Array

const proxy = new Proxy([ ref ], {
  get([ ref ], key, receiver) {},
  set([ ref ], key, value, receiver) {},
  has([ ref ], key) {},
});

Any iterable should be referenced as such to be sure that checks such as Array.isArray(proxy) would return true instead of false, playing very well along with all regular JS libraries and expectations when lists, collections, tuples, call it as you like, are meant to be handled like arrays.

Proxy Function & Class

There are various ways to reference something that is meant to be invoked but here’s the tricky part: other programming languages might not have all function variants present in JS (arrows, short-hand methods, legacy functions, modern classes) so that the “one solution to rule them” all is:

// reusable for all function cases
function proxied() {
  'use strict';
  return this;
}

const proxy = new Proxy(proxied.bind(ref), {
  construct(target, args, newTarget) {
    const ref = target();
    // ... return new instance of that ref,
    // or throw if that ref is not a class ...
  },
  apply(target, context, args) {
    const ref = target();
    // ... return the invoke of that ref,
    // or throw (maybe?) if that ref requires `new` ...
  },
});

With above traps, the typeof proxy will return function as expected and both invokes with or without new will be possible. Of course it’s also possible to fine-tune and branch out specific cases, one where new is never desired or one where new is always desired:

// it fails with new
const arrow = new Proxy(() => ref, {
  apply(target, _, args) {
    const ref = target();
    // ... invoke the ref with args and no context
  },
  // construct trap won't ever be invoked even if defined
});

class Proxied {}
class ProxiedHandler {
  // the proxy handler constructor
  constructor(ref) {
    this.ref = ref;
  }

  // the actual Proxy trap for `new`
  construct(_, args, newTarget) {
    // use the handler ref property
    const { ref } = this;
    // return a new instance for that ref
  }

  // apply trap won't ever be invoked even if defined
}

// if will fail without new
const Class = new Proxy(Proxied, new ProxiedHandler(ref));

I am letting you decide which approach is better or easier to reason about but I am usually handling things via proxied.bind(ref) because it always work and if it needs to fail when new is used or not: let if fail!

Rule #2 — don’t repeat proxy handlers

When proxies are used for WASM interoperability reasons or for reflecting API purposes, or simply any other FFI use case, it’s very likely that the runtime will handled hundreds, if not thousands, proxied references during the lifecycle of the program.

On top of that, things might become easily slower than these need to be, so that keeping in mind that proxy handlers can be shared, or can actually share their traps if these are instances and not just literal, will save a lot of Garbage Collection work + it will be definitively faster and ligther than it is now.

I am guilty as charged in this post because for brevity, context, and simplicity sake I have used objects literals as handlers, but the truth is that none of my heavily Proxy based libraries use runtime object literals for handlers as that 99.9% of the time a sloppy slippery slope for both performance, RAM, and GC pauses.

Accordingly, every time you write something like this that could occur more than once:

const proxied = ref => new Proxy({ ref }, {
  get(target, key, receiver) {},
  // ...
});

You should rather refactor that as such:

const objectHandler = {
  get(target, key, receiver) {},
  // ...
};

const proxied = ref => new Proxy({ ref }, objectHandler);

// ... or even ...

class ObjectHandler {
  constructor(ref) {
    this.ref = ref;
  }

  // traps
  get(_, key, receiver) {
    const { ref } = this;
    // ...
  }

  // ...
}

const proxied = ref => new Proxy(
  // good enough to mimic literals
  Object.prototype,
  // ref is handled directly
  new ObjectHandler(ref),
);

As result, your code will be cleaner, faster and less greedy on the RAM, plus each handler could itself carry more interesting data that its prototype can reuse across handlers, change state, track things, use this context when needed to point at such handler and so on.

Rule #3 — trap only what needs to be trapped

If you have a handler which goal is to define an object or an array and you have apply and construct traps in there, that’s both confusing and wrong.

Proxies are special “beasts” in JS and despite their names not everything will be invoked so that those function related traps, as example, won’t happen with object literals … we need to be smarter there, for instance using the proxied.bind(ref) approach and then add all sort of traps to make that behave both as literal and function but then again, that will make such proxy an “alien looking” kind of object with typeof function but both invokable and usable as object literal? … well, you do you but only if you really know what you are doing, so it’s important to learn all traps potentials, when these are needed and when these are not, and leave all other traps behind the proxied object that will already answer properly to its expected behaviors.

… and be careful with Arrays

Proxied arrays expect to always return at least length as list of ownKeys but that’s granted if you proxy [ ref ], but when such length is retrieved it cannot be just 1, it has to reflect the real length or size of whatever it’s pointing at.

Same goes with Symbol.iterator which must be the one that will iterate over the real ref, not the proxied reference, and so on so … add tests to your proxies and be sure all edge cases, or most edge cases, are covered.

And that’s a wrap; I hope you’ve found something useful or new in this post and you’ll manage to improve your proxies within your project sooner than later so that interoperability will improve, as well as performance and RAM usage will be reduced, as well as “surprises” when dealing with proxied variables.

If there’s only an extra point to make in this post is that proxies break the structured clone algorithm and cannot travel across workers so that having any way to recognize proxies and prevent these from being sent elsewhere is always a good idea, among a way to serialize these so that these can be reflected elsewhere … and if you don’t know how or where to start, remember that both coincident and its reflected-ffi use all best practices to work seamlessly across tabs, workers, or even the server side of affairs 👋

• if the ServiceWorker is registered as a module Firefox might throw out of the box when statically importing more complex files
• in Chrome/ium + Edge browsers you cannot use lovely shortcuts such as https://esm.run/@project/module because it does a redirect and, apparently, that’s not allowed
• if you use the right URLs with no redirects, Firefox breaks and those imports also cannot be asynchronous, module or not … the dynamic import(...) is not allowed for “reasons” nobody can actually reason about (keep reading)
• if the ServiceWorker is not registered as a module, we’re off with blocking/synchronous importScripts, a Jurassic, awkward, and synchronous, global polluter for an API space where nothing can block or be synchronous by design ( see event.respondWith(value:Promise) and caching based APIs, all async )

Now … “what if I told you” that none of these imposed limitations or forever unresolved bugs make any sense, when one could write a ServiceWorker like this one and no browser would complain about it?

let defaultValue = null;

const dflt = (_, value) => {
  defaultValue = value.trim();
};

const named = (_, values) => {
  const literal = [`default:${defaultValue ?? 'null'}`];
  for (const exports of values.split(',')) {
    const [ref, name] = exports.split('as');
    literal.push(`${name.trim()}:${ref.trim()}`);
  }
  return `\nreturn {${literal.join(',')}};`;
};

const amaro = fetch('https://esm.run/@webreflection/amaro').then(r => r.text()).then(
  code => Function(
    code
      .replace(/\/\/# sourceMappingURL=.*$/, '')
      .replace(/export\s+default([^;]+?);/, dflt)
      .replace(/export\s*\{(.+?)\}/, named)
  )()
);

// ... the rest of the logic

All limitations just vanished 🤦

• I am effectively using a CDN with a redirect to …
• dynamically import anything I want and …
• evaluating runtime transformed code …
• without blocking anything at all!

Now bear with me, except for the last point of this list it feels like a circus of bad practices all compressed in a few lines of code … fair … but can we agree that there is nothing stopping me to bypass those absurd limitations, limitations or inconsistencies (Firefox breaking on static imports) that brought me to write that “horror show” of working code?

What’s that code for? Well, I’ve ported NodeJS amaro to the Web and a user asked me if it could transpile on the fly .ts files via regular imports intercepted via a Service Worker so that I’ve created a Proof of Concept that showcases just that and … it works 🥳

No counter-arguments

One could argue that dynamic imports are bad because (really … why is that?) but if I need to evaluate code in a SW the situation just got worst.

The follow up comment would be “yeah but … you wrote that Service Worker code and you cannot use a Service Worker from a CDN, it’s your own code in there” and so was my own intent to use dynamic imports when/if needed (think about polyfills too for primitives and APIs not there yet).

It’s not that me evaluating code in my file is better than me explicitly importing a well known and maintained module from a well trusted CDN, you know? So why cannot we have dynamic imports when actually we can if we stretch a bit our nonsense beyond the “you must not use eval”?

I don’t want to write that code but if it’s the only way to make my site/service better, why should I listen to standards that have no concrete reasons to impose those limitations, when the alternative is to use blocking old primitives that could also be generated at runtime via server after UserAgent sniffing and pile up the list of bad practices as a result?

Extremely hard to debug

For all these Web standards promoters, use PWA and yada-yada, debugging a Service Worker has been, and still is, one of the most complicated and convoluted experience the Web development flow has to offer … how can we promote PWAs if nobody can easily understand what’s going on in there? Please let’s focus a bit on these “modern” primitives left as a developer excercise to master, circumvent, and bypass in limitations so that we can really tell the story about how easy it is to develop for the Web?

</rant>

I am now facing an issue that appears only on iPad (not on iPhone) and a slightly different one that appears only on Firefox and you cannot imagine how frustrating it is, among other thousand things I would like to focus on, solve these things that work seamlessly on Chrome/ium + Edge so thank you for your patience in reading this little rant but please help me reach out people behind browsers that could empathize with my sentiment and help moving forward around this topic: very much appreciated 🙏

P.S. yes, I’ve filed tons of bugs in Firefox / Mozilla … most of those are stuck forever with no follow-up, updates, fixes, nothing … dare I say Firefox is already dead but they don’t really want to announce it … the amount of APIs that break and remain broken for years start becoming unbearable but breaking on static imports out of a module? Hell no, that’s unacceptable folks, I am both afraid and sorry for this browser 😢

Used internally by IndexedDB, Workers and other communication Channels, or used directly via structuredClone global utility, the structured clone algorithm is both “a wonder” for JS primitives and “a curse” for developers.

The Wonder

One could transfer, store or clone almost everything that the platform provides, most notably very complex primitives such as entire files, personal storage access credentials, buffers or views of all kinds and whatnot.

There are just a few limitations that, differently form JSON that silently ignores or loses data while stringifying, would throw hard at runtime if found within the structured data:

• no functions allowed (reasonable: functions have scope and context access that cannot be brought elsewhere)
• DOM nodes (also reasonable: workers, as example, have no DOM and surely not the same one live on the main thread)
• accessors and/or private fields + some special property or prototype chain fully ignored
• symbols will throw … but also will Proxies !!!

The Curse

• No Proxies means that most complex projects need to implement their own logic to avoid passing special references around, including foreign interface based wrappers that are the only possible kind of identity that any WASM targeting programming language can offer to interop with JS … that means: you have a Python Proxy around that contains just some data and you want to postMessage({ some: py_proxy_map }) somewhere else? Nope ☠️
• No Classes (part 1) means that even if you extend native classes with extra sugar on top, nobody can distinguish that special taste elsewhere, even if the very same library and classes used at the origin of the message are available and identical at the message target world 🤦
• No Classes (part 2) also means that circumventing the fact no functions can travel is not possible because only derived native classes instances can travel: forget about your logic being able to be transferred anywhere else 🥲
• No Classes (part 3) also means that accessors cannot sit where they belong, which is the prototype, because if they do that data won’t travel but if they don’t the accessor logic and/or reactivity will be lost 😱

The Common (non) Solution …

There are literally dozen attempts to solve this very same issue at the serialization level, providing libraries that accept extensions where once gazillion of instanceof operations are performed, if some of the registered one returns something, then such “something” will be serialized among the rest of the data but in all my benchmarks that dance is a slow and bloated overhead I really don’t want to deal with anymore:

• requires both serialization and deserialization
• requires a lot of callbacks invocation for extensions of all kinds
• it’s not always provided a way to retrieve instances back on the other side
• it’s most of the time fully focused on cross Programming Language portability while I want to solve in JS my JS issues and get rid of any unnecessary abstraction that makes the crytical path way slower than it could
• it produces anyway something that needs to travel via postMessage and received via message handlers on the other side, when the project is JS

Don’t get me wrong, projects such as MessagePack or cbor-x are fantastic but these don’t solve my specific issue: I want to send JS references to a JS target and I don’t always need a binary overhead because binary serialization makes sense only with synchronous Atomics.wait when every other case is better off with just async dances that won’t need 3rd party libraries or binary serialization to work!

The JSON limit …

I can hear already people thinking “mate, just use JSON then” but that misses the points in so many levels:

• toJSON() escape hatch won’t get triggered by structured clone + it does not provide a way itself to revive whatever was returned after
• JSON is not able to be recursive data and any recursive capable alternative is not nearly as fast as JSON is, surely not faster than structured clone
• all complex primitives need to be serializaed in a JSON friendly format where if you pass a buffer as Uint8Array, all its keys from 0 to its length will also pass through the optional callback you passed thinking you were smart in there … it’s instead a slippery slope to slowness unfortunately not many out there realize: as soon as any callback to serialize or parse back is provided, goodbye performance!

In short, JSON remains the fastest and preferred way to deal with simple data + it never throws if not when unexpected recursion is passed along but it’s definitively not a solution, although many used it to solve the Proxy issue by providing normal data via toJSON, when accessed, yet we have no way to have the cake (structured clone) and eat it too (a better mechanism than toJSON to both serialize and deserialize).

My Proposal @ WHATWG

I wasn’t joking when I’ve said it was my birthday wish, ’cause if there’s something that is driving me crazy and it’s extremely infuriating with the kind of projects I’m dealing with daily (WASM driven PLs hooked into JS via main or worker threads), is that inability to intercept the structured clone internal (recursive capable) data crawling to provide hooks that would let me decide how any Proxy around users’ code could be transformed or reflected elsewhere through a way that can be restored on the other side of the affairs.

In my case, what travels can be anything that the Reflect namespace can handle, via postMessage orchestration and SharedArrayBuffer that handle via synchronous cross-realms communication even DOM nodes from the main thread, nodes that can be passed around as method arguments (think just an element.appendChild(other) that happens within a worker) and whatnot!

The limit in my case is not even my immagination, it’s simply the lack of a better way to deal with this … so here I come with a proposal: a SerializationRegistry namespace to rule them all!

class Serializable {
  static revive([count, data]) {
    const ref = new this(data);
    ref.#count = count;
    return ref;
  }
  // private properties via reviver? ✅
  #count = 0;
  #data;
  constructor(data) {
    this.#data = data;
  }
  // accessors? ✅
  get access() {
    return this.#count;
  }
  get data() {
    this.#count++;
    return this.#data;
  }
  // define how to travel? ✅
  get [SerializationRegistry.symbol]() {
    return SerializationRegistry.transfer(
      'my-project@Serializable',
      [this.#count, this.#data],
    );
  }
}

// define how to revive? ✅
SerializationRegistry.register(
  'my-project@Serializable',
  Serializable.revive.bind(Serializable),
);

OK then, we have our very own class that:

• defines a SerializationRegistry.symbol accessor, just the way Symbol.toStringTag or others work so that it’s clear no argument would ever be passed while cloning, which will be accessed while cloning
• that accessor returns explicitly something to transfer that assumes the class has been registered with that unique identifier, either in this world or in the receiving one
• SerializationRegistry.register registers that unique identifier so that this class, as module, would work to both send or receive its own kind

… and that’s it? Let’s see it in practice:

const ref = new Serializable({ some: 'data' });

// just to trigger the accessor and increment count
ref.data;   // { some: 'data' }
ref.data;   // { some: 'data' }
ref.access; // 2

// let's post that reference
postMessage({ extras: true, data: [1, ref, 2] });


// on the receiver side
self.onmessage = event => {
  const { extras, data } = event.data;
  const ref = data.at(1);
  console.log(ref); // instance of Serializable
  ref.data;   // { some: 'data' }
  ref.access; // 2
};

… how wonderful is that?

• we can just define when/where appropriate a way to both serialize and deserialize data
• we don’t need to change anything else around the code
• proxies can handle that symbol when accessed and never throw
• no special IDs, properties, extra checks, extra crawling is needed to retrieve back, or send, data as we meant in our program
• … profit for everyone?

Not just transferable …

Of course the SerializationRegistry offers a way to register, unregister or transfer explicitly data but its current special symbol, which ideally could be instead a global Symbol.toStructuredClone so that it’d be detached from the registry logic (although used internally), allows to simply intercept clone intents and provide a substitute:

const pythonHandler = {
  get(target, prop) {
    if (prop === SerializationRegistry.symbol) {
      if (target instanceof PythonProxy)
        return target.to_js();
    }
    return Reflect.get(target, prop);
  }
};

const ref = new Proxy(python_ref, pythonHandler);

structuredClone(ref); // it will not throw 🥳

As Summary

It took me years of experience in the Proxy, Atomics, Workers, MessageChannel, SharedArrayBuffer w/ binary serialization or FinalizationRegistry field to land what seems to be an obvious and simple enough proposal to tame the most powerful, yet limited, API we have to send or clone data in JS and I would be more than happy to answer any question around this proposal but please, if you think it solves it all for you too, help me and everyone else working with JS and Web based primitives to move this proposal forward because it is really missing out there and it’s really bad that only the PL itself can decide what class can travel and whaat cannot … so thanks in advance to whoever will help us all to have a way to fix the structured clone related issues that keep affecting our less trivial projects 🙏

When low-level Web APIs are based on guestimates you already know what the outcome could be: a (very likely slow) mess!

Meet maxByteLength on MDN to know more what is this about …

Why not realloc?

Here the thing: in order to resize an ArrayBuffer or a SharedArrayBuffer we need to provide upfront a maxByteLength parameter which is based on … assumptions, nothing else. There’s no way to explain what that value is, what a good amount would be, we have hints from the Web it should better not exceed 1GB of data, where NodeJS apparently has a 2GB cap limit and yet, this amount is strictly platform dependent because on constrained environments, even asking for 1GB could fail, due limited amount of RAM inferior to such limit, or already overwhelmed by the rest of the system.

Put in the fact a library that would like to provide best effort/performance over a Raspberry Pi, as well as a 128GB RAM based server, is incapable of deciding a best effort on spot and that’s it: an API that backfires on users’ intents as opposite of providing what has been around forever in the programming field, realloc!

Super slow via SharedArrayBuffer

Trust me when I say that a resizable ArrayBuffer is going to be 2X, up to 5X, faster than a resizable SharedArrayBuffer, up to the point you wonder if using just duplicated memory to then fill up the shared one would outperform just having a resizable shared one around … and you’d be surprised if you perform only a single grow call on that one and fill its bytes via a view set instead of working directly with that shared one … but you duplicated needed RAM so you’ll probably fail at that point anyway?

Benchmark

I know you don’t want to take my rant for granted, I wouldn’t neither, so here some numbers:

RESIZABLE BUFFER
encode: 3.037ms cold
decode: 2.514ms cold
encode: 1.389ms hot
decode: 0.78ms  hot

RESIZABLE SHARED BUFFER
encode: 7.77ms  cold
decode: 3.093ms cold
encode: 4.477ms hot
decode: 2.298ms hot

MAGIC VIEW FIXED BUFFER
encode: 4.995ms cold
decode: 3.695ms cold
encode: 1.513ms hot
decode: 1.585ms hot

MAGIC VIEW RUNTIME BUFFER
encode: 5.089ms cold
decode: 3.892ms cold
encode: 2.08ms  hot
decode: 2.013ms hot

DATA VIEW DECODE
decode: 1.591ms cold
decode: 0.95ms  hot

FIXED BUFFER - REFERENCE
encode: 1.817ms cold
decode: 1.901ms cold
encode: 1.006ms hot
decode: 1.058ms hot

Let me breakdown that for you:

• a RESIZABLE BUFFER is one that knows upfront what the buffer is going to be … “magic guessing” that might overflow the guessed max size
• a RESIZABLE SHARED BUFFER falls into same previous category, providing way slower resizes in the making
• a MAGIC VIEW FIXED BUFFER is there just to compare imaginary worlds, where you would use such utility and yet you already know the final size of the buffer, so that no resize is ever needed
• a MAGIC VIEW RUNTIME BUFFER is what this post is about: a way to transparently re-grow the underlying ArrayBuffer so that you don’t need to think about any of this at all and RAM is preserved by all means
• a DATA VIEW DECODE is what you would use to decode a pre-allocated ArrayBuffer via one way or another, it’s the native fastest decoding thing we have to date on the Web
• a FIXED BUFFER — REFERENCE is there to represent how fast all of this could be if the DataView instance would have an already perfectly sized ArrayBuffer that can be used to both encode or decode, with enough RAM available and guaranteed on the running system … it’s the benchmark reference not by accident!

Analysis

In an ideal world, we should never use resizable ArrayBuffer primitive because it’s slow on resizing, but that’s like “crystal ball programming”.

On the other hand, the fastest alternative is to use a resizable ArrayBuffer but that might suddenly go “out of bounds” if we had no idea what the size of the “thing” we were going to encode would be: it cannot resize on demand, it checks the system behind the scene before agreeing the maxByteLength size is reasonable, without giving us any way to retrieve such heuristic.

Further down we have a deadly slow SharedArrayBuffer primitive that cannot compete by any mean with generic ArrayBuffer performance. The reason we use this primitive is to have a shared reference we can await on when bytes have been filled, but discovering such primitive is so slow at changing might be a bottleneck or a show-stopper already.

As the common case is to fill data into your view, I have created a thin abstraction that provides all DataView methods over an instance able to track changes and, only when needed, create a new buffer after transfering the previous one internally, so that there will be enough room for extra data as long as the system has RAM available, bypassing the need to know how much memory is available in there.

This module is known as, or called, MagicView, and it’s my current attempt to forget about all these constraints we have around RAM based APIs, allowing with nonchalance all DataView related operations plus the ability to set any dynamic typed array value or even an array of numbers, as long as those numbers are within the uint8 boundaries.

MagicView in a nutshell

• it’s a DataView abstraction that lets you forget about memory contraints
• it’s ideal to keep filling up incrementally the ArrayBuffer with data
• the resulting buffer can be used to decode anything via native DataView or even Uint8Array capabilities
• you can use its extra setTyped, getTyped, setArray and getArray methods when convinient for your use case (MessagePack or Buffered Clone like related fields)

So that is basically it: one day we’ll have a “just grow as needed” primitive or method that does the right thing in a way developers can stop guessing target HardWare capabilities and memory availability; today that simplfication is represented by this module and as benchmark states, it’s a wonder to deal with while encoding, because it’s nearly as fast as any other native alternative and more than twice as fast when it comes to SharedArrayBuffer equivalent to encode data.

Enjoy 👋

Community Expectations

Well … Yes! Like many other core libraries’ developers that would avoid TS for reasons I’ll explain in here, among others, we all want to publish on npm something that can provide a great DX all over the developers’ space: targeting people sticking with vanilla JS or people using TS as default, and it’s all doable behind the scene!

This post is about exploiting just one of (hopefully not) many things TS makes you believe your code is better, or safer, while it’s not, actually the opposite … and from a developer (me) that, during his certified PHP days was all about “strict” (or even all) error reporting around the code, trust me: this is not looking good at all, especially when TS enthusiasts don’t understand the underlying issue!

A Failing Use Case

You can try yourself this simple case over TypeScript Playground:

const wm = new WeakMap<Object,string[]>;
const key = {};

if (!wm.has(key))
  wm.set(key, []);
wm.get(key).push('WUT?');
// ^^^^^^^^ oh, "the horror"!

You can play with strict VS non strict behavior and see that the error will always be the same:

Object is possibly 'undefined'.

And What Could Possibly Go Wrong …

First of all, from a single-threaded PL like JS is, nothing at all could possibly go wrong … unless:

• the guard is about using a potentially poisoned get method of a Map or a WeakMap randomly used in the code (spoiler: it’s not!)
• the guard is about TS not understanding the context around that WeakMap or Map in the wild … 🤔

Not sure you really needed to think about these options, but the answer is … 🥁🥁🥁 … the latter! 🥳

If a .get can fail, so can any .has or .set accordingly, but most importantly, in there I wrote code I want to be sure about that if such .get fails, I expect a “poisoned environment, GTFO or bad things will happen!” sort of instantly throwing message … right? … right?

I don’t want that code to silently fail and moveover because I trust I can find what I have been looking for (literally 2 LOC before, but the logic breaks further) … and I would never expect any error otherwise, accordingly to the logic I explicitly wrote!

Enter TS Misleading Safety Feeling

Most of the TS lovers still reading this, would just fix that issue with an “innocent” ?, isn’t it?

// previous code ...
wm.get(key)?.push('WUT?');

… fair enough, now I am going to ask you: what did that change to your original intent in writing the code the way you meant to write it?

Here some clues:

• that code will silently fail in there, keep going and doing things after instead of throwing in case that .get method was poisoned by evil code around (that is WeakMap or Map .prototype.get to be clear)
• my code trusts no evil code is around (bad for libraries authors, still the most common case in the wild) so I just want the TS compiler to be happy … writing meaningless and potentially less predicable code in the making … (congrats? when that will become a habit? 🙃)

Again, fair enough if you are OK with the second clue, yet … have you read, and understood, the first one at all?

Basically what we are saying is:

it’s OK if TS makes me write code that is more prone to 3rd party evil attacks and bugs, as I cannot guarantee anymore my expectations would fail fast when needed, i.e. when a poisoned or broken .get happens!

… but wasn’t the whole premises of TS about writing better code?

Enter @ts-ignore

The moment I need to write that comment anywhere in my otherwise fully valid JS code, is the moment I start questioning what TS really brings on the table … to me it starts falling into one of these categories:

• I use TS to help me refactoring later on (likely the only use case I agree about)
• I use TS because it makes me write better code (honestly the worst use case I agree about)
• I use TS because everyone else uses it (fair, in terms of job-market thinking, yet … not fully satisfying?)

Wondering about me? … Well, I am more about:

• I use TS because the community asks for it and my IDE understands JSDoc TS so that occasionally I have hints instead of shenanigans created by TS itself I need to fix later

… and that’s pretty much it, yet happy when it works!

Personal Conclusions

TS is there to stay, or even take over the JS world, but it has still tons of things to improve and I feel like it’s still in its early stages, despite all the great things it improved over recent years.

My personal thinking though, is why anyone would chose to make a powerful scripting language less powerful, and more error prone, due intrinsic conflicts between being strictly typed and naturally being “just a scripting language” (if not the best one) like JS is … I feel like everyone claims successful stories around how better TS made their daily workflow but nobody is able to admit how many times that workflow is stubbornly stuck behind, or slower due, TS incapability to really understand the JS code expectation and logic underneath, like I’ve shown in this post.

Once again, I love TS and what it does for me on daily basis, when I try to make it work out of JSDoc TS awesome integration, but it is in these cases that I wonder if I’m wasting my time instead, using directly or inderectly a project that feels not fully there yet.

Curious to know about your feelings around this topic too though and please, no hate, just sharing, thanks 👋

Closing with this gem: folks, it’s not about how strict or not strict TS is, it’s about TS not understanding the code where strict checks make it just more obvious TS does not, in fact, understand the surrounding code!

There are some lovely Quora’s answers regarding this topic, and I’d like to already break the ice around the fact MDN has been the go-to website when it comes to Web specifications, documentation, examples, broader context around APIs or experimental features and whatnot, so that if you are here to “hate”, I want to clarify that MDN remains (imho) the most trustworthy reference for Web developers out there these days … until they are not though, hence this post.

some background

While many on X that don’t know me at all described the topic I am going to talk about as “ego issue”, these are some historical facts around me and my 25+ years experience on the field:

• I am an Open Source and Open Web believer since my first days of Web development: I’ve learned from OSS and I’ve always tried to give back
• I have written polyfills to move the Web forward since IE4 times (yeah, I am 46 old, and I contribute as I can since I was 20 or even earlier), but if you don’t believe me, I’ve written polyfills before the term even existed for browsers like Firefox 1 and others around at that time … please don’t stop there though, me writing polyfills has been a thing up to today and FAANG to startups used my code in production too
• I did write some whole page on MDN in the past plus I did contribute in more recent times, due time constraints, amending here and there on occasions … even recently
• as annoying as I could be on (hopefully rare) occasions, when I disagree around some topic, my history of working experience from FAANG to startups can probably confirm I am also perfectly capable of letting it go and quickly move forward over disagreements or even suggest the best outcome for everyone out of such disagreement
• I have sporadically contributed to TC39 (ECMAScript / JS) specifications, or some WHATWG idea, plus I collaborated with Igalia to help them bring in the CSS :has(...) selector (and other less popular topics)

“But dude, why should I care about all this?” You are right, I might be “Mr Nobody” to you, but I think in the specs, and Web field in general, I probably or hopefully gained some trust: not as the best dev, surely not as the best dev to deal with, hopefully as one that has records of trusted contribution to the Web itself without ever causing issues with his popular, up to hundreds million downloads per month, OSS ideas.

And yet, MDN wouldn’t care a bit about me, my previous work, my history there, my contribution to their browser in the past, or the fact I also do OSS like they do, with tests, coverage, and cross-browser or cross-engine intents, because this is the answer I’ve got from my recent (double) PR:

We generally reject links to one’s own work

If you are still reading, I’ve tried to explain that it’s not like I want a special throne on the Web or anything, but from there to be a “generally rejected link” there are oceans:

• what does “generally” mean in there? where is the explanation of what it takes to be excluded from that rule? … crickets!
• why is a project born to be a community project that doesn’t even use my GitHub namespace, such as @ungap is, considered “one’s own work”?

Meet @ungap project

The @ungap project is a community related effort to bring mostly newly spec’d APIs to the browsers, in a “best effort” way that doesn’t include all the bloat other polyfills would include by default.

Quoting the project’s goal:

Pragmatic is better than (im)perfect

There are parts of the specifications that are very hard, if not impossible, to polyfill. The main purpose of this project is to help developers move forward, and possibly without unnecessary bloat. This basically means that polyfills are written to support 99% of the use cases, without granting 100% spec compliance.

If you need that, which again is basically impossible in most of the cases, feel free to keep using whatever monolithic polyfill or approach you were using before.

We all rant about JS bloat here and there and most don’t even realize the moment they use any transpiler that bloat is included by default to help them writing otherwise not necessarily usable, out of the box, code in the wild … and here @core-js plays a wonderful (no irony intended) role:

• it’s used by Babel and other transpilers, so that even if you don’t know about it, it’s likely part of your code-base or toolchain
• it’s under a single person repository, it’s not an organization or a collaborative place: you need to file issue to that original repo in order to get anything approved
• it’s paranoid about JS pollution, so it includes all over the place its internals. This is not a bad thing in general, but it’s free repeated bloat for anything you need or use from that repository
• because of the previous point, if you include 2 ponyfills separately from core-js, your bundle size will double out of the box for no reason and, most importantly, no extra security warrants

But here is the catch:

• core-js is popular because popular bundlers use and trust it and MDN promotes it
• core-js code-base is defensive by design, but it’s objectively as vulnerable as anything else on the Web, because the moment some evil script manages to pollute the env, if core-js is loaded after, in a module, or lazily, it’s a doom field like any other JS script that exists to date (until native import from ‘esm:Object’ lands in browsers and no bundler would dare touching it)
• because of all previous points, contributing to core-js is a giant effort, because learning all the ways core-js works, to grant that pseudo-feeling about security, and deliver, requires a lot of time to investigate or a lot of time in fixing whatever PR lands in there: you know it already? maybe easy … do you just want to move forward about some recent spec? Good luck there, I value my time more than ever these days (full-time employee + father of 2.5yo kid)

So, beside the fact I, as extra fact, value my time, the time it would take me to change current core-js polyfill around anything would probably mean a week of work, if lucky, while solving the problem my way would take, depending on the task, of course, half to 3 hours for an MVP that solves already whatever I needed to solve …

Broken MDN metrics

We generally want some proof of popularity (downloads, stars…) before committing to suggesting it

Let’s recap what happened in here … I’ve proposed an alternative ponyfill for a specification that nobody even knows it exists and the popularity argument has been used as a reason to close my effort to contribute?

I smell a catch 22 situation here or favoritism all over the place:

• you promote only core-js in there: how is anyone else even able to contribute by adding smaller, faster, yet still as safe, alternatives that could possibly be more popular?
• how can you disclose, ignore, destroy history around, the person trying to contribute for the community, one that contributed already a few times, one that has collaborated with standards here and there, one that is trying to help the community back by stating “here there’s a ponyfill that you can try with ease without breaking or slowing down everything around its usage” ?
• how can you make, as guideline for experimental related contributions, your decision on metrics for something maybe landed the day before and something nobody knows at all existed before?

So here I got triggered, because none of the above points make sense to me … maybe the fact the reviewer had no idea about myself is even OK, but what is the nonsense around this popularity point, when MDN publishes non existent in standard (yet) features and ignores anyone maybe even excited about such feature, or one like me that needs that feature daily, that even spent time to provide via a community project a solution that doesn’t cause bloat or global slow-down for every JSON related operation?

I believe the answer in there, and forever, would be crickets, because once again, while everyone on X has been fast enough to blame my ego, few understood that there is an overall issue with all the reasons the PR has been closed out of the box: no discussion ever started … “I suck”, that’s it!

The FUD around Security

We are particularly wary about links to polyfills, because (a) they will eventually be removed in favor of native solutions (b) they represent one of the most vulnerable attack vectors for supply chain attacks. Therefore, we have by convention decided that we will only include core-js polyfills.

This is the real reason I am here to talk about this review process:

• polyfills will be removed, and so will ponyfill. The MR in charge of doing that, once the time is right, is exactly one … so that my extra link wouldn’t really have bothered anyone in the future; it’s not that I added maintenance burden, a topic I would’ve paid more attention to if presented
• they don’t have any process in place to validate that core-js polyfill actually works as standards meant; they just accepts without a doubt that core-js works … if they had such process, other links would’ve been welcomed, or rejected by CI, because it means they tested the standard behavior, and can make an informed decision about accepting, or rejecting, that PR. Here they just decided any link that solves, in possibly a better way, the issue is not worth it, but no process exists to make sense of that decision …
• they are assuming me, my account, my OSS, is vulnerable, without providing an explanation around “why is that” or “what can I do to make it less vulnerable” … have I learned anything around that PR and my effort to improve the DX around this newly introduced API? No, nothing at all, all I know is that my code is considered vulnerable out of the box, thank you MDN!
• they tried to make the security argument later on, not while closing the PR, and that is even worse than the rest of this story … keep reading …
• there is a convention that established core-js is not vulnerable, and boy if I have links around that …

First of all, I already wrote a post around the fact nobody can trust JS execution, it’s by JS design, it doesn’t matter how paranoid is the stack you are running, the moment my evil.js script has a chance to run before your trusted core-js internals, you are doomed, trust me!

I wrote libraries that help mitigating this issue as long as these run before evil.js, that’s the contract: first run, first safe, there is no “but” here!

It’s not that I am new to the security concerns world neither, I have been working with security-concerned companies (as security service) where I could taint a whole environment to provide security concerns related issues for production sites … again, not my ego, it’s just a matter of facts that I know JS inside out and I wrote about security concerns “forever”.

Moreover, the moment you discard any community contribution in the name of security, implicitly inferring that the contributor is not a trusted JS developer, is the moment you are vomiting out anyone out there that actually has a way to contribute to the community by providing code that understands these concerns and provide better solutions that still work in best conditions, just like core-js does if no evil.js file has been landed on the page before its execution.

So here I might have lost my patience, answered badly, you name it in there, but if you make security a joke and you blame security on others, you are doing a disservice to anyone reading that thread, anyone believing core-js is infallible, anyone trying to learn what security means on the Web.

Security means you are behind CSP, you trust and validated every single script that lands on your page, including those 3rd party Ads related scripts, and you are sure by code validation before going in production that no script, unless trusted, would ever try to pollute global prototypes ahead of time … now that’s security, not your cheap and easy blame on ad-hoc issues created for the sake of creating those issues, because once again, I wrote “evil” code that can feel native, once introspected, by all means and others did the same before me! core-js is not immune and nobody should believe that using core-js means no security risks can possibly exist on the Web.

As Summary

Don’t trust MDN around security concerns: they have way more work to do before developers could be really informed around it and the fact they promote only a single polyfill on their documentation is rather an increased security risk (ad-hoc core-js evil.js as single point of failure) than a guard for Web developers.

This was the post, this was my rant around it … security has no compromises, if you care about security, and you should, that Pull Request is not the place you’ll learn anything about it, quite the opposite: it’s making you feel safer about their choice while you are not.

The rest of that discussion went from ugly to unbearable to me, so once again, I might have over-reacted, but I do take security concerns seriously and that was not the case in there .. and on top of that, my presented alternative stats:

• it doesn’t patch the global JSON primitive, hence it doesn’t make it slower by default, that’s what a ponyfill does
• it’s as “secure” (accordingly to those broken metrics used in there) as core-js
• it’s 90% smaller as plain text, 60% smaller once minified
• it’s 3x up to 5x faster than core-js once minified and gzipped

This is raw-json, a ponyfill MDN doesn’t want you to use or try … and this is the end, I hope I’ve given back to OSS something, one more time 💕

Update

MDN locked my issue and my account after also pointing me at other 3 locked discussions … and when did that happen? After I’ve invalidated all arguments in there providing fixes to the mentioned “security” concerns and benchmarks about code size and performance where my ponyfill wins by far compared to the polyfill they propose to all Web developers.

That’s Open Web “at its best”, isn’t it?

https://github.com/mdn/content/pull/36294#issuecomment-2411767537

If you haven’t read (entirely) this Jake’s post you should.

Now hear me out: the moment JS developers would need to track or nullify variables as if they are writing Rust is the moment any reason for scripting to exist is basically dead … so I am not going down that road, I am taking a tangent to this issue.

Avoid closures when not needed

As simple and silly as this might sound, every time you write this:

const outer = { huge: 'reference' };
setTimeout(() => {
  console.log(outer);
}, 1000);

you are better off with this:

const outer = { huge: 'reference' };
setTimeout(console.log, 1000, outer);

And every time you write this:

class Counter {
  constructor(element) {
    this.i = 0;
    element.addEventListener('click', () => {
      console.log(this.i++);
    });
  }
}

you are better off with this:

class Counter {
  constructor(element) {
    this.i = 0;
    element.addEventListener('click', this);
  }
  handleEvent(event) {
    console.log(this.i++);
  }
}

I wrote like 7 years ago why latter pattern matters, beside this blog post topic, and you should read it if you didn’t know about such pattern.

Track your references with ease

I have been dealing with memory leaks related topics for many years and recently I got that bar rised via WASM related projects where not leaking foreign PLs references is crucial.

Because I wrote tons of libraries to make leaks less possible, I also updated recently the most important one, the one that deals with the FinalizationRegistry, which now exposes a handy utility to track collected references via console.debug right on your browser’s devtools.

import BUG_GC from 'https://esm.run/gc-hook/track';

// HINT: use a constant so that rollup or bundlers
// can eventually remove all the dead code in production
// when the following constant is `false` instead
const D = true;

// create any reference
let test = { any: 'value' };

// when debugging, pass an object literal to simplify
// naming -> references convention
D&&BUG_GC({ test });

setTimeout(() => { test = null; });
// now press the Collect Garbage button in devtools
// and see the lovely message: **test** collected

The gc-hook module is 100% code covered and it’s been used in production for more than a year to avoid leaks from WASM targeting PLs to JS and vice-versa. Its /track export is just an utility that uses the module behind the scene and it will show via console.debug any reference that was collected. You can name references via object literal and read in devtools when these are collected. If you don’t read anything after you pressed the Collect Garbage button in your devtools it simply means that never happened, the end.

P.S. you need to enable verbose / all things in devtools to read console.debug in there … please double check before thinking your reference actually leaked!

As Summary

Apparently, due performance reasons, JS engines are refusing to fix a bug that is actually haunting the Web when it comes to memory consumption.

There are, however, easy ways to avoid closures leaks, such as:

• avoid closures when not necessary … that includes every setTimeout or setInterval that is not using extra arguments after the delay. If your counter-argument is that such practice requires extra memory to retain that outer scoped callback in memory try to do the math: is it better to have little extra overhead once or to have that callback overhead (the new closure each time) also leaking forever in your code?
• avoid closures to re-assign methods in classes so that these can be used as listeners, there is a handleEvent pattern that works fast and better since year 2000
• track references with ease through gc-hook/track module if you are worried something won’t get cleaned up
• use the React compiler if you are using React as apparently that tries to mitigate the issue too
• be mindfull of the unnecessary closures you create in your code … those are easy to write but apparently extremely difficult to digest behind the scene … nobody wins if each closure results into a leak (luckily, that’s not always the case, you should track that though)

Happy TS or JS coding everyone 👋

That’s it, that’s the post, really … if you look for SharedArrayBuffer in search engines the only thing that comes out is related to issue with headers, COI, CORP, COEP, and all the acronymis nobody needing this primitive really cares about, so here I am telling you that I have managed to polyfill this primitive for all Desktop to Mobile browsers, and it’s published on both npm and GitHub under the name sabayon (SharedArrayBuffer always on).

… previously …

I have previously talked about the beauty and power of this primitive, but it’s only over last weekend that I’ve decided to nail down an ochestration that “just works”(™️), one that wouldn’t compromise security at all, or that requires special headers that browsers’ vendors can’t even agree about, or need iframe credentialless attribute still in an implementation limbo when embedded foreign content is desired in websites that actually need Atomics and “SAB”.

Sabayon — the nitty gritty

Hopefully explained reasonably well in its GitHub’s README under the “How does it work?” detail, this module provides all related primitives to be used in either the main thread or the worker’s one.

A crypto secure unique identifier is used per each page or tab to ensure a safe communication across workers and main threads, and of course the Shared bit of the equation is a facade of an ArrayBuffer orchestration, but that’s fully transparent for this module’s users.

// Worker example
import {
  Atomics,
  Int32Array,
  SharedArrayBuffer,
  addEventListener,
  postMessage,
  ignore,
} from 'sabayon/worker';

addEventListener('message', event => {
  const { handle, complex } = event.data;
  handle[0] = 1;
  Atomics.notify(handle, 0);
});

const sab = new SharedArrayBuffer(4);
const view = new Int32Array(sab);

postMessage({
  handle: view,
  passThrough: ignore({ complex: "data" })
});

Atomics.waitAsync(view, 0).value.then(_ => {
  console.log('view changed', [...view]);
});

Atomics.wait(view, 0);
console.log('view changed', [...view]);

// Main example
import {
  Atomics,
  Int32Array,
  SharedArrayBuffer,
  Worker,
  ignore,
} from 'sabayon/main';

const w = new Worker('./worker.js', {
  type: 'module',
  serviceWorker: './sw.js', // optional
});

w.addEventListener('message', event => {
  const { handle, complex } = event.data;
  handle[0] = 1;
  Atomics.notify(handle, 0);
});

const sab = new SharedArrayBuffer(4);
const view = new Int32Array(sab);

postMessage({
  handle: view,
  passThrough: ignore({ complex: "data" })
});

Atomics.waitAsync(view, 0).value.then(_ => {
  console.log('view changed', [...view]);
});

Because the module is actually not obtrusive at all, what you’d get from it, if the right headers are around, is the native, untouched deal, except for waitAsync that is automatically patched in Firefox, as it apparently didn’t get the memo, but if headers are not there, and solutions to enable those headers are not desired, you’ll get the whole thing just as if everyhing was fine to start with: a win-win situation 🥳

Enjoy the beauty of buffers based exchanges between workers and main thread without the hassle and/or implications these primitives have behind the Web scene 👋