DEV Community: Reinis Ivanovs

Extending native JS prototypes is not such a crazy idea with symbols

Reinis Ivanovs — Thu, 20 Jul 2023 15:37:23 +0000

Dynamic languages like JavaScript have something called "open classes" that allow to extend or monkey patch code at runtime, including the standard built-in objects, and this has always tempted users to try and improve the language with custom methods that are in the shared global namespaces like Array.prototype instead of their own, because it's just convenient that objects come "batteries included" without having to be wrapped in anything and even if they're constructed using literal syntax. To illustrate, you could look at all the historical Stack Overflow answers about flattening arrays before Array.prototype.flat() was added in 2019, because all of them come with different tradeoffs for something that should be a very basic language feature.

Workaround #1 for missing built-in methods: helpers 🛠️

It's no big deal, right? Just abstract flattening to a helper function:

function flatten(arr) {
  return [].concat.apply([], arr);
}

Except this comes with a host of practical, performance and aesthetic issues, starting from the fact that it's not chainable like other array methods and you need intermediate variables, which you can fix by making it a callback to .reduce(), but then it's making N function calls instead of just one like before, etc. It's still no big deal, but the inconvenience adds up, including if you're using helper libraries like Lodash where a lot of work has already been done for you.

Workaround #2: wrappers 🎁

Wrappers step up the complexity, but improve on just helper functions because they allow method chaining, with the most classic one being jQuery's $(). The nice thing about wrappers is that they can namespace methods and editors can show context-aware autocompletion for them, but their Achilles heel is the need to wrap and especially unwrap values, and also that wrapping or converting hides the previous identity so you can't do simple identity comparisons etc. All in all, the fact that even high-profile projects like Immutable.js have limited adoption testify to wrappers just not being convenient enough.

Workaround #3: function composition and pipelining 🪠

An alternative to method chaining or the so-called fluent interfaces is pipelining, and, for example, Lodash provides it as _.pipeline(). This is the functional approach, and functional languages have built-in support for it, but even though JavaScript is a multi-paradigm language and has functional elements, pipelining is just not idiomatic in JavaScript, while chaining is. This is illustrated by the difficulties the pipeline operator proposal has faced in getting standardized, even though it's on many developer's wish list.

Workaround #4: native prototype extension 🏗️

This circles back to the beginning of the article with array flattening as a missing standard feature, because around 2006, when the first JavaScript libraries were just appearing, one of them went and fixed this issue by implementing their own Array.prototype.flatten, and it also tried to "play nice" and not overwrite the method if it already existed, which ironically ensured that code relying on their custom implementation would break when a standard one was added and didn't behave the same. This all caused an event called SmooshGate, and similar situations are responsible for why some of the other method names in JavaScript are also somewhat odd due to more obvious names being "taken".

In fact, the very first widely adopted JavaScript library was called Prototype.js, and one of its selling points was extending the DOM APIs so that DOM Elements would come "batteries included", but it got out-competed by jQuery largely because people realized that native prototype extension is dangerous in that it's fragile and hard to maintain compared to wrappers.

Since then, monkey patching the built-in objects has been a long-standing discussion, with some people still trying to cling on to its promise, but overall the consensus is that it's a bad practice that should be reserved to polyfilling, and that you should only modify objects that you own.

Solution: symbol protocol extension 🤯

The concept of protocols is already in use in JavaScript, most notably as as iteration protocols, and there is even a proposal to add first-class support for symbol-based protocols. I've also made a proof-of-concept library (Symbola) for implementing symbol extension in userland, and it actually works nicely, with some caveats.

Something that should lend legitimacy to this approach is, firstly, that it aligns with similar language features like Swift and Clojure protocols, Rust traits, Haskell typeclasses and others, and, secondly, that it has theoretical grounding in that it solves the expression problem. In a nutshell, the expression problem is when you want to both be able to easily extend existing methods to new data types, and to extend new data types with existing methods, all without modifying the source code, and also while retaining type safety.

The extension problem is not just an academic exercise, because there's real pragmatic reasons why you are not able to or don't want to modify code but want to extend it, and not owning the code is one of those reasons. This is why, in a sense, the "open classes" and monkey patching in JavaScript are a fix to the expression problem, but you're not supposed to use it because it leads to fragility, namespace collisions and maintenance problems.

Symbols to the rescue 📯

Symbols are unique and can be used as keys instead of strings while using the same namespace like, for example, Array.prototype, and define a flatten method that can be accessed only with reference to the unique symbol:

const flatten = Symbol('flatten');

Array.prototype[flatten] = function() { return [].concat.apply([], this); };

[[1, 2], [3]][flatten](); // returns [1, 2, 3]

Using interface merging in TypeScript also allows this to be well-typed, and the really interesting things start when building on other protocols:

const map = Symbol('map');

Object.prototype[map] = function*(f) {
  for (const x of this) { yield f(x) }
}

const xs = new Set([1, 2, 3]);
console.log(...xs[map](x => x + 1); // logs [2, 3, 4]

Suddenly the Set objects have a map method, but so does every object that inherits from Object.prototype and conforms the iterable protocol, namely has a [Symbol.iterator]() method that returns an iterator, and this, too, is easy to express in TypeScript:

interface  Mappable  {
  [map]<A,  B>(this:  Iterable<A>):  Iterable<B>
}
declare  global  {
  interface  Object  extends  Mappable  {}
}

This means that editors can know to auto-complete the [map]() method correctly, and the type system will check if the target is actually an iterable, so the support for it is first class.

In conclusion, the biggest caveat of this approach is probably the unfamiliarity to developers, but it does have a valid use case, and JavaScript and TypeScript so far just seem behind other languages in exploring it.

Deno is probably not worth it right now

Reinis Ivanovs — Fri, 15 May 2020 16:01:02 +0000

Deno has been riding a certain hype train since its recent release, and it's important to look at it critically, first and foremost to avoid investing your limited time in a technology that might not pan out for your requirements and use case.

The title of this post already gives away the conclusion that Deno is probably not worth it, but the way I arrived at the conclusion was by trying to like Deno and to see how it could be used to its strengths. This post won't say anything very original, but the intent is to give a concise overview of where Deno fits into the tooling landscape.

Improved security

A highlight of Deno over Node.js and most other environments is the improved security model: programs don't just get blanket access to the resources available to the current user. I've seen the security improvements dismissed out of hand compared to other approaches like containerization, but it's actually a modern and welcome approach to limit access to resources by default; it should be an increasingly familiar approach going forward, and an another example of it is WASI using a capability-based security model.

A fresh start for APIs

Outside of security by default, the other major advantage is to be able to break with the legacy aspects of Node.js APIs. To illustrate, this is how you can watch for file system changes using Deno:

for await (const { kind, paths } of Deno.watchFs('.')) {
  console.log(kind, paths);
}

It takes advantage of ES2018 async iteration, and it even works at the top level without needing to be wrapped in an async function. Setting up the same (excepting the top level part) in Node.js would require boilerplate like this:

const changes = new stream.Transform({ objectMode: true });
fs.watch('.', (event, pathname) => { changes.push({ event, pathname }); });

It creates a Node.js stream, which also implements the async iteration protocols and can be used with for-await-of loops, but you'd have to go out of your way to even know to do this, and usually it'd just be done using a plain callback, which at its worst can lead to the "pyramid of doom" problem. It's not a huge deal, but is an example of how a newer API can feel less "crusty" to use.

Deno also aims to avoid duplicating existing web APIs, such as fetch(), which means you can reuse the same API knowledge between platforms, and it should generally be a welcome idea.

Dependency management is where it gets less fun

Deno is made by Ryan Dahl, who's also the original developer of Node.js, and, since the outset, the development of Deno has been couched in terms of fixing Node.js pain points, but the talk that explains the motivation can also be (only somewhat uncharitably) summarized as "you could make the Node.js implementation simpler by not implementing features, like packages". It's not a compelling point to those relying on the features who would need to find workarounds.

Deno takes a page out of Go's approach to dependencies and doesn't provide a dependency manager like npm or Rust's cargo; instead of having special module resolution rules like with require(), modules are just loaded from URLs using the ECMAScript module format, and conventionally are re-exported from a deps.ts file instead of being listed in package.json.

There's still a way in Deno to create lock files, there's also an optional way to have zero-installs like with Yarn by commiting a $DENO_DIR, and there's even something that vaguely resembles a centralized registry, so it's all kind of similar while still being different and incompatible with existing tools and approaches in different ways.

Compatibility and interoperability are crucial

Deno simplifies its implementation by skipping package management, but then it, for example, has a built-in test runner, which Node.js doesn't. Deno simplifies the Node.js APIs, but then it still needs to provide a complex compatibility layer, because there's a lot of existing and useful software using Node.js APIs. It's also adding a native plugin feature, although it'll probably never support Node.js native extensions.

The developer experience in all of this is a stream of "how do I…" and then often discovering that you either just don't, or that it's rudimentary compared to what you're used to (like the built-in Deno test runner compared to something like Jest), or that it half-works (I couldn't get the test runner work in watch mode using Denon, which is meant to be the alternative to Nodemon).

For example, npm and Yarn provide package scripts, which give a set way for users to discover and run commands, but in Deno you'd either have to find Velociraptor (made less easy by the non-descriptive name of the tool), or use Makefiles or just shell scripts, and you'd also possibly be leaving out Windows users.

A list of issues like this could go on for a long time; some will have workarounds, others are just due to Deno just being released, but overall, if your goal is to get specific tasks done and not just use a "shiny new" tool, the lack of interoperability or compatibility skews the equation against Deno.

Conclusion

It can be helpful for Deno to "shake things up" and, for example, maybe make Node.js improve faster in aspects like modernizing its APIs, and to put the "security by default" model more solidly on the map, but overall Deno is a hard sell from a pragmatic standpoint. It reminds of the situation with Python 3, which brought improvements, but then took a long time to reach wide adoption due to it often just being easier to continue using Python 2.

Features like first-class support for TypeScript can also be a mixed bag (which I say as someone who generally prefers TypeScript), because use cases like prototyping or one-off scripts can actually benefit from dynamic typing, and it's also not necessarily useful to have type checking in the test runner if you already have it in the editor and the CI, but Deno doesn't yet have a way to selectively turn type checking off.

Even if you're not using Deno but are a library or tool author, you can look forward to possibly getting bug reports from a new, not fully compatible environment, or requests to support it, which isn't trivial (although the upside is that Deno should hopefully speed up ES module adoption).

The bottom line is that it's probably better that Deno exists, but its selling points are stretched thin by that it's still new, and that a lot of useful libraries and tools don't work and sometimes can't be ever expected to work.