Tools page review and suggestions

Great job on the new tools page 🎉! I looked over it today and saw a few suggestions.

Environments

I found it confusing to have online tools listed under validators. I think environments is pretty important information and should either be clearly labeled in the listing or presented separately somehow.

Hyper Schema

LDO Utility can be merged with Hyper Schema. LDO is part of hyper-schema.

I'm not sure any of these should actually be listed. They should at least somehow be marked as a work in progress.

• Core API Hyper-Schema codec - Appears to be just a few lines of code that doesn't have anything to do with hyper-schema or even JSON Schema in general.
• mokkabonna/json-hyper-schema - Appears to be incomplete. The author never got it to a usable state.
• @cloudflare/json-hyper-schema - Described as the beginning of an implementation that clearly didn't get very far before being abandoned.

The only complete and usable implementation of hyper-schema there has ever been is jsonary (draft-04) which doesn't seem to have survived the transition to the new page. I think it should be included and probably should be the only one included.

Abandoned Implementations

There are a lot of implementations listed here that are clearly abandoned. For example, json-schema-benchmark is known to be the source of misinformation due to being so out-of-date and maintainers being unresponsive. It would be nice if we could at least have some way of visually making it clear that the project is not maintained if not remove these altogether. I know it would be quite tedious to go through every implementation to determine if it's active or not, but it would be nice have a way to mark the ones we do know are abandoned.

Category Suggestions

There are a few categories that can probably be merged. Here are my suggestions.

• Merge LDO-utility into hyper-schema -- LDO is a hyper-schema thing
• Rename schema-to-web-UI to form-builder -- I was so confused why there were no tools listed for form builders. Eventually I realized that's what schema-to-web-UI was supposed to mean.
• Merge model-to-schema into code-to-schema -- This is really code-to-schema really means types-to-schema and types are type of modeling, so I don't think we need a separate category for model-to-schema.
• Merge schema-to-code into schema-to-types -- "Code" means "types" in this case, so there really isn't a difference in these categories.
• Merge util-draft-migration into util-format-conversion -- draft migration is just another kind of format conversion.
• Merge editor-plugins into editor -- I don't think it's necessary to have a separate category for editors and editor plugins.
• Merge linter-plugins into linter -- I don't think it's necessary to have a separate category for linters and linter plugins.