Sean: Hi, and welcome to Pod Rocket. I'm Sean, and joining us today is Tim Binniks, principal developer advocate at Uniform, Next JS Ambassador, Mock Alliance Ambassador and Cloudinary NDE. He joins us to discuss his recent talk at Jamstack conf, the modern digital pipeline. The future of Jamstack is composable. Welcome to the podcast, Tim. Tim Binniks: Thank you, and what a fancy intro. I feel special. It's awesome. Sean: Yes, certainly a lot of titles there, and before we get into the talk, do you mind telling us a little bit about your background and how you got into development? Tim Binniks: Sure. So I'm originally born and raised in Amsterdam, and now I live in France in the countryside. We are one of these people that decided to go away from the city into nature and work from home, and it's relatively recent, and we are very happy with that, and so if my accent sounds strange, that's where it comes from, because I work in English, but I live in French, but my native language is Dutch, so there you go. So back in the day, I liked playing video games, and then it turns out I liked hacking the video games more than playing them, making configuration files and things like that, and back in that time, this is beginning two thousands, and I'm dating myself here, but it was quite open back then, and somehow I realized I could also make websites. A friend of mine showed me something in Flash. I think that was just kind of the hype, and it was amazing that you can actually do things like that, and slowly but surely, I just kept doing very bad at development, and next to school, kind of thing, and at one point, I did it well enough to pay for my university, and... Well, not all the years, my parents helped a bit, but that was cool, because my university was actually to become a nurse, which is a very different approach to being creative and doing technology stuff, but in the Netherlands at that time, things changed so much. They privatized a lot of the healthcare, and we were in the midst of that complete paradigm shift, and it was terrible. My whole year of university, I think maybe two people now are still a nurse. The rest is, everybody's out. So I figured, "I learned this thing about web development. Why not try?", and there you go, and I've actually spent all my career at at agencies, consultancies, building websites for customers as a developer. Moving from a junior to, a few years ago, leading the global effort of a pretty big consultancy. I was the front end lead for 48 offices, which is kind of ridiculous, was way too big. Lots of politics, and so at the end, I got an offer to work at a startup that plays in the same space as the customers I used to work with, these really big enterprisey people, but then super modern, all about the Jamstack, all the stuff we might talk about today, and so that's how I ended up with a startup being a DevRel, with a background of being a proper developer, doing politics on the CTO level or CEO level. So I'm coming at this as a totally different approach, but it seems to be working. After a while now, I'm starting to get like, "Hey, this is something I like." Sean: Yeah, that's really interesting, because I imagine that you have those insights to the problems that those enterprises face, and now you actually have the tools that maybe you wish you had to solve them back at the agencies. So I imagine it's a breath of fresh air for you. Tim Binniks: Oh, it's so different. We are a very flat organization. There's not that much politics going on. We actually built for customers that want to work with us rather than customers that think we're expensive, and we kind of have to work around it to get to what they want. It's a different approach, and you know what's interesting? The things I learned at the agency to speak to these high level people that have to say yes and buy something, actually being a nurse has helped me most there, because you learn to speak to patients and to doctors. Give them bad news. How do you give somebody bad news? Well, you better have good posture, understand what they're feeling, things like that, but same with speaking to doctors. If you want something from a doctor, they're always extremely busy. They're running around. They're extremely smart, but they don't really have to use... This is what we learned in school. We literally learned how to manipulate doctors. Nurses tend to go from books and then argue their way into something, where doctors have to know so much, it's almost impossible, and so they're really good at judging a situation and then still being super smart in that. Of course, by knowing also books, but it's a different way of arguing, and so we kind of learned how to get around that, to get on their level, figure out what they liked, and then go from there, and that made it successful, and now when I'm in a room with a CEO, it's remarkably the same, and so you kind of have to work around how they fight in meetings and make your point in 30 seconds or you're done, and so actually being a nurse, I don't do it at all now, but it helped me a lot in the career. Sean: That's really interesting coming at it from an organization perspective or a people problem perspective, because I think not many folks who go into development have that as part of their background. I think it definitely comes across in your talk that you're very effective at pitching and just explaining very succinctly this product, and so I guess just to back up a little bit, in your intro, I mentioned the acronym MAC. Do you just want to explain that for folks who might not know? Tim Binniks: Yeah, sure. So the MAC Alliance is something that actually got started in Europe a few years ago, but it's now rapidly spreading over the world, and it kind of stands for, it's an alliance of companies that work inside microservices based, API first, cloud native SaaS and Hatless, and so that's what MAC spells, and so that's a lovely acronym, because MAC also stands for speed and stuff like that, and so basically, if you are a company that does anything as providing microservices, or you're a Hatless SaaS, like a Hatless CMS, or you're Hatless commerce or you are an enabler of these things, like Netlify, to be able to compose all these things together, or Uniform where I actually work, we are all in this alliance together to figure out how to build the modern web, basically, and it got started because... I'm not sure, that's probably not the main reason, but especially what we noticed at agency back then, we'd be doing this stuff for many years. It all exists, it's just a lovely, put it together and you have something, kind of thing, because back in the day, we had all these monolithical software systems, the big players, and they were doing really well, but they were not as flexible for multiple disciplines. From tech to using it to hosting it, and so we were looking at, "Okay, I need something smaller that doesn't do everything 60%, but one thing 150%," like amazing, like Cloudinary to do them, or Contentful to do CMS. So when you would go to these huge clients and you would say, "You know what? We're going to go away from that large system that you've been using for 10 years, but we're going to take this smaller company to do just your CMS, and we're going to take that front end, and it's Hatless," all of that was not always as easy to sell, because it's new stuff, and making one of these alliances, marketing it well, making sure that you demo how amazing this stuff is as an alliance, when you're with this alliance, it's amazing for companies to grow, it looks good, and pitching gets easier, and now it's all over the place, and I think even companies that are building these monoliths want to be a part of it. So something went really well there. Sean: Got it. So it's not necessarily an alternative or competitor to Jamstack, but rather a group of companies and the folks that are contributing to the technology that's powering Jamstack. Is that a way to understand it? Tim Binniks: You can see it like that, but it doesn't have to be Jamstack, per se, and this is what's so interesting here about the Jamstack, because has it changed of what it was before? Is it just a way to build a website with certain technologies, or is it much bigger? Does it involve edge handlers and stuff like that? So the paradigm is kind of shifting on what Jamstack is, but I think if you go to Netlify or Jamstack.org, it's still relatively the same as it was, but between us, in the community, we're making it bigger than it is. You could use the MAC Alliance to build a PHP front end, and use all the tools in MAC, and it's still a MAC Alliance kind of architecture. You probably don't want to do that. There's other reasons. So Jamstack is not, per se, enveloping all the things that MAC does. It's just a combination of tools that you can use for anything, because you can use Hatless CMSs and DAM systems and all of that stuff to make an iOS app, and it's not Jamstack. So it's quite similar for... It looks like it talks about the same things, but it's actually, everything is decentralized now. There's not one organ explaining what everything is anymore. So we all have to do more homework. Sean: So maybe guided by similar philosophies, but then, I guess, could we also get a quick overview of what is Jamstack today, I guess, as it expands to maybe fill more needs, and also, what is the composable architecture piece of it? Tim Binniks: Yeah, sure, and all these things are really well put together, as all these concepts are super nice. Right now, especially now that a lot of tech and architectures and infrastructures are scaling a lot, these things work well together. So to start with Jamstack and why I think it fits so well with all these composable stuff that we keep talking about, is the Jamstack originally is JavaScript, APIs and markup. Really simple, and how it started is you build a whole website in your favorite meta framework, call it Nuxt, call it Next, whatever you want, and all the dynamic bits of building these pages, when you hit build on your CICD stack, it actually pre renders everything into HTML files, so static files, and this bunch of static files that as the artifact of your build can now be put on any CDN or any server, and it becomes a static website. This is how the Jamstack started, and then quite quickly, new things started to be added, which makes it even better. Things like with Next JS and Nuxt, and now all the others, is every page is statically generated, it's just an HTML file, essentially, but fancy JavaScript is added on top, that subsequent page load. So when you click on links, it becomes a single page app. So it hydrates this static HTML, and what that means is your first load is always fast, because it's an HTML file that exists. The JavaScript hydrates, and then from there on, it's never reloaded again. So you keep clicking and it's all just JavaScript. So it's kind of like the most complex thing, but it's the best of both worlds, because then when you refresh your page, down as the HTML again, hydrates with JavaScript. So all these modern meta frameworks started to add more and more on top, and now suddenly, especially when you look at Next JS in React, they're working together with 4Cell, and 4Cell is a CDN, or I don't even know if you can call it a CDN anymore, they have so many things, but they came up with things like serverless functions, and so why not, in that app that you are building your Jamstack side, add an API route that is actually dynamic, and then the rest is still static? Why not make certain routes or certain URLs that you face dynamic and other static, and suddenly the Jamstack started to grow in scope, and now all of these CDNs, from CloudFlare to whatever, they all have these serverless functions and extra API routes and all these meta frameworks, kind of understand these systems, and suddenly you can build hybrid websites, and are they still Jamstack? I think so. What do you think? Sean: Yeah, I think it's a natural evolution of, first you're solving this problem of sending a ton of JavaScript to the browser that it first has to download and then run in order for you to see your site show up. That seems like... Makes sense to solve that, but then you want to have some sort of functionality that does have to run on an edge function or some sort of server to be dynamic, and add that in on the CDN. Feels like the most natural place to put it, because you're so used to your site being fast from being rendered statically. Now you don't want to have some sort of origin server that you're talking to that's going to slow things down, and so now I am understanding how this is maybe solving some of those problems of these big monoliths, maybe the problems that your agencies were facing. Do you want to dive in a little bit more of what those problems were that Jamstack is now solving? Tim Binniks: Yeah, definitely, and with that comes this whole composable story. So basically, that Jamstack thing fits so well in this composable story, because if you want to compose your architecture, it's no longer this big monolith. It has one piece of software that you host somewhere. You have a little puzzle, with all the puzzle pieces you put together, and they somehow need to work together, and there is no center of the universe anymore. Your Jamstack site is on the CDN edge distributed. There's no central origin anywhere, but your Hatless CMS also doesn't have an origin. It's just a SaaS somewhere, also served from an edge. Your Cloudinary DAM system or your story block CMS, all of these things or commerce tools or Shopify, there are no origins, there is no central organ that has all the information. That's why Jamstack fits so well, because everything is decentralized, and Jamstack just scale that way. It's like these two were meant to work together, and so what we're facing when you're dealing with... You know what? This is actually multifaceted, because when you are in a monolith, you cannot choose to change just the CMS part or just the analytics part or just the commerce part. It's all one big thing, and so you're locked into what Defender decided for you, and so what we've done at these agencies in the past, we would still build custom things on top to make it better for the end user, because maybe that system was three years old, and three years ago, we did everything with J Query, and now we kind of wanted to use Few, but that means that this system still has this whole library embedded, and you have to use it. So we would kind of customize it and we had amazing projects that we customized, but then it was time for an update of the system, because of some security issue. Impossible, because we changed it too much and it just becomes too expensive. What we've seen is people asking, "Oh, can you just add a wishlist?" We're like, "Okay, six months probably," and now when you're composed, all these things are separated, they have their own little scope of what they do, you just have to connect them up, and so if you want a wishlist now, you can just say this week or next week. That's a very different conversation. However, I just mentioned this is multifaceted, because when you go to this composable thing, when you put all these things together, they somehow have to link up to become one system, and the more you scale, the harder these connections will be, because there never has been really connecting fabric for these systems without giving a lot of opinion on how they connect, and I'm currently working in the space to make a tech agnostic opinionless system to connect these things up. Because imagine right now, CMS systems, the Hatless CMSs, they're seeing, "Hey, we need to make content editors happy, but it's so abstract, how do we do that? Well, let's make integrations to other systems, like to Shopify, to your CMS," but then does a content director actually understand what they're doing there? Not really, because it's just an integration. It's not orchestrated. They have to understand both systems, but how do you make a preview for that? Do you implement the preview SDK of the CMS, or of Shopify, or of another system, or are you just hard coding everything and hoping that content directors just understand it when you give them documentation, and then you start scaling and you become a multi-tenant corporation. As in, in Europe, I have this CMS, but in the US, I have that CMS, but you have 16 other systems connected. Are you going to reintegrate all 16 in that other CMS also? What if you want to change one thing and everything is interconnected? You're going to be very unhappy, and this is what my talk at Jamstack conf is about. How do you cable manage your desk, as it were, or your architecture so everybody's happy, from content editors to developers? Because in the past, lots of people have tried to do this, right? You have the backend for front end kind of systems where this tends to work, but they're all proprietary. They say, "Do your data this way, integrate that data that way, and then use our components and we host it for you," which sounds lovely, until you need to do something special, and every project, at one point, needs to do something special, and then suddenly there's too much opinion, and it's problematic, and so at Uniform, where I work, we have been thinking about this for many years, because we've all worked either at these monoliths or at agencies dealing with these problems. Sean: I think in the talk, you described this problem of the lack of composability and having to know about every one of these integrations as building Legos with glue. That made so much sense to me. I think it was a really good metaphor, because yeah, in theory, all of these things are these little units that do their own API really well, but then once you put them together, you're stuck like that. Tim Binniks: There's many choices you can make there, and sometimes you want to glue them together, but sometimes you don't, and when you don't, you have to have some sort of way to make them not fall apart when you pick up your Lego piece kind of thing, or when you add something else, then it just drops, because it's out of balance. There's so many things you have to think about, and it's an interesting space to be, because what happens when you start connecting these things, where developers have to be happy, but content editors are equally important? Suddenly you have to think differently, and so there's a different separation of concerns in terms of where the data comes from, where it's stored and how it's dealt with, and this is the hardest bit that I've noticed when I give these talks and I talk to people of... Because it's such a different approach. The idea is that your page composition lives in one place, and that points to all your data sources that live in other places, and that's a new thing, because people have been used to, for many years, to go into my CMS, let's make a page, and I have a bunch of fields that might be integrations to other systems, but actually, my CMS is the place where I make my page, because with a lack of other tools, that was the only place to do it, but essentially, a CMS should be simple. It should have your domain data. If your domain data is, let's say, events, because you are Eventbrite, your domain data is people that organize events, the events, the venues, the locations, things like that. That is data that needs to live in your CMS, and it can probably be connected between each other, because this person speaks at five events. That's a CMS job. You can have really nice, let's say workflows around making events and setting it up, but then if you want to show these events on a webpage, you might want to connect that with your eCommerce system to buy tickets. You might want to connect it with copy around the event that says, "Look backstage," all the pictures, all the fun stuff. If you do these things, your events system shouldn't have these, because one day, this event shows big on the screen, it's a featured event, but then when you actually have a search result where all the events are listed, it's not big, but the way you've probably set it up is you go to your CMS, to your data model, you add a checkbox, make it featured. So content editors can go there and make it featured, but maybe next month, you wanted to have a light background, because you changed something. "Oh, let's add a dropdown to select colors or something." In a year, when you look back, your data model is dirty, and it's going to be really hard to deal with, and it's out of context of where the data should be, and so when you have a system like where I work at Uniform, we take that design data or the composability data off your page, out of the equation and put that in Uniform, because quite often, a title that says, "These are the latest events," your CMS shouldn't have that, because why would it? That's in context to the latest events. So you put that in Uniform and you do a query to Algolia with your search index, that query is the latest events. Sean: Yeah, that makes so much sense that a lot of the complexity comes when the CMS is trying to also decide how the data is going to render or display. It kind of reminds me of the model view controller paradigm that rails pushed so hard. The model just let it do the data, and then in your views, then you can do the display logic and render it there. Yeah. Let's dive more into Uniform. How is it solving this problem? Tim Binniks: So in Uniform, you can make component definitions, and what I mean by that is there are representations of components that you would put on your page. For example, you have a hero component and you have a listing component and a video component and maybe a footer or something. So in Uniform, what you do is you actually go into an interface where you build this component, it's like a form, and you make JSON properties, basically. So what you do is if you have a design system already and you have a hero component, you know your props, the props that make up this component in the front end. You map these props in Uniform. So it has a title, an image and a background, something like that, and so what you can do in Uniform, once you have that item set up, you can add parameters, variable stuff like that, and variants of the components for how they look, and you connect them to a resource, and that resource is one of your integrations. So what that means is if you have connected your, let's say, Contentful CMS, and in there, you have a bunch of videos or data models for videos, our integration will see, "Hey, you just made a parameter that says this is a Contentful entry. Select which of your data models you want." So you just scroll down the list and you find your video data model, and you connect it to Uniform's component. So Uniform's component is nothing but a little bit of JSON with parameters, which is connected to a content source elsewhere, and so when you start building your page, you can imagine you have five or six of these components, or maybe 20, you can go as granular as you like. You can go full atomic design if you want to, and so you can kind of drag and drop these components of how you think your page would look like. Then when you select a component, you can say, "For this resource, I need these fields to be filled for my props," and you can do that by multiple ways. You can either just select, this is the thing that is connected to it in the CMS, which is just a direct connection, and the only thing Uniform will store isn't like an ID of that thing. So in the front end later on, the developer can choose how to query it, because we are not going to tell you how to query, because it's no opinion. You, as a developer, need to choose, and so that's the base model we're dealing with now. We're experimenting with other things that I cannot fully talk about right now that make that a lot more powerful, because you can imagine, if I connect something to Contentful, it's just an ID. If I now have type script on my front end, I don't know which fields came out. I cannot properly type these things, because there's something in Contentful that I query and it just comes out. So we are experimenting with other things that I'll be showing on Jamstack conf on how that actually works now, but the interesting thing is now that you have control over your components and the sources, you want to do something with preview, but not tie it to each source. You want to tie to nothing. If something changes in Uniform based on property, you change, like a checkbox you click, that thing that we built is in our SDK, where you render your page. It also has preview built in. So we've built a universal preview no matter what source you put in. If you have a markdown file that you change, that preview will update, because you can just make an integration that looks at your GitHub account, find markdown files and access a CMS, or you have no integration at all. You just make a few text files in Uniform, and that becomes your CMS if you want it to. Let's say you're a developer, you want to start on a project, but your boss hasn't chosen a CMS yet. You can just literally make your components and props in Uniform, and fill them by hand, so you can make a prototype, and then a month in when they chose a CMS, you connect your integration and you just assign these fields to something that comes from the CMS, and you're done, which means you can change everything all the time without problems. Sean: So it sounds like the mapping is happening in Uniform, but then it's easy to switch out what data source it's talking to. Tim Binniks: Exactly, and so we have something on top of this that makes it much nicer for developers because I can already hear people think, "Oh boy, you're cashing all that stuff, all these mappings, and maybe they don't fit my props next year." That happens, and so what we've built is something we call enhancers. So what you can do, you can query the Uniform composition by slug or by ID, and what you get back is actually, for each of these component types, let's say it's a hero, for the hero, you get back, this is a Contentful entry, with, this is the ID, and what you can do is we give you little SDK functions to connect to Contentful. You give it the environment's variables that you need from your code, and we will query it for you, and when it comes back, you get the data that's specific to that CMS, right? It has lots of extra JSON, or maybe it's a GraphQL endpoint, whatever. What we have given is something we call enhancing where you can actually say, "Okay, I can compose," your composability comes back all the time. You can compose these data sources together, so we can make an enhancer to first query your data, and then in line, next to it, you actually make another enhancer that says, "You know what? I just saw a whole bunch of JSON that I don't need for this component. Let me just remove it, remap that data," but then maybe the CMS has a rich text field, which is represented in JSON. Well, you want that to be HTML, right? So you make another enhancer where you query their MPM package that says, "Hey, this is JSON to HTML. Let me just do it," or if it's marked down, it's marked down to HTML, that would happen there. Then whatever comes out is a completely clean and fits exactly to the component that this enhancer was working for, and we made that API really strong. If you wanted to add a dad joke to every component, you could, or if you want to add global data or whatever you want, and so if you now switch your CMS or you add another source, the only thing you would have to do is literally just make an enhancer that matches that type of component parameter for another CMS content stack, for example, and just write your quick mapper from the data from the one system to the other, and you're done, and the interesting bit is these enhancers can live anywhere. You can actually make a microservice or a serverless function that enhances your stuff, and then your front end doesn't even know what it connects to, and with that in mind, I've actually built a little serverless function on 4Cell somewhere that's called Tim Binniks Compositions, and I just built my website in Nuxt, because I like Nuxt, but then for work, I had to learn to do React. So I built my same website in Next JS, and next week, I can make it in Svelte, and it just works, because these components, it's just props. That's it. Sean: Yeah. So it works with whatever framework you choose? Tim Binniks: Anything you want, no opinion, and what makes it really interesting is that... We can go deeper in Uniform here with that, which means that now that you have access to all these sources on one composition page, as a content editor, you can certainly start to think about, "Okay, what if this source is cool for a person from France, and also this component, but when it's actually somebody from Germany or from the US, I want to show something else." If you have everything on the page, we build a button that says personalize. You literally click the button, and the tree view of whatever that component is changes up, and so you can actually attach a bunch of rules for component A to, if somebody comes from a certain country, show this one. If they come from another country, show something else, and so naturally, when you build something like this, suddenly other products just fall out of the sky that you can now build in a super simple way. We didn't realize that. That just came on our path. It's like, "Whoa, that is cool," and so we started making integrations with CDNs, like Netify, 4Cell or CloudFlare, because they actually give you information about where the user is or what their browser is or whatever, any of that, and so in our personalization tool that we built alongside of it, you can actually add key value pairs of information about the user that you get on your app, and our SD case is quite smart and just figured these things out, and what you can also do is we kind of built a thing that's a tracker. So think about it like, if you integrate Google Analytics or Plausible or something, you kind of look at what the user does, they click a button, they go to a page and you send an event. Well, we do the same thing, and that tracker looks at what users do, and you can kind of configure, if a user does this, if they send this action or there's a query string or they have a cookie, set a bit of score against something that they have done that you think is interesting. So you can make an intent profile off that user based on what they do on your website, and that whole profile, you can figure out in Uniform, and so content editors can say, "Okay, if this person came from a URL from LinkedIn, because she did some campaign, show this component," because when they click on that thing, it scores against that campaign, and so with that, you have a lot of power, and especially when you consider that now all the CDNs also have edge functions. So we've built a thing where you have a Jamstack site on the CDN, and all the personalization happens in the edge function, because how edge functions work nowadays with most of the CDNs is you render an SSG page, it's just a URL, but every time you hit that page, it goes through a function that's dynamic on the edge, and we actually figure out, "Okay, this user has cookies and stuff," so let's look at the cookies and see, in the return of the HTML, if there are blocks that are identified as personalizable, or that's a word. So they're changeable, and we change them dynamically on the edge, but it's still a Jamstack site, because the page you're looking at is statically rendered, and because it's on the edge, it's ridiculously fast. So we can completely personalize a page to somebody's... Whatever signal they gave, or whatever they did yesterday on the website, in 50 milliseconds. Sean: That's awesome, getting that dynamic personalization, but as fast as the static site. Tim Binniks: Exactly, and we had to do it this way, because there's no longer an origin server. There's no server that knows everything about all personas and makes all the rules. So we've had to go this direction of making it organic, so you can set up signals and intents and things like that. Basically, if somebody does something, we give a little bit of score against that thing. So if you go to a tutorials website and you go to intermediate tutorials, we score some points. Every time you go to an intermediate one, we add little points, but then when you go to easy ones, we also add some points, but then when you go back to the homepage, and intermediate has more score than easy, our query to Algolia is going to be, "First, give me all the intermediate ones, then give me the easy ones," and suddenly you made dynamic personalization without setting up any rules. Sean: That's super convenient. Tim Binniks: Yes, and a thing that wasn't possible two years ago. Tech has changed, and we've now pushed really hard at this personalization business, because when I worked with agencies, and we're talking 13, 14 years of big customers, things like... I worked for Nike, things like that, EA Games, every customer asked, "I want personalization," and for every customer we said, "Nah, probably not. Maybe version 15 of your platform," because then we have enough budget to figure it out, and now you can do it in the first MVP, because it just comes out of the box with this type of tool, and it's an exciting time to work in this space, but it's also a hard thing, because what's interesting here is we don't have an opinion on how you build this stuff. So for every issue you have as a developer, we have 15 solutions. So I'm a DevRel without opinion of how we should do these things, and so I'm kind of just trying to figure out how to make developers like this thing, and so I'm going to have to add a bit of opinion and then figure it out, but not piss off the React guys if I only show for you, and it's a really amazing place to be at the moment. Sean: So you get to gather everyone's opinions, and does that drive, then, what kind of features you build next into the product? Tim Binniks: Oh definitely, yeah, because as a DevRel, I'm patient zero of all these things, and I love building things with the community, but also for myself. At Jamstack conf, I'll be releasing a project that I made with all the stuff we just talked about, but it's not a demo, it's like an actual project. So it's not a customer that did that. I did it and I had to learn how to figure it out with all these things that are in Alpha state or Beta, literally on the edge, and the thing works so incredibly well, and I only took a month to build it. So if you understand the things, it's really easy. Sean: Yeah, I was super impressed watching your screencast of this talk, because you did a live demo, and basically, I think it was about 30 minutes long with no hiccups. Anyone who's done live demos before knows that's a pretty impressive feat, because this stuff just worked pretty seamlessly together. Tim Binniks: Oh man, I've done the talk many times with many hiccups, I can tell you, but now when I'm speaking at bigger conferences where I cannot just live code. So I've filled it in. I did some nice screencasts to make it even more impressive, but it is totally doable if you understand the matter of what you're dealing with, if you really are into this composable thing, and that's one thing that is slightly challenging. Now that customers are starting to use this stuff, they need to learn more about what they've chosen themselves, rather than just ask the agency, "This is the software, go." You need to learn a lot yourself, and as a developer, it's the same thing. I was dragged onto more backend related full stack things coming from a full front end person, because now I have to deal with, "Okay, I connected to four systems, how do I actually deal with that data?", and you learn a lot, and then Uniform makes it a lot easier, but it's a data driven approach, but it makes it fun. I kind of like backend stuff now. Sean: Yeah, it definitely brings together the backend and front end in kind of a seamless way. I'm super excited about what's coming next with Uniform, so I'll be staying, I'll be looking out for that talk where you'll go into the future features, and for those listening, where can they find out more about Uniform online? Tim Binniks: You can go to Uniform.dev, which is our website. For developers, I think it's nicer to join our Discord and look at stuff there. You can go to Uniform.to/discord, which is a little short link for an invite. You can also follow me on Twitter or YouTube just at TimBinniks, one word, because I'm doing a ton of stuff in this kind of space. I even started a newsletter on this whole DXC thing, because it's so new, people don't know what it is, and I'm defining it as I make the newsletter as well, which is kind of a crazy thing to do. You can find that on my LinkedIn profile, for example, or on my Twitter profile. I have this little newsletter thing now, and so there's lots of places where you can find more. Sean: Awesome. Well, we really appreciate you joining us today, Tim. Yeah. This Jamstack stuff is really exciting. So thanks for explaining this to us. Tim Binniks: Thanks. I love being here. Thanks for the really good questions and allowing me to ramble on about this fun stuff.