The difference between a code-based and GUI-based CMS

Hey, how's it going everybody? So I want to show you something real quick. The difference between GUI based CMSs and code-based CMSs. Now everybody has different opinions on this, but I'm going to give you my opinion. I think this is the right opinion and we'll go through it very quickly. So essentially the two differences between them, and I'm going to show you two different examples. This is Dato CMS. This is their default marketing template and this is our Turbo template. They're very, very similar, but they're like the best-in-class, or at least we like to think they're the best-in-class between Dato and Sanity. Now Dato is a GUI based CMS. And what do we mean by GUI based? Well, let me show you. It means when you start building schema and when you start building your content models, which is what you enter your data into, you have to drag and drop them. So for example, I can throw a piece of text in here. I can say it's a single line string, a multiple paragraph text, or some structured text, right? They all have their own proprietary way of doing it. So this applies to almost every headless content management system. This applies to Dato. This applies to Contentful. This applies to Prismic. Prismic has a weird one. They're kind of halfway between the two, but we'll ignore Prismic. All of these have some form of kind of like data structure where you can pull drag and drop items inside of them, apart from Sanity. The other exception on this is Payload as well. Payload is also code-based, because they basically just copied Sanity's homework. Anyway, going through the fields here. So you have your text, your modular content, your media. All of these are unique for every single system. And when you click them, you can drag them in. You can press single line string and I'm going to say, "Oh, this is the title of the page." Okay. Now some of them will have localization on, some of them won't. There will be different validation. So you can see the validation here, and this is a very important one because we're going to come back to this in a second. But validation is essentially the way that you actually validate the field. And it might sound simple, you know, "Okay, it might be nice and easy," but what happens if you, for example, need to match a specific pattern? And some of these do support it. Some of them say, you know, URL or email, custom format, and this is where it starts usually going to regex. If you don't know what regex is, it's a really, really complicated way of saying, "Oh, by the way, the third letter has to be a capital or something like that," or we can only do regular text and dashes. So this is kind of useful, but the problem here is, and this is what we always recommend, the same thing is GUI based stops at a certain point with validation. It also stops at a certain point when you need to do something custom. So as you can imagine, their GUI is presented on their website, but as soon as you want to start doing things like, "Oh, by the way, can I integrate our custom component that we use on the website?" Or, "Can I create a brand new SEO validator that sits inside of here?" Or, "Can I make sure that if this website has Wikipedia, we don't reference it because we shouldn't be using Wikipedia pages to reference to?" Um, that's not possible with these validations usually inside of a GUI based CMS. Compare this to, um, this is the Sanity version. You should always remember this. Um, this version has obviously a visual way that you can edit the page. You know, you can click on things, you can drag and drop, you can do all this kind of stuff. Nice and simple. So same fields, everything the exact same. However, there's a lot of custom stuff that you may want to do inside of here that Sanity allows you to do because it's code-based. Now that's not the only benefit. There is some negatives as well, but the benefits are that you can also build custom things inside of it. So if you look here, this is the blog page on our Turbo Studio website. You can see we have things like create OG image field, image preview field. The reason why we use that is because I don't want to have to create a brand new image every time I push things to Sanity. I just use the OG image field that we've built to generate a very purposefully built image with all the text and all the data and a generated cat on there. So it means that every single time we publish something to Sanity, we're doing it in a fraction of the time. And the idea, you'll hear this again and again, but the reason why we love code-based CMSs is because you get this progressively better and better and better kind of gains in publishing and what's the word that they use? They use content velocity. That's the word that we're looking for. So they use this expression of content velocity. The more you can do that, the less time you have to burn through marketers and things like that. And again, the same principle here. So there's a lot of reusability and a lot of things that you would do in JavaScript. So this all sounds very positive. Why doesn't everybody just use code-based CMSs, right? Well, there is kind of this is the negative bit. It's harder to build them. And anything that has a skill floor that's a lot higher, people go, "Oh I don't want to learn that." So it is more difficult. Now Sanity does have an entire learn section, but it's still quite a difficult tool to learn if you're not used to kind of like the paradigms of how a headless content management system works. So what I would say is our personal preference is always a code-based CMS, but it is very important to know the differences here, which is that if you have a GUI based, there are going to be more agencies that can work with a GUI based CMS or a GUI based content modeling system. But it ultimately will be worse when you get to the point of "I can't do this anymore" or "I can't do this particular functionality because it's limited by the CMS itself," whereas something like Sanity, and by proxy I think Payload is similar, you will get to the point where it doesn't matter how complicated it is, it can be built. It's just a case of time and money that needs to be used to be able to build the thing. And so you can see this here, nice and simple, but if you can read this and it reads kind of like traditional JSON, then you can basically build anything. And there is some really clever stuff that's in here. So there is things like AI automation in here because we don't actually want to write our FAQ questions every single time when we build a blog. We would much rather just take the entire content of the blog and generate the FAQs. But the best thing to do if you were trying to weigh up the difference between what is a GUI based CMS versus a code-based CMS is just run the default templates from both, so from Sanity and from Dato and from any other tool that you're looking to potentially use, and see how they feel, and whichever one feels the best, go for that one. It's as simple as that. But the other side of this is think also about how you're going to scale your website because if you want to be able to scale something that's like 10,000 pages with a lot of nuances, you probably won't be able to do it as well with a GUI based CMS. I don't know anybody or I haven't seen too much talk about people coining the terms GUI based CMS and code-based CMS, and I don't see it thrown around a lot, but it's actually the core thing that changes how you build your website. So pay attention to it, and if you have any questions just send us a message over. Cheers. Take care. Bye.