great one ;)
231 karma · joined January 20, 2016
I'm the maintainer and we have a #jobs channel on discord where you'll find some offers. There's definitively a need for Docusaurus developers because technical writers are often not enough good at frontend dev to customize a site, so we'll try to improve that in the future.
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...
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.
> 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.
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.
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
Some new features in React 18 (and upcoming releases) like Server Components are going to have a great impact on 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.
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...
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.
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
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.
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.
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.
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?
https://docusaurus.io/docs/markdown-features/tabs
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: - https://xsoar.pan.dev - https://prisma.pan.dev/
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.
https://twitter.com/__morse/status/1532430153338474534 https://twitter.com/Whelton/status/1540306373497724928 https://twitter.com/mweststrate/status/1181276252293853186 https://twitter.com/jstrry/status/1461342355068309512
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...
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.
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?
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/
> 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.