Live data from Hacker News

Show HN: I’m building open-source headless CMS for technical content

vrite.io

21–30 of 54 posts

Re: Show HN: I’m building open-source headless CMS for technical content

#21

Earlier quoted context omitted.

Hugo, Jekyll, etc. are Static Site Generators (SSGs) Content Management Systems are likes of WordPress, Ghost, Contentful and Strapi - they help you create and manage content. From those, headless CMSs form a distinct group, which only provide a dashboard for you to manage and create content with, but no built-in frontend. Instead you have to use API and other means to create your own frontend based on the content fr…

but this DOESN'T "only provide a dashboard" or api. this SPECIFICALLY provides a GUI to manage it. your definition makes sense to me, but since this has a GUI it doesn't fall into that definition.

Content presentation layer is the "head" in this case. Any frontend or blog you might have. The management dashboard is a separate thing not really considered in this definition - every CMS has it. Maybe this article will explain things better: https://www.contentful.com/headless-cms/

Re: Show HN: I’m building open-source headless CMS for technical content

#22
Congrats on launching, that very interesting!

I recently started doing a project in this area too, it's tempting but there are a lot of push back from developers to change their habits (and markdown).

Anecdotally I also tried to integrate Monaco with TipTap, you did it way better than me, well played!

Re: Show HN: I’m building open-source headless CMS for technical content

#23
post #16

Earlier quoted context omitted.

Headless means the CMS itself is an API. It can be hard to visualize so people may ask what could this look like? From there a headless cms can use the api to render the data as a site. It can be static, or dynamic.

but it specifically has a GUI. It touts the features of its GUI. Like... i feel like i'm not understanding something obvious. I get the idea of an API only server. I've written many. BUT by shipping a GUI (as part of it or separately) and then touting the features of that gui for managing the CMS they're no longer talking about a "headless" thing. They're talking about a GUI that may talk to a "headless" cms but the…

"Headless CMS" doesn't mean it has no management GUI. It means that the output is an API instead of actual HTML pages. The "head" is HTML pages, like what you get with WordPress. "Headless" says nothing about how the CMS is managed, just what it outputs.

Re: Show HN: I’m building open-source headless CMS for technical content

#24
post #22

Congrats on launching, that very interesting! I recently started doing a project in this area too, it's tempting but there are a lot of push back from developers to change their habits (and markdown). Anecdotally I also tried to integrate Monaco with TipTap, you did it way better than me, well played!

Thanks! I think that with something that allows for incremental adoption and "raw Markdown mode", this might be possible. Vrite isn't there yet but maybe it'll get there in the future.

Also, yeah - integrating Monaco wasn't easy. Took me a while to get it right.

Re: Show HN: I’m building open-source headless CMS for technical content

#25
Is there any support for translation?

If you self-host, can you use it flat-file or does it require a database? If I have my content in Markdown files in a repo, where does Vrite fit in?

Why is there no search on https://docs.vrite.io/? Or am I just missing it?

Re: Show HN: I’m building open-source headless CMS for technical content

#26

Is there any support for translation? If you self-host, can you use it flat-file or does it require a database? If I have my content in Markdown files in a repo, where does Vrite fit in? Why is there no search on https://docs.vrite.io/ ? Or am I just missing it?

- No they, though you can use any language you want in the editor. - Self-hosting is currently limited but, in any case, MongoDB and Redis is necessary. - A sync integration with providers like GitHub or GitLab is in the pipeline, but currently you might be able to work something out with Webhooks and Content Transformers, depending on your use-case. - Docs are fairly fresh. Agolia recommends that you have some content ready before you integrate it for the first time and I'm looking to add some more details in there, like API docs in upcoming days. When that's done, I'll add search.

Re: Show HN: I’m building open-source headless CMS for technical content

#27
There is definitely a gap for a product like this. At Ritza (a tech writing agency) we use a hacked together set of tools to accomplish this so I definitely see the need and am probably part of the target audience.

Some feedback (based on a quick skim - you've probably thought about all these more than I have but just in case anything is useful)

- Why include project management? It's hard to beat a tool like Linear, Trello, Jira or whatever people are already using.

- I like the idea of a built-in markdown editor, but I think it's also important to allow technical people to bring their own editor or use git directly. Do you support this? If yes, I'd call it out on the landing page. Gitbook used to do this pretty well but they pivoted to a more GUI-focus and now there are weird bugs if you try to use both their editor and git directly

- I agree with other comments that images are something to get right for something like this. Let people paste from clipboard, upload a file from their machine, or link to an already hosted file. Allow the user to the optimization similar to TinyPNG automatically (maybe also CDN, or at least allow integration with CDN). Assuming you're dogfooding this for your own docs, images are loading very slowly so I assume you're not doing this atm.

Good luck!

Re: Show HN: I’m building open-source headless CMS for technical content

#28
post #27

There is definitely a gap for a product like this. At Ritza (a tech writing agency) we use a hacked together set of tools to accomplish this so I definitely see the need and am probably part of the target audience. Some feedback (based on a quick skim - you've probably thought about all these more than I have but just in case anything is useful) - Why include project management? It's hard to beat a tool like Linear,…

I've freelanced for tech writing agencies and some of my experience comes from there so in a target audience you likely are :)

That said, great, constructive feedback there, so let me address some points:

- I don't like jumping between different tools. I prefer a consistent, great user experience when available. That's why project/content management is a big part of Vrite. That said, I'd like it to be more customizable to different use-cases people might have so, in the future, other "views" aren't out of question, e.g. list view or folder view.

- I see the point. However, building a product around external products (i.e. other code/text editors) doesn't make much sense to me. However, a "raw Markdown mode" with Monaco Editor or a sync extension for editors like VS Code is in consideration for after full GFM support is implemented. Indeed Gitbook has recently been my inspiration as I'm trying to extend Vrite to handle general tech documentation rather than just dev marketing. Git is a big part of that, and I have some ideas on how to integrate it though, given that Vrite is an API-based CMS, this will be a challenging process.

- Various integrations and asset management/optimization are cetainly important. Images are already handled by Cloudflare's R2 so CDN-wise it's already good - they're just too big. That said, I'm currently working on an assets manager and optimizer for Vrite.

Re: Show HN: I’m building open-source headless CMS for technical content

#29
you've done a great job on the overall UI/UX, but as always, for me the question is where and how the product fits in the overall marketplace. this is true even for free/open source products, as it's hard to maintain momentum on stuff no one else really notices or uses.

is there a pain for managing content for technical writers? yes, probably. not many products target this niche. is the pain big enough to overcome inertia? that seems questionable, but perhaps it is big enough. i doubt large businesses would even look at a fledgling product like this, as it doesn't solve enough pain for them. it seems that there might be a market in small-to-medium-sized technical businesses that have like 1 technical writer and a few guest postings to use a platform like this.

but does it make sense to target developers at all? perhaps for initial marketing, but i'd conjecture that devs mainly just want to get something out on one platform (whether their own blog, or dev.to, or whatever) and perhaps secondarily on twitter (or similar) for more reach and discussion. it seems to be an uphill battle to get them to switch over to a completely different tool that requires integration to get content flowing to all the right places (which is what a headless cms requires).

in any case, the positioning as a headless CMS falls flat to me. that seems to be leading with a technical detail ("headless") rather than the pain and the solution. my off-the-cuff suggestion is something more like "Content Automation" as the descriptor. similar to "Marketing Automation" (e.g., buffer, hubspot) yours is a CMS plus and an automation platform (in the making). it helps people crank out technical content and put it in all the right places to be seen by the people you want to target.

Re: Show HN: I’m building open-source headless CMS for technical content

#30
I think there's also a missing gap in how to present Swagger beautifully, the default one ( https://petstore.swagger.io/ ) is meh. I'm looking for something that can generate like https://stripe.com/docs/api but open source (since the OP is talking about it).

I imagine a tool(chain) that can take Swagger generated from annotations in code, and combine it with a folder containing Markdown files for "free form" documentation, and generate a Hugo/Jekyll static site that can be deployed in Cloudflare Pages in docs.mycompany.com

Post reply on HN