No no, I think you misunderstand me, the description is fine. I understand what it does and what it is for; But having a code example of it in use goes miles to help avoid making dumb mistakes and show it in propper context. and JS never tells you until you get the thing exported, plugged in, and it doesnʻt work. An example with the description makes it easy to see how it is implemented. I only brought up that particular item to show, like most entries, there is no example code.
Iʻm not saying "why donʻt you make this like unity". That feels a little like a straw-man. Pretty much any api documentation I have ever seen includes at least a single code snippet of the item in use, which is fair. Iʻm using unity as an example because it perfectly illustrates "...what more there is to add." (namely code examples with comments). But if that still feels unfair, these other examples will do just fine and are made by solo devs.
Here is documentation for a tool made by one person: ludiq.io/chronos/api/timekeeper.
Documentation for another package made, originally by one person.
corgi-engine-docs.moremountains.com/API/class_more_mountains_1_1_corgi_engine_1_1_a_i_action_jump.html
Constructʻs api isnʻt insanely huge, so comparing the effort needed to maintain or build documentation in contrast to unity isnʻt fair either.
On a favorable point, constructʻs documentation is well written, much better than gamemaker. And honestly, when it comes to the eventsheets, it is pretty much perfect, plenty of examples too. It just is missing examples for the api.