We hope these answers give you an honest insight into the project — its current state, the possibilities, and supported usecases etc. Please share additional questions on the community forum!
Tina introduces an entirely new paradigm to the content management space, which can make it difficult to grasp. In short, Tina is a toolkit for making your website its own CMS. It's a suite of packages that enables developers to build a customized content management system into the website itself.
Tina allows you to expose content editing directly within your website's components. You can use Tina to build your own custom CMS and have precise control over how editors interact with those editing capabilities.
Here's an overview of the current CMS landscape:
Tina is not an application on its own that you login to, however you could build that authenticated editing application into your site with Tina. It is not a one-size-fits all solution. It is incredibly flexible, providing precise control over an entire content editing infrastructure — from the database to the user experience.
Currently, Tina is pre Version-1. While much of the core architecture is fairly-well settled, many of the higher-level APIs are still being built and shaped. Breaking changes in non-core packages are introduced regularly (but communicated in Release Notes) as we push limits and hone the developer experience.
As of now, we'd recommend using Create React App (CRA) or Next.js if you're wanting to use Tina in production due to a few constraints in the way Gatsby works.
While it is entirely possible to use Tina with Vue, currently there are no adaptors, packages, or documented methods of doing this. This is an unbeaten path.
We can identify a few different ways to approach Vue support:
The Core Tina Team is focused on creating a solid foundation with React first, before considering Vue. However, if someone in the community wants to spearhead this effort, we will certainly offer support and guidance.
From a content editing perspective, the current UX has been created with developers-first in mind. For example, the GitHub editing workflow and interface assumes the content editor is comfortable with Git terminology such as forking, branching, pull requests etc. We chose to focus on developers editing sites before adding abstractions to smooth out the experience for non-technical editors. This strategy has allowed us to quickly expand Tina's core capabilities and improve it's stability.
It depends on your framework and who is editing the site. The approaches outlined below represent the well-documented and supported avenues, but they are not the only methods.
Right now with Gatsby (or any Git-filesystem packages), you'd generally need to run a development server in a cloud editing environment to track and manipulate the local filesystem directly. In theory, it is possible to use Gatsby with an API-based content source, but we haven't explored this yet.
There are obvious limitations to running a development server in the cloud, so we explored an alternative approach that leverages SSR to edit a live production site. The best example is our own website, tinacms.org.
This site uses Next.js's preview mode, which allows us to host a website that is fully static by default, but switches to a dynamic mode that runs server code for authenticated users. Content changes are managed through the GitHub API.
Currently, the easiest way to use Tina in production is with Next.js and GitHub as a content source.
No, but these workflows are the best supported at this time. Tina is designed to potentially work with any data source.
Yes — since the editing interface is built into your site, there will be Tina code in your production build. We've taken steps to minimize this by preventing heavy dependencies (e.g. moment, react-color, react-dropzone, prosemirror) from loading by default.
An idea has been brought up to strip Tina from production, but we do not have plans to implement this. It's also worth noting that some sites want to use Tina code in production (for example tinacms.org) since editing occurs on the live site itself.
A trade off for utilizing Tina’s editing interfaces (especially the inline editing interfaces) is that there will be extra code in your site. We will do our best to handle the biggest offenders via standard methods of decoupling but it is not possible to reduce the impact to 0kb.
Tina provides a real-time preview of React-based websites by manipulating the content that gets passed into a component's props, triggering the re-rendering of that component. Without Tina, this type of content is not usually changed after its initial render. It's common for latent performance issues to suddenly emerge when these props start receiving frequent updates. The following tips might help:
Give me some of your tots 🦙.