IIRC, this platform uses CDN-hosted libraries rather than bundling/vendoring. As a result, users are exposed to not just outages of the CDNs but also the data collected by these servers. That’s a bummer.
…but it’s not the only bummer. The usage of Highlight.js + MathJax on the front-end is horribly wasteful. Why? It demands all clients parse & render the syntax/LaTeX which is not only taxing on CPUs and batteries, but this action is idempotent meaning every user agent on every page visit is going to do the same wasteful parsing to get the same result. There is no good reason that syntax highlighting shouldn’t be done at build time nor should it require JavaScript.
Even though the MathJax js file will in turn probably load more things hosted on the CDN. I don’t understand why they are not putting all of the MathJax files alongside the generated HTML files. So that one does not have to rely on any CDN.
Now that I’m at my laptop I can see that you are correct on most things at least now being vendored–though it took me a while to find it since the scripts in the <body> like it’s last decade instead of in the <head> with async or defer attributes.
With first-party isolation being the standard for the last couple of years, there are no “shared caches”. A third-party CDNs might load a particular resource faster, but at the cost of user privacy & reliability. You can know, barring exceptional circumstances, that if your site loaded, it can load its own libraries. Look at the news of Cloudflare, Fastly, et al. going down and the ‘internet breaking’ because there’s been too much centralization and bad advice that all site’s need these sorts of ‘optimizations’.
Its a port of mdbook to Nim, but also extends it with the ability to generate interactive content as well using Nim's Javascript backend. Though I haven't tried this piece myself I like the idea of an all in one way to make interactive elements when desired: https://pietroppeter.github.io/nimib/interactivity.html
Notable mention to [Sphinx](https://www.sphinx-doc.org/). It's workflow is more tuned to the "book" format rather than the blog, forum or thread format.
I’ve tried MdBook, Jekyll, and MkDocs. MdBook is slick for basic projects, but I felt it was too minimalistic for me. When I dug into the source for the MdBook sites that I liked, I saw that they had extended MdBook with some custom Rust code.
My recommendations are:
- MkDocs: Good default choice, reasonably flexible.
- Jekyll: For people who want a little more flexibility—things like landing pages, blogs, etc.
- Antora: For people who want the best docs, and are willing to put in the most effort. It will manage, for you, the process of generating documentation sites that collect documentation from multiple projects and possibly multiple versions of each project. Asciidoc is full of features you’ll find useful.
Hugo looks like it has a lot of flexibility like Jekyll, but it seems to take more effort to get everything working the way you want, and it also seems like there’s just too much variation in how the different themes work. To be honest, I never really managed to make anything with it—I found out that the theme I was using didn’t have some features I wanted, so I switched to a different theme, but it’s not easy to switch themes. I was too frustrated and gave up.
It looks like MdBook is reasonably active, so I’m sure it will catch up.
I am a long time Jekyll user and I still think it's a great tool for blogs, but by far the best SSG for documentation websites I have found is Docusaurus. (https://docusaurus.io/)
I resisted trying it for the longest time because I didn't want a JavaScript based tool, but I am glad I caved. It's so easy to get started, crazy fast, and the sites are absolutely beautiful out of the box yet easy to customize. The mdx support is awesome too.
Somehow I missed Docusaurus when I surveyed documentation generators—it looks very good!
I can understand the desire to want something not written in JavaScript, and I certainly have my own language prejudices, but when I surveyed static site generators, language choice was all over the map. Like, I was willing to wrangle Ruby installations and gems to get Jekyll working, something I have nearly no experience with.
Wow, what is up with the material mkdocs theme (https://squidfunk.github.io/mkdocs-material/)? That's an extremely spiffy landing page, especially given that it's for a theme designed for a totally separate piece of software.
mkdocs-materials is underselling itself as only a theme imo. It bundles a lot of value that mkdocs is missing out of the box as plugins and tweaks, like a good client-side search, page tags, or easy support for a lot of markdown extensions (e.g. code syntax highlighting, admonitions/callouts).
From my personal experience mkdocs+mkdocs-material is like GNU+Linux.
Thanks, I hadn't heard of Antora, but the behaviours of assembling docs from multiple repos and using branches for versioning is exactly what I want. Too bad it's not using MDX though, as all our existing docs are markdown + interactive react components.
I've trying also bookstack and even it's more "wiki" like it's great too for less tech-savvy people (I usually edit my mkdocs projects in vscode and keet them in git repos and bookstack is all web based).
> I've trying also bookstack and even it's more "wiki" like it's great too for less tech-savvy people
Thanks! My main goal when building BookStack was to build a platform that could be used by all departments, of varying technical confidence, of the company that I was working at since existing open source documentation/wiki systems were positioned for a more technical audience.
It was the most painless experience I've had with quickly setting up docs from a bunch of .md files, and the plugins give it enough flexibility for most of the usual stuff I need.
I used to use gitbook to generate til.secretGeek.net but it got slower and slower over time, would take 45 mins to build the site… and then the parts I was using were either deprecated or made “premium” - something happened. The “enshittification” set in, basically. If there’s some nice free thing you use that’s too good to be true… wait a few years it will go to muck.
I bit the bullet and wrote my own very minimal static site generator in .net, so the site builds in a few seconds again. Note that I’m not spruiking it for others to use… because if it became popular, no doubt I’d end up enshittifying it too.
I’m now very self conscious of using the word “spruik” (a feature of Australian culture is that we look down on Australian culture… this is called our “cultural-cringe”) - and just saw “spruik” used in a headline in an Australian news story, which shows it is still a very current word here.
Was using mdbook for a lot of projects, but these days, I feel like material for mkdocs just has so much more built in that makes it nice to use.
One example, I really like the page TOC on the right side that is notably absent from mdbook, where it seems the standard to set up SUMMARY very detailed and break what could've been a single page into many different files.
I been a huge fan of mkdocs for a while now. It really does just get the job done with a minimum of fuss and muss, and has a lotta nice themes to choose from (as well as being fairly easy to customize or build your own).
Started using mdBook couple days ago for documenting small project. This is exactly what I need: small static pages generator.
Tried HUGO, but it seems so huge and bloated comparing to mdBook.
Now I edit doc with Obsidian/VIM, push to Gitea and in minute get public documentation.
I use hugo with the book theme (https://github.com/alex-shpak/hugo-book). It takes a bit of getting used to (if you're not familiar with hugo) but after that it's pretty good with all the flexibility that hugo provides for shortcodes, etc. You can get auto numbering of figures, equations, etc. with appropriate shortcodes. Is it possible to get autonumbering in mdBook?
It also gives a nice toc/tags on the right side (if you want it), and the ability to split the page into columns. The katex support is good (looks like mdBook uses mathjax) and publishing is easy and is just a push/rsync.
I recently started exploring, and slowly migrating, to .mdx over .md for content. So far it’s been a breath of fresh air tbh. My biggest problem of markdown was the specific flavor I happen to be using and the type of cliffs I’d run into, then how to extend them.
I’m extremely satisfied with 80-90% of the standard Gitbook markdown flavor. Then every now and then I really wanna make a complicated table, or a code block highlighting few lines while maintaining syntax highlighting, or an interactive slider, or a formula calculator that’s built-in the documentation instead of a complicated function, or a particular graph/chart etc. I don’t know how something like mdx would work for a large team (ever tried to clone Microsoft’s doc repo?) but at least for my own stuff, it seems like a definite improvement.
> My biggest problem of markdown was the specific flavor I happen to be using and the type of cliffs I’d run into, then how to extend them.
First time I heard of .mdx and looked up the site [0]. I am insufficiently in the loop of frontend standardization. Now it would be great to get rid of flavors and have one universal approach. In the Docs I read:
> MDX is not coupled to React. You can also use it with Preact, Vue, Emotion, Theme UI, etc. Both the classic and automatic JSX runtimes are supported.
A sibling comment already mentions a Svelte implementation [1]. So I fail to see how this doesn't open a pandora's box of yet more flavors, this time coupled to frontend frameworks. First in .mdx and then incompatible with .md
Extensibility. Yes, I guess, if your stack is supported by any of the existing implementations.
JSX is evidence that new generation of programmers are not taught engineering. There are very valid reasons why we went for encapsulation and separation of concerns. JSX throws the baby with the bath water and goes back to PHP5 sites with markup and code interspersed. Even authors of JSX cannot make it work reliably in their flagship product. MDX couples JSX with markdown.
I cannot see how this yields maintainable source. Sure, spaghetti code is nice for quick, one off scripts, but if you'd volunteer for helpdesk shift to be yelled at rather than fix a bug in 5k SLOC collection of Windows Batch scripts, then maybe you should reconsider mdx.
.mdx can be used with https://astro.build/ very easily, which is a JS metaframework and no-JS-shipped SSG-first approach. There are themes you can use, but for any modern web developer it would be pretty easy to roll your own.
I wrote KeenWrite, a free and open-source cross-platform tool, to create Markdown-based books. KeenWrite calls out to ConTeXt to typeset the documents and uses my KeenType fork for typesetting math while in preview mode. KeenWrite can generate PDF files from the command-line.
That mouthful compiles the book that I'm writing. The book defines numerous variables that are referenced throughout the prose and defined in an external file. Variables can also be passed in as metadata, which tells ConTeXt various PDF properties to embed. The chapters argument allows selecting a subset of chapters to build (e.g., 1-3,5,9-15,22). Lastly, the theme directory points ConTeXt to the instructions to use when typesetting the document, which controls colours, fonts, layout, annotations, etc.
I just wonder why Markdown (or whatever alike, I know there are alternatives superior in numerous ways) is not the default format for books, documents and everything. Some years ago I switched to Typora and discovered I hardly ever need Word/Writer for anything I write and I only use it to open documents others would send me. 90% of books I read don't look like having a serious reason for not being in the Markdown format either. I understand there is typesetting one has to do to print a nice-looking paper book but the majority of the text read on a computer/smartphone or printed from MS/Libre Office lacks this job done anyway.
Markdown is a really poor storage format. There is quasi-official standard (CommonMark), but since it's feature-poor, people mostly use something else, like GitHub Markdown. Individual apps often extend Markdown in various incompatible ways.
There are better alternatives (e.g. AsciiDoc, but it's specialized towards documentation), but they don't have anything close to the momentum of Markdown.
> 90% of books I read don't look like having a serious reason for not being in the Markdown format either.
Markdown is a late comer to the game, so the better question is - why should books be in Markdown? Markdown's biggest (or the only?) advantage compared to binary/XML based formats is sort-of readability in plain text, but that's just not that important for the majority of publishers and readers.
> Markdown is a really poor storage format. There is quasi-official standard (CommonMark), but since it's feature-poor, people mostly use something else, like GitHub Markdown. Individual apps often extend Markdown in various incompatible ways.
I hope GitHub and Obsidian are going to synchronise their MarkDown extensions in near future and this will become The Standard. Whatever a case, anybody can easily write a script to automatically convert any Markdown flavour to another.
> why should books be in Markdown? Markdown's biggest (or the only?) advantage compared to binary/XML based formats is sort-of readability in plain text, but that's just not that important for the majority of publishers and readers.
Read anywhere. I mean anywhere. Without a need for software as complex and resource-hungry as a web browser engine ePub would require. I used to read TXT books on a pocket MP3 player during the pre-Android era. Also very easy automated processing.
In fact my actual preferred format for books is FB2. I mostly convert ePub books to FB2 to read on a PocketBook eInk device because it would use book-specified fonts and pages (which I never want) if I don't and FB2 is sort-of Markdown-like (in terms of its logic and features) XML. FB2 also has a great metadata section to store information about the book.
And besides books there also are documets. Word/LibreOffice documents others would send me often are real pain to modify as WYSIWYG word processors bundle tons of redundant invisible formatting details for every bit of text even when not asked for.
> Without a need for software as complex and resource-hungry as a web browser engine ePub would require.
I know that technology purists love that, but any electronic reading device handles HTML easily (especially the simple HTML in ePubs).
The point becomes moot when your book contains images/illustrations and you (like a normal reader) want to view them within the content. You will use some Markdown formatter/viewer which is again based on browser.
> Word/LibreOffice documents others would send me often are real pain to modify as WYSIWYG word processors bundle tons of redundant invisible formatting details for every bit of text even when not asked for.
Markdown is just insufficient for any non-trivial document. There isn't any standard way to set image size for example. There's no standard way to create even rudimentary tables.
> “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
Then go for plain text. All those headings and asterisks are a distraction anyway. Years ago, many e-books used to be distributed in plain text in fact.
> Then go for plain text. All those headings and asterisks are a distraction anyway. Years ago, many e-books used to be distributed in plain text in fact.
Markdown is more semantic. E.g. it gives you a ToC (a very important feature of a good book, and it has to be semantic markup-based when you decouple the text from the view by omitting explicit pagination) for free.
Isn't Markdown meant to be lightweight HTML with shortcuts to declutter it visually? Afaik it even is considered officially correct to use HTML tags in it when necessary.
There is a lot of nuance and complication to typesetting books that isn't apparent to an untrained observer, and markdown + css simply isn't sophisticated enough to handle it. Even html/css + js is technically capable but far far behind the state of the art in digital typesetting.
This is also a very classic "well I could do it better" engineer trap so please don't assume that without some research. It's an ancient domain relative to what we're talking about here and has accumulated a lot of valuable insight & technique that should not be simply discarded because markdown is almost good enough for some things.
I don't have any professional typesetting experience, just some adjacency from having done some work for a type foundry at one point, that gave me some insight into how much actually goes into it.
Most professionals use expensive professional software for it. Latex or pollen or other pure markup solutions only work for smallish documents, or digital ones. Once you're going to print, esp in different formats, you need to care about page imposition, aligning with folios & signatures, widows & orphans etc. Just generally the physical reality of paper leaking into your abstraction of "the book" in ways markup alone can't accommodate.
I write a lot of documentation as part of my job and having Markdown side by side with the rendered output is great. Once you get the hang of the syntax, markdown is so much faster to write than using any text editor like Word. Just writing a list in text editors is painful.
I found mdBook easy to use, especially like that users can choose themes. I primarily use it for online version of my ebooks [0] and curated resources [1][2]
In all seriousness, HTML started out as a markup language for documents. That is why tags like <p> for paragraphs and <b> for boldness etc. are so prominent.
If you aren't trying to build a SPA or something like that and you just want to mark up some text for formatted output ... HTML is kinda made for that task.
That being said, I tend to stick with Markdown since I find angle bracket tags to be noisy and distracting when I view documents in plain text.
It’s just plain old dumb boring static text that is being moved around the web.
The internet was essentially created so that CERN could share plain old text documents with others remotely.
Why do I need a big bloated overly complicated PHP webserver that talks to an overly complicated database, when it’s just plain old static text after all?
AsciiDoc still has no footnotes, but only endnotes. Therefore not really useful for writing non-fiction books. As org-mode files are only text files, you can use any editor you like. If you want all the goodies (agenda, TODOs etc), you have to use Emacs, yes.
Markdown is a formalization of formatting conventions that people were using well before it was invented as a separate product. It was slightly different - the link syntax was novel, and asterisks usually meant bold instead of italics - but it was close enough that the allure of 'your reflexes still work' held. Nothing else is as popular as Markdown because it isn't actually Markdown that's popular, it's what preceded it.
Personally I'm happy for it because it'll finally stop programming languages from inventing their own domain-specific oddly-syntaxed subset of HTML; the way Rust uses it is something others have no reason not to copy. For your own technical writing, AsciiDoc works pretty well.
I think markdown's popularity comes from its simplicity. For things like bulleted lists, especially nested ones, I can just type an asterisk and keep going. The raw input is still very readable (for the most part) and adding formatting is quick and easy. For anything basic - such as chat systems, social media posts/comments, or quick note systems - I don't think anything more is needed.
Something like reStructuredText (.rst) is a similar alternative, but I think that if you're irritated by the limits of Markdown then rST isn't going to be any better. If you really want good formatting options, then LaTeX is the best I can think of at the moment.
I haven't seen the newcomer Starlight[1] being mentioned, so just throwing that out there as well. It's by the wonderful folks who created Astro[2] and my own limited usage of it has been great!
My friend introduced me to Astro the otherday. I have a few Gatsby projects under my belt but I could never really get into it, Astra looks fantastic compared to it
The rust zealotry put me right off fwiw. As it does my interest in the language itself. I wish those guys would calm down they're totally detracting from whatever the strengths of rust are with that nonsense.
What zealotry? Rust isn't mentioned until the last two points of eight:
mdBook is a command line tool to create books with Markdown. It is ideal for creating product or API documentation, tutorials, course materials or anything that requires a clean, easily navigable and customizable presentation.
- Lightweight Markdown syntax helps you focus more on your content
- Integrated search support
- Color syntax highlighting for code blocks for many different languages
- Theme files allow customizing the formatting of the output
- Preprocessors can provide extensions for custom syntax and modifying content
- Backends can render the output to multiple formats
- Written in Rust for speed, safety, and simplicity
- Automated testing of Rust code samples
It mentions Rust because it's written in Rust and used by the Rust project.
In other words, the project wouldn't exist without Rust but
I think they'd be best served not using the words "Rust" nor "GitBook" in their marketing, given it lacks most of the features of GitBook (that's probably why it isn't free!); mdBook appears to just be a static site generator.
I've written an online book with mdbook (https://lhbg-book.link) and it was a breeze. I believe mdbook was one of the reasons I even finished the book.
1. It's super easy to install. If you have a rust toolchain, just `cargo install mdbook`
2. One command to initialize: `mdbook init my-book`
3. One command to get immediate continuous feedback: `mdbook serve`
4. It allowed me to keep writing in my preferred environment (emacs)
5. It looked good by default. I could focus on the content.
6. Setting up auto deploy ci on github is about 30 lines for yaml
Though one point of improvement would be better support for other export formats such as pdf and epub.
tl;dr mdbook allowed me to use the path of least resistence to complete my project, and I highly recommend it.
Also it is possible other platforms can do the same or better but I haven't tried them.
Md book is great! We created a Nim version to support content written with nimib (a framework to publish html pages with Nim code and its results) and it has been very useful! https://pietroppeter.github.io/nimibook/index.html
As people are sharing other SSG (I think material for MkDocs is the absolute best for documentation sites), let me share a relatively unknown one that I find very interesting: https://github.com/dmulholl/ark
I have as next project to try and port this ark to Nim/nimib (and ideally nimibook should be refactored to use it).
Since I see a few people in these comments mourning the general dive that gitbook has taken over the last few years, you might like this, an actively-maintained fork of gitbook as it was before it got bad:
> It is ideal for creating product or API documentation, tutorials, course materials or anything that requires a clean, easily navigable and customizable presentation.
Markdown is really crap for any of that.
Any real writer knows that the best way to communicate an idea quickly and effectively is to present it the right way. Markdown does not have good presentation. It was not designed for good presentation. It was designed to write an incredibly basic-looking document, such that the plaintext and rendered document look similar.
I know this is going to be a shock to everyone. But it turns out that ASCII isn't the best way to encode presentation. On behalf of the poor SOBs that have to read what you churn out: Please stop subjecting people to your shitty presentation and get a real document format. Thanks.
I disagree. All it takes is a CSS file, some semantic HTML in the right places and some inline Mermaid diagrams and you have a pretty decent document. I routinely write one-pagers, memos and architecture summaries in Markdown and generate PDFs with weasyprint (or even just iOS’s print to PDF feature), and all I use is a print CSS file and whatever JS is required to render the diagrams.
I would love to not use a browser engine at all (and moderately detest Mermaid because it cannot work fully in-memory without instantiating one), but it works.
> *Note:* my complete disregard for <blockquote> semantics because I wanted to put a box around something, but my lightweight syntax doesn’t offer richer features
I’ve used both, I recommend MkDocs over MdBook for most people. MdBook is simpler and easier to get started with, MkDocs has more features, more plugins, more themes. Both MkDocs and MdBook are easy to use. IMO, MdBook is a little too simple.
Recommend using the material design theme for MkDocs as a starting point. If you are working on a Rust project, use MdBook instead. If you have lots of docs / multiple projects / multiple versions, use Antora. If you want cooler landing pages, use Jekyll.
It suggest that , when I use build command it gives html files, what if I want to compile all these in PDF format? Since PDF format is quite suitable for all the ebooks
I used to do this with GitBook, but it has not seem active development for some time. Wonder how easy it would be to move from GitBook to an Obsidian workflow with mdbook. The links are written like a wiki as [[]]. Would this tool understand?
Why? I'm mystified as to why there are vanishingly few VIEWERS for Markdown. One open-source project after another offers up .md files for documentation, but have you ever tried to find a plain VIEWER for Markdown?
I have been wondering about using a set of *nix tools backed by a git repository as a planner/diary. This tool seems to be an interesting addition for the presentation front.
Eh, in this case it's a tool created by Rust programmers for generating documentation for the Rust language, and has particular features for validation of Rust code snippets in said documentation. I think in this case, mentioning Rust in the description is reasonable.
…but it’s not the only bummer. The usage of Highlight.js + MathJax on the front-end is horribly wasteful. Why? It demands all clients parse & render the syntax/LaTeX which is not only taxing on CPUs and batteries, but this action is idempotent meaning every user agent on every page visit is going to do the same wasteful parsing to get the same result. There is no good reason that syntax highlighting shouldn’t be done at build time nor should it require JavaScript.