Hacker News Reader

Comment by brabel | Hacker News Reader

I was hoping for something I could use to generate my docs, but this is so incredibly over-engineered it's comical to me. React components, MDX, TypeScript config files, CSS-in-JS? Do you really need all that to write docs?

I have my own little markdown-to-html static site generator that does nearly everything I would ever need, and it only uses a small library for conversion MD to html plus a custom, very simple templating language to do things like include other files or get a list of files in another dir so you can create a list of links... and that's it. You can probably write one yourself on a weekend. I will be sticking with my own, thanks.

View on HN

You don’t need it to write docs. But, as someone who’s worked in a relatively large documentation org… it’s nice to have a stable, extensible base that you can extend consistently across multiple docs sites. It’s ideal to have a similar look and feel, but the flexibility to tweak that for each product.

Basic docs sites can literally just be HTML. But the more you maintain them, the more you want to experiment with novel methods of documentation (think: interactive consoles, new methods of styling guides and tutorials like Apple’s SwiftUI docs, or even new methods of segmenting content within a single docs site (SDK and versioning selectors, anyone?))… eventually, simple tools will hold you back. Or you’ll end up building an unmaintainable nightmare on top of a simple tool. In those cases, it’s nice to use a “batteries included” product so you don’t have to write all of that infrastructure yourself.

For personal blogs and small docs sites, it’s overkill of course. But in docs land just as in developer land, ICs want to build new skills for their resumes or personal interest.

And, of course… it has a built in dark mode! Harder to find than you’d think.

Thanks for the feedback

Agree Docusaurus might be overkill for simple docs, however we also made sure the experience for simple usage is great.

It comes with file-system routing convention, versioning, accessibility, internationalization, good SEO by default and many useful features that would take time to build in userland...

We have many devs using Docusaurus as a portfolio or personal blog, we even have a dedicated showcase tag for that: https://docusaurus.io/showcase?tags=personal

For advanced needs, like multi-sdk support, we get you covered.

Site with multiple frontend SDKs (React, Angular...): https://docs.dyte.io/react-ui-kit

Palo Alto Networks has a dev portal with multiple products using Docusaurus, all sharing similarities but with tweaks per product: - https://xsoar.pan.dev/ - https://prisma.pan.dev/

yes - people should match their docs offerings to the maturity of their project: https://www.swyx.io/documentation-levels

and not dismiss out of hand tools that accommodate a different level than they are currently at.

I thought so, too. I've switched to mdbook[1], which is more lightweight, and (at least at the time) was one of the few solutions that compiled down to a directory that can be used without limitations while offline.

[1]: https://rust-lang.github.io/mdBook/ – the website itself is a demo of the sites produced by mdbook.

Docusaurus has a PWA plugin with offline support

https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-pw...

We'll look into more "offline supports" in the future including producing pdf files etc (it already exists but as community plugins)

I'm sure that Docusaurus can do a lot, and more in the future. I think the resulting pages feel a little heavy to use (how they load and react in a browser), but that's just my personal opinion.

I had tried to find a tool that would be simple, quick to use, and as close to a static HTML page as possible while still retaining a "book" character. Even a Vimwiki HTML export would have been an option, were Vimwiki's Markdown support better. Mdbooks fit the bill, and does not seem to stray too much from that initial direction, as far as I can tell.

Just curious whether rust is an advantage for this sort of a tool? I don't know much about rust but my impression is that it's a systems language like C/C++. Is security a major problem for this sort of a build tool? It just seems like of I were writing something that processes text using a C/C++ class language isn't going to maintain well or be easy to adapt, extend or customize.

IMHO Rust is useful for its speed. Many frontend tools use Rust today (like swc, napi-rs...).

We are willing to include Rust in Docusaurus in the future (alongside Node.js), as it can help to build the static doc site faster. BTW our docusaurus prod site (docusaurus.io) is built using swc already (https://swc.rs/)

Now using a 100% Rust tool to build a doc site would be great too, but at the end of the day if you want a great experience you'll also need some JS and not just plain static HTML files. And Rust devs are more likely less "frontend-y" (I've been a backend Scala dev 10 years ago, I know how good looking UIs are produced by backend devs ^^). So I guess a combination of Node.js + Rust is great, and the frontend community that care about UI/UX is more likely to contribute to the JS side to polish things.

I guess I'm just thinking in terms of these tools as being text in, text out transformers. And it seems like an embarassingly parallel workload. So speed seems like the wrong thing to optimize to me.

I am not able to understand what you mean here sorry. What is the thing to optimize then?

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.

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.

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?

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.

No idea, actually (not a Rust developer myself). What I have noticed is that Rust seems to provide good tooling for building monolithic executables that contain a complete application, including assets. That's quite nice for trying stuff out or managing a few of those without a package manager, but has nothing to do with documentation generation per se.

Oh, that's nice and I do agree about that! I've noticed go does that sort of thing, too (hugo, etc).Some of these systems out there include so many moving parts that it's really difficult to just even try them out (i.e. supabase vs pocketbase).

With Docusaurus we are looking to compete with top notch documentations, not simple ones.

The goal is not only to get some html files online but also to great a first-class experience for the end user.

Do you truly believe that your home-made setup would be sufficient to output a top-notch doc site?

Really curious to see what kind of site your setup produce, can you share a live url so that we can compare?

Docusaurus v2 has a site showcase with many great looking sites: https://docusaurus.io/showcase

Many companies using it: Supabase, Redis, Figma, Ionic, Snapchat, LinkedIn, Microsoft, Shopify, Tauri... I doubt these companies would be satisfied with a home-made setup like yours.

If you don't have advanced needs, you could as well just publish md files on GitHub?

I wouldn’t worry too much about that comment. The top comment is very much in keeping with the HN tradition of trashing others’ work without fully understanding the use case.

My favourite HN comment went like “For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem.” (https://news.ycombinator.com/item?id=8863)

Fortunately the person this was addressed to continued building Dropbox.

ahah, I welcome all comments, haters are a good source of engagement ;)

Well, there's a tool for every task and yours in this case might be too overblown for the simple task that the user is trying to solve. No need to compare it to the use at bigger companies and organizations. No need to either get arrogant or stroppy. Just because a user doesn't use your tool, she is not a hater, neither. Sound a bit like "But mine is better/bigger/shinier than yours!" to me. Keep cool.

Well, the op was quite offensive in the first place

> this is so incredibly over-engineered it's comical to me.

Isn't it fair that I defend the tool I work on after reading such comment?

The op can stick with its original tool and that's perfectly fine to me. Indeed Docusaurus might be overkill for many simple use-cases.

Does it mean it's over-engineered? Well, that's worth discussing. Some companies really need the features we provide.

Can you build something as advanced as some of the existing Docusaurus sites we showcase, using a simpler stack? That's an interesting discussion to have, but share some links.

Well, I don't see the offensive part here. As you say it yourself: "It might be overkill for many simple use-cases." Period. No need to jump into every thread where a user says that it is just too much for her use case, and you asking for links to compare the output (as you did with me as well?). Just be happy with what you created and the showcases prove the demand for it. So?

Well, we don't have at all the same definition of what "offensive" means then.

> where a user says that it is just too much for her use case

That's not at all what the op said, just a 2nd reminder:

> > this is so incredibly over-engineered it's comical to me.

The op said it's over-engineered, in general, not for her use-case

---

I am happy with the result and I won't be affected too much by comments from people that criticize what we've built without giving it a try. Now I keep the right to defend the tool when it's criticized this way.

Don't get me wrong... I just like simple things, and this is definitely not simple, so not to my taste... I am sure the majority of people out there will love support for React, TailCSS or whatever else this supports...

But I do believe I am able to write top notch documentation by simply being good at HTML/CSS... because that's what it really goes down to in the end?! How does Docusaurus make things pretty? By using themes? Well, I can copy your theme into my hand-written HTML which then wrapps the markdown content I wrote... I don't think end users would notice any difference whatsoever?

One thing I have difficulty generating is a search toolbox... but that's only because I haven't added the "feature" yet... and as I said: I like to keep things simple.

FYI Lee Robinson/Vercel just did a nice video demo of Docusaurus.

https://twitter.com/leeerob/status/1554211061284364290

1 minute: it's what it takes to init a new Docusaurus site and publish it to a prod url with https.

2 minutes: you are already submitting your first doc PR, review it and merge it to deploy to production.

For me, this is simple. I understand this might look complex to you if you come from a different background, but nowadays, frontend devs are used to such workflows.

brabel that's fair, I also like simple things btw.

Can you please share your doc site, so that I can at least know what kind of docs experience you are building?

Tailwind is not something we support atm, and when we'll do it will be optional.

The only choices you cannot opt-out are: Node.js, React, CSS, JavaScript, Markdown/MDX.

The rest is all optional and provided as plugins. You don't need to use TS nor Tailwind, but isn't it nice to be able to use those if you want to?

For sure you can hand write a top-notch doc site using html, css and vanilla JS. You can also write all your programs in assemble/bytecode/machine code if you want, and similarly they could potentially make these programs faster than their C++, Rust, Java equivalent. I doubt this is a great idea, but in the end you are responsible for your choices.

Docusaurus is a tool that will help you achieve the desired result for a lower effort, it's like the Pareto principle.

> Well, I can copy your theme into my hand-written HTML which then wrapps the markdown content I wrote...

Well, it doubt it's as easy as you think it is. We took great care of accessibility, interactivity and many other things that you'd have a hard time copy/pasting.

I wonder if you have looked at any Docusaurus site. Here's a good example: https://www.courier.com/docs/reference/send/message/

To me, even if technically it is possible to reproduce such site in Vanilla JS, it would take me a lot of time to do so. Docusaurus only helps you save time to achieve that experience.

> One thing I have difficulty generating is a search toolbox... but that's only because I haven't added the "feature" yet... and as I said: I like to keep things simple.

So you want search or not, it's not clear to me? Because if you don't, then users can't search and that may be a UX/DX problem, and if you do, then your stack becomes more and more complex and you invest a lot of time building it as you pile features one after the other. You could as well bet on Docusaurus in the first place, and use our search plugins to get search for free.

TLDR: if you value your time and plan to scale a bit your doc, Docusaurus is a great choice to me, even if it looks overly engineering for your initial need. Now you can definitively get a similar experience with vanilla JS, if you are willing to invest a lot of hours to make everything work. And there are things that Docusaurus do that you may not even notice by simply looking at the UI, such as make your doc very accessible or providing good SEO by default.

This account is my "anonymous" account, so I can't give you an example of what docs I can create myself... but docs systems I like include asciidoctor[1] and mdbook [2]. Though I find that even those are overkill for my hobby projects at least ... professionally, I prefer to use them anyway because of support/updates and to leave something others can manage themselves later.

> Now you can definitively get a similar experience with vanilla JS

This comment seems to show we come from very different worlds. Why do you believe you need JS to create documentation?? Have you tried writing HTML/CSS without any generator/JS/tools? It's actually pretty easy... Documentation is mostly static, which HTML/CSS was designed to create... and if you want to add a little interactivity here and there (e.g. run this code live) you can just embed something like Codepen.io or even, yes, vanilla JS if really necessary.

I do agree your tool is quite amazing... the fact it takes care of verifying crosslinking, for example, is great... but I hope you do understand that you're using a heavy-weight tool to do something that's usually pretty basic (or maybe you think of docs as something much, much more advanced than what I think of - like the Rust Docs to me are a good example of great docs and I can't even think of why anyone would need anything more advanced - I think you would find that far from advanced? Othewise, you'd agree you can easily write that by hand with HTML/CSS and a little scripting around perhaps to do crosslinking, md-to-html conversion and simple stuff like that).

[1] https://docs.asciidoctor.org/asciidoctor/latest/

[2] https://rust-lang.github.io/mdBook/

> I like include asciidoctor[1] and mdbook [2]. Though I find that even those are overkill for my hobby projects at least ...

That's one thing: Docusaurus is not necessary just for hobby projects where the doc only exists for yourself and a few users. It can be used for hobby project but it can also scale for much larger projects where the doc is a critical part of the success of the project, and where the company behind is willing to invest thousands of dollars to have a really great doc. For example, the doc of React-Native is critical for React-Native success: https://reactnative.dev

> I prefer to use them anyway because of support/updates and to leave something others can manage themselves later.

If you have a small project, you can also use Docusaurus in a very simple way, and stick to our stock template (which looks like this: https://tutorial.docusaurus.io/)

The only thing you'll need is to leave a folder of Markdown files to your colleagues, that's all.

I have planned to add a very simple CLI on top of Docusaurus to make it even easier: just run "npx yolodoc ./my-md-docs-folder" and it will build your simple Docusaurus site => No need to install anything, know that it's using React/MDX/TS or whatever: the only thing you'd need is to have Node.js installed (which is not more complicated to install than Python or Ruby btw)

> This comment seems to show we come from very different worlds. Why do you believe you need JS to create documentation??

I don't believe that. I believe you can do everything by hand but at some point when you have thousands of docs pages, you also need to be productive and fall into the pit of success by adopting tools that streamline the docs authoring experience for your doc team. Do you prefer throwing 1000h of your time on your home made solution, or just use Docusaurus and save time, and get a better result for something like 200h? => That's the value proposition of Docusaurus.

Also note that for some accessibility details, you do need to have some JS because using just HTML has its limit. Docusaurus takes great care of accessibility concerns by default for you: progressive enhancement, skip-to-content, aria labels, keyboard navigation, focus rings, semantic html...

> and if you want to add a little interactivity here and there (e.g. run this code live) you can just embed something like Codepen.io or even, yes, vanilla JS if really necessary.

There are many places where you probably want JS in your doc site: collapsible categories, search, tabs to switch SDK languages, mobile drawer menu etc... Using just HTML has its limit.

Now Docusaurus doesn't just bring interactivity to the "layout" but also inside the docs. This makes it possible to build interactive documentation where the experience is natively more "playful"

https://docusaurus.io/docs/markdown-features/react https://docusaurus.io/docs/markdown-features/code-blocks#int...

Using Codepen.io or CodeSandbox inside your doc leads to a subpar experience to what we want to provide with Docusaurus. Those embeds are not native to the website and require a heavy iframe to load.

Also the demo code you maintain would be saved in a separate system which makes long term maintainance more complicated than to colocate example code with actual docs rendering those.

Using an iframe can also reach some sandboxing limits due to browser securities for certain use-cases.

If you are going to build an API client for your REST API (ie have a Stripe-like API docs experience), I doubt you'd be able to get a great DX with iframe embeds. Instead you want the API client to be native, load fast, and integrate nicely with the rest of your docs site layout.

See for example this Courier API client using Docusaurus: the code sample has a sticky positioning and always remains visible: https://www.courier.com/docs/reference/send/message/ It would simply be impossible to get this better UX with an iframe embed.

---

> I do agree your tool is quite amazing... the fact it takes care of verifying crosslinking, for example, is great...

Thanks ;)

> but I hope you do understand that you're using a heavy-weight tool to do something that's usually pretty basic (or maybe you think of docs as something much, much more advanced than what I think of - like the Rust Docs to me are a good example of great docs and I can't even think of why anyone would need anything more advanced - I think you would find that far from advanced?

I think I didn't explain very well, but most of the "complex stack" of Docusaurus is not directly exposed to you. Similarly, do you really care about which libs MdBook is using under the hood? Would you say "MdBook is overly complicated because it's using XYZ as a dependency!"? Docusaurus used React, MDX, Node.js, Remark, Webpack, TypeScript, Infima... All those buzzwords are internal implementation details, and you do not really need to care about them: just write markdown files!

Is one of those 2 commands really more complicated than the other?

"mdbook serve --open" vs "docusaurus start"

Because in both cases, it's what it takes to use the tool: just start it, and focus on writing good content in Markdown files.

Docusaurus can do much more than that, but you can stick to the simpler workflow if you have basic needs. Just watch this 60sec video demo and see how simple it is: https://twitter.com/leeerob/status/1554211061284364290

> Othewise, you'd agree you can easily write that by hand with HTML/CSS and a little scripting around perhaps to do crosslinking, md-to-html conversion and simple stuff like that).

I totally agree with that. I just feel it would be more time consuming than using a dedicated doc tool that already solved this problem for you. It can by MdBook, Docusaurus or whatever else you like. But at the end of the day, you are free to use whatever tool is good for your use case.

I do believe that the default Docusaurus output provide a better UX than the MdBook output, but it is a matter of personal taste I guess. And it's not more complicated: you just give it Markdown files and run a CLI command to build the site. The only major difference for you, as a docs user with relatively simple needs, is that you have to install Node.js instead of Cargo.

My team uses Docusaurus for internal docs. I just had to make my first contribution to that repo the other day, and it was a mess. Docusaurus didn't work from within WSL (well, it mostly worked but every page load crashed when viewing), so switching to native Windows NPM and the several dependencies and installation steps to get it working took about a half hour with the help of a colleague who knew how it worked. And ultimately, it was just so I could write markdown.

The generated docs are nice, to be sure, but I certainly would not go through that pain if I had to go documentation from scratch.

Hey, Docusaurus even works in your browser

docusaurus.new

I'm not sure why you went through all this pain, but if you don't report it, how can we fix it? Others do not have the same experience afaik.

React components, MDX, TypeScript config files, CSS-in-JS? Do you really need all that to write docs?

No you don't, you only need to write the markdown.

Yes, and that's exactly the value proposition of Docusaurus.

You just write markdown files. Eventually you create a custom landing page with React (optional, we also support a Markdown landing page).

If you want to customize your site, you can use more advanced tools, but really you can stick to Markdown if you want something simple.

Now Docusaurus uses advanced things under the hood, but it's an implementation detail, not something you really have to deal with.

Just try it and see: docusaurus.new

You don't need any of it. It's included in the framework if you want to make your docs more interactive but you can stick to plain text in markdown (like most of these frameworks).

That's why I made https://reactivedoc.com/. You can use it to write interactive documentation in markdown and save it as a simple, self-contained, html+js file.

Now I'm working on v2, with cleaner syntax & more widgets (I want to add an embedded web base terminal to run shell commands), you can see an example here: https://reactivedoc.com/editor/

What does it solve that Docusaurus does not solve?

With MDX you can embed JS and/or React in Markdown already

I just needed a quick way to write in MD and have 'templates' with parameters to avoid copy/paste/replace, especially when documenting shell commands.

I think it depends on your end users. If you're building a product for devs, personally, I think it's worth investing in a great docs experience and more 'advanced' features. Docs are going to be one of your most used interfaces. But you should make sure that making docs 'pretty' isn't detracting from usability. If you're making internal docs, then ya, I agree with you, keep it dead simple.

> Unless you're spinning up a documentation team with engineering resources, you probably want Docusaurus! > Rachel Nabors, Former ReactJS & React-Native docs manager > https://twitter.com/rachelnabors/status/1452697991039660038

Actually I don't consider Docusaurus as a real investment. altough as a non-Node.js/React dev all this might sound complex, but this is actually the basic stack for many frontend devs today, not something very fancy.

Investing in your docs mean assembling a tech team for a long effort to build a first class experience. I believe you can achieve something almost as good as a full team by having just 1 engineer working on your Docusaurus doc a few hours per week.

> If you're making internal docs, then ya, I agree with you, keep it dead simple.

Internal docs also deserve a great DX. You can use Docusaurus for internal docs, and use our stock template to get started in a few minutes: just write markdown files. We have been reported heavy usage of Docusaurus at Microsoft and LinkedIn for internal documentations for example.

This is what our stock template look out of the box: https://tutorial.docusaurus.io/

You don't have to do anything to have this DX: just write md files. Maybe you can already feed Docuaurus with your existing md files, and it will just work without any change.

I came to write this.

Was also hoping for a docs generator from my YUIDoc source code comments in PHP and JS.

Is there anything out there that works with YUIDoc or something I can transform it into? Anything?

As it is, we are using YUIDoc and themes to generate documentation and it’s pretty good.

If you can find a way to generate md files from YUIDoc, then Docusaurus could consume those MD files.

We have seen many examples of Docusaurus sites generating pages from code comments, GraphQL or OpenAPI schemas

For example here's a plugin that does something akin to what you want, but from TS comments: https://www.npmjs.com/package/docusaurus-plugin-typedoc

And here is an example integration of Redoc/OpenAPI in Docusaurus: https://redocusaurus.vercel.app/examples/using-single-yaml/

I use this to run my project docs, no compiling, just one index.html and the rest are markdown files: http://dynalon.github.io/mdwiki/#!index.md

Your docs seem to flash unstyled content for a second before the CSS loads.

This is not really comparable to Docusaurus: your thing is a little toy to publish documentation online but not really useful to create a great advanced and looking doc site.

Just consider this: your tool requires client-side JS to work. This is very inaccessible and does not respect the progressive enhancement philosophy of the web. A Docusaurus site takes great care of accessibility, and the experience with JS disabled remains good.

Also using JS this way with anchor link routing will likely lead to bad SEO, and a flash of unstyled content which gives a really bad UX.

As the rep for a product: I wouldn't recommend bashing someone's project by calling it a "little toy". It works for them regardless if it looks as "fancy" as yours. Not a positive look for you or your project if this is how you're going to treat others.

Maybe the word "toy" is wrong and I'm sorry for that if it offended anymore

But I stand by that such documentation tools are really not great. I've argued why here: https://news.ycombinator.com/item?id=32305770

Now if you clearly understand the tradeoffs of such tools and still decide to use it, that's fine. What I see in practice is that many decide to use such tool and are not really aware of the tradeoffs they make.

I personally believe being accessible is a mandatory feature for any documentation website framework. But maybe you'll publish the docs just for yourself or a very limited set of persons, in which case you might care less.

At least as a user i find tommica's "toy" much faster and easier on the eyes than the showcase sites in Docusaurus. The only negative is that small visible "reflow" whenever a page loads.

EDIT: the courier and ionic examples linked elsewhere were faster though.

Reply on news.ycombinator.com