What does Docusaurus offer more, if anyone who's used both can compare?
See the carousel of site screenshots here:
I'm curious to see highly customized MkDocs sites that truly respect your branding.
What I mean by respecting your branding:
- Courier: https://www.courier.com/docs/
- Figma: https://www.figma.com/plugin-docs/
- Iota: https://wiki.iota.org/
- Hasura: https://hasura.io/docs/latest/index/
- Ionic: https://ionicframework.com/docs
- Quickwit: https://quickwit.io/docs/
All those sites are customized, they do not look like a stock template. You don't need to be Stripe anymore (with a full engineering team) to get a beautiful and interactive docs website
The only thing I can see is that maybe you are more familiar with Python than Node.js? Otherwise using Docusaurus or MkDocs are both equally easy IMHO
You can get a Docusaurus site online in 1 minute, and publish your first doc edit in 2 minutes. See demo video: https://twitter.com/leeerob/status/1554211061284364290
You can even try it in your browser right now: https://docusaurus.new
I didn't need any coding.
The only difference is that our config file is a .js file instead of .yaml, which I'd say is more powerful since you can do fancy things like reading env variables to make your config "dynamic".
But by default a Docusaurus config file is not too complex. Probably a bit more than MkDocs (as we keep some boilerplate on purpose so that you can just tweak it) but still not really requiring to be a JS developer to edit. See: https://github.com/facebook/docusaurus/blob/main/examples/cl...
Congrats on the release.
Really tried hard to highlight the fact that you can truly customize your docs site with Docusaurus ;) custom navbar, footer, layout, sidebars... everything
Here's a 70sec demo video deploying Docusaurus on Vercel: https://twitter.com/leeerob/status/1554211061284364290
We provide a "docusaurus deploy" tool to deploy on GitHub pages but it is more work to setup the GH Action CI than using a good static hosting solution
Regarding Obsidian, we don't provide an official integration with it, and IMHO Obsidian is only the "markdown authoring experience". Similarly you can use another tool like VSCode, Sublime or Intellij.
What I would do:
- Author md in Obsidian
- Sync Obsidian vault md to GitHub using https://github.com/denolehov/obsidian-git
- Setup Vercel/Netlify to deploy my doc site from the GitHub repo
Note: we don't support Obsidian bi-directional linking such as [[xyz]], as this is not part of the CommonMark spec. But I definitively want to support something like that as well in the future, as I'm interested to create my own second brain / digital garden using Obsidian and put it online with Docusaurus. This way Docusaurus could become a free competitor to Obsidian Publish.
Again, any of these features can be built. If you enjoy building just what you need, go ahead.
What Docusaurus offers is all of these features pre-built. You’ll have access to the solution as soon as you encounter the problem.
One thing in particular is that Docusarus has the CMD + K command to do a search, it's so nice being able to go to all the different sites for docs and have the UI work in exactly the same way.
To be fair what you describe is more a side-result of our community rather than our own features.
CMD+K is a popular shortcut. It's not built-in Algolia DocSearch modal.
Also other frameworks like VitePress have a similar experience: https://vitepress.vuejs.org/
We call this "contextual search": https://docusaurus.io/docs/search#contextual-search
It's now enabled by default and facet on version + language so normally you don't have to do anything (like it was the case on v1).
Now we don't provide very good APIs to customize this default facetted search, so it's more all or nothing.
Is this solving your use-case or you need something else?
Yes that's the value prop of Docusaurus: you can get started in 5 minutes, but the tool scales well with your usage if you need something more advanced
Our project consists of many components and we used to have a bunch of md files scattered around. Due to the MD-native nature of Docusaurus migrating from that to a Docusaurus site was really easy.
Even though a lot of customization is possible, the default theme is a great start and made our docs looks much more polished.
The thing I liked the most is that it's now a lot easier to contribute to it, and a lot of internal and external developers are adding content to it, which at the end of the day, is the important part.
Last, y discovered unDraw (https://undraw.co) through Docusaurus and it has been an invaluable resource!
Thanks Docusaurus team! <3
I would say though that part of what appealed to me does seem to be getting lost - the simplicity. I know you don't have to use all the features and v1 is still around, but it is becoming a bit of a buzzword beast.
Yes Docusaurus v2 is more featured and powerful than v1. I understand simplicity is an advantage and sometimes less feature is actually better.
We aim for site owners that want to start simple, and yet scale their site to more advanced needs. If you plan to start simple and stay simple, other tools are probably good enough for sure.
It's not the case for all other docs pages though, and we bet on progressive enhancement, so most of those things should also work if you disable JS and load less things.
Also we have link prefetching so that navigating to links appearing viewport will be immediate, but it will also load some data when links enter viewport. In our experience, these techniques to load resources a bit more eagerly produces a better UX. Would you reject a PWA, just because it loads more data upfront? No because after that you can eventually use the app offline.
Go to a regular doc page (not overcrowded with images) and disable JS: you'll see much less traffic, and the site remains usable. For example go to: https://docusaurus.io/docs/cli
Some new features in React 18 (and upcoming releases) like Server Components are going to have a great impact on Docusaurus
That looks like rejecting Node.js for Python.
I also think MkDocs is great (and I'm the Docusaurus maintainer), and probably even simpler, but IMHO Docusaurus is more flexible and customizable that MkDocs.
We have seen greatly customized Docusaurus docs site, looking very different one from another. The MkDocs sites I see in the wild usually looks quite the same (often using Material for MkDocs).
See some greatly customized Docusaurus sites here:
I'd be curious if you could show me some MkDocs sites with that level of customization
* There's usually mess in documentation for JS-based ones. For eg. "quick start" section of the docs uses npx. Then full installation manual uses entirely different commands. JS is not my main technology so it's very confusing.
* Builds tend to be significantly slower when npm is involved.
* Plugins and themes very often have compatibility issues.
* They tend to use mdx, which is not necessarily very well supported outside of JS world and some solutions break when you try to bring your existing markdown.
I'm aware that:
* None of this is inherently JS property.
* Docusaurus is actually not guilty of most of these issues and I would recommend it.
* Probably it all makes sense/is avoidable, when you work with this ecosystem often.
However I'm just trying to setup documentation page, not start new carrer patch and non-JS based solutions are usually better on understanding that.
Not OP, but as someone working on backend, infra, and some part time game dev, JS isn't in my skillset in any meaningful way so I don't use tools within that ecosystem if I can avoid it.
> IMHO Docusaurus is more flexible and customizable that MkDocs.
Presumably only if you're comfortable working in JS?
You don't need to be Stripe and have a full engineering team working on your doc to make it awesome.
Docusaurus is a content-centric static site generator based on Node.js and React. You can build a documentation site but also a blog, landing pages...
The idea is that you just write Markdown files, and we generate a great docs site for you. You can get started in 5 minutes, focusing on content, and later do more advanced customizations so that your docs are top-notch.
I like to compare Docusaurus to the Pareto principle: you only need 20% of the effort to get 80% of the result. Docusaurus is flexible so you can also decide to invest more and get a better result.
Full-featured: docs, blog, pages, plugins, themes, versioning, i18n, a11y, SEO...
It is based on MDX (Markdown + React), which can help make your docs interactive.
Some comparable tools: VuePress, MkDocs...
I believe we do a better job than others: more features but also great flexibility. In particular you can deeply customize the UI so that your documentation site really respects respects your branding.
Docusaurus 2.0 has already been widely adopted by the community during the beta phase. Some examples
We have also see adoption for internal documentation at Microsoft, LinkedIn, Shopify...
We have a site showcase with almost 300 sites in case you are looking for inspirations.
> With Docusaurus we are looking to compete with top notch documentations, not simple ones.
> Do you truly believe that your home-made setup would be sufficient to output a top-notch doc site?
> I doubt these companies would be satisfied with a home-made setup like yours.
> 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.
Your combative attitude throughout your comments here has really put me off trying Docusaurus. You don’t have to lash out at people who prefer an alternative approach.
I think I'm quite fair with other tools.
I shouldn't have used the word "toy" but I mean it. I really dislike tools such as Docsify or MDWiki and can clearly back this up: those tools rely way too much on JS, are not "progressively enhanced", are bad for SEO, accessibility... they have their little use-cases but you should IMHO avoid them in most cases if you are looking for building anything serious.
Other tools such as VitePress, VuePress, MkDocs, Nextra... are all great sane competitors of Docusaurus.
I just believe that Docusaurus is more featured and flexible, that's all.
These other tools have other advantages that Docusaurus do not always have, but I claim the right to defend Docusaurus where it really shines.
Sometimes being less featured is an actual advantage (simplicity). Sometimes being built on another platform (Nextra using Next.js, Dokz using Gatsby), frontend framework (VuePress, VitePress using Vue.js...) or language (MkDocs using Python) is another advantage.
I understand that my words might look offensive, and sorry for that. Please also take into consideration my feelings when you compare a 1 day home-made setup with a project being worked on since 2018.
That’s not the problem. This is the problem:
> they have their little use-cases
If you look at what other people in this thread are doing when they are comparing other tools to yours favourably, they are talking about what Docusaurus does better.
When you reply to somebody comparing other tools to yours unfavourably, you jump to belittling the other tool.
It gives a really bad impression of Docusaurus that, when you think about it in relation to other tools, you aren’t thinking of what Docusaurus does well, but immediately try to belittle the alternative in some way. Docusaurus can’t be all that great if the best things you can think of are insults about some other tool.
The most convincing comments in favour of Docusaurus are coming from everybody but you. I don’t think that’s what you are trying to achieve with your comments here is it?
All the other docs tools are great too, and I'm not saying Docusaurus is better. I believe Docusaurus can scale from small sites to very advanced doc sites with minimal effort.
If I were a Python dev looking for something simple but that remains quite flexible, I'd definitively try MkDocs.
If I were a Vue dev I'd try first VitePress/VuePress before Docusaurus. It has less features but a great UI design, some convenient Md features, and it's convenient for a Vue dev/team to reuse their existing VueJS knowledge.
If I had a Next.js site and wanted to integrate docs feature in the same site, I would try Nextra.
Really, apart my comment on MdWiki (which I still stand by: most of you shouldn't use it), I think I'm fair with all the other tools?
Don’t mind the tone if a bit heated - especially when people are posting projects they have been working on for years.
“Please respond to the strongest plausible interpretation of what someone says. […] Assume good faith.”
In https://news.ycombinator.com/item?id=27134785 in reply to me you said:
> You can display real production source code in code blocks in any language without having to copy-paste and it can stay in sync.
I've never tracked down the docs for doing that (e.g. including lines 31-34 from ../../src/path/to/library.py in the documentation and keeping it in sync as that expands to lines 31-36) - can you point me to them?
It's a bit hacky and will likely change in the future, but you can do so this way: https://docusaurus.io/docs/markdown-features/react#importing...
My use case involves documentation for, e.g., a software library that can be used in different languages/frameworks. The documentation is the same, but then we provide examples is different languages and we're looking for a way of elegantly presenting this.
Do you support any way of marking the original markdown so that a "switch" from the UI can present one of alternative parts?
I apologize if that is not clear -- and asking about a custom use case.
But really, MDX gives you the freedom to implement your own tabs system. See for example how Courier is documenting usage of an API with multiple languages: https://www.courier.com/docs/reference/send/message/
See also this frontend framework switcher in the sidebar: https://docs.dyte.io/react-ui-kit/
You can even have SDKs that have different lifecycles (for example MyProduct-Android-1.4 vs MyProduct-iOS-2.6)
And finally you can build an abstraction on top of Docusaurus so that you have one separate doc per product and yet all your product docs look the same:
Also, I'd love to see a theme marketplace. I'm also not a designer and would pay for pro designs (especially landing pages). Check out mui, that's what they do (open source but with marketplace).
We are definitively interested to provide more themes in the future, starting with a TailwindCSS one.
I also believe the Tailwind ecosystem provides a lot of useful copy/pastable code snippets (including full landing pages) so having a Tailwind theme might help reuse the output produced for Tailwind.
Curious to know more about what you are looking for
Here's for example a plugin that integrates with TypeDoc (TS): https://www.npmjs.com/package/docusaurus-plugin-typedoc
I doubt we'll ever officially provide an official integration for YUI but rather we'll let the community provide one: it's difficult for a small team to be exhaustive and provide first-class integrations for all languages/tools.
Our plugin ecosystem should be good enough to enable you to build it in userland. If that's not the case, please let us know.
Just sharing your blog url for the interested: https://blog.johnnyreilly.com/
We also have a lot of other personal website/blogs in our site showcase: https://docusaurus.io/showcase?tags=personal
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.
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.
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:
and not dismiss out of hand tools that accommodate a different level than they are currently at.
: https://rust-lang.github.io/mdBook/ – the website itself is a demo of the sites produced by mdbook.
We'll look into more "offline supports" in the future including producing pdf files etc (it already exists but as community plugins)
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.
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.
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.
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.
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?
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.
> 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.
> 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.
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.
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.
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 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.
> 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).
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"
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...
> 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.
No you don't, you only need to write the markdown.
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
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.
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.
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/
With MDX you can embed JS and/or React in Markdown already
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.
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.
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/
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.
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.
EDIT: the courier and ionic examples linked elsewhere were faster though.
The stable release is not very different from the latest betas: it's mostly our commitment to respect Semantic Versioning for the next releases.
I don't know GitBook well but GitBook is probably less flexible, but their main advantage is likely that they are less developer centric than Docusaurus. They offer a managed service and content updates can be sent without commiting markdown files to a Git repository.
Docusaurus does not come up with anything to author Markdown files: you'd have to figure your authoring experience yourself, using a CMS (git-based or not), VSCode, GitHub UI, Obsidian, it's up to you...
Generating a proper PDF document still seems a very basic requirement for anything that produces documentation.
I am sure I am missing something?
I did that - the resulting pdf can not be presented as documentation.
It is not satisfying even the most moderate requirements for a documentation pdf.
Generating only a website for documentation seems like a cultural step back.
Keep in mind Docusaurus is a good tool to produce interactive docs. A PDF is not very interactive so if you want any interactivity, you'd have to limit yourself to a subset of Docusaurus features.
> Generating only a website for documentation seems like a cultural step back.
No it's actually the trend to have more interactivity. A linear PDF is more like old-school. Don't you like that on the Stripe docs there's a built-in API client?
How are we supposed to render this Docusaurus page on a PDF exactly? https://www.courier.com/docs/reference/send/message/
Supporting PDFs remains useful but it's more an edge case than the main feature of Docusaurus. We have some users willing to edit books using Docusaurus, but most users do want interactivity, and it's definitively a step forward.
What are you going to do, print it?
Remember Docusaurus input remains markdown files so you can still look for another tool that is able to generate a PDF from the same folder of existing markdown files.
We'll likely support producing a PDF but it's not the main value proposition of Docusaurus, just a nice to have for those that really want a linear static PDF instead of a beautiful and interactive doc site.
When I’m learning something new, I’ll print out some basic stuff and it makes it so much easier to learn. I go sit in a chair, read through it, and mark it up.
We believe a documentation can be much better when it's made interactive, so Docusaurus favor interactive experiences over generating a static PDF export. But we'd like to support PDF exorts in the future to please people like you that might have a different opinion
Also, aren't react docs on nextJs?
I believe we have much more features and more flexibility to customize your site in Docusaurus, but other tools are great too if you look for something simpler. Our showcase (and launch blog post) references great looking Docusaurus websites that would be hard (if not impossible) to build with the other tools.
Afaik Astro has a docs starter template but it's more a boilerplate that you have to maintain after initialization, so not really comparable with the tools above.
Note that we also want to explore if Docusaurus could run on top of Next.js, Gatsby, Remix, and eventually become framework-agnostic.
The Docusaurus team is relatively small, and can't really compete with Vercel/Next.js on the static site generator infra, build performance etc... Until now we mostly focused on implementing a good set of flexible docs feature.
What are the downsides of using an SPA?
We believe React enables a better UX, and this weight is worth it for multiple reasons (SPA navigation, prefetching, and upcoming things).
You can compare for yourself and see what's best: docusaurus.io (SPA/React) vs v1.docusaurus.io (MPA/vanillaJS)
Note we didn't upgrade to React 18 yet, which will reduce the cost of using React client side, and provide new interesting concurrent features like progressive hydratation. We also want to leverage React Server Components later. We could also explore using Preact.
The web APIs are also constantly evolving, with new page transition APIs and things like that. It's not impossible we move back to a MPA in the (long term) future if it makes sense.
If you want in-app authentication, remember we are a static site generator so at the end of the day we have to produce static html files, and at build time we can't know which user it is. You can use a client-side authentication where your HTML first render a profile placeholder and then the profile data gets loaded with an auth request. You can also render a full-screen spinner on the static page, and then use React client-side to auth the user.
See also: https://github.com/facebook/docusaurus/issues/958#issuecomme...
We simple removed the GraphQL data later from Docusaurus, and are more opinionated toward the docs use-case while Gatsby is a more generic tool focusing a lot on CMS integration. We are more developer-centric and based on Git by default.
Even if you don't like Meta, is that a good reason to reject Docusaurus?