Thanks for creating TinaCMS. I’m looking forward to playing around with this application, but I’m a bit confused. What problem does TinaCMS solve that hasn’t been addressed by WordPress or Django? What is the value add for a company adopting TinaCMS?
I don’t work for TinaCMS so there may be more value-added depending on different use cases they might be able to add to this.
I’ve recently rebuilt my blog to use TinaCMS Portfolio site using Tina CMS Grande. I could’ve built my website in Wordpress or any other CMS; however, the performance would’ve suffered, and I would’ve had to pay for an instance of a LAMP stack somewhere. By using TinaCMS, I was able to get lovely WYSIWYG features and also have the performance benefits of a static-site generator (in this instance Gatsby). Until TinaCMS, there wasn’t an option to edit your static site without creating raw MD or JSON files or setting/linking up a CMS like Wordpress or Drupal to expose an API.
I like to think of TinaCMS as a WYSIWYG editor for static and React sites.
Hope that helps!
Thank you @xaviemirmon for your thoughtful answer.
As someone who knows how to code codes, if I wanted to build a blog, it would be much more straight-forward for me to clone Gatsby’s starter blog, customize the CSS and then proceed to deploy on Netlfiy.
Does TinaCMS make it easy for folks to build a website and where they can focus more on writing content and less on centering content. I I know this is a trivial example, but these trivial problems add up and makes it cumbersome to build a sleek looking site.
I’m hoping that TinaCMS can make design easier, and still allow me to drop into a component’s source code when necessary.
The Gatsby starter blog doesn’t come with any editor. Meaning, if you wanted to update or add new pages, you would have to add new MD files to the /content directory. TinaCMS is very flexible so you could retrofit this starter to incorporate TinaCMS.
For editing my blog, which started with the TinaCMS Grande starter, I have these two options when writing.
So it’s much more straightforward especially with editors who don’t know code to edit the site.
I see what you mean, but I’m perfectly ok with updating written content via git. I don’t see a wysiwyg editor as a huge value add for my use case.
Cool. You can always add TinaCMS to you site at a later date if you need it. I personally find it much nicer to have an editor. Plus TinaCMS also deals with things like Hero images, menu items, page creation, etc. I’ve found the whole experience very slick and it meant I was able to get up and running very quickly!
I don’t see a strong use-case for TinaCMS as well if all you want is a some sort of developer blog. As a developer, you can always just edit Markdown/MDX when using a SSG or just use WordPress, WebFlow or whatever technology. It is just not a critical piece of software in the end.
However when your use-case is a large-scale JAMStack app, that needs to integrate multiple services like Stripe, PayPal, Algolia, … and is connected to a backend like Firebase, you have a lot of dynamic parts that require bullet-proof and well-tested custom code (we use Gatsby/React for frontend code and express for cloud functions, all TypeScript with a good deal of code-sharing between client and server), but you also have some parts, that are just static content, like a blog, newsletter, article or whatever collection that should be editable by members of your organization.
This is where I see the sweet spot of TinaCMS. It is a really nice approach to solve the CMS problem for JAMStack apps. It would allow me to make only the static parts editable for content-editors, and there is no better and self-explanatory way than in-place editing.
TinaCMS itself won’t solve the provisioning of an editing environment for your content creators, as you cannot possibly expect your content creators to run a development server locally and deal with git commits. An editing environment should enable editorial workflows, role-based access and handle all the git stuff, like committing and preventing conflicts.
I do not want to provision it myself, so I will take an in-depth look at Tina Teams, which is supposed to solve that problem.
Well said! TinaCMS isn’t designed for developers who are happy to just use their code editor to create content. Instead, it’s designed for cross-functional teams composed of developers and non-developers. We’re determined to create the best developer experience and the best editing experience.
Ahah! This is the first time I’ve seem anything written about the editing environment. It seems to be a gap in the documentation where live editing is mentioned and that it is easy to add it to sites etc, but its not clear that live editing does not happen on a ‘live site’, much as it does with a Wordpress or Drupal site.
For developers setting it up locally it is easy to commit changes to their repo, but its not clear to me how this would work for content editors without git knowledge. Presumably they need a version of the site set up somewhere that is running in develop mode (Gatsby) so live building/previewing can happen but that site needs to be protected somehow (logins etc) and also be able to commit to git. Tina Teams is mentioned but are there are docs or guides on how to do this if a developer wanted to set this up themselves?
I’ve just seen this thread which tackles this question in more detail
I work at an agency which makes websites for clients, and we’re looking at this as an alternative to Concrete5, Ruby on Rails and WordPress - we need WYSIWYG and a “site-builder” type experience for users, but we also want to kill boilerplate and enpower our development team by using tools that we enjoy working with. There’s very much a use case for TinaCMS and I’m going to be following closely.
I am working on a prototype at the moment as a content mesh which will look at bringing in content from WP API, Concrete5’s new API, Shopify and Strapi.
live editing does not happen on a ‘live site’
It can, it just depends on the tools and configuration. With Gatsby, you need a development server and there are obviously big limitations to that. But with Next.js you can leverage their preview mode to edit sites in production via the GitHub API. This is actually how tinacms.org is configured — anyone (with a github account) can edit the live site and open a PR to contribute changes via the ‘Edit This Site’ button.
We’ve focused many of these workflows on developers first, before we look towards abstracting to meet the needs of content editors. Tina is very flexible — while currently there are packages that support the Git & GitHub workflows, it is designed to potentially work with any data source. We’ve made prototypes integrating Tina with API-based data sources, it just isn’t well documented at this time.
Tina is a toolkit to build your own custom CMS. It’s not a one-size-fits-all approach like a conventional CMS. We think of the main aspects to consider when building a CMS as: constructing the editing interface, storing and managing data, and then integrating with various Frameworks.
We’d like to provide developers with control and flexibility in all these aspects related to building a custom CMS. Right now, we’re building from the ground up, trying to make a solid foundation with React and Git-based workflows, but that’s not the end of the story in terms of what’s possible with Tina.