JAMstack, Netlify CMS, and 10x-ing Smashing Magazine with Matt Biilman and Chris Bach


I think also part of the story is that – Matt’s background, he was the CTO of the largest agency in Spain, that made more than 100 websites a week, so on a very large scale, and I came from an agency background as well… And what we saw was that the APIs - obviously, they can be anything and everything, right? So all these microservices can be job boards, and could be – they could really be so many things, but there are some things that are much more standard than others. Content management, comments, subscription, commerce, and of course authentication, and form handling.

[00:36:18.28] Those are sort of the ones that you would see again and again and again, so it made sense for us to say, “Okay, we’re going to put some effort into contributing something to this space…” As far as open source APIs goes, those should be it. So you have like a basic toolkit that you can run with, and of course, do anything you want with.

The whole point here is staying agnostic, saying you can use two of them and then do your own thing for the rest, or whatever. That’s the beautiful thing about decoupling the frontend and the backend - you get to mix and match. And since you don’t have to run the code together, it’s not like if you chose a traditional legacy system, you choose for example PHP, and that’s just the end of it.

When I was in agencies, there was a CMO or someone that said, “Okay, we wanna use Wordpress, because that’s what we’re used to updating.” That’s a lot of good reason for choosing it besides that as well, but the point is just that no matter what, I had to go back to ten developers and say “Okay, now we’re coding in PHP”, because that’s just the name of it, right? Whereas now you can say “Well, let’s look at the resources we have, and what’s interesting to us, and what will bring joy. Should it be made in React, or Go, or .NET, or PHP?” or whatever, because the build tools now are executed differently and we don’t have to run them anymore together on the site, so you can have both.

So I think the darling for us here was really the content management, because as I mentioned earlier, there are some fantastic services out there… They’re all proprietary. If they are open source, they’re sort of more with a smaller scope, and then most of them are API-based. And for us, all of this is about enhancing that Git workflow. So everything we do, whether it’s open source or it’s part of the business, we always measure ourselves with “How does that play into the Git workflow for a developer?” and I think that the CMS – Matt was the one who saw the opportunity of saying “Okay, what if we did a Git-based CMS? What if this was actually just like a single-page app that was built all agnostic, would work with any site generator, but then just worked with consistent layers of data in Git?” because then it’s a 1-to-1, right? It’s not something you make work with Git, but it’s just part of that workflow.

And then on the other side if you can get a local dynamic real-time preview of everything you do so you feel completely at ease, but every time that you click Save you’re actually running a branch deploy preview. And every time you say, “Okay, that looks fine”, you use rich text editors, it looks completely like anything would for a content editor that isn’t a developer, and whatever they’re used to from a legacy point of view, but when they click Publish, then it just merges into Master behind it.

So far you had to choose, right? CMS, obviously - we can all agree; that’s a no-brainer - is not for developers. The developers would rather just write the code; the CMS is an extension of the code that really just enables content developer writers, right? And so far you really had to choose who you are catering to, right? And we thought that maybe (just maybe) you can have that where you can get both, where you can have a developer workflow that isn’t compromised; you stay in Git, this is your workflow, this is how you do things, this is how everything fits in, and this is how you collaborate with everyone else, but you also cater to the end users as far as content editors go.

I think that’s the really important thing here. We’re getting a lot of contributors already that are taking this and running with it for their own use cases, which was exactly what we were hoping for.