Oleg Isonen, Bogdan Chadkin - Webstudio

{/ TAB: SHOW NOTES /} This week we talk to Oleg Isonen and Bogdan Chadkin, the people behind Webstudio. Webstudio is an open source visual builder for the web, aiming to right the wrongs of the current visual builder landscape for a more collaborative and accessible experience. - https://webstudio.is/ - https://github.com/kof - https://bento.me/oleg008 - https://x.com/oleg008 - https://www.linkedin.com/in/bogdan-chadkin-ab1684b6/ - https://github.com/TrySound - https://bsky.app/profile/trysound.io {/ LINKS /} {/ Paste show notes /} {/ TAB: SECTIONS /} [00:00:00] Introduction [00:03:00] The Journey to Webstudio [00:08:51] The Role of AI in Webstudio [00:12:49] Design Tokens vs. CSS Classes [00:16:25] Component Reusability and Abstractions [00:25:00] Open Source and Developer-Designer Collaboration [00:34:21] CloudFlare's Impact on Webstudio [00:36:45] Future of AI Integration in Webstudio [00:43:53] Final Thoughts and Wrap-Up {/ TAB: TRANSCRIPT /} Oleg: do we know how to create abstractions? Do we really understand? How to reuse anything at all. Like when do we even need to reuse anything at all? Because every usage of, of something is usually slightly different. [00:00:19] Introduction Andrew: Hello, welcome to Dev Tools fm. This is a podcast about developers and the oh, this is a PO podcast about dev tools and the people who make 'em. I'm Andrew, and this is my cohost Justin. Justin: Hey everyone. Uh, we're really excited to have Oleg and Bogden on with us. Uh, so, uh, y'all are working on a product called Webstudio, uh, which I, I feel like is gonna be a really exciting episode. I've been really interested in tools in this space for a long time. So, uh, I'm. We're very eager to dig in more and talk about what you're building. But before we start, uh, we'd like to hear more about you. So Oleg, would you like to start us off? Oleg: Sure, Sure, sure. Um, hey, uh, nice, uh, nice to be here and I don't even know where to start because Webstudio is such a big topic that encompasses the entire, you know, website creation space, which is on itself like a giant topic. So, yeah, let's see where we can get with this. Justin: Yeah. Do you wanna tell our listeners a little bit more about like your past and sort of like what you've worked on and how you got to this point? Oleg: Oh yeah, sure. Um, so I've been developer, mostly front developer for my entire career and, um, at some point, uh, about two and a half years ago, I decided to start the company, which is Webstudio. And yeah, I've been, uh, working on some tools. Uh, one of those is Webflow. Uh, it was, uh, one of those company that has been, they have like huge impact on how I think about the entire web development, but also, um, it changed my career entirely. And, uh, part of the reason why I built this company or started this company, uh, was me working at Webflow and then realizing. What else can be done in this, uh, space? Where are we actually, and why are we not better than this? Justin: Uh, Bagan Do, would you like to give a intro too? Bogdan: Uh, yeah. Um, hello, I'm Bogdan. Um, I've been doing open source like. 11 years already. Uh, I started, uh, as a post CSS contributor. Uh, I liked CSS and, uh, uh, I needed tooling, uh, to work with it. Uh, Uh, and I've been a maintainer of post CSS for a while. I've been maintainer of roll up SVO, um. But now I focus primarily on, uh, webstudio. It's a very cool project. Um, I like the idea of bringing designers and, uh, developers together, um, bringing, uh, this, uh, old, um, web masters, uh, thing, uh, back. Oleg: I call this uh, white Masters today. Andrew: Cool. Yeah, I've, uh, I've seen you on many a GitHub. Uh, cool. Let's get into it a little bit. [00:03:00] The Journey to Webstudio Andrew: So, uh, webstudio seems like a very big product. Uh, you had a path that led you here. Could you tell us about what took you from Web Flow, uh, to another company to finally go, I wanna solve this problem, uh, with Webstudio. Oleg: Um, so originally I didn't plan to start Webstudio when I was at Webflow. I, um, like. The idea of making something as complicated as, you know, the visual builder, it's, it is just doubting, you know, it's just a lot of work and it still is. Um, and it's kind of, I never planned this to happen, but, um, the ideas kept, kept me kind of like thinking, what if we did this? What if we fixed collabor real time collaboration like Figma did? What if we actually stick to the web platform fundamentals when. We try, you know, to create UI around, um, h ml CSS, what if we stop, um, you know, abstracting away the platform and just make it more accessible, but still keep it, you know, really close to the bare metal. Uh, what if we make it really fast, like, you know, things, there is so much stuff that we, developers are doing, and we do, we do this over and over again, and it's kind of like, it's weird, you know, because. Everyone is building websites and most of them are still bad. And how is this happening? Like, why is that? So that kept me bothering and I, I decided to, you know, try and do something and I built a small prototype when within, you know, a few months, launched it on product hunt and, um, investors contacted me and I raised, uh, pre money to start this company. So that was essentially like, you know, two things together. Me still wondering can we do better and actually doing something about it and then, you know, getting off the ground. Justin: So Webflow is obviously a, a big contender in this space. Uh, but there are a lot of other sort of like visual site builders. Uh, so the category is, is both broad and a little crowded. So when you were thinking about this problem, uh, what were the things that you saw as like gaps in the market that you really wanted to bring with Webstudio? Oleg: Y you know, the thing is, if you compare the, the size of their market, the, not, not even the size of market, the size of their audience that is using these tools, it's kind of tiny in comparison to let's a WordPress and that shows kind of like where Webflow is in comparison to the global market. And then if you think about it, what is the reason why that, so, of course, WordPress is very old and like it has had a lot, a lot of time to, to, to, to get this, uh, level of awareness. But fundamentally, I think it's, first of all, open source aspect of it because you, you know, like visual development has been and still is a different paradigm. It's a shift. Yeah. And uh, it's, it's, it's kind of, it's a big shift from, uh, weeks type of, uh, tools where you can't just build, you know, really complex professional websites. And then it's also different to normal web development where you have to quote everything and there is cost to it. There is complexity to it. So visual development was something entirely new. And I was thinking like, will it stay like a super niche thing? Or can it become mainstream? And in my mind, the only way to to make it mainstream is being open source. And that is the core foundational reason to start something like this. But then at the same time, I think there is a chance to build a better tool if we build it not as a proprietary, closed sourced type of platform. Because simply the amount of input you can get from everyone in the world is is it should be life changing for it. It should be actually life changing for any product. Andrew: Have you guys seen good support from the open source community? Like have you had random people adding Oleg: Um, not random features. Uh, well, there, there has been some, some, some attempts to, to kind of like build a feature and like come out of nowhere, but, you know, usually, usually the, I would say even in the entire open source space code is not the most important aspects. Their problem statement is. The ability for someone to express their problem, define exactly why they have this problem, discuss the solution and collaboratively come up with something that works. That is kind of like the thing that is completely missing in any closed source platform. Code is code doesn't matter. I mean, we can rewrite or implement anything relatively quickly. It it, this is not a bottleneck. Justin: I got a question before we sort of like dig into the specifics of Webstudio. So you started this, uh, what, around early 20, 23 ish? Uh, well that was the, the, like why, why Webstudio, why now? Uh, blog post. Um. Like AI was like starting to kick up, but like hasn't, it didn't really reach, its sort of like the hype level that it is today. Um, and the, the sort of momentum of the industry feels like it's shifted. Um, so there's a lot more people, you know, there's just sort of this meme where like every startup now is like a chat, a chat box, uh, and they're like trying to auto drain everything from that. So it's like as you're in today's market and you're looking at, you know, all of these like. bot box companies, uh, how do you think about like visual builder tools in this space and how do you think about like, positioning, um, webstudio in the, in the like age of ai? [00:08:51] The Role of AI in Webstudio Oleg: Yeah, AI has changed quite a few things for us. We started originally, not even in 2023. We started in mid 2022 where AI has not been on our radar whatsoever. And um, as we launched in mid 2023, the better version of Webstudio AI has been, you know, the only thing everyone was talking about. The problem also was, and still actually, is how people talk about ai, what they assume it cannot or cannot do. And when, because of that, it's difficult to kind of like build something and raise more money or, um, hire more people. When everyone is thinking, oh, in six months nobody's gonna be visually developing anything in 12 months, you're, you're not gonna have developers at all. And of course we have been, you know, proven that this, all of this is wrong. Nothing is completely changing, but things are changing in certain way. For example, this chat interface that you're talking about, and essentially it's not even that. I, I think like ultimately, I don't know why we all using the chat interface, because you know, we are talking way fast, faster. are we not mostly using sound interface? I don't know. Um, but, but essentially in that, this, this is just the input mechanism. You wanna be able to talk to LLM, right? And, uh, depending on what LLM can do, actually, that becomes essentially the main entry point for any application. But that's, that's just the input mechanism. It doesn't really matter. Andrew: Yeah, on the last episode we had on Adam Argyle and he had a very interesting like, view of what websites might be in the future, where instead of us like working on assets, uh, like in webstudio. Or even in your code editor, you're more have like a prompt that is your product and your product is a output of that prompt. And then rather than working on the product at all, you just kind of like craft and hone what your product is and like what your ideals are around like having UI and. You don't actually care about the details, and I don't, I don't even, I don't know if that's the future, but like, that seems like the, the like natural foregone conclusion of, oh, chat's the best interface and this textual interface is the best Oleg: I, I think this is the maximalist, uh, thinking like as if, uh, like the same thing with test driven, remember days of, uh, TDD, like where every developer thought that the, the only way to, to, to do things is to write test first. And, um, yeah, it's, uh, it's not a bad idea on itself. Um, there is so much more than just defining, uh, you know, some feature on a higher level. Um, it's just, it's just a 10% of the, of everything that the software is doing. Uh, it, it's just a start. That, that it's just a start. That that's what it is. It's essentially the scaffolding of the application and then the actual board can be begin. And then if you think about what applications generally do and like what, why are they so expensive and difficult to build? Then you realize the most money is spent on fixing bucks and scaling systems. It's not defining the feature, it's not even building the feature, it's fixing all the things that go wrong with that feature or. Removing that feature in the end because it was wrong one to build in the first place, and that's where we spend 90% of the time. How much time do you spend like really implementing a certain feature, especially if you don't have a lot of technical data to clean up. And my estimate, it's like 10%, 5%. Justin: So let's talk about some of the like actual features of, of Webstudio. [00:12:49] Design Tokens vs. CSS Classes Justin: So one of the things that sort of jumped out to me is, uh, y'all think about design tokens instead of like CSS classes. Um, so. Anyone who's, uh, worked in an organization that's using design system, like design tokens may be a familiar like term, but what was the shift there and like, why are you thinking more of like in terms of design tokens over CSS classes? Oleg: CSS has fundamentally one flow, and I've been trying to fix this for my entire career studying this. You know, some of the earliest, uh, most popular, you know, approaches to this was, um, the CSS and JS library called, uh, JSS, which was me trying to fix CSS at the time where we had no CSS variables. Um, we had a lot of other features not in place, which were really making our lives difficult. And the, the, the core problem with CSS is the CSS specificity algorithm that makes it hard at scale and at scale. I, I don't mean like a hundred people, I mean, just a larger growing application. So. In a visual development, it's no different. If you, if you start building on top of the very same abstraction, if you start using the same class system, you will end up with the same type of issues with specificity, but even worse because now you don't, uh, only have the specificity issues. You also have, um, a UI that potentially doesn't directly explain what the problem is. It hides a lot of stuff that we, developers know how to dig out. From code or from the browser. But then if you talk about visual development environment, it, it, it's not gonna be representing what's, what's happening with CSS? So sign tokens have been essentially it's like, um, mixing or, um, actually it was inspired not by mixing, so the time, it wasn't even like a thing. Uh, at the time, um, I was looking at the spec, it's called design tokens. It's, uh, it's kind of like a draft that is not supposed to be used by anyone yet, but the idea is essentially it's like classes and every class can have a single or multiple properties. So it's a class, but the composition model doesn't rely on select. So you basically have a bunch of classes, you put them together, you. So separate them, you use them, you, you mix and match, match them as you want. Same thing is a mixing, and that mixing is actually going to be in the standard. So essentially I fixed the specificity issue simply by not having, you know, class-based composition, even though their mental model is exactly the same. Andrew: So Oleg: It is like you have a name and to this name is a bunch of properties and values attached. That's, that's all you need to know. And then you can put them together. You see how they combine, they, you see how they merge and you never have to experience any conflicts that are completely out of the blue. You see all the conflicts right up front. Andrew: Interesting. So, uh, it seems like you have some parts of like what, uh, developers might consider a design system. Uh, you also have, uh, erratics UI integration, which brings like all of the accessible type components to the editor. Uh, one thing that seemed to be missing though was components themselves. So like, if I wanted to make a reusable popover that I have everywhere, is that something you guys plan on on doing? [00:16:25] Component Reusability and Abstractions Oleg: Uh, the thing is, we, we just never got to build them. There is so much stuff that we have been trying to solve that we never actually go to the components itself. Um, right now, if you want to use something, you create, like you, you can easily reduce the styling information. But you can't reduce, uh, the structure, so you are basically recreating the structure. But on the other hand, we built a giant website. I mean, it's not a giant website, but it's pretty reasonably big website, um, webstudio itself. Like the webstudio I is. And we didn't have much trouble. And we have a lot of users who build, uh, relatively complex, large websites and they also don't have a lot of trouble. So sometimes, and we internally also discuss it like once in a few weeks, it comes up like the, uh, the whole, you know, discussion around components and reusability and all that jazz. It's like, yes, we, we came from React world. We, we, we came to. Think that we need something that we can parameterize and reuse and everything in a way that, you know, react components are reusable. But reality is that most of the time, the moment you start reusing some component, it becomes the obstruction and the moment it becomes the abstraction, you start using it in different places. It becomes difficult to maintain. And that in, in that moment, you start for every extra usage and extra use use case, you start adding more parameters. You start becoming really difficult to understand what's going on. You start breaking things simply because you don't know, uh, all the things that are using this component and how they're using it. And this is the concept that like we as developers, developers who professionally write, quote for decades, we are struggling with making this kind of like. Work. We add tests on top of this. We, uh, we try to make things very seman correct. We spend a lot of time maintaining semantics and all this just, just to make sense of everything. In the end, it's still like, hit and miss. It's difficult. It's, it, it, it works to some degree and then it doesn't. So sometimes we are wondering like, do we know how to create abstractions? Do we really understand? How to reuse anything at all. Like when do we even need to reuse anything at all? Because every usage of, of something is usually slightly different. And then you, you start with parametrization, et cetera. And the new tendency, especially with the mindset of AI, is actually copy pasting a bunch of O with a bunch of styles and adapting it to the use case that you needed to. And this is kind of like a little bit wild unexplored approach to web development that I see happening more and more today, actually pioneered by Tailwind, because simply a tailwind was, um, not really reusable styles, but more like a reused, um, you know, set of styles that you copy paste all over the place. And I was so turned off by, by, by, by this fact. I, I was, I was never a fan of Tewin, actually. I was, I always hated this fact because, like my programmer mind needs a component. My, my programmer mind needs to reuse everything, every bit. I still fight my team on this, like I am the, the guy who wants to reuse it and they don't want to reuse it anymore. They just want to have it copied over. Make it work and maybe some tiny bits and pieces like variables here and there, like some configurations here and there that are definitely not gonna change getting reused. So with this in mind, I, I still think we will need, uh, some version of components for visual development as well. Um, I'm at this point where I'm not quite sure how this should work because components, especially building them visually. Um, it's a quite messy and complex topic. Like using them in code is not easy, but using them visually is, is not gonna be easier either. It's, it, it might be actually even harder because, you know, you have to define the interface or everything that gets in. You have to define how this component composes other things inside of it. What is allowed, what is not allowed. You have to define the slots. Things that you can, you know, throw into that component from the outside. You have to, um. Decide what properties from the component can be forwarded down to, to other components. And then like this is only the visual part. This is only building this thing to make it look the way the way you want. What about the logic? What if you want the parent component to communicate to the child and then child communicate back to the poor parent? What if some property in the parent changes? That affects the child and then the child changes something that affects the parent. So we, developers, like the entire React ecosystem is struggling with this. Like, uh, you know, you know, child parent communication in React is messy. You have to, uh, like if you don't use, uh, libraries for that, you, you have to pass functions, uh, mutate values, uh, you know, call the callbacks back to the parent, make the parent do something. This is a very messy. Uh, thing to do. So I'm not sure what's the right approach for visual development to actually have both visual systems, like visual bits, snippets, reusable, but also logic that is attached to them and everything composes. Andrew: It's interesting that like you guys have found, uh, like. A lot of runway with like the classic web approach where it's like you've divorced, uh, the markup from the styling and that makes everything a lot more flexible. And like you're kind of saying like, components are an abstraction that we've used as developers to like conquer that complexity. But that doesn't really make all that much, it only adds more complexity though when you're in a visual tool and it's adding this like extra layer of like API and having to know things, whereas just. Knowing the primitives gets you very very far. Oleg: it does. What if, uh, what if we, in order to reuse, uh, some sort of markup, we didn't have to use component, what if it would be referenceable in some way? That is, just give me that snippet and that's it. Svel is actually another example where they didn't take the traditional approach to components, even though they have still a notion of properties and, uh, state and parent child component, but they also solved all the other aspects like allowing the child component to have, um, bidirectional binding for property between child and parent automatically, so that like you can add these two properties. And they're always in sync. You don't need to build this manually. Um, or, um, how the styling works in, in spelled components, like they have thought about it in a little bit different way. They don't have a component itself that you are defining. The module is your component essentially. And it has HMO, it has potentially CSS and it has the logic in the script deck that kind of like. Decides, uh, the behavior of, uh, of, of, of, of your representational layer. But, um, in a, in a sense of react, there is no components. Uh, like they, they exist, but they are purely con conceptual model. It's like, it's, it's more like a pattern than an actual component. Maybe that's what we need in the development. Justin: It's interesting that spelt has the notion of a snippet now it's like a first class thing of, of way of like a non component way of like sharing like templated stuff. But also to this point, it's like kinda interesting too that there's a lot of design tools that take this, this track too. So I, I remember like, uh, sketch back in the day, the the Mac app that a lot of designers were using, it didn't really have like componentized. Uh, like a componentized pattern for like a long time. It was like a thing that, like, it, it took them a while to like figure out like what the pattern for that is. And it does seem like a sort of a challenge in this space for sure. Um. [00:25:00] Open Source and Developer-Designer Collaboration Justin: So, so bug, then I would like to give you a chance to talk. Uh, I'm, I'm curious about like how your experience in the open source and the, the tooling space, especially like, you know, working on things like post CSS, how has that influenced, uh, how you approach, uh, working on a product like Webstudio and, and what are the kinds of things that you've been able to bring to the product? Bogdan: Uh, the most important, thing is, um. In such product is, data which, uh, represents, the state, uh, of the application, of website. it's basically an ad abstracted, syntex three. of everything. our compiler di directly translated into code. you get, react application. in, uh, builder, it, uh, translates into a runtime code, which, uh, reactively, changes when user, changes something in the project. We one thing, I figured, while working on this project is, uh, we don't need a complex, pars, uh, or code generation tools. We just can, iterate of, abstract synex tree and uh, uh. Generate code with, uh, strings. Like we don't need complex, libraries like Babel. we can, use this, uh, to generate any, code for any F framework. Uh, it can be react, it can be spelt Eventually, uh, we will make. More communication between, uh, developers and designers by, designers to use code from developers and developers to use, some components designed, in webstudio. Oleg: That, that reminds me actually, uh, the reason why these tools exist in general. It's actually the, the, like, if you think about it, the core of this matter, what, what we are trying to solve is all of these tools is the design and developer collaboration. Because it's never been solved. It's still not solved today. And the core reason is simply the, the gap between the ways of working for designers and ways for working for developers is just so different. And we have been trying to solve this with so many different. You know, approaches starting with, you know, at least some part of the design should be like tokens, uh, encode it in some Jason and then synchronize into the design system and code. It doesn't work or it works, but creates, uh, so much more work that you ask yourself if it was even worth it in the end. Because we tried, we actually, actually, the, the first version of the builder. Um, was built using this approach. We, we were trying to synchronize the tokens in the, in, in Figma and design. Like, um, the, the entire interface was built in Figma. Um, everything was tokenized and then the tokens were synchronized in the builder. We still use this because we haven't migrated away for that is just no solution to, to this. And in the end, this is a madness like building complex ui. And this approach is just not expensive. It's just too much work because you start in quoting every little thing, every little color, every little space into the token system. And then you have to maintain it in places, in both in Figma and, and where it's used. And then there is still so much stuff that comes on top of it that um, yeah, you can change those things, but they might break something else and. It is, it is, it is just not worth it. Like we, uh, like the, the attempt of trying to solve the design and developer collaboration by having some kind of, like protocol between the tools, it's, it is just, this protocol is just a subset of everything that needs to be done. And this is probably like 1% of everything that needs to. So I think ultimately the only solution to this, if we ever as humanity, are going to solve the design and developer cooperation, uh, is to have a single tool or single place where both of them can operate. And that's what everyone, and I'm literally, I literally in every, you know, tool that is meant for complex things like Webflow and even Framer and Webstudio. This is all we're trying to solve actually. Andrew: Yeah, I, I think designing and developing in the same place has a lot of merit to it. Uh, one, one feature that I saw from you guys that seems, uh. Like, nice for that is the way you guys do semantic elements. Uh, like in, I used Webstudio or I used Webflow with my wife one time and I was just so surprised at how much I had to know as a non-developer to like, make a website and make it look good and make it right. Uh, can you, uh, you were bugged and go into like a little bit about how the element works in Webstudio and how that helps, uh, people make semantic websites. Oleg: But we don't take this one because the mastermind behind it, he actually, we started initially with components and uh, with their react thinking like sort of there is a, you know, component for every single thing. And then. It's a high level abstraction and then something is happening under the hood. Uh, but then we realized with ai it's gonna be difficult because it, like generally, AI doesn't know your components. It knows each them out. And you want to be able to generate something with ai, bring it into Webstudio, and this is where Bodom came up with, uh, the element. Bogdan: we recently had a new element component, which basically gives you, An ability to create HTML elements. main idea was to give very low level control for, visual designers, to let, uh, them, specify any, heading levels, any paragraphs, not, uh, abstract, too much. So generated code can be, the same as, intended originally. the same goes with the ai, which, can, manipulate, uh, any existing, each team elements, but it, uh, cannot know our abstractions. but idea to just, rely on, uh, something that exists in the wild. one important thing here, in HTML element is, um, content model, which, I basically passed from HTML specification. There is a indexes, Table, which shows, which element can be in which parent. and just scraped it. built, a, a list of rules for webstudio. And, uh, now it's, it can warn you when you put something incorrect. There is a tag property, which, uh, shows, only tags which you can, uh, use, within context. for example, um, list item. Um. Can be put only inside of, lists. another list, numeric list or menu, tag and, backward. When you try to, change your tag on parent, it'll not, let you, use for example, paragraph because it, uh, knows what's, uh, children it has. So it, let us enforce, semantic HTML, for users. it shows, only, specific attributes, for this element. And in the future we will introduce, accessibility three awareness. so it will be additional layer to validate, what a user. builds. Oleg: I think that the fundamental, um, thinking here is that if we are using components that we made on top of the web platform. We are working sort of against the web platform. Yes, we can make ni nice components. Yes, they can do a lot of stuff, but fundamentally, every month, every year, uh, web platform comes up with new things. Now, there is a huge amount of work being done in CSS in HML that pop over API, um, um, the, what is it called? What is it called? The, the triggers, uh, that we can have. Yeah. Yeah, exactly. And all those things are kind of like HTML and CSS is slowly catching up to the requirements of the real world or the things that we, we, we used to do with, with custom code and, and all those custom obstructions that, uh, we, we, we like to be building as developers are actually going to be like in a year a bunch of legacy code that you don't want to have. So our, our idea is actually to rethink how we are moving forward and. Get back to what HTML and CSS is trying to accomplish and get outta the way. So, um, with this element, it's kind of like a context where element obstruction that allows you to use any element in the right place with the right attributes and tells you when you are wrong. And it's kind of like weird because as a developer, if you write h them out. You most, I, I almost guarantee you that none of us can write fully compliant, valid html without looking it up. Like I'm looking up constantly, things that I cannot or cannot use. Like today, I, uh, I, I have to look up if I can use a header element inside of a dialogue element. It seems logical that you could use header, but no, you can't. It's not for this. And stuff like this happens all the time. Um, and weirdly in this visual kind of environment, you're actually easier. You can, you can see what can be used and what can't, because it just tells you right away. Justin: One thing that I wanted to. Dig into really quickly, which is a bit of a, a, a divergent from this topic. [00:34:21] CloudFlare's Impact on Webstudio Justin: Um, so both in the call out post of like, why Webflow, why now, and just sort of on your documentation site, you, you, you call out CloudFlare as a very specific enabler to like what you're building and you put a lot of emphasis on it when a lot of other times, you know. People may be building a CloudFlare but don't mention them as much. So, so why is it important to you to call it out? Like what is, what is it that CloudFlare is giving you that you think is uh, sort of a differentiator? Oleg: I, I think, um. Uh, feature or like infrastructure that got me thinking that CloudFlare is the good, uh, is workers, they did two very important things. They made them super cheap, uh, and, uh, well distributed across the globe and isolated like little tiny machines that leave, uh, in, you know, 200 central locations across the group. And nobody else has this. Quite like that. And if you think about it, what do you want from a website? Uh, you want it to be really fast anywhere in the world, and you want it to be able to load dynamic data and still be fast. And that's what you can do with workers. Uh, plus the caching because. Essentially bringing down infrastructure cost to near zero and making it really, really fast. Isn't this what everyone wants for, for a website? We, we could have done this with, you know, classical CDM, but then it would be only static website. You can't build, um, you know, a seriously big website, uh, without, uh, having ability to call APIs, having ability to, to cache. Um. CloudFlare is just making it work really well with, uh, with the storage, with with, with the storage, which is, uh, S3 compatible, but doesn't have the address cost. With the C-D-M-C-D-M, that is like one of the best in the world with, uh, workers with Kiwi caching. Um, it feels like they are the only ones. Who really build the platform for this. And uh, um, sure there is like gazillion way of doing this, but uh, CloudFlare is really doing some things right. Justin: You take the next one, Andrew. Andrew: So, yeah, sure. Um, [00:36:45] Future of AI Integration in Webstudio Andrew: so, uh, before we start wrapping up, uh, we touched on it a little bit at the start of the episode, but AI has changed a whole lot. Um, how you integrate AI in a product is, there's a bunch of different ways you can do it, as we already discussed. People love to put chat boxes into everything, but how are you guys approaching it and, uh, integrating AI into your tool and not making it feel like just something pinned on top. Oleg: We, we did, uh, the, the wrong type of integration in 2023, and we just thought, okay, charge four is out. It's crazy. We, we need to implement it. And we, we did it, but then it was very useless because it was, it was able to do basic things, but you can't rely on anything. Uh, it's difficult to understand what it's doing. It's uh, it's kind of like we're building a professional tool where you have to, you want to be able to control, uh, every aspect of your build. Um, but then you have to figure out a way for, um, for, have like a controlled approach for everything. Um, so we, we, we removed it, we removed it entirely just recently and for, for, I dunno, like 3, 4, 5 months now. We are working on a new thing that is called Inception. Uh, inception is not a replacement for the builder. Inception is a design tool, and inception is built from the ground up for using LLMs and other models as well. And the core idea in there is, um, essentially combining a design designer canvas like Figma, Figma style canvas, where we have many frames. Ability to see many different version of things, uh, at the same time, experiment, branch off. And, um, essentially we intentionally don't have any design controls, like Figma has the tools. Really simple. It's chat, it's chat interface on top of a designer canvas. Um, and the, the, the idea is essentially to be able to. Generate a lot of ideas, experiment a lot with all sorts of directions using AI on a canvas that is specifically designed for experimentation. And then instead of having a picture of what you have created, having an actual code, which is HML and Tailwind, which like we are specifically using LLM, so it is thinking in, in Tailwind. Essentially it is designing everything in tailwind. Uh, there is, there is no abstraction. There is no translation between what, uh, you know, uh, what you built with your rectangles and what is actually possible. It's a webc canvas. And then, um, essentially you start, uh, you start experimenting there. You can build the entire design. You, you can build some sections, and then you can copy it over to either builder because a builder now supports pasting each amount. Uh, tailwind you can. Copy from anywhere essentially, and paste it into the builder. It'll also download all the assets and, uh, store, store them. But you can also take the same thing, the same approach, and get the quote from, from inception and continue building in the builder. You see exactly what, what you are pasting. There is no side effects, there is full control. You can change everything you see on Canvas because that's the builder, kind of like fundamental idea that you can control everything and you can go to production. So we, we kind of like, we are trying to combine the two worlds using two separate tools that work together really well. Justin: You're muted. Andrew: Bad about that. It, it seems like your tool has a lot of very, like, nice ux uh, features to like facilitate that transformation. So like just being able to copy and paste A-H-T-M-L with tailwind of the tool, that's pretty cool. I also saw that you can just like paste CSS properties into the sidebar, and since it's all just web, it just uses all of those properties. Are there any other like cool little UX web web platform features that you have on the platform? Oleg: A lot of them are, I, I would say our fundamental thinking is you should be able to, you know, take anything from, from. You know, any website copy it and paste it into webstudio. The only thing that you, you right now, like, you can just take any CSS with random really com complicated selectors and paste it because that would defeat the purpose. Uh, someone would have to untangle the complexity. So, um, essentially we. We try to, like, we essentially support, as far as I know, we support the entirety of CSS, just without the selectors. You can paste the entire, uh, any, any CSS block, any, any type of declaration. Um, you can paste each amount. You can do essentially anything you can do with H on CSS and, um, that opens quite a bit of, uh, you know, possibilities. But then we provide the interface. That allows, at least with, you know, certain level of awareness of how CSS works a way for designers to also interact with all of this. They don't need to be, um, you know, opening some code-based project where unreasonable amount of code is written in random places, and you have to find your way through this. It's an easier way to work for designers. That's, um, I think this is the main, the main idea. And then by the way, inception is kind of not made. I mean, I think designers will also like to explore it and experiment with it, but Inception is essentially made more for developers and product managers and people around, uh, digital products. Because essentially we made inception in a way creative because we, we, we essentially try to figure out ways to make alarms creative. Um, so that you don't have to, so when, when you enter a prompt, you can say something that is relatively simple, make me a, a hero section for a coffee shop website, and it'll come up with interesting concepts. Of course, the more con uh, context you add, the, the more interesting the design will be. But, um, generally you don't need to be the designer to use it. You can be, you can add extra context, extra info. You don't need to, and we do everything around it so that you can start generating a lot of different ideas without having, you know, full, uh, designer contest. The one thing that you need to have is taste you in. Then someone has to decide what is good and what is not good, and you will be having like 10, 10 of variance and versions of everything. Uh, so you have to decide. Bogdan: since we support, uh, CSS, variables, they can be copied from a Figma or OT and, uh, pasted directly into the root and, uh, used a cross hold project. uh, it's a good, feature to share with the designers, values and the. Built, based on this design system, [00:43:53] Final Thoughts and Wrap-Up Andrew: Well, that wraps it up for our questions this week, guys. Thanks for coming on. Uh, you guys have built a very powerful tool and the fact that the whole builder is open source is incredible. So thanks for coming on and talking about it. Oleg: Thank you guys for having Bogdan: Thank you. Justin: we, appreciate it. Uh, and yeah, it, it's such a cool tool and we're excited to see how it develops in the future.