contentlayer VS markdoc

This looks and sounds great...

I'm currently using [contentlayer.dev](https://github.com/contentlayerdev/contentlayer) to manage docs and blog content, mostly .mdx files on urlbox.com.

It works well with next.js but unfortunately is abandonware now.

I also have a few custom remark/rehype plugins.

You're right it is a pain to update articles buried in your repo especially with less technical team members. I already tried out TinaCMS to try and solve the editing issues, but their editor wasn't so nice, and it seemed to implicitly make a commit on every tiny change to any content, so I'm really hoping I could use something like this to edit my already existing content...

Content Management: Contentlayer

For my personal website, I use Next and Contentlayer since I prefer to write my content as markdown files. I then host it using vercel's free tier.

I've seen https://www.contentlayer.dev/ used for similar stuff on open source codebases like taxonomy from shadcn

Contentlayer makes it super easy to grab our mdx blog posts in a type-safe way.

Flowershow uses Contentlayer to turn your Markdown content into data stored in JSON files. By defining document schemas, Contentlayer can generate data that is validated (making it type-safe) and can be imported from anywhere in your Next.js app.

My first reaction was to use MDX and use next/image just as in the example. But that means that we can't use normal markdown images and it turns out that this won't work with contentlayer. This wont work, because Next.js does some magic on the import of the static image. The object which gets returned by the import, contains not only a path to the image, it contains also the width and height, plus a very small version of the image for the blurred placeholder. This magic does not work if the MDX file is loaded with contentlayer, because contentlayer uses its own bundler, which does not know about the import magic for images.

After the installation we have to tell MDX that it should use the plugin. The example below shows a contentlayer config, but it should work with every MDX setup.

Or please share any API documentation tools you use that is opensource and NOT Swagger.

Stripe has Markdoc[0] but it doesn't seem to be automated in any way.

[0]https://markdoc.dev/

Try using https://markdoc.dev/ .. this is the documentation tool/editor by Stripe and it also powers the extensive documentation of the Stripe product itself .

Extension frameworks like Stripe’s, MarkDoc allows documentation to have code examples in multiple languages.

I'm bullish on Rust, but there's a long way still to go. The overhead of passing values across the boundary between JavaScript and Rust is quite high. There are a lot of cases where you want to be able to provide a dynamic configuration to Rust, ideally in JavaScript, and that's still pretty costly from a performance perspective.

One of my projects (https://markdoc.dev/) is a Markdown dialect that supports custom tags and a React renderer. I recently experimented with implementing a parser for it in Rust in order to increase performance. My Rust-based parser is significantly faster than my existing JavaScript parser, but then I have to serialize the AST in order to move it from Rust to JavaScript. I'd like to implement the entire processor in Rust, but I need to let users define custom tags in JavaScript, and the overhead of going back and forth is far from ideal.

I'm hopeful that the recently-ratified Wasm GC proposal—which introduces managed structs and arrays that don't cost anything to pass between the Wasm environment and JavaScript—will help a lot. But it's going to take awhile for Wasm GC features to land in LLVM and be properly supported in Rust.

Consider going down the docs-as-code route. There are open source options that require an investment of time for you to become familiar with the tech stack, so learn Markdown and Git if you haven't already. Stripe (who many consider to have some of the best documentation available) created Markdoc as a means of easily maintaining solid docs with some of the fancy quirks of the upper-end doc tools, including content re-use.

Most modern developer blogs and documentation websites have one thing in common— they run on JAMstack (static websites) and their content is file-based and powered by Git. This allows multiple developers to collaboratively edit content with perks like versioning and version control. In this tutorial, we’re going to see how we can build a simple yet powerful and interactive blog with Next.js and Markdoc.

Hola. Former Stripe employee here - they use Markdoc: https://markdoc.dev/