I appreciate the change to the navigation, it makes things a whole lot more clear!

> Can you explain this _unsettling_ comment further? Do you find the limits too low?

Perhaps I could have worded that better. I don't see myself hitting that limit any time soon, but it represents some amount of lock-in (though, less than typical since the everything is mostly plain markdown). My reluctance to use paid software that gates features or may disappear entirely is due to the lock-in and vanishing of previous tools I've used. Not to say that is what is happening here, perhaps I'm predisposed to side-eyeing non-open-source tooling since it is such a core part of my work. At least with an open core, I could fork and maintain the existing features should the business-side ever go under.

That said, thank you for also clarifying that the $99 pro license is only required if a site were to stretch beyond 100 pages. I may give it a go on one project, but I can't see myself committing completely.

> or may disappear entirely is due to the lock-in and vanishing of previous tools I've used.

Another important point. Retype is distributed via NPM and NuGet (.NET) package managers. Once a release is published, we can't walk it back or remove it from the internet. There's also no gate-keeping with Retype or gate-keeping of content. You control the content, generation, and hosting. Retype cannot in any way disable or remove your website. Again, for better or worse, I'm not sure, but you are autonomous and anonymous to Retype, and at least the app, cannot disappear.

> I may give it a go on one project, but I can't see myself committing completely.

That would be most excellent. I would greatly value your feedback.

Hope this helps.

Sorry for the wall of text.

> but it represents some amount of lock-in (though, less than typical since the everything is mostly plain markdown)

This is an important point. Retype has been developed with the explicit goal of preventing lock-in. For better or worse, I'm not sure, but the point of the app is that you are not locked-in by design. You 100% control the original source of all your data and that data is being stored in the absolute simplest of forms being just static text files. Your data is not squirrelled away in a proprietary app, or sass service, or spread across tables in some database. Sure, you (or whomever) might be skilled enough to extract that data back out of the database, but that scenario is certainly the exception, and certainly will never ever be as simple as just plain text files stored in a folder.

In the future, you might decide Retype is not for you, or a better system comes around, no problem. You control ALL the data. Just switch to a different generator. There's no exporting data out of some system and hoping you fetch everything, assuming you can even get the data cleanly out of a system.

Even gitbook is not that clean. You can mostly export your content out of gitbook, but that does include everything. They give your content back, although that is not enough to recreate the site with configuration.

Yes, there are a handful of Retype specific Markdown components that enable convenient UI components such as Tabs, Panels, and Buttons, but... those exist in all static site generators and Retype has by far implemented the cleanest syntax solution. That solution, by design, is also the easiest to port away from. Maybe the system you move to in the future does not support the exact same syntax, but it will be trivial to port from the Retype syntax to another.

For instance, compare the Retype Tab component syntax (https://retype.com/components/tab/) to docusaurus (https://docusaurus.io/docs/markdown-features/tabs), which is actually relatively clean compared to the mess that gets exported from gitbook. BTW, Retype 100% supports the block of Tab code exported by gitbook, so your site will "just work" without being required to do any cleanup of their exported syntax.

I would love to add many more components to Retype. It would be trivial to do, but I explicitly do not because I want to try and avoid vendor lock-in. If a better system comes around in the future, even I want to be able to port my project as easily as possible.

Docusaurus maintainer here

The Docusaurus tabs use MDX, it's not a custom syntax for tabs, it's a powerful low-level way to use React or frontend interactive components in markdown, and likely to become more and more widespread (so hopefully portable and yet very powerful)

It's also possible to implement tabs with Rehype syntax in Docusaurus in user land thanks to a Remark plugin, so portability remains possible but not free.

At the end of the day, md is not the most powerful out of the box and it's difficult to ship something meaningful without any extension

MDX is interesting and powerful, although creates all kinds of portability issues and is a terribly leaky abstraction of what should be a simple content syntax. Very much (IMHO) against the ethos and beauty of Markdown.