about the episode
about the guests
Brian Douglas: Welcome to another installment of JAMstack Radio.
On the call we got Scott Gallant from Forestry.io and TinaCMS, and then also we got Jordan Patterson as well, also from the same company.
So Scott, tell us why you're here and what you do.
Scott Gallant: Hi, Brian. Thanks for having us. Happy to be here. Jordan and I started Forestry.io a few years ago.
Forestry.io is a content management system that's backed by Git and the JAMstack, and that's why we're on the show.
We see ourselves as part of a crew that's carrying this movement forward from legacy stacks to modern stack for web development.
Brian: Very cool. So you're CEO, Scott, like you've donned that title. Then Jordan, you're CTO?
Jordan Patterson: Correct.
Brian: What is your role at Forestry today?
Jordan: Picking technology stacks, making technical decisions.
I still am actually still doing a lot of development, which is great because that's what I like doing.
But I also get pulled into meetings more often than I like, but apparently that's par for the course.
Brian: Yeah, fair enough. How big is a Forestry today? I assume smaller, since you're still knees deep in hands-on code.
Jordan: Yes. We're 14 I think, at the moment. We just had a new person start yesterday, so I think that brings us to 14.
Brian: Nice. Congratulations.
Scott, you had actually reached out specifically about Tina CMS, which was actually just launched a few weeks ago at JAMstack SF.
So, do you want to go ahead and give us an intro? What is Tina? Or, "Who is Tina?" I guess is the correct Jeopardy saying.
Jordan: Sure. TinaCMS, "Tina" is an acronym. It's a recursive acronym.
Do you know what that means, Brian?
Brian: I know about recursion, because I always fail those.
That's why I can't get a job at Google. But go ahead and tell me what that means.
Jordan: OK. It's an acronym, but the first word of the acronym is Tina. It uses its own name in the acronym.
Jordan: You know, how PHP was "PHP Hypertext Preprocessor,"" I think.
GNU is "GNU's Not Unix." I'm not going to tell you the answer, but if you can figure it out by the end of the chat here we'll give you bonus points. It's a recursive acronym.
Jordan: It's Tina CMS, so what TinaCMS is this open source project and we're calling it a site editing toolkit.
It's less of a CMS and more of a toolkit to build real time live editing functionality into your site.
So you can imagine, a traditional CMS is a separate system that you build.
It talks to your content and your site is a separate thing, now that we live in a headless world where these two things are de-coupled.
But with Tina, you actually bolt on editing ability onto your site so your editors can go into edit mode and live edit the site.
This happens through two ways, one is through this sidebar UI that exposes fields.
Where they edit these fields and you can see the page update in real time, but also we gave developers the ability to drop in editable regions.
When we were user testing this, we found that "OK, running long form content in this little sidebar UI isn't that great. If you're writing a blog post or documentation, you don't want to be confined to this small little UI."
We allowed-- Again, we built this live in page mode so you can edit a blog post much like you'd edit a Medium post.
So, that's what Tina is. It's a live editing experience with these two solutions, in page mode combined with this exhilarating UI.
Jordan: Does that make sense?
Brian: Yeah, it makes sense. I'm looking at the UI instead of the examples, and I got the gist of "You can add this to an existing--"
You'd mentioned in the site Gatsby and Next.js as examples.
Are these the only examples that Tina works with, or are there--? Is that just the example she led with?
Jordan: Yeah, those are the only two at the moment that are officially supported.
But really, I think we can probably make it work with any REACT SPA.
Jordan: But we do have plans for Vue support as well in the near future, and then I can even see potential for us to start supporting older static site generators like Hugo and Jekyll.
Scott: Yes. So Brian, I'm sure your listeners know that you work at GitHub.
Scott: If you were to say you wanted to add a new blog post to the GitHub blog.
The way we see it working in the future of content management, is you would go to your blog and you would go into edit mode and add a new post, and then you'd be looking at a fresh blog post on the GitHub blog with maybe a dummy title and an empty body.
You just start writing there, and that's where you do all your content editing, like in page.
When you click "Save" it right now would commit that to your repo in the future, and maybe that would do other things.
Brian: Yeah. That would be super valuable. I noticed firsthand because I come from the world of the JAMstack world, which is why did a podcast, and GitHub the blog itself was hosted on Jekyll.
We've grown into that, we're at 1,300 people at GitHub at this point.
The content managers said, "Let's just use something that we're familiar with," so we migrated the blog itself to WordPress.
It was mainly because there was no connection between the people who are not technical and the people who were technical, because everybody who's technical wants to work on the harder problems like adding new buttons to the pull request or working the GitHub actions.
So, we just had to make a very quick decision on either stall the blog or continue the process of GitHub shipping content.
I see that having some drop-in and dashboard directly in your Gatsby or Next site or future React SPA.
That's the bridge to get people just to go ahead and edit that content directly.
Scott: Right. There's often a battle between developers and non developers about what tool you should use.
Developers, I'm sure, wanted to build a static site.
You said Jekyll, but maybe it'd be different going forward. The non developers are like, "Give us WordPress. We know how to use that."
But the way we see content management and web development is that it doesn't need to be a battle between these two groups of people.
The vision we're trying to pave with Tina is a tool that's really a 10/10 for both parties.
Something that makes developers like, "This works so well with my workflow. I can build sites how I want to build them, it's still de-coupled."
And the editors are like "I get this magical experience. It's amazing and I can make great content."
So, how do you--? I'm curious Brian, how do you feel about the WordPress shift from Jeckle to WordPress?
Brian: To be quite honest, I don't read enough on the blog to care, but if it was my decision and if I was working on the team that had to make that decision on a technical basis, I would reach for something like a TinaCMS or something to bridge that gap.
Because we're already on the JAMstack to basically add that drop and replacement, but unfortunately the timing of this--
We don't have to go into way more detail, because some of this is privileged information, but the decision was made and I didn't change the way I write blogs because to be honest, GitHub uses GitHub to build GitHub.
The blog actually starts has a GitHub issue before it even gets at a point that you're actually going to drop in content, which is another interesting use case.
GitHub is very unique in how we approach problems, because we use GitHub for everything.
We might be shoving GitHub size nails inside of simple holes.
Scott: Dog fooding.
Brian: Yeah, for sure. I'm curious though, how is the data maintained?
If you have the Wysiwyg TinaCMS that's coming out through the sidebar, how are those changes reflected?
Is that also powered through Git, similar to Forestry?
Jordan: Yeah. Currently Tina works with markdown-based content, similar to the way Forestry works with markdown-based content.
We're reading and writing markdown with frontwriter files.
As you're typing and live editing, it's actually writing out to the file system, and Gatsby is doing its library load thing, or Next is doing its library load thing.
Then when you save it we make a commit and push that to your repo.
Scott: If you check out the video from the demo at the JAMstack conference, you'll see me editing a site with Tina, and then I just say "I'm putting it next to VScode," and as I'm editing that site but you're watching it update in real time.
You see VScode updating too, so it's cool to see from a developer's perspective that you're actually ready to do the markdown files yet in the future.
It's super important for developers to have structured content and have it separated from your site.
Right now, markdown and data files is Tina's data store, but in the future we can see that branching out to other things in the database.
Brian: I have to ask too as well, is Tina open source as well?
Like are people over to see how the sausage is made and how you started making that interaction?
Because editing the code in the browser that edits the code in my local file in VScode, that's pretty unique.
Jordan: Tina is open source.
You can install it and run it locally in your development environment.
We're also shipping a CLI that will allow you to run a Tina Serv command so you can host that in an environment where other people can't have access to it.
Then we're also shipping a managed hosting solution for that called "Tina teams" shortly as well.
Brian: So when you say "managed," is that also--? Like, is Tina also going to have to run on a server? or can I host that on Netlify?
Jordan: No, you wouldn't be able to host it on Netlify. Netlify does the build and then you've got the static assets.
Jordan: But just the nature of the way that Gatsby works. There's a lot of processing that happens server-side.
When you're running Gatsby Develop, you don't get marked down in the browser, you get HTML.
So when we're running it, Tina requires you to run it in Gatsby Develop mode.
Scott: Same with Next, or anything else.
Brian: OK. Gotcha. So, I'm curious. I put in our talking points "What's the next generation CMS?" What's the punch for TinaCMS?
Jordan: The whole reason we made Tina was because we saw these second-gen static site generators like Gatsby and Next , Grid and some things like that.
We really felt that they needed a different solution, or that they could really benefit from a different solution, something that was built from the ground up and tailored to work the way that they work.
In doing that, we've been able to ship a much better editing experience. As far as what makes us next gen is that it's really working with those next gen tools.
I might be giving it away, but Tina is not a CMS. It's a library for building a CMS into your site. Right? It's a tool kit.
Scott: Yeah. But I should also add though, Forestry is a headless CMS that is backed by Git.
We've been really close to this whole movement for a long time.
One of the big problems I see when people use our products is the fact that headless CMSs are so decoupled from the site's code that you can't preview a site, or if you can it's still this slow process where it may take minutes to build your site and see the previews.
So, it's this clunky de-coupled process and sometimes it doesn't even exist.
So, you can imagine as in the content editor ending a site with no preview button, you're like "OK. I filled out these form fields and hit save. I'm just going to kick that over the fence and hope it's OK."
And then you see it in production and it's not, and then you have to do it again.
To be honest, this is something I was really close to for a long time because I've been a freelance web developer since the early 2000s.
I would build websites for people, often WordPress sites and I'd sit down and watch them use the CMS.
I would see like this disconnect as they are going between the UI and the CMS and the final website. And they're trying to map the fields from the CMS to a web page at their site.
To us developers it sounds like, "Of course. Makes total sense. You got structured content that gets used over there." But to an editor, it's often not like that.
Then the pains of the headless CMS.
This was brought back to me recently, we were testing a site with Spotify and I watched the person Spotify used their seat in the Forestry CMS for the first time.
I said, "OK. Edit some content, click preview and preview opens up the new tab."
They look at it and I said, "OK. Go back to Forestry and we're going to head up more content. And they're like, "I don't know what you mean."
I was like, "Go back to the editing interface." They're like, "I don't know where to go."
And I said, "This person doesn't realize that they are on a new tab." This is like they're now looking at the preview of your site.
So I said, "Go up to the tabs and go to the next one over," and she went to it.
She was like, "OK." Then it just reminded me, and this is what I lived through since the early 2000s, I'm just watching people with this disconnect and seeing as it solves that problem where it gets at the editor in that context.
They need to create great content.
Brian: That makes sense. It sounds like their use case makes a lot of sense too.
You'd asked the question about the GitHub blog, like this sounds like that disconnect between just trying to get content out there is painful.
I find that same thing when I go to write markdown content for a simple adding an issue or a pull request.
I always hit that preview tab multiple times, and I go back and say, "It actually needs a style like this," or "I missed a Curly bracer," or whatever it was.
I'd go back and forth and to the point where I forget if I've actually published this or not, so I'll do all that work on the issue, hit the preview tab and like "I'm done,"Then forget that I actually never hit save, because I see the structured content in the preview tab.
Not completely one-to-one Tina CMS, but I could see that problem.
Scott: Yeah. It totally exists in GitHub, I know what you mean.
It doesn't need to be this way with website content editing, it may need to be that way for a GitHub issue, but that's for GitHub to worry about.
We don't feel like it needs to be that way for our website content creation.
Brian: That's fascinating, so is Tina--?
Is this going to be another product under Forestry, or is this a whole other thing that you're running in parallel? How do these live together?
Scott: For now, it's a parallel product.
We expect the roadmaps to merge in the future, but we expect to open up Tina to the Forestry users.
But for now, we released it as its own open source project.
We're just building some community and making progress with it now, but we expect those things to emerge in the future.
Brian: That's awesome. Because I'm on the market for a new blog design and editing interface, mainly because I'm using Middleman, mostly out of inertia.
I started a blog like 6-7 years ago, and it works. I can drop in Netlify CMS and it works, but I'm on the fence because I'm not writing blog posts anymore.
I'm on the fence of like, "Do I continue to write content there? Or do I go to a place like Dev2 where it has everything built in naturally? Or Medium, it's all built in, the same experience."
That sounds like that thing that everybody loves about Medium where you just hit the edit button, you write the content, it's there.
You're not another admin interface, you're writing the content live. Did you take a lot of cues from Medium, and other interfaces similar?
Scott: Yeah. Our saying "We have this in page mode," a lot of that inspiration came from Medium.
We had that initial frustration of "OK, writing long-form content in this little sidebar sucks."
So after exploring all options out there, we landed on Medium being the best experience. Have you used it, Brian?
Brian: Yeah, Medium, for sure.
Scott: The editing experience is wonderful.
So that's what we're boring from, now we're giving developers the ability to empower their teams with a Medium-like experience on their sites.
But it can be any site, right?
Brian: That's just part of reason why I'm using paper docs for my podcast notes, because the content is structured and it renders markdown as I'm writing it.
I'm used to writing markdown down all day, and then things like literally I'm looking at the TinaCMS link.
It unfurls and I can see a rich preview. Like, do you guys have rich previews as far as Tina goes?
Jordan: No, we don't. We do have a Wysiwyg markdown editor that will translate your markdown as you go, and something like that would be a user choice anyway.
That may not be what they want to see, and what we're trying to do is give them an exact preview of what it will look like when they publish it.
Brian: I'm curious, Tina is not a CMS, so we figured that out now.
If I were to think "I have a workflow, and I figured this out, and this is what I do," are there options yet to do plugins?
Jordan: Yeah. Tina is really just plugins.
It's all built around that notion, like last night I was doing-- I did a talk at a meet up in Orlando, and 15 minutes before the meetup I was like, "I should build a custom field for this so I can demo it."
I quickly whipped up a field that could pull in the meetup links from the meetup API, and then add those to your front matter so you can have a link on your blog.
Plugins are really just REACT components, or trying to appeal to developers who are already familiar with these things.
Brian: That sounds like a great move for getting plugins together.
Because if you're-- If Tina is obviously coming out of the gate with Gatsby and Next, you can make assumptions about the users and the developers that are going to be working on this, so I think starting with a small cohort of users and expanding from that makes a lot of sense.
I'm actually really excited to actually try this out. I've been thinking about how to approach my--
I have a blog, but I want to make that my site less focused on blogs because I'm not doing it anymore, but I'm writing tons of code.
I want to have an experience where I can create a portfolio site which has a blog component in the corner, but I can see my each one of my portfolio pieces and sites that I'm working on.
Being structured content, that could just be live editor designed.
I'm also really into design right now, I've been spending some time-- Which I'll get to in the picks, learning UI design.
Scott: Cool. I can't wait to hear that. And then, you're still set on keeping content in markdown in Git? Is that right?
Brian: I am on the fence of what I need to do to make it, because keeping stuff in Git in content and markdown was the structure that I come from, and it's the easiest for me to wrap my brain around.
But I'm also preparing myself to make a site that I'm not going to update every week.
So, I'm looking to make content that looks good in whatever limitations or non-limitations that I have to setup for myself to make that happen. I'm all ears for that.
Scott: I love it. Can't wait to see it.
Brian: Excellent. If you don't mind, I guess we'll transition ourselves to picks.
I really hope that people will try out Tina, it's awesome that it's open source and that it's working with Gatsby and Next.
I don't go an episode not mentioning Gatsby, and I'm all for having the next folks out here, so hopefully I'll reach out to them and have them on the podcast to talk about their product or project.
Scott: I was just going to say that, when we launched this a ton of people were asking us for Vue support, and it's something that we anticipated.
We just don't want to commit and set some these expectations. But you should expect to see a Vue version of this soon.
Brian: Excellent. I'm sure a lot of people are looking forward to that. Vue is a community that definitely has a lot of support behind it.
It'd be awesome to see that support come through. Excellent, so let's transition to picks. These are picks that we're jamming on.
Could be food related, movies, code related. I know we just talked about a lot about codes, so feel free to keep going or tell us about something else.
But if you don't mind, I'll go ahead and go first and set the pace for the picks. I just recently came back from two weeks in South America.
I had some time in Brazil and had some time in Colombia. I speak Spanish at a College level. I joked in the last episode where I do--
My language is basically survival, so I know enough to survive, but I don't know enough to get on stage and start speaking Spanish or talk about technical topics.
But I learned of a method, which is called Pimsleur Method. I don't know where the origin is from, but the person who told me about it came from the military.
And basically, you take these structured sentences pretty much in the vein of survival mode, like if you want to walk into a store and you want a coffee.
You could say, "Le gustaria cafe," or "Le gustaria mochila," or "Le gustaria boligrafo."
But anyway, I just used that method and I was pretty successful in Colombia, mainly because I already knew a lot of the words.
But when I went to Brazil and spoke Portuguese, which I knew none before I got there, I was able to accomplish most of what I needed to get done whenever I stepped outside the hotel.
Everything except finding my lost cell phone, all those words are really hard and I could not figure out how to find my cell phone in Portuguese, so I wiped it remotely.
Scott: It's funny, being from Canada I speak French like a lot of Canadians.
Then I did some traveling in Mexico, and the similarities between French and Spanish. There were a lot of similarities.
Unlike English and Spanish, I found what happened was I was trying to learn Spanish and I did a poor job of it, I learned a little bit.
I wasn't quite at survival level like you, but I would often just kick into French mode because my brain would just go to French.
Then my girlfriend at the time visited me and she just automatically snapped over to French when someone spoke Spanish to her.
Brian: Yeah, when I was in Brazil I'd go to Spanish first just to see what would happen and if people could understand me, and I'd say about 99% of the time no one knew what I was talking about.
The myth of the Portuguese and the Spanish language being similar is untrue.
Save your emails and your Twitter DMs, I'm just going to lay out facts and statements and then walk away.
My other pick really quickly, it was that I started getting into sketch.
I've always avoided design and I've recently just jumped in to-- I had a project, which is Open Sauce, and I've mentioned it quite a few times in this podcast.
I hit a wall of actually getting the project over the fence, mainly because I didn't have any body to design and I didn't know how to do it myself.
So while I was stranded in a hotel room trying to speak Portuguese, I was also learning how to do design.
I honestly, if you're a developer and you haven't really touched any design thing and you hit a wall, it's a couple of YouTube videos away from learning it.
So I got on the LearnUI.com which is a structured video series content by some designer, and I was successfully able to create some designs and I'm in the process of converting those to REACT components in storybook, which is super awesome.
So, try design out. That's my pick.
Scott: Yes, the sketch team are users of ours.
Brian: Yes, actually I saw that in the Mooseheads that they called that. Cool. Scott, do you want to go next?
Scott: Yes. Mine's a little less cool, but it's still a pick nonetheless.
I became a vegetarian-- I shouldn't say I became a vegetarian, I don't like putting myself in a box.
I eat a lot less meat and I've been doing this for about a year, but I like to cook a lot and so does my wife, and we have a little daughter too now so we do a lot of cooking at home.
We milk this blog for all its worth. It's funny , if you go to the bio it's this picture of this guy in France, but if you search online you can't find anything behind this person.
I think it's maybe the blog is written by an AI, or maybe it's a fake person in a different part of the world.
But the recipes are outstanding, and there is one that is a lemongrass soup with tofu in it that is a really good recipe.
If you want top notch vegetarian or vegan cuisine, I would go to FullofPlants.com.
Brian: Cool. I'm definitely going to check that out. I've got one vegan friend that I claim as a friend.
Scott: You could impress them.
Scott: You could really impress them with this.
Brian: All the other vegans I know are acquaintances.
Scott: You like to keep them like that?
Brian: Yeah. They come into my house, we're having bacon. Cool. Jordan, what's your pick?
Jordan: All my survival languages are programming languages, so I can survive in Python and I can survive in C and whatnot.
Brian: You can code yourself out of a box?
Jordan: Yeah. I don't know, I have no spoken survival languages, unfortunately. And I eat lots of meat.
So, mine's completely unrelated is what I'm getting at. I have a pretty big gaming collection, retro consoles and stuff like that.
I also have an eight year old who loves playing them.
This past winter, I decided I didn't have enough of a collection or it just wasn't quite complete so my son and I built a custom arcade cabinet with joysticks and buttons and all sorts of things.
It's powered by Raspberry Pi and it runs Retro Pie. Anyway, Kim found RetroPie and it's pretty incredible.
It's just one of those things where it's hard to believe that so many people put in so much time in making this free and open source, and it's so easy to use and so fun.
Brian: Yeah. That's awesome. I've actually played one of those two times in my life.
One was at code school back in the day, CodeSchool.io bought by Pluralsight, they had one in their office.
The other one was at GitHub. Actually, before I actually joined GitHub I was there for an event and they had a RetroPie downstairs and a full on cabinet, and they had--
One even went all out and had designs actually spray painted on the side with Octocats.
But when I joined GitHub, it wasn't there. I'm not really sure what happened to it.
So, if anybody at GitHub knows what happened to that, let me know.
I also have a small child and spend a lot of time doing retro gaming, which I think I mentioned from the podcast as well, but from my Mac with a Wii controller.
So I didn't actually build anything, I just bought a Wii controller.
Jordan: Yeah, I found some like rough plans of an arcade cabinet on Instructables or something like that.
Jordan: I have a really good friend who's a good artist. He painted it all up and we named it, and it turned out really awesome. My son loves showing it off to his friends.
Brian: Yeah. Coolest kid in the neighborhood.
Brian: That's awesome. That's what I've learned in fatherhood, is always try to make your kids as cool as possible by being cooler than them.
Jordan: Right. Because I'm sure that's the way your kids see it.
Brian: I'm just going to live by that. I just keep getting older and cooler, and he just keeps getting cooler and older as well.
So with that being said, I'll go ahead and end that there before I dig my hole even deeper.
Thanks for coming on and talking about TinaCMS, and touching a little bit about Forestry and the future of non-structured content on Gatsby and Next. I appreciate it.
Scott: Thanks, Brian.
Brian: And listeners, keep spreading the jam.