[gladimdim]

Some of us (me, for example :) have to spend multiple weeks a year to draw the design architecture of certain parts of the product. During engineering meetings everybody raised the same question: i commit to new area in product, how can I understand what are the components and how to do certain things? You can ask your colleagues but they might know it as well.

So I decided to document main flows and designs in PlantUML diagrams. having these diagrams greatly improved onboarding process, cause you can quickly glance what component does what and what are the dependencies (the code base was in JS, so it is usually quite limited on refactoring/figuring out wtf is going on).

But the problem with such approach is: diagram quickly gets out of date. Someone makes the change and the diagram makes no sense at all now. With what I saw in Gtoolkit, you can always query the real source code and build custom dev tools that always produce current and real overview of the system. I would love to have a starter kit for JS projects that you can drag and drop and start building your own tooling for your product.

[tudorgirba]

Indeed.

Manually drawn pictures should only be acceptable for depicting future intent, but not for depicting the existing system.

With Glamorous Toolkit we want you to build your own environment specialized for your own system showing what you say is important.

For JS, you can start from here: https://gtoolkit.com/docs/analyzing-js/

[blandflakes]

The ballerina language actually had an interesting take here, where you could generate diagrams from the code:

https://ballerina.io/why-ballerina/sequence-diagrams-for-pro...

[derangedHorse]

How fast are your components really changing though? I write a lot of documentation for the systems I work on and rarely find old diagrams not making sense at all. Maybe smaller projects might have more changes going on but I find I have to add things more often than completely scrapping docs (the specific product I work on is almost 10 years old although the company I work for is a lot older)

[pdimitar]

> I would love to have a starter kit for JS projects that you can drag and drop and start building your own tooling for your product.

Can you elaborate on that?

> But the problem with such approach is: diagram quickly gets out of date.

True, but using something lighter-weight like Mermaid.JS helped me in these cases.

[folkrav]

You often see stuff as simple as a README get out of date. Lowering the barrier of entry to write documentation is hardly a bad thing, but the problem remains that said documentation takes time and work to stay relevant.