Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to rewrite classes using closures in JavaScript

gaurangtandon.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: How to rewrite classes using closures in JavaScript

#51

Post by mumblemumble »

mjburgess wrote: post #45
mumblemumble wrote: post #17

The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He careful…

Yeah, I'm losing my edge. The kids are coming up from behind. I'm losing my edge. I'm losing my edge to the kids from Stanford and from CMU. 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 2…

Nice. I want to see this set to the music and put on YouTube.

Re: How to rewrite classes using closures in JavaScript

#53

Post by masklinn »

cjcenizal wrote: post #25
lemper wrote: post #16

> The this prefix is mandatory for every instance property, which increases code bloat. what does "bloat" mean in this sentence? people use "bloat" liberally nowadays.

The author might have meant “boilerplate.”

They mean bloat as in source code bloat as in the source is larger because you have to prefix every method call with “this.”

It’s… a take, for sure.

Re: How to rewrite classes using closures in JavaScript

#54

Post by moritzwarhier »

stupidcar wrote: post #22
rickreynoldssf wrote: post #12

There are private properties in classes 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.

There are also getter (and setter) properties that can be backed by private fields: get name() { return this.#name; } Half of this article seems to be based on the author’s unawareness of JS class syntax.

The optimization points are good to keep in mind, no?

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.

Re: How to rewrite classes using closures in JavaScript

#55

Post by nurple »

masklinn wrote: post #36
nurple wrote: post #32

Earlier quoted context omitted.

Agreed. I spent a small epoch of my career trying to make js have "classes" in the heady days of OOP. It took a bit to realize that idiomatic js didn't need them. Besides being sold so hard on OOP as a concept, failing to understand prototypes was one of my biggest mistakes. By the time they landed, I was actually pretty disappointed to see the language get classes.

> By the time they landed, I was actually pretty disappointed to see the language get classes. 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 `.prototyp…

Yeah, that's fair. I guess I don't really use prototypes anymore either. I find modules and closures are intuitive and powerful, though very different conceptually from classes/prototypes, tools for handling things like private state. Really OOP is what I've grown away from over the years in most languages. I even enjoy writing C++ in this style since its capabilities around things like closures has improved, anonymous namespaces make for a similar "module" scope to what you find in js.

Re: How to rewrite classes using closures in JavaScript

#56

Post by w3news »

the__alchemist wrote: post #40

IMO before the before and after patterns are a mess compared to a struct in Rust etc or a dataclass in Python. `this` or `self` is important to be explicit; C++ is an interesting case in that it gives you a choice; `this->` is the better approach than implicit, which is ambiguous. 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 suspe…

Typescript wil not help, you can create the same mass. What me helped is to write almost all code functional and not oop. Every method had just 1 way data can in and out the method, no side effects. Classes have a lot of flexibility that make things complex and increase bugs. If you are strict in what to accept and what to produce, and start with the test, if you create mess, you can eat refactor to create clean code.

Re: How to rewrite classes using closures in JavaScript

#57

Post by hn_throwaway_99 »

lucideer wrote: post #44
hn_throwaway_99 wrote: post #35

Lord, no, please, please don't do this in any codebase that anyone else has to actually look at/contribute to. 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…

> non-standard way of doing things 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…

Totally agree with the other response. This absolutely was not standard before class syntax was introduced. Use of constructors, new, this, etc. was the standard - class was essentially just a back port, adding syntactic sugar on top of the prototype design that was inherent to JS from the beginning. The only time I saw something like this was just from people that didn't really "get" or understand inheritance or OOP.
Post reply on HN