[fluidcruft]

Time required for customization, feature implementation and maintenance should be minimized. Documentation generation often needs to be extended and customized. So the question is how much developer time gets sunk into adapting the tooling vs buying CPU time.

[slorber]

We optimize for features, easy of customization and easy of upgrades in priority

Now we have large docs sites with thousands of pages, and it's painful if their static site takes forever to build, so we should also optimize for speed. Build-time speed reduces the feedback loop and it also saves developer time. It's like having a better computer somehow.

[fluidcruft]

I'm confused. Is docusaurus implemented in a system's programming language such as rust or C/C++? Wouldn't the easiest way to improve build time be to get a parallel build system (assuming it doesn't have one) and then throw more CPUs at it?

[slorber]

We build a single page application and use Webpack (nodejs build tool to create SPAs). In 2018 there weren't many alternatives to Webpack so we pick that, but may reconsider in the future. We don't have the bandwidth to create our own frontend build tool, we focus on the features.

Docusaurus is also IO intensive as we read a lot of markdown files on the disk and also emit intermediate files.

Webpack already builds things in parallel, but it remains nodejs, and IO/CPU are both bottlenecks at different steps of our build.