(reading time 15 min)

Behavior Delegation  – OLOO (objects-linked-to-other-objects) pattern.

Some time ago I wrote this tweet:

I’d summarize it like: Thinking JS has classes is like believing the engine of your car has real horses in it. I hope I got it right 🤓

Reading the You Don’t Know JS (YDKJS) book series leaves something inside you, especially when you have been in the front-end dev world for so many years.
It is a mix of amusement, inspiration, and sense of chaos about what web dev is, and what it has been for Javascript development in this specific case so far.
So sometimes you want to throw some message in the air, to externalize such feeling.

I personally found what I tweeted, quite significant so I decided to share it in other places, included Linkedin.
There a guy, front-end dev like me, showed his appreciation for my post and suggested to read a post he wrote on the topic.

I read it very carefully, this subject passionates me and it was a quite interesting post.
But at the end, the way the issue was tackled gave me this feeling, it was saying something like “ it would be interesting in theory, but do it this, instead, because everybody does it this way/this is the real trend”.

This was the conclusion on how to tackle a basic object structure in JS:
(I added some comment in the code to underline which code I’ve appended, just to allineate the two solutions, the post’s one, and mine):

That is what you can find in the vast majority of the articles and tutorials around.

The post was quite aware of the real pattern under the hood of JS, and of the fact that JS just doesn’t have such things as classes.
But at the end, it was like, “yes it’s kinda like that, but this is what it’s considered best practice, instead”.
That’s fine, I mean everybody sends the message that feels right, and I cannot say that’s not the truth.

But that made me grow the will to go further. I was like, ok, now the status quo is important to know about, but I think it’s time to go on and try to send a different message.
The message could be something like “Here’s a potential more performant, maintainable and javascript-ish (real javascript way) to use javascript. Maybe It’s time to consider this.”
I stay very much away from sending a message like “F@#£ the legacy code, throw everything away! Let’s start from scratch!” I am not so crazy.
But I feel that this way of writing JS and all the concepts that it brings, deserves more, and deserves to be shared and pushed more firmly.

That’s my version using the OLOO pattern according to YDKJS:

It’s simpler and implies a lot less potential problems and it’s way more efficient.
This is my opinion of course, or I would say this is Kyle Simpson – YDKJS opinion, and I find it extremely valuable.

I could write a lot and a lot more about this, but mostly it would be just a very bad copy of the YDKJS book series.
So why you don’t dive into it.

If you want to start from the beginning go here.
If you want to jump right over the exact point in the chapter that inspired this post go here.

If I didn’t accomplish my intention here, that was to make you wanna dive hardly in this book series, watch this.
These are the two diagrams that compare what should happen under the hood in JS when you use the first approach (FIG.1), and what it implies working with the OLOO pattern (FIG. 2):

class-ish js way model under the hood

FIG. 1 [from YDKJS series as linked below]

oloo js way

FIG.2 [from YDKJS series as linked below]

Ok, I feel a little better now 🤓.

I hope someone finds something new to learn or just some inspiration, or maybe just a pleasant time of 10 minutes, here.
It would be worth it anyway.

This for sure inspired me so much and gave me a new perspective for a lot of things.

Keep on searching for the “better than before”! Cheers!

p.s.: if you wanna play with this code, here’s a JS Bin for you

p.p.s.: Here’s the Linkedin post (unfortunately they commented in Italian)

Leave a Reply

Your email address will not be published. Required fields are marked *