Can someone please read this article and sanity check me that it makes sense outside of my head and I’m not actively putting garbage out into the world?

https://amyshackles.codes/why-is-em...

I would greatly appreciate it.

You really should fix that horizontal scroll thing on iPhone 6S

@bagfox I ... don’t have any control over that whatsoever.

Not a JS dev, so nothing constructive for you, but this post has a few redundant statements which makes reading a little bit difficult. I got the crux only after reading it twice

Maybe add a TLDR at the top?

@asgs Better?

@AmyShackles the statements regarding OrdinaryToPrimitive are there too often. They could be established as rules in a "Context" section. The other two sections could simply walkthrough how it is in effect for those two operands

The third paragraph under toPrimitive([]) seams identical to the same under toPrimitive({}) which causes me to reread it to try to understand the difference which is not there.

Since this is a general description of how toPrimitive works without specifics it only needs to be there once, either under the section for {} or possibly before.

Then there is the part where you explain what toString returns, first [object Object] then “”.

But since both is an object I would have liked more explanation why they result in different strings.

That part is just stated as a fact with no explanation to why, which in my opinion is very important for the understanding.

So in my opinion the explanation cones up short of the goal, why does toString return different values for two different objects.

But just so I do not come across as to critical, I could not spot any obvious errors in the actual information :)

@asgs clooooser?

@Voxera Good point with the reason why they result in different strings. Good looking out!

My only thought is there should be an introductory paragraph as to why I'm reading it. It feels a bit like a knowledge dump a reader may lack context for. Just needs a short abstract (no pun intended) paragraph with an example explaining the novelty in question.

Technically good.

I assumed that everyone uses === in comparisons now. What is the use case for doing those comparisons? It seems like it would confuse another dev. Or is this a demonstration of a language quirk?

@irene It was just an example to see the output of toPrimitive in a different context. If you were to use a strict equality comparison, it wouldn't attempt to convert to primitive first (since they're different types).

SEO wise

Title too short and non-descriptive, it will be impossible to search this title in search engines

Section headings are also non-descriptive, Single word headings are not recommended,

Instead of linking to TLDR, you might place TLDR on top.

Content wise

Feels empty, I know it's just supposed to answer a question, but, didn't feel like I am reading something great.

So, over-all, make the sections more meaningful and add value to the readers.

The title in the URL can be the actual title, along with {} > [] in brackets.

Second paragraph under OrdinaryToPrimitive is kind of hard to follow - I feel like I'm missing some "why". Knowing the rationale behind why they designed it like this would help greatly in understanding it.

The rest is quite clear. I really appreciate the links to the Ecmascript standards. This is probably the clearest explanation of this property I've seen in writing. Nice one.