Should I build my website in markdown?

Hey folks, how's it going? So this is a bit of an interesting one today. Markdown. Should you build your website in markdown? It's kind of interesting because I've heard murmurings in the whole kind of tech industry about people starting to go this way. And we've actually had personal close experiences with it ourselves, which I thought was very interesting because, believe it or not, we've actually had experience on both sides of the fence. So you might be thinking, you know, Sanity, Next.js, that's what you do all day, day in day out. And you're probably just going to say that Sanity is the best way to do all of this. And truthfully, not really, and kind of really, just to give you kind of an early spoiler for the video. But people might not know that we've actually done something to basically build a knockoff Cursor just to see how markdown works, or more specifically MDX works, for building websites. Because, you know, it's a time where everybody's going for agentic websites and agentic this that and the other, and I thought it would be kind of interesting to talk about the realities of these things, as well as kind of reference something that went off between Cursor and Sanity. And I think they both have relevance and I think they both have content that you should take into account before you even start building something, thinking of the long-term aspect of a website rather than just thinking, okay, we're going to build a traditional website, it's going to get launched and then we're probably going to put a blog up once every couple of weeks and then that's it. The entire kind of ecosystem is in a strange position right now and it's kind of wild westy. But we have had experience of everything that's involved in this, so I thought we'd just tell you from a pretty off-the-cuff way. So first of all, let's start with a traditional headless content management system. Who do you think we're going to talk about today? Now we actually haven't just had experience with Sanity. We've had experience with Contentful. We've had experience with Storyblok. Unfortunately, we've even had experience with Strappy and Prismic, which has been a blast, let me tell you. But all of these different systems all kind of have very similar ways of working, and kind of like very similar software stacks or not software, but like stacks of what they do, which is usually something like a media browser combined with some way of being able to build models for a website, so kind of a traditional page builder if you think of that. And all of these things combined basically create a headless content management system. Now, it's kind of cool that we're able to just talk about that side of things, but the other side of this is markdown, or more specifically MDX. And if you don't know what MDX is, it's basically markdown with the ability to put components inside of it. And you might be asking, why do we put components inside of markdown? Why do we even care? It's because if you have components inside of it, it means that you're able to build a traditional page builder blog like you see here. So, you know, there's a hero here, there's a logo pond, some people call these things or social proof or whatever, there's a left text, right image, left image, right text, and a whole bunch of buttons and all this kind of functionality that exists inside of there. Each one of those would be built inside of kind of React in a component. I'm saying React, but more than likely we'll talk Next.js in this video. But this can create these whole brand new page builder blocks. Now, this is where the paradigm shifts. Now, if you're using something like Sanity, you get a very, very easy to use drag and drop builder. If we're using something called Presentation, or you get kind of like the old school way of creating pages using something called Structure. Structure kind of works a bit like an Excel spreadsheet where you just kind of drop things on the page and you write inside of inputs, kind of like a HubSpot form if that makes sense. And that gets translated to a real world website. Kind of cool. However, and this is where the difference starts. When you are building a website with markdown, chances are the vast majority of your time you're interacting with building pages on the website is inside of kind of like a ChatGPT prompt window, you know, like the little thing where it says, "Go talk to me today" or whatever it is. You've seen it. It's on every single website now. Basically, it's talking to your website in that way to create things. And this fundamentally changes the way it works because if I make changes on here, the changes go to Sanity's content lake. And that content lake is what provides the whole website with the data. And then you're obviously offsetting that to a third party vendor, which has a lot of benefits, also a lot of negatives depending on which way you look at it. And then in comparison with markdown, you are basically putting everything inside of GitHub. Or, and this is the point that I want to kind of focus on quite heavily, you have a little bit of a problem now, which is that you have media inside of this. And if you ever use GitHub, you'll know it's a bad thing to basically save these images inside of GitHub, which takes you on to the second point, which is then, okay, what happens when you need to move away from a traditional headless content management system and now you need to start saving images? So I believe it's Vercel Blob, from last time I checked, that the Cursor team is using. I'm not sure whether it's said about on here. They're mostly talking about removing complexity, which is like user management. So they're handling all of this again through the actual GitHub side now. And so that's quite cool and that seems like a logical next step. And I think it is very cool, but you're basically kind of shifting from one third party to another third party because effectively, if you say need to save images, the most simple way of doing it is through something like Vercel Blob. But the problem here now, if you are going to go down this route, is that you need to be able to upload those images. Now, how do you do it? Now, I can't remember if this is fiction or whether I've actually seen this. This is it. Yeah. So this section here, they talk a little bit about asset management. Now, they've built their own asset manager, which I think is built on top of Vercel Blobs, last time I looked at it, into their website. Now, depending on how you look at this (and this is my bias coming through here), I absolutely hate rolling your own for most things. The reason why is that as soon as you start rolling your own, you have to manage those things, and if they break it becomes a nightmare. Especially if it's something as kind of fundamental to a website as a media browser. That being said, you know, the Cursor team is very talented tech team, so I suspect they may be able to build a media browser that never breaks and is totally fine. However, there's a lot of complications with that and it's very, very easy to break them. And then there's the other problem here. Obviously, there is one great thing here, which is they're going to talk very quickly about the cost of this because it is a lot cheaper to potentially do it this way. But the big thing here is you have to take into account that Cursor's team is obviously going to be using Cursor a lot. I think they even said themselves pretty much every member of the team uses Cursor, which I actually think will become increasingly normalized: an AI agent working for every member of the team. I don't believe that's going to be something like Microsoft Copilot. I don't think it's ever going to expand that functionality out into every single crevice and cranny on like your website and being able to use all these different interconnected tooling. But I do think something like Claude or like ChatGPT is going to sit as a middleman between all of these different systems. But right now, that's a very, very different kind of thing. So, for example, in most companies you probably can just create a page, and again, this is where if we go back to the Sanity version, you can already use Sanity with an MCP. So you are effectively doing the same thing just with one less service in place. But you can build page builders this way. So you would say, okay, can you build me a homepage for the sanity.rostudio.com website? Um, you also now have to kind of onboard marketing folks into the concept of, oh, by the way, you need to understand how context works, which is not the easiest thing to understand if you, you know, you haven't been adjacent to development all these years. But essentially now, the whole model changes in the way that it works because we're saying, okay, everybody's a developer. So this is where you can see this gets kind of complicated, because we're only up to the point of where we're saying, okay, let's just put a couple of images on the website. But I think it's a very interesting point, and you can see here one of the biggest things as well was performance. That you can see on this, and I think this is kind of interesting because people are going to push harder and harder for performance with their websites because naturally, you know, there's far more focus on providing content (I don't want to talk about SEO, we're not going to talk about that today) to kind of like LLMs to be able to get information about your website. So if you go, what's the best Sanity CMS agency, hopefully we show up, right? But that is something that people focus on. And again, this is really important that you kind of understand all of these things, the benefits and drawbacks in it. I'm going to let you in on the spoiler that I talked about at the start: neither option is without its faults or without its problems. And the very system that you use inherently is going to make a massive impact on your business. Now, me personally, I actually really do like the markdown way of doing things, the MDX system. However, 99% of teams, I would probably say this. Well, I say, okay, here's the caveat, right? 99% of teams at this moment do not understand the trade-off to build it this way. And I don't think the team is going to be able to edit and continue to build it. However, I think if that team is willing to skill up and spend the next three to six months pretty much teaching every single member of the team, no matter, you know, like age, ability, previous experience adjacent to developers, if they're willing to take that time to spend that time to try and focus people around these things, maybe it might be worth the payoff. If you're a team like Cursor, it's absolutely worth the payoff, right? If you're a team that's very, very close to the metal when it comes to development, when it comes to AI, yeah, it seems great. However, on the other hand, if you have a lot of marketers on your team and the marketers are willing to start actually taking baby steps towards using AI in separate flows, so like are able to use AI and start moving into AI with MCPs. Sanity's got an MCP. Why not just use that for now and see how they get on with that? And if anybody has done this, and we have done this ourselves, if you start looking at how these output content, you really have to do a lot of personalization of creating a full AI harness for yourself to be able to generate the content that you actually want with the voice that you want. And if I said harness and your eyes just glazed over, a harness is effectively just the way that you use AI to do what you want to do: your personalization, your opinionation of that particular AI and all the systems that you use around it. And that is extremely important in building these things. If you are particularly interested in that, we actually use it quite a lot internally and I'd be more than happy to do a video of that in its own right. But I would say, you know, consider all these different trade-offs: the media browsers, the focus on forcing people to actually use almost religiously an AI tool, the way that you actually make changes on a page. So gone are the days where you can go into, for example, Sanity and you can click and you can highlight it and change it manually like you would do a Word document. That's going to change quite crazy in comparison. All of these things are the trade-off, but the thing that you get out of this is a more agentic ready website if you are willing to take the compromise. And by agentic, I'm talking like a bare bones setup. The easiest way to describe it is that you have Sanity, which is kind of like a Swiss Army knife or like a modern car, like a brand new electric car. So like a Tesla, let's say a Tesla for the sake of this. Tesla has all these different functionalities, right? You can reverse it. It's pretty hard to slam the Tesla into a wall because it's got all different bells and whistles being able to do that. And compare that kind of fully integrated, fully end-to-end solution versus, you know, like one of these kit cars that somebody builds in their garage. It probably, well, probably in a straight line will out-accelerate a Tesla. Okay, let's not think too much into the analogy. But it probably, let's say for the sake of this, would out-accelerate it. However, as soon as you start reversing that thing, it might not even have a reverse gear. It might not have, of course, it's not going to have any electric sensors and it's not going to do all this fancy stuff. But it does this one thing very, very well, which is kind of like a more refined, restricted, or a stripped-away driving experience, in the same way it is with a markdown website with AI with Next.js. I hope this is a kind of a nice primer, like an intro to all of this, and we're more than happy to kind of talk more in depth about each of these individual aspects. And if you liked it, feel free to, you know, hit the like, hit the subscribe, whatever at the bottom, because I would absolutely love to talk more in depth about this sort of stuff. But yeah, good primer. Have a great day. Take care. Bye-bye.