Rich text, html or rich content?


What is better to use, HTML or Rich Content?

For forum like. Example what is used here at the Bubble Forum, or in general?

Input is a rich text , but output is a html language

Bubble uses

So the both HTML and Rich Content are the html as output? There is no difference between the two in the back-end?

I know about Bubble and Discourse, but still wondering what Discouse then uses, HTML or Rich Content?

I don’t know about bdk’s plugin that you reference in the first post, but Discourse can handle markdown, HTML, and bbcode (depending on which plugins are turned on): Supported formatting in posts (markdown, BBCode, and HTML) - users - Discourse Meta

I’m guessing that since it’s going to be rendered in a webpage, the output will be HTML.

I’m guessing that there isn’t a “better one” – the goal is to match them. I’m guessing if you feed it HTML and say it’s rich content, it won’t work properly.

1 Like

Thanks! Make sense. I have realized there is a difference between the HTML and Rich Content saved data. Although not sure what is more recognized in the code world? Example outside Bubble, and if one day we need to move our data base to other servers and whole app, what would be more agile and universal to make such transition?

Markdown. It’s simple and can be easily transformed into HTML, rich text, or anything else.

HTML is not bad either.

And between Rich Content and HTML, as we have I guess only this option in Bubble app builder? With context from previous message, a potential transition from Bubble into more custom code and servers? Thanks! is a full-stack platform. So I would say the Next.JS (Full-stack framework) as I gonna try and move out one of my projects to Next.js. But it’s the case only if your app is web.

1 Like

Sorry, I am here without the code background.

I have though the Next.JS (Full-stack framework) is the language, same as Phyton and others, and if that is the case, I am wondering here about database and rich text, it’s usage and potential transition between the two or between the bubble database and custom server database.


What CHAT GPT says (:

The choice of the best rich text format (RTF) for applications often depends on the specific requirements of your project, compatibility considerations, and user experience goals. Here are a few popular rich text formats that are commonly used in applications:

  1. HTML (Hypertext Markup Language):
  • Pros: Widely supported, versatile, and commonly used for web applications. It allows for a high degree of customization and supports multimedia elements.
  • Cons: Can be more complex than other formats, and rendering may vary across different browsers.
  1. Markdown:
  • Pros: Lightweight, easy to read and write, and widely adopted in documentation and online platforms. It’s simple and intuitive for basic formatting.
  • Cons: Limited in terms of complex formatting compared to more feature-rich formats.
  1. RTF (Rich Text Format):
  • Pros: Designed specifically for rich text and is supported by many word processors. It allows for a good balance between features and simplicity.
  • Cons: Not as widely used as HTML or Markdown in modern web applications.
  1. XML-based formats (e.g., Docx, ODT):
  • Pros: Provide extensive formatting options and are used in popular document processing tools like Microsoft Word (Docx) and LibreOffice (ODT).
  • Cons: Can be more complex, and processing XML-based formats may require more resources.
  1. JSON-based formats (e.g., ProseMirror, Slate):
  • Pros: Suitable for web applications, easy to integrate with JavaScript, and can be customized to meet specific needs. Examples like ProseMirror and Slate are popular for building rich text editors.
  • Cons: May not be as widely supported as other formats, and the learning curve might be steeper.

The choice depends on your specific use case, platform, and user expectations. For web applications, HTML and Markdown are often popular choices. If you’re dealing with documents that need to be edited in word processors, then RTF, Docx, or ODT may be more appropriate. If you’re building a custom editor within a web application, JSON-based formats like ProseMirror or Slate might be worth considering.