Taylor ⁓ good morning, Sean C Davis. How are you, buddy?
Sean Fantastic, what's up Taylor?
Taylor Not much, happy Thursday. This is episode five. It's kind of, it's crazy to think that we've already done five of these. I feel like we've covered a lot of ground and yet we haven't covered much ground at all. Maybe that speaks to the vast landscape of AI tooling and things like that that are out there. Okay.
Sean Agree. Yeah, and the ideas change every week too. They're always evolving, which is fascinating.
Taylor They really are. Okay, so this is Blood, Sweat, and Tokens, the podcast where we're talking about agentic workflows and product development and just kind of any random ⁓ interesting topic along those lines. We're building real products, ⁓ primarily products that use natural language ⁓ processing to help reduce friction for the end users. So Sean, what do you got on your mind today?
Sean Well, last week we had talked a little bit about the ⁓ tolerance for latency and delays in that. think the previous week we kind of came away from that. If we came away from episode three and we're like, people need previews in real time. And then as we kind of worked through that concept in episode four, we sort of walked that back in the sense that If you go back in history a bit, you know, like the way that agencies tend to work really effectively is they want to just get on the phone, call somebody, say, make this change happen, and then sign off on it before it goes live. And so there's just some expectation of delay in that particular case. And so what I played around with a lot this week is, ⁓ if we accept that as long as we are responsive and give feedback to the user and keep them informed essentially of the work that's being done that maybe the instant preview, which is a really, really, really hard problem to solve, isn't that important. And that's probably not always the case. I mean, I think people want, they want to see things as fast as they can, but it feels like we're hitting on this, we're leaning into the natural language portion of this solution and ⁓ so if you can communicate, I know we talked a lot about voice last week, I didn't really get anywhere with voice, but I think that's just an interesting part of it is like, well, if you can have a conversation and move something forward, you don't necessarily need to see the result right away, maybe, I don't know.
Taylor ⁓ Yeah, it's interesting that you say that. So for years, we've kind of noodled UIs in different ways to help give the user feedback. I think it's fairly commonly accepted that, and we can probably all appreciate this statement as users of the web, right? You go to do something, you click a button. If there is not some sort of tactile feedback for you, some sort of response, whether it's a progress bar or spinner, or maybe the button that you clicked goes disabled and becomes, you know, like ⁓ it says the word processing or submitting or something like that. That's the feedback loop, right? Those are extremely important and it's gotten really weird ⁓ in these day and age. So I was doing a little bit of research. before this episode and what I found, here's an interesting one from 1985 I think like 46 years ago there was a research paper by a group called CHI. They talked to 240 people. Oh, you know what? I'm sorry. I'm confused and stuff. This is actually the same group, the CHI, but this is in 2026. So they did a research study on AI this year. They interviewed 240 people in a controlled experiment. They gave the exact same response from the LLM to all the people, but they arbitrarily adjusted the amount of latency attached to those responses. So some people got immediate responses and some people got significantly longer responses.
Sean Hmm, okay.
Taylor Turns out that when it took longer to get your response back from the LLM, people attributed that to the LLM thinking harder and therefore regarded that with a more positive response, provided there was feedback on the screen, right? So it's kind of interesting. ⁓ Nine seconds apparently felt more useful to the participants of the study than two seconds. People literally thought the AI was thinking harder. That's pretty interesting, right? But then it's like a bell curve. When you got out to 20 seconds, people would get pissed off. Nine seconds. So if you can arbitrarily build nine seconds into a thinking process, apparently according to this study, you're gonna have more positive perception on behalf of users. So I thought that was interesting.
Sean Yeah. I totally buy that result too, because I'm thinking in different form. If I open up Claude and I get an answer too fast, I'm like, I'm not sure I thought enough about that response. And it could be that it was just already trained on the data necessary to give a proper response. But there have been cases where I've been like. I don't think you research that go back and research and then the second time it takes way longer for the response to come back because it actually does go try to look for more updated information. So that's that's interesting. Yeah, yeah, totally, totally. So yeah, this is psychology or psychological thing. That's interesting.
Taylor Maybe, maybe it's just fucking with you. Well, it's so interesting, And that study is fairly contrary to the commonly accepted knowledge, okay? So the research or the group, the CHI group did a study in 1985, so this is 46 years ago, that...
Sean 40, wait, wait, 41 years ago, right?
Taylor Thank you, 41. Man, math is hard. That's embarrassing.
Sean It is. Well, I was just maybe we're doing this podcast in the future and I was unaware.
Taylor Whoa, you just kind of blew my mind on that, bro. ⁓ Anyway, that research study indicated that, ⁓ you know, in terms of feedback loops, you give somebody 0.1 second of a response, it feels instant, but one second keeps you in the flow of whatever you're doing, whereas 10 seconds was... you ⁓ so long that you peaced out or whatever. And that was in the 80s. Like that was pre-internet days, right? That that research study concluded that. Amazon apparently at some point proved that... ⁓
Sean okay.
Taylor 100 milliseconds, so one tenth of a second, could be directly attributed to 1 % of the revenue, meaning that for every additional 100 milliseconds attached to response times, that actually costs them real world cash and a lot of it, like 1 % is not chump change when you're dealing with that scale, right? Yeah, yeah, yeah. Okay, so now when you think about multi-step.
Sean Yeah, I saw Walmart do something similar a handful of years ago too. Yeah.
Taylor agentic workflows, like what you're working on. So right now, the prototype you're working on, just to recap for any listeners who may not remember from prior episodes, we're building a natural language processor for a CMS. Basically, how can you replace the front end of a CMS literally with either a chat bubble or a sidebar widget that flies out and you just talk to it and say, hey, I want you to update the homepage with this headline. I want to remove that image, replace it with this one. That is a, what would you say, Sean, three, four, five step process from end to end, the moment that I say the words to the moment that I can see the changes on screen.
Sean Yes, ⁓ actually, actually, let me show you this, because we, don't know, I just did this like 15 minutes ago, but I'm gonna share because, let's see here. ⁓ I've been playing with the, you know Excalibraw? You know this tool? They have, the Excalibraw Pro has an MCP server. And so I was like,
Taylor Yeah, sure. Mmm.
Sean Hey, I gotta talk about this in a few minutes. ⁓ Why don't you draw me some things about what we changed and how this works today? And then I found a skill to help it and it actually did it, which is kind of, it's pretty decent. I tried it without the skill yesterday.
Taylor Hmm.
Sean and all the arrows were on top of each other, so it wasn't great. But whoops, I think this is kind of what you were getting back ⁓ at was like, what's the flow look like? And this is pretty much it, right?
Taylor Exactly. Yeah, yeah, yeah. Okay, that's great. So this is a visual ⁓ outlay of everything that needs to happen from that moment. I say the words to the moment that I see stuff, right? Or I guess the looks good, maybe what the fifth step in that process kind of represents the preview. ⁓ well, I'm sorry. ⁓ yeah, deploy. Sorry, I'm just kind of like reacting to this off the cuff. Okay, so if that is a four or five, six step process, And there's latency for each one of those steps, right? So like the amount of time it takes to take my verbal speech, turn that into actionable text, that is gonna cost you some time. Then sending that off to the agent, that's gonna cost some time. And then there's compounding factors such as network communication, like bandwidth issues, you know, if you got other stuff going on in your network, maybe that impacts the throughput. ⁓ Then what happens, Sean? So the agent,
Sean Mm-hmm.
Taylor The agent at this point needs to call some tools, right? Because that at some point has to translate from the inference of those words into actions taken against your website. So go update the database with this value or whatever. That doesn't actually, that's not really represented on your graph, is it?
Sean No, in fact, there's, so I was trying to think about that. Where are these latency points? So we do this, you make this request. So there's here, let me just do like a, what's it? Time timer? I don't know. Yeah, here, great, cool. Okay, so here's an ⁓ opportunity for latency right here. So you send the request and the agent, this is what had kind of changed this week, cause I thought, it would get us there quicker. Now, there's still quite a bit of latency because right now everything is wrapped up in a Claude subscription. What I really wanna do is switch over to something like OpenRouter where for the planning portion of it, you can just be like, yeah, I got this model that's super snappy. So it's really slow right now, cause it's overkill. And then we're missing a piece here, cause what happens within this bucket here is ⁓ the agent comes back and it's like, this is...
Taylor Mm-hmm.
Sean This is the plan and we can see this in action shortly, but here's the plan. Do you approve it? And so you can click yes, or you can type back in. this looks good. This is, this is a little bit off. This is more like there's a decision here, which is does the plan look good? And if the plan looks good, then we have a multi-step process where the agent's like, cool. Okay. I'm going to go update the content, which is pretty quick because it's just a simple API, a deterministic API call. that's already been decided what needs to happen. But then we need to rebuild the site with the new content. And that takes a little bit of time as well. So that's kind of like what's in here as the preview is building. And then we say, here's the link to the preview. Does that look good? And if you say yes, then we do the same thing. We publish the entries in the, or the records or whatever we call them in the content source. And then subsequently kick off the production build and then we've got that link to the production build. there's really, I think, three steps in this particular flow where the system itself has to do some work and the user has to wait.
Taylor That makes sense. So each one of those steps introduces latency to the total.
Sean Yep.
Taylor it's additive, meaning like if step one takes an exorbitantly long time, steps two and three are going to suffer as a result of that. Now, one thing that in somewhere, I don't know, I'll never be able to find it, but I read something about ⁓ the benefits of parallel ⁓ model route. Like the only way to reduce this down would be to figure out what could be spun off as a separate parallel process. And that once you do that, then you can take advantage of models that run faster than others. So the big models, the big, big models, they can run, they're fast, but if they have to do a lot of deep reasoning or something like that, or you have a really complex task, that's necessarily gonna take longer. But certain other... ⁓ processes like updating code, those can be done pretty quickly with much, much smaller models. So you're saving both on token cost, you're also saving on the speed at which that can be executed on a remote system. And so somewhere I read an article about how you can take advantage of this parallelism, right? Talk to me a little bit about your workflow today, Sean. So I know you're using some parallel agent tools to do some of your coding. Do you buy that? is that, how do you think about different models, different tasks, and how do you manage those ⁓ both throughout the course of your day, just doing research or other kind of administrative tasks versus strategic planning and execution on a code level?
Sean Yeah, that's great question, because I think for me it depends a lot on ⁓ what is the thing that we're actually doing in the moment. when it's code, I take this maybe back to writing programmatic unit tests. And when we were doing all of that work by hand, you had to consider, you know, it was just like a pain in the ass. You build out this giant Rails applications, right? We've worked on these projects before where you're like, I'm done, I'm ready to ship this code. I gotta run CI. So I gotta wait like 30 minutes before I can actually deploy the code. And so what you end up doing in these systems is you look for opportunities to parallelize tests that aren't gonna conflict with one another so that you've got individual workers, you shrink that time down. So I think it's a similar concept. ⁓ And I think what we run into, what I've run into is just the same, it's a similar hurdle as I hit in those Rails days, which is not everything can be parallelized. Some things need to step through. Like in this particular case, it's a very clear flow where I'm not gonna have an agent do work until the work has been planned. I'm not gonna deploy the site until the content has been updated. So it's kind of stuck being linear. And in my day-to-day work, think it's, ⁓ what I really like doing is making changes in ⁓ kind of isolated environments. And we'll see that when we get to demo here because that's reflected in how I've designed this so far, which is, I wanna have a conversation about this set of changes. Could be code, could be content. And then I can have another conversation in parallel. I can have as many as I want. The challenge is, developers, I think of that as, ⁓ okay, I'm opening several pull requests at the same time, which is something we've done constantly. And I think we're trained. to actively think about whether or not it makes sense to open up a new pull request or shove this in the existing pull request based on a number of factors, many of which are directly related to how much is it gonna suck to resolve conflicts if I introduce conflicts in the code. And so I think there's this thing that's maybe even down in my lizard brain at this point that's like, when I'm working with an agent, I'm still processing in that way, but I don't know that that's necessarily how everyone wants to work. So it's something I've had to consider in this prototype as well is like, well, what even it could be two humans or it could be one person, one human who's just like, here's a thread. I want to change this thing here. Here's a thread. I want to change this thing here. And they don't realize that under the hood, this is actually causing a conflict or this is overriding this. And I didn't mean for that to happen.
Taylor ⁓ my god, that sounds like a disaster.
Sean So I think there's, there's like, there's, it's just that I think back to your point, there's opportunities to reduce the latency, but you, you have to consider and to parallelize tasks, but you just have to consider the risk in doing that and whether the value of waiting or putting something in series is going to save you time in the long run.
Taylor Yeah, that's a good point. mean, one thing that I really struggled with at the beginning of the Jamstack era, you know, when we first implemented this, there was no reasonable preview solution available. And it's still to this day, previews are coupled to the framework that you're using, right? Or the tooling, but like at the end of the day, all the different kind of headless Netlify-esque style Jamstack front end delivery platforms. I know you guys are evolving way beyond that today, but like,
Sean No.
Taylor Most of those front end delivery platforms were always predicated on build the thing for production use and that's going to take a minute or two. Sometimes it can take upwards of 10 minutes or to your point 30 minutes or whatever. Problems the same, know. The downside is that, or at least in 2018 when we first started implementing these systems, there was no way to get that immediate feedback. It was brutal. So you'd make one change, have to run a build.
Sean Mm-hmm.
Taylor oh shit, it's wrong. So then you make another change after you run a build. And I mean, if it takes three minutes per build, your whole day could get wrapped up in noodling some extremely small content task. It's brutal. Like it was absolute, like I remember when I discovered Netlify, we started, you you and I were largely learning this stuff together and like kicking the tires and playing around with this ecosystem together.
Sean Yeah.
Taylor I remember at one point thinking like we've made a horrible choice. Like the concept of decoupled architecture for websites makes so much sense on every front except for this one thing, but the actual administration of this experience is just like a, it's like a kick in the teeth, man. It makes you want to commit seppuku. ⁓
Sean Mm-hmm. How are you solving it today now for your current clients?
Taylor Okay, so today, well, what I don't like about it is that it's still coupled to the tooling, right? So whether you're using Astro or Tanstack or Next.js or Gatsby or whatever, it's like slightly different or your implementation details are more coupled to like the frameworks way that it does server render.
Sean Mm-hmm.
Taylor or server-side rendering. So the common pattern we're following today is Next.js with some sort of API route that you can hit that will ultimately drop a cookie for your session and redirect you back to the SSR, or sorry, what is it, the ISR version of the page, right? Like it'll, I'm getting my terms confused. We'll render the page server-side. so that we can reflect all that stuff in real time. When we do a production build, that page gets rendered. statically where it can. So in the large vast majority of the clients that we work with, all the content is statically pre-rendered for build purposes, so that reduces latency for the end user. Ultimately, it gives us the opportunity to tree shake stuff and optimize performance. We can deploy it to a CDN. It's super portable. If you don't want to work with this provider anymore because their prices went up, you can move it somewhere else. I it's all fairly self-contained.
Sean Mm-hmm.
Taylor So the problem with that, obviously, if you're statically pre-rendering the stuff, then you can't make those real-time updates. So all we're doing is taking advantage of the server side faculties in these different frameworks to render those. And the strategy by which it works kind of depends on the CMS, how their preview tooling works, whether it's contentful, it's slightly different contentful than it is on...
Sean Right.
Taylor know, data or sanity or some of these others. And so you just kind of have to manipulate a very similar workflow depending upon the framework and the CMS that you're working with. Is that common practice? How are, I mean, you probably have more ⁓ visibility into how other people are doing this than I do.
Sean Well, yeah, I was wondering about the mechanism that gets you, so even if we stay in Next.js world, because it's a different pattern to server-side render than it is to statically render and hydrate. ⁓ So is that just like a, is that a conditional in the code just based on your environment, which one you're rendering?
Taylor Yeah, ⁓ I think we've implemented it several different ways. I don't have the code sitting right in front of me. I'm doing less and less code writing on a daily basis. So, 2BETARuto is not on the call. could probably give us some explanation with that. But yeah, it's my understanding, at least in some of the more rudimentary implementations, it's just a conditional where we're swapping out the rendering.
Sean You
Taylor It's kind of a question of how you aggregate the data at the top of the file, whether you're this method or that method is ultimately what it comes down to. And then we're just passing the payload down into the rendering engine so that it can render that particular page.
Sean Mm-hmm. Yeah, it's interesting because one thing we released at Netlify, not too long ago, maybe a few years ago, was much more control over the caching primitives. And so what might actually be simpler today,
Taylor Mm-hmm.
Sean it's gonna sound ridiculous, because now we're going back to the Rails days, but it's like always use server-side rendering. So you've got the same rendering pattern, but then you take control of, you just have to do the engineering to be like, okay, now what's the logic for caching? And I mean, to be honest, Netlify's primitives, I don't know how Versel and Cloudflare work in this regard. I know,
Taylor Yep. Yeah. Right.
Sean Vercell and Next.js are pretty tightly coupled because Next.js has a lot of, it has a whole caching API now in the newer version. But in Netlify, you can tie those, you can tie cache tags to ⁓ deploys. So it's way less complicated than, or I should say it's the other way around. It's a lot easier to invalidate, I think, than it was in the Rails. I just remember like untangling Rails caches was.
Taylor Yeah.
Sean those like fragmented Russian nesting doll caches. It was cool.
Taylor I actually, I love that. I thought that caching scheme was awesome because you could like target each layer of your cache independently. if you busted the cache on the smallest doll and the Russian nesting doll example, it would just automatically walk right back up the ladder and invalidate the cache all the way up to the most global outer layer. Which that in my brain, that actually makes a lot of sense, but.
Sean Yeah, yeah, It was cool. It was cool.
Taylor Yeah, I know it's interesting. okay, so to be clear, what you're suggesting is perhaps an easier model. Let's, using Next.js, you build everything server rendered, and then you just throw this caching primitive in front of that. And what are you doing? You're caching the entire output of the page. I guess what I don't understand with that model, ⁓ I guess you're caching any object that comes off of your endpoint, right? So like, the JavaScript, the underlying JavaScript files and all that stuff, you are literally caching the physical fingerprinted version of that file. And that's what can serve to the end user. Or are you caching relative to the path itself? Like slash about us, you're gonna take a snapshot of what that looks like and then that's what lives in cache. Sorry if I'm brutalizing this.
Sean Yeah, that's probably what you would do. And then you can have your, if you need those client side components, they can pull in data from API routes or whatever on the client.
Taylor Right. For what it's worth, I have used the Caching Primitive in a project we did recently for its construction company and it worked great. mean, was like totally saved my ass, kept the site online. It looks good. It worked really well. Okay, well, so I guess what we're saying is... Well, how about, why don't you show us the demo? Maybe you could walk us through that. Is that how you're doing it today? Are you using server rendering? you thinking, like your multi-step process kind of indicated to me that you're doing a full build after every change. Or, you know, when we started talking about parallel builds running concurrently, yeah, talk to me a little bit about the architecture for your demo that you've landed on.
Sean Yeah, yeah, so I think that the the challenge ⁓ that we have to solve in this problem or this project, I think that we touched on it just briefly either last episode or two episodes ago, which is that it's to build something that's going to work for multiple projects. You. ⁓ yes. What we got into last week was like you don't want to. We want to minimize the amount of work that a developer would need to do to be able to adopt the product, right? So, to be honest, didn't think too hard about the how are we ⁓ rendering the preview content and just took the classic long tail approach, because I think that's gonna have to be one.
Taylor Sure.
Sean ⁓ one particular approach, but yeah, I think I should definitely tinker with the server-side rendered approach. So I guess what we're looking at probably the most inefficient version of it where it's really like, we've got to build after every change. The other thing is I was trying to not get too far ahead of myself, but ⁓ it's not, I don't love the design where ⁓ you've got you're seeing, like the way that Contentful is designed is you have environments, but you're super limited on the environments that you can have. Whereas in Netlify, and I would think most cloud providers, that every atomic deploy is kind of its own self-encapsulating environment, right? And so it's really nice to be able to have those. And what I'd ultimately love to get to is,
Taylor Yeah.
Sean when any user opens a thread, they're not just opening a chat thread, but they're also kind of opening their own environment ⁓ that they can work in. And so you won't have these conflicts, or at least the conflict will be apparent before they go live. So it's a little bit more like that, ⁓ maybe a little bit more like the pull request model.
Taylor Hmm. Yeah, but how do you negotiate the conflicts? Like inevitably you're gonna, right? Okay, so imagine a situation you've got two people that wanna update the website. One person's in marketing, maybe the other person is like, and we'll say they're also in marketing, but they've got two different tasks, right? Maybe they're both building campaigns, so they're gonna build a new page and then they need to update the homepage with like a banner or maybe update the card and position number one to point at that campaign.
Sean Mm-hmm.
Taylor Person number one does that while person number two is working on their stuff. Now, are you constantly rebasing against master? Do you present the user back? I said that as if we were talking about code, but we're talking about actual data objects in a database somewhere. How do you negotiate? I can see from a user experience standpoint, you probably want to get that in front of the user and say, here you go, another way to solve this would be like, well, you can only have one session, one environment that you're working within running at a time. That doesn't feel great. What are your thoughts?
Sean Yeah. Yeah. Mm-hmm. I don't know. I don't know. It's such a hard problem to solve. What I've done here, we'll see. Let's try to recreate it and see if it actually works. But ⁓ it's more just flagging it, because it's such a simple prototype, where it's like if some other thread has introduced a change.
Taylor Ha ha ha ha, fair.
Sean since you introduced this, then it means that what you're seeing, well, I guess then it's flagging it, because you're all on the same preview branch. That's the thing that just doesn't work really well here is like, you have these individual threads, but preview is the same.
Taylor I get the sense that we keep butting up against these ⁓ primitive level constraints. You know what I mean? Like if you think about the way Nellify works, the model, like the way that you've conceptualized steps one through steps five were largely attached to the workflow that Nellify imposes on you. You run a build, you get a deploy preview, you review the deploy preview, then you merge it.
Sean Mm-hmm.
Taylor If you kind of took a step back, I think there's another constraint that I think we're struggling with too, which is this concept of like the underpinning data layer. I know that you started with the concept of like, okay, we have a contentful test project and I'm going to build something that lives on top of I could see an argument in defense of that system providing permissions or governance controls or just general feature set, that kind of stuff. But I do have a question. If we're coupling ourselves to the concept of primitives, and we'll use Netlify as the example because we're both familiar with it, they employ you. So there's that. ⁓ If you couple yourself to those primitives, why do we need Contentful? ⁓ You know, this kind of gets back to the original concept. If you're looking at a website, all the content is there. It's on the website, right? It's particularly for brochure sites. I'm not talking like dynamic web applications, right? But like my agency's website is just a whole bunch of HTML files, but what you see is what you get. there's not, we might have like PDF stored somewhere that you can't see immediately on the homepage, but whatever. The source of truth for that content is the website itself. Today, the way we think about CMSs is the source of truth is the CMS. But I posit that if you flipped it, do you still need a CMS? Meaning like if you could just say, hey, the source of truth is the website. And I understand where you're coming from, from like, well, I want to branch this version of the website so that you have a safe environment to experiment within. But I do think that like if we're... coupling ourselves to that very linear flow that imposes some restrictions on the way we might think about this. And then if you're trying to couple it to an out of the box product like Contentful or Datto or whatever, that imposes even more constraints on your ability to give the user that super quick inference. Sorry, super quick updates and response feedback loop for the user. So I guess the question I would ask is, Is there a world where your light layer of natural language processing can simply hit the database primitive alongside a server rendered page? So it's more like a traditional staging environment where update the headline, update this, update that, update that. I know I still haven't solved your like concurrent editing slash merge conflict resolution issue. But I do, I am curious like what your thoughts are on that, right? Like I love Netlify and all, and maybe it works on Netlify because you guys support server rendering and you've got some great primitives and the database primitive you just rolled out and the caching primitive. But I wonder if we're limiting ourselves by thinking about how this works within either that ecosystem or because it's the underpinnings is this headless CMS project.
Sean Yeah, it's a great call out. I know we were going to use this for the prototype, but that was always the risk was this. It's like, we've got, there's the three, it's kind of three angles. Because the other one that I think you talked about earlier was the actual framework itself. So there's the framework, there's the content source, and there's the platform that it gets deployed to and hosted on. ⁓ And in theory, we would have to be agnostic of all of those things, but that becomes, that's where a lot of that complexity is coming from, because as you mentioned, there's constraints there. The reason...
Taylor Yeah. And how did you deal with the framework agnosticism issue at Stackbit?
Sean We, ⁓ with some incredibly complex engineering, mean, was, what we ended up finding was that most of the, most of our paying customers or prospects were using Next.js. And so that kind of became our happy path. So we sort of designed a lot of our, content reload primitives and basic functionality around Next.js and then would wrap that with things like, you might call them adapters for, ⁓ you know, it'd be like, okay, well, I'm using Gatsby. We're like, okay, cool. So you got to do these three things and then it will work. So that sort of thing.
Taylor That sounds so risky. it's like a whole business built on the backbone of a framework that is, I mean, okay, I like Next. Next is great. It's a very powerful framework. I'm concerned about the relationship between Next and Vercell because it feels like a really brilliant way to corner the market and engender some vendor lock-in and a man.
Sean Yeah, I-
Taylor is extremely difficult to catch up with. Like how much time do you guys spend at Netlify keeping up with Vercell? Can you even say that? Sorry. That's probably not a fair question.
Sean Yeah, that's, yeah, it's changed, it's changed a lot. And I think there's a lot of collaboration happening now, but I think. ⁓
Taylor Well, okay, I mean more specifically though, like let me put a finer point on it. When the new version of Next.js rolls out and Vercell couples that with like this new announcement that we support this, this and this, you guys as competitors have to figure those, you're basically having to reverse engineer some of those things, right? And get those into your platform.
Sean Yes, yeah, yeah, yeah. we've worked out a better system with their, I don't know why the name's escaping me now, but we've started to pull these adapters to get, ⁓ it's called OpenNext. So it's kind of this initiative to standardize on the adapters. Because otherwise, yeah, it was just kind of the Wild West of who can build their adapter the fastest by reverse engineering it.
Taylor Yep.
Sean And so there's, mean, and there's the next side of thing. One of the nice things that has happened in the industry is that almost all the other popular frameworks are built on top of VEET. And so we, we have this VEET adapter, which kind of provides the very low level foundation. And then there might be like a little bit of code that we have to put on top of it to work with Astro or Tanstack.
Taylor That makes lot sense. where is, ⁓ what's the market share attached? Sorry, I know we're going off topic here, but what's the market share attached to Next.js today, do you know? Like, it used to be insane. It was like 75, 80 % or something of the market, if not more. ⁓ Understanding all these newer successors to Next.js.
Sean I don't know, no I'm not sure.
Taylor have this commonality that is VJS. I wonder where's VJS in terms of the total market share relative to all the websites online in this space.
Sean Yeah. And does it get counted because there's so many meta frameworks that wrap it that it might slide under the radar in some cases.
Taylor Huh, that's interesting, yeah. Anyway, sorry to get off topic, but ⁓ coming back to the question of where is your head now in terms of, you were gonna just thought experiment, if you were gonna delete your code and start a fresh project with the same direction and the same intention. Would you still follow the same path or would you kind of take a more of that fresher look at the server-side approach with a caching layer?
Sean Yeah, let's see. ⁓ so here's what I think I would do. Because I think, you know, there's that concept of the minimum viable product where you're like, just build the prototype as fast as you can, don't worry about abstractions. The more we're talking about this, the more we're like, okay, there's these three components. And quick sidebar is that one of the reasons we started with Contentful, was because we, one of the really, the first episodes we were like, we had this concern that clients would be less likely to adopt it if it also means a big CMS move. So we're like, okay, let's plug into what you've got now and do this migration. I think that the,
Taylor Uh-huh. Yep.
Sean The model, there's just no getting around this model of you have your engine and then you've got the three components that need their adapters to it. So you've got to figure out how you can support various rendering models. You got to figure out how to support multiple cloud providers and you've got to figure out how to support multiple. ⁓ data sources, even if one of those data sources is our own internal API, which in theory saves people, you know, hundreds of thousands of dollars a year. I think what I would do and, and, ⁓ this is ambitious, but maybe this is the next step is two parallel prototype paths so that the foundation has to be able to serve both. So pick two data sources, pick two frameworks. pick two cloud providers and build something that can serve both of them. And I think that will inevitably lead us to, okay, cool. So you need adapters probably for each one of these components. And then there's the core system. Is that how you would think about it too?
Taylor Mm-hmm. Yeah. Uh, I'm, I'm recalling a conversation that you and I had seven or eight years ago, which was an abstraction layer between these various. So, the entire ecosystem, I mean, it's still, what did we say last time? It's like a aims to be like a $70 billion industry and headless content management, you know, by 2033 or something. It's crazy.
Sean Yep, yep. Yeah, yeah, yeah.
Taylor But back in the day, know, we were, and it's so funny because if I get my time machine and I go back to that moment, you and I had this big debate about, we go with Datto or do we go with Contentful for this client? And I remember we read a white paper that was so prescient that I should have paid more attention, but it was basically... ⁓ criticizing Contemple's pricing model for exclusively focusing on the enterprise, for constantly rejiggering the prices and changing the entitlements to the accounts, and my goodness, it was so...
Sean Mm-hmm.
Taylor accurate. It is still to this day that you are playing that game and it has become so unpalatable, I will say, for me to make a recommendation based on that volatility. It is absurd. I get it. I'm the mid-market, not the enterprise market exclusively. So I think I'm just, you know. They're not as into me as I was into them, I guess. Anyway, so based on that, like all of that stuff, like we evaluated a million different frameworks and a million different CMSs. And I think you and I had this epiphany where we should build an intermediary layer that consumes content from these various services. Name your CMS, it doesn't matter. Pick one, pick a data source, could be anything.
Sean Hahaha
Taylor You write that to markdown files in a directory on each build, and then you consume those when you're running the build. So I think the project, was a Jekyll project we were working on, which don't add, we're not going to get into the reason why Jekyll was the, it was a bad idea. I still regret that one. ⁓ It was a Jekyll project, right? And it ended up getting so big that the builds,
Sean Yeah
Taylor you know, the consumption process alone, pulling all the data in from the CMS would take, you know, two or three minutes and then the build would take another 10 minutes because fricking Ruby. But anyway, at the end of the day, that model actually was kind of brilliant. was sort of cool, right? Because it was sort of this internal caching layer and I remember making the argument at the time like.
Sean Mm-hmm.
Taylor Okay, well what if the service provider goes down? You can't get in the CMS, but you gotta update the homepage. You have a whole bucket of markdown files sitting right in your deploy directory. You can just go make those adjustments manually or whatever. And at the end of the day, it served the purpose, it was great. And now you see frameworks following suit. So Astro has an entire content collection. ⁓ schema, right? Like there's a whole feature inside most of these newer frameworks that follow a similar pattern. know Hugo does the same thing. There's like, you know, basically these frameworks are all engendered with functionality to read markdown files from the file system in some sort of structured format that you can config either through the archetypes attached to the content or in the config file for the framework itself, whatever. So I mentioned all this to say, like, I don't know. I think that there's an argument you can make of like, listen, it's scary to come off of your CMS, but it's also exorbitantly expensive to pay for multiple systems, in which case one thing Contentful does really well is they've got a ton of features and functionality in their command line interfaces. Amazing. Like you can export your entire
Sean Mm-hmm, mm-hmm.
Taylor a space worth of content and assets to the file system with a stroke of a command. In which case, maybe the question would be like, well, do you export that? then, we get back to this concept of there's some sort of middle abstraction layer that understands the contentful content format and understands the way Datos API works or understands the way Sanity likes to structure its stuff. I recognize too that like I'm saying this and there's a lot of decisions that each developer makes when they're standing up these systems, right? That can have some bearing on the structure of the directories, the format of the front matter in your markdown files, you know, and that kind of stuff. So again, we're back to that same question of like, how do you engineer a system that is resilient to plug in to infinite number of frameworks, infinite number of content sources?
Sean Yes, yes. ⁓ That is a great question for me to take into this next week of building. I do want to, do you have a few more minutes to show you this demo? Cause I want one more perspective from you, which is ⁓ we talked about the, so we'll see a lot of this is like, ⁓ yeah, okay. We've talked about how this needs to change or whatever.
Taylor Yeah.
Sean I'm curious about the feeling of where the thing lives and in response to like how quick you see the content versus you're having this conversation, ⁓ you know, cause previously we were looking at this little widget inside the site, which is nice on one hand. ⁓ but if you're still waiting, is it actually better if you don't have full control over the UI? And I also. selfishly wanted a an experiment to build a native desktop app. So I was like, what would it look like to build a desktop app? And it was actually pretty cool and fun.
Taylor That's awesome. Okay, is there any way you can zoom in on this desktop app? Cause my old man eyes can barely see it. Hold on. I gotta make my screen bigger.
Sean No, no, I'm so sorry. Okay, here's what I'm gonna do. So I'm gonna put this app, which is just labeled BST. Yeah, I'm like, can I? I don't, oh wait, maybe. No wait, that's the other one. All right, does this one have a view? No. Okay, we're gonna, we got it.
Taylor ⁓ psych. It's all good. I'm full screen now. I can hang with the young buck.
Sean All right, so we're going to we're to do something like we're back to our to be fair, it's small for me, too. I tried to I tried to hit this earlier and I was like, I did not build that into it. I thought that came for free. It doesn't.
Taylor It's weird, there's been this like, kind of ⁓ convergence of problems in technology, like the screens are getting bigger, but the resolution's getting better, so the pixel size gets smaller. It's just like, goodness gracious. Anyway, go ahead please.
Sean Yep. Yep. Uh, what do I get? I don't know if I thought, oh, it's cause we've, we've been here for an hour. So I'm like, I'm not on, do not disturb already. Uh, I'm, I'm back on disturb me. Um, okay. So I'm going to say we're going to do multiple things, which I think we may be, we tried last time. We're going to be like, uh, here's, me an image image coffee shop, a better shop.
Taylor man.
Sean Okay, so that's, it's kind of uploading in the background right now, which is cool. It's uploaded. So we say, so change the hero image. Oh my God. I'm so sorry.
Taylor It's done it turned green No, Sean, you need to use whisper flow for this.
Sean Okay, all right, here we go.
Taylor It's the best. It is the best.
Sean All right, change the hero image to the attached image, change the headline to say shop our spring sale and left align all of the text in the hero.
Taylor Hmm. It's gonna look terrible.
Sean All right, so we're gonna save this. So now what we do is we kind of create this thread. And again, we've got this issue with the way things are coupled in a goofy way. So that'll be an interesting thing to dig into. here, this is what I kept going back and forth over the last few days was like, okay, at first we had this screen and it just sat there and I was like, I can't see anything happening. so, this is, I wonder if I...
Taylor Yeah, it's been nine seconds. I'm starting to get annoyed.
Sean God.
Taylor Well, it's interesting, right? Because I can see it's doing stuff. Yeah, there we go. But I think this is where the more desktop-y kind of frontier commercial models, they're giving you that token response. Like, you can see kind of the thought process. I mean, it really does make a big difference.
Sean Yeah, kind of see if we can stream that in. think that would be huge. And so what this does is it then it summarizes what we're talking about, quick title and summary. And then before it does anything in Contentful. it tells you what it's going to do. So it says, I'm going to replace the homepage here with this attached image. I'm going to change the heading. And then this, thought was pretty cool. It calls out the code change and it says, ⁓ basically we can't do this, but you can copy a message that you could then send to the developer, to your agent or whatever that might be. And ⁓ then kind of summarizes what that impact is going to be. But I can say, Whoops, I forgot, I also want you to update the button to say shop now. and we're gonna build that plan again. And so I almost did. Bad UI design here. Who's designing this UI? I actually, I've never used this. Have you ever played with, what's it called, Tauri? T-A-U-R-I. So that's the framework for the desktop application. And part of the argument,
Taylor Mmm. You almost approved. You almost clicked the approve and deploy button. ⁓ No, what is this? I'm gonna write it down. ⁓
Sean I did a bunch of research and I was like, is it React Native? it Electron is another popular one? And this was because it was, it was pretty, apparently pretty easy to port over to mobile, which I'm not gonna mess with yet, but ⁓ that's appealing to me. And I'm working on a second desktop application and it looks identical to this. So I'm like, okay, this must be the default design. So we'll do some UI work here this week. Okay, so this time it gave me the same things and then it's like, okay, here's your button. So we're gonna approve this. And this is when we hit our ⁓ series. So we see, I don't know if you saw it happen real quick, but the flash over here. So that's ⁓ Contentful Updating. then, yeah, and this is goofy because it thinks there's a conflict. I wanted it to flag the conflict, but actually the reason it's showing that is because it...
Taylor Yeah, but you had already touched it. Yeah, so what it is is there's a versioning system in Contentful's API and you need to update the marker to point to the latest version after it had changed on your last update.
Sean It basically made three edits. Yeah. Yes, and so that's what this is doing today because it's looking for did some other thread update the content, but it's all it's all within the same thread.
Taylor you Hmm. No, I mean, it's kind of interesting because what you really did was you sort of engineered that exact scenario that we talked about earlier about conflict resolution and how do you negotiate this in real time, right? Because effectively you just bumped into a conflict. mean, it's, you know, not as straightforward as what we had said before, but anyway. The UI notified me two entries were modified outside this request. So that's good.
Sean Mm-hmm. Mm-hmm. Okay, this. All right, and then deploy says it's ready. Let's check it out. It is. Cool. No, ⁓ because that's over here. And that's what it's trying to flag. Yes, exactly, exactly. And so then we can publish. And that's going to kick off our production build over here. Yeah.
Taylor Hey, it's not left alone though. ⁓ ⁓ you need the engineer to do it for you? Here's a question. You know, we spend a lot of time talking about different frameworks and gradations of service provider and all that stuff. What if the framework was the CMS? Well, what if the CMS just was the front, like it's the VJS superset that literally. I don't know, like you get all the same bells and whistles and benefits, but the framework has the built in, you know, connections that give you the opportunity to make updates verbally. That's a super oversimplification, but are you following me?
Sean Not, not totally, no.
Taylor Let me kind of, let me simmer on that one and see if I can formalize that and we'll come back next week and I'll talk about kind of where my head is on that. But the point being is that like instead of integrations, it's just an opinionated output, but it gives you the same, gives you all the same tools and primitives to work with that you would have today. You know what I mean?
Sean Yeah, okay. Mmm. Yep, Okay, yeah, that's it. Maybe that's topic for next time.
Taylor Like what if it's an Astro plugin or something? And all it does is, you know, there's some predicates. Like it must be a server rendered version of an application. You know, you need to have this database layer attached to it, or maybe it's the content collections. All you're doing is you're writing to content collections on the file system. I don't know. I'll have to think through that a little bit, but.
Sean Mm-hmm.
Taylor I've been really impressed. What do they call them in Astra? They're called integrations. You can build a custom integration to basically manipulate different lifecycle hooks in the framework. It is, sorry, okay. Anyway, I'm gonna have to keep noodling that in my brain.
Sean Yep. Yep. Yeah, that's interesting. Cause we just, basically go back to what's the, the communication surface. And I think that's a big part of my question here is does it make sense to be this self-contained application? Does it make sense to plug in on the client where you would, where the site is running or hook in to the platform where it's deployed or hook into the framework that's that's running and it's like, mean, none of those are wrong. It's just kind of probably got to pick one to start with, right?
Taylor Yeah. Yeah, yeah, it's true. I can see why the more opinionated approach would be limiting in a lot of ways. Probably not something you necessarily want to do, but I don't know. It's interesting thought experiment. Okay, Sean, this is awesome. Thanks for the demo. That's exciting. I feel like we've got a lot of fun stuff to kind of simmer on and reflect on next week.
Sean for sure.
Taylor Anything else before we bounce? know we're a little bit over time today.
Sean No, no, I really enjoyed this one and I love this format because I feel like ⁓ every week I come away with like, ⁓ yes, now we're getting closer. We're getting closer to something that I think is really solving this problem.
Taylor Yeah, making sausage is a messy business, but it sure does taste good when you're All right, man. Well, thank you so much. Okay, so this has been episode five of Blood, Sweat & Tokens. Really appreciate everybody's time. We'll look forward to seeing you next week where we're gonna unpack maybe the next step. Maybe next time we'll talk about the ⁓ different models that exist and how we might be able to better direct traffic.
Sean This is true.
Taylor basically build more awareness into some of that user feedback loop and stuff that we talked about today. Thanks, Sean. Hope you have a great week.
Sean All right, you too, see y'all.