Howto is super important to me, it's absolutely bananas how many docs seem to assume you understand the whole library and don't explain any surrounding context or how things effect other things in the context.

Especially bad in 100% documention requirement shops where you get stupid things like '@param foo - Control <foo>' where having some examples would be much more useful than a wall of those parameter 'descriptions'.

From my experience with my canvas library, devs seem to want different types of documentation for different purposes:

1. Something that tells them what the library does: what problems it's gonna solve for them; how easy it is to work with; etc. Having something to play with is really useful here, for instance some "Getting started" code to (very quickly) show them the basics and let them play with the library. A set of "learn to" lessons tackling some interesting problems is good bonus documentation, alongside a good range of demo code.

2. Something that they can show to whoever controls which libraries they can use in the product they're working on, to help convince them to let the dev use the library. Usually involves some marketing copy and comparison charts - whatever A/B tested copy|crap floats the boat.

3. Some easy-to-use lookup reference stuff - what function do I have to invoke to get this specific thing done? Stuff that their coding environment doesn't reveal at the click of a button. This is where the LLM-focussed documentation comes in (I think), given the move to using code assistants: failing to (be able to) teach the models what the library can do (and how to best do it) can lead to bad code and wasted time, which reflects really badly on the library.