How to rewrite classes using closures in JavaScript
gaurangtandon.com
gaurangtandon.com
Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress.
On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened.
But I was there. I was there in 2008. I was there at the first Expo show in IRC. I'm losing my edge to the kids whose fingertips I hear when they get on the decks. I'm losing my edge to the Internet seekers who can tell me every member of every JS design committee from 2008 to 2018.
I'm losing my edge. To all the kids in typescript and wasm. I'm losing my edge to the bootcamp Brooklynites in little jackets and borrowed nostalgia for the unremembered nineties.
I was there. But I was there. I can hear the fingers every night on the decks. I was there in 2008 at the first search engine collapse. I was working on MVC frameworks with much patience. I was there when Ruby started up test-driven development. I told them, "Don't do it that way. You'll never make a dime."
I was there. I was the first guy playing dynamic dispatch to the php kids. I played it at phpclasses. Everybody thought I was crazy. We all know. I was there.
I've never been wrong. I used to work in the dev store. I had everything before anyone. I was there in the C# linq booth with Anders. I was there in Glasgow during the FP clashes. I woke up typing on the beach in frontpage in 1998.
But I'm losing my edge to t-shit clad people with proprietary ideas and more investment. And they're actually really, really nice.
I'm losing my edge. I heard you have a compilation of every good quine ever written by anybody. Every great patch by Linus Torvalds. All the flamewar hits. All the sourceforge tracks. I heard you have a floppy of every 90s asm rpg on German import. I heard that you have a white label of every seminal Gang-of-Four techno hit - 1995, '96, '97. I heard that you have a CD compilation of every good '60s fortran book and another box set from the '70s.
I hear you're learning vim and lifetimes and are throwing your c compiler out the window because you want to make something safe. You want to make a web app.
I hear that you and your team have deleted your .NET repos and installed npm packages. I hear that you and your band have deleted your npm packages and installed F#.
I hear everybody that you know is more relevant than everybody that I know. But have you seen my records? Wirth, Peyton-Jones, Dijkstra, Fortran, C, C++, D, R, Haskell, PHP, Python, Scala, Java, C, ... malloc, gcc, #include, while(*s++), ...
You don't know what you really want
- no private properties (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...)
- no readonly properties: You can use a getter. Or define the property as non-writable, the syntax isn't nice but in my opinion it's still much nicer than what the article proposes.
Some of the points are just a matter of taste ("this" is awkward)
There's the implementation itself which forces you to use non-idiomatic code for no good reason or benefit (Class.init instead of new, just why? You can absolutely return a constructor function there while preserving everything else)
Doing what the article proposes also destroys the ability to do instanceof checks because the prototype of instances is not set (can be fixed), and inheritance is severely limited if you want to preserve any of the purported benefits. You might say that inheritance is actually not a good thing and so it's a feature, not a bug, but if that's your opinion why are you trying to mimic a class?
TBF classes are just a layer of syntactic sugar over the (awful) prototypal system (which somewhat sadly few were interested in making better let alone good).
Behind the scenes, they pretty much just create a ctor function and prototype function, except you don't have to mess with the terrible `Object.create` and `.prototype =` nonsense.
Abandoning constructors and going full-on with prototypes would be an other thing entirely, but the reality is that javascript is not very good at it so it's not very fun (except as a proof of concept / investigation of prototype based OO), and pretty much nobody is interested.
Other commenters have pointed out some of the technical issues with this implementation (all instances get a copy of every method, no prototype-based type checking, non-standard use of "init" vs new, etc.) But the much more important issue is that you did not make life easier for other developers looking at your code. Instead, you just forced them to learn one additional, non-standard way of doing things with very little, if any, real benefit.
Developers need to learn to be extremely judicious whenever you use unusual/non-standard patterns in code. Everyone already needs to learn the standard way of doing things, so there should be a giant bar in terms of things like productivity enhancements or performance improvements if you're forcing everyone to learn your non-standard pattern. Avoiding "this" doesn't cut it.
Fwiw this exact pattern was the idiomatic defacto standard in JS before classes were added to the ECMA specs. This will be extremely familiar to anyone with a reasonable number of years of experience in JS.
That's not a good defense in itself: things should ideally be familiar to beginner devs, but that's more of a debate on what's being taught in current JS education than on what's "better".
i.e.: if this were a better pattern (it's not), lack of familiarity wouldn't be a good argument against it.
> with very little, if any, real benefit.
In fairness the article spends most of its time laying out the proposed benefits, so stating that there's no benefit without addressing its arguments is a little lazy.
Some of the arguments are inaccurate (private fields have been widely supported since 2021) but it's true that ECMA's class implementation is riddled with issues & exploring alternative patterns is worthwhile.
Even before ECMA added classes, I never liked this pattern: it seems a clumsy attempt to shoehorn classical inheritance -esque arrangements onto a prototypical language without ever putting forward reasoned arguments for the benefits of doing so. This article at least tries to put forward arguments about why fake shoehorned classical inheritance pattern is better than the "standardised" shoehorned classical inheritance pattern, but in reality both are bad.
No it wasn’t. Some people used it, to be sure, but more used the prototype chain properly, storing data in `this` and all that.
Just because of your personal opinions and certain things that don't matter in the end, you want to ruin everybody's development experience.
The proposed solution is way uglier than the standard syntax, and you'll be lucky to get any intellisense or type checking out of it.
This will package a copy of the functions with every instance you make, the class variant will only create member variables for each instance.
Maybe save a few bytes down the wire with a different developer experience for fundamentally more bloated code.
And anyway, all of the stated problems either are none or can be solved by using TS.
what does "bloat" mean in this sentence? people use "bloat" liberally nowadays.
It’s… a take, for sure.
class Foo { #ImPrivate = true; #meToo() { if(this.#ImPrivate) cantTouchThis(); } }
new Foo().#meToo() === BOOM
Also with using closures for "classes" takes up a whole lot more memory because new instances off all the closures are created for each instance of the class.
get name() { return this.#name; }
Half of this article seems to be based on the author’s unawareness of JS class syntax.
See for example:
https://github.com/rollup/rollup/issues/349
I think it is good to know that there is no tree shaking for class methods, even when public.
This is a valid consideration IMO.
The missing minification of identifiers and properties of the Vue instance in general were always bugging me in Vue 2, even when not using the class keyword.
https://lea.verou.me/blog/2023/04/private-fields-considered-...
Quote:
> Private fields, proxies, pick one, you can’t have both.
And thank god for TypeScript compiler's private keyword! While... I can see how this plethora of possibilities looks confusing.
Here's the example code: https://gist.github.com/conartist6/95f5be3488b2ae6c0dfd9a886...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
"Having to write:
this.progressBar.addEventListener(this.handler.bind(this)); is much worse compared to:
progressBar.addEventListener(handler);"
If handler is declared as:
class Foo {
handler = () => {
// handle
}
Then there's no need to bind it to this when using it later.[2]
You can just write
this.progressBar.addEventListener(this.handler);
Additionally if handler doesn't reference any other class properties and isn't referenced outside the class, it can also be a function in the module.
class Foo {
constructor() {
this.progressBar.addEventListener(handler)
}function handler () {
// handle
1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
2. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
[0] - https://stackoverflow.com/questions/2497801/closures-are-poo...
console.log(`Average height for dogs is ${AVERAGE_HEIGHT_FT} kg`);
I can't tell from a glance from either before or after what the fields of the class are, let alone what sort of data goes in them. I suspect my IDE would have a struggle as well, and allow mistakes, at runtime, to either raise exceptions, or perform incorrect behavior.
I think maybe a cleaner approach in this domain may be TS interfaces + standalone functions that act on them.
Stopped reading there. Whenever someone displays this mentality of "less code is better, every character above the minimum necessary is bloat" I immediately assume they've never had to read complex code written by someone else (or even their past selves) in their life.
If you don’t want to go with classes, not exporting a value or a function from a module is almost the same. The rest can be done with closures.
When looking through npm modules, there still seems to be a variety of approaches.
Deno has some ideas though:
> Don’t import any symbol with an underscore prefix: export function _baz() {}.
> Don’t link to / import any module whose path […] Has a name or parent with an underscore prefix: _foo.ts, _util/bar.ts.
If you want replicate more class-like behavior (but without actual class/inheritance information):
- Some type of exported constructor function
- The function instantiates an instance of data internally that is possibly mutable (let vs const)
- That function returns an object/interface of functions that have access to that data by virtue of it being defined in a higher but accessible function scope
- All other private functions are simply not exported
Or you might mean singleton data:
- let or const data at the file/module scope level
- export functions to operate on the data
- Don't export functions you want to be private
The first is sort of reinventing a class instance, but if you are anti-inheritance for the most part (likely a good idea), then you can use a "kind" or "type" property on the returned constructed plain object if needed (TypeScript generics make this quite ergonomic to represent as well). So, you don't really need classes, but they have their uses and have familiar and comfortable syntax to programmers from other languages. You can use either and they are both accepted as idiomatic.
I usually still allow classes in codebases that I have some control over, but add a custom ESLint rule to ban extension unless with an ignore comment. This sort of encourages you to compose more like the functional/data approach, but allows you to still use instanceof since it's an actual class. It also means you're not creating a copy of all the method functions if you don't need to between instances.
There is a caveat that there is a class syntax:
method = () => {}
That auto-binds the method to this, creating that method copy for all. In this case you're encroaching on the plain object behaviour, again with a more familiar syntax.
So, I guess it's more messy than I thought reflecting on it. But you have some choices depending on what properties you'd like to encourage in your codebase.
With so many options, it’s hard to know what you’re doing is “right” and to setup the appropriate lints and whatnot.
The machinery behind the scenes might be ugly, but this syntax is also what I love about React Hooks.
I was preferring closures to ES6 classes before using React, despite the performance implications.
Since switching to TypeScript I also like ES classes though.
Especially for things like MobX... but even without it.
Regardless of React, I feel like classes are the context where getters and setters feel most natural and ergonomic.
And classes are great for grouping state and behavior in an easy-to-understand way.
`this` is excellent for maintenance (being able to easily distinguish between instance variables and other things is very valuable), and generally good for performance (more subjective and nuanced involving runtime and memory and consideration of how often you instantiate and how often you use and I won’t provide any citation).
> No private properties
This is where the article falls down; and everything after it is suspect. Because all browsers have supported private class fields since mid-2021. For almost all purposes, this has fairly recently become good enough to depend on. Private class methods is right on the verge, since Safari added it in 15.0 (September 2021) rather than 14.1 (April 2021) like private class fields; I’d say that most purposes can safely depend on this now.
Reference: https://developer.mozilla.org/docs/Web/JavaScript/Reference/...
> No readonly properties
class MyClass {
static get prop() {
return 123;
}
}
MyClass.prop = 456;
The more-efficient-but-less-friendly-to-some-tooling alternative is placing this after the class:
Object.defineProperty(MyClass, "prop", { value: 123, writable: false });
There is some legitimacy to this claim, but it’s entirely because all relevant tooling is surprisingly primitive. And most of the places where it seems legitimate, your replacement will suffer from the same issue.
But a lot of it is actually not legitimate: if you only used private fields, they would be optimised, detected as unused, &c. in all these ways.
The example is also a bit dubious in points like the AVERAGE_HEIGHT_FT field on Dog: writing it that way rather than as private or (typically my preference) as a const adjacent to Dog implies it’s supposed to be public (and the naming of these static fields supports this).
And .height and .weight being part of the public interface? I expect that to be a feature, not a bug. .weight is not unused, unless you check the whole code base and find it so. (And the surprisingly-primitive tooling can’t do that whether you use a class or an object.)
> Closures to the rescue! […] Immediately, we see several advantages:
Four are listed. Numbers 1, 2 and 4a are broadly or completely false because you just needed to use private fields. 4b has also been addressed (readonly is just spelled using a getter function).
The only interesting claim is the third:
> 3. We have lesser code bloat thanks to removing this. and Dog. prefixes.
You probably have a smaller bundle size, but it wasn’t bloat: by removing it, you’ve vastly increased memory usage requirements and normally slowed things down, because now instances share almost nothing (only static fields), instead of almost everything (all except for instance data).
—⁂—
All up, I say: try using private properties for a while, and measure various aspects of performance: actual bundle size savings, plain and gzipped; memory usage; and performance if you have any places slow enough to actually measure anything. Then come back and we can consider the topic anew.
Will bookmark for future reference.