The Web Development Engine (Interview)

34:07And I think that it's not far from how people often organize code anyway. But each of those kind of have their own UI. They're a separate problem. Like the editor for doing like pure formulas, like pure computation, looks very different than the editor for like doing a flowchart, right? And completely different from any of the UI stuff, right? When I'm poking around the UI, I see the option to add formulas and variables. Is that what you're talking about when you say flowcharts and stuff like that? Like that's pretty interesting because you've got like different types and integers and data coming from different places that connect via nodes.

34:46Is that what you're talking about? So when I say flowcharts, obviously it's a bit abstract concept to apply directly. But I'm mainly referring to what we call the workflows. So if you go, if you select an element, there's like an event tab. So you can say, and there you can click on the click event, for example, right? And that sort of shows up this dialogue that says, okay, what do you want to happen when someone clicks this element, right? And there you can add nodes. And that's a different UI. It looks kind of a little bit like the formula UI, but it's actually tipped on a different axis to sort of make it distinct.

35:24And so we separate, like, what do you want to happen when I click, right? Okay, so I want to update this variable, right? But the value you set on the variable, right, that's probably something you compute. most of the time right and that computation is a formula so from in that you open the formula and by having those two separate you actually you get to a point where it's very easy to get a high level overview what's going on and very easy to then dive in to exactly the point you want and one of the benefits we see with that is also that when you're working in the same tool both engineers and designers, designers can sort of opt into how much they want to get into.

36:04So like when my co-founder joined the project, he only touched the UI, right? He didn't touch any of the logic, none of data fetching, none of that, right? It's just, I'm only looking at the UI, I'm styling it. And he was super happy about it, right? And it worked really well because effectively we'll work twice as fast as we would normally do because we weren't doing all the UI worked twice, right? He would just design directly in Nordcraft. I would just actually wire up the functionality. A lot of times I would build it first and not style it at all. Just add like the minimum amount of UI to make it functionally work.

36:39And then he would take over afterwards and actually run shipping it. But as a designer, you can choose, do I care about how the formulas work? Do I care about the workflow? Do I need to know? And initially the answer is probably no. And over time, what we often see is that you can sort of get a high level idea. Okay. So this is the thing that, you know, this is, this is where it updates the variable. This is the button that eventually fetches the, makes us fetch the data from the server, right? That kind of thing. Or you can, if you want to go really into like, why is it that decision? Why did it do exactly that thing?

37:14And why was this the value that was set? Right. but if you're not a programmer and you're just coming into this right you you sort of have the option of saying like i don't really need to to deal with that yet but still get an idea well i also know how the editor open and i'm clicking around as we talk it's very interesting it reminds me of well like pixel mater or figma with more things in there for like action like actions for instance um is it baked i mean is this is this thing ready to rock are people using it is it how long you've been working on it and is it nothing's done but is it like the 1.0 is it ready it is it is super ready we've been we launched a year and a half ago okay and we've got quite a few like obviously we don't have any like a massive enterprises that built the whole stack in north graph yet right because a year and a half is not quite enough for people to discover a tool and then build on it for several years right but we have some really interesting projects um that's built in nordcraft one of my personal favorites is a guy in malaysia who built uh like he he calls it a was essentially a competitor to shopify it's not feature complete like shopify but in malaysia apparently the way shopify does card payments means that it's almost impossible to use so he built uh like um the e-commerce store platform like shopify in nordcraft and it has its own visual editor where you can build your shop which has a nice sort of inception concept to it and i think he he's already processed like orders for over 10 million dollars in that one stop like in that project and i think like on the first day he launched within the first first three days he just like processed the first ten thousand dollars so like immediately successful and he's he's done a ton with that right and we have a couple of projects like that that's really successful a lot of people are building like hobby projects and interesting things things for fun to try it out right most of our users are like always on the freemium plan and just building interesting things and and of course the biggest project like the whole editor that you're using right now.

39:35We're building in Nordcraft as well, right? Gotcha. So it's like self-hosted in that way. What's the language? I mean, you said you created a language and a framework together. Do you know, I mean, does the, do I, would I learn the language as I build things or would I not have to know? So language in this case, there's not, we haven't given a name. Okay. Because we don't really refer to it in that way. Like it's just the thing underneath that powers the whole thing, right? But you never have to poke under the cover. No, there's no, there's no, we haven't invented a syntax for it. Like the whole thing is just stored as ASTs and JSON, right?

40:11So what about when I'm hooking up my actions? You know, when you click on this, here's what I want to do. Go hit this API, get the results back, display them in a table. Am I coding in the language then? Or am I clicking on things? What am I doing? I think that's almost a philosophical question, isn't it? Almost is, yeah. Because especially, I used to say that it's not coding, but it's programming, just because coding for me was like code. Sure. But people use the word code a lot to refer to what they've done in Nordcraft. And I mean, I'm not sure it's wrong, right? But there is no textual representation of it, right?

40:54okay so i is i am clicking on things and and hooking them together yeah i'm never so like again if you were writing a javascript function right that says like add two numbers together right yeah um what the browser actually does when it sees that initially right it starts passing the actual text and then it builds up this tree structure in memory and like the first node is going to say this is a function node and then it's going to have some attribute that node that says the name of it, probably whether it's async. I can't remember what the standard ASG for JavaScript looks like, but something like that.

41:31And then it's going to say, and there's some parameters or argument, that's going to be an array. And if you have like numbers as input, it's going to show that you have parameter A, that's of type number and parameter B of type number. And then it's going to say, and there's a block, right? So it basically takes your code line for line or bit for bit and try and represent this at large tree structure. And every compiler does this. That's the parsing part, right? And then if you're using Babel, what Babel does is it just applies a bunch of different transforms on this AST, right? If you're doing TypeScript, that's again like TypeScript runs type checking on this data structure so that you can run all these different processes against it.

42:17And then the final bit of that is if your language is a compile language, it turns that into a bunch of ones and zeros through a complex process that I feel like we can leave out of the scope. Also, I don't really know anything about it because I've never built a compiler. Or if it's an interpreted language like this, there's literally a program that goes through that tree and then performs all the different actions that matches what that is. So if you're saying, okay, this node is a function call and this is the name of the function, it's going to go, well, I need to go look at my function stack and find that function and apply it, right?

42:51And that's the same thing that we do, right? So the only difference between, like, in this case, Nordcraft as conceptually as a language and any other one is that we don't start out with text. We cut that off. And this AST that the parser normally generates is actually our source of truth. And that's what we store in our database. And the editor loads that in and has that model in memory when you're working with it. And whenever you edit anything, it goes directly into that AST and say, I'm going to change this property, right? So if you rename a function, it's going to go find that function in the AST and say, I'm going to change the name property.

43:26So when you're building a formula, you are clicking, you are saying add an if condition, here's a type of variable, it's a Boolean. You're like connecting things together. And so it's very visual, even when you're building formula. Formulae? Formulas? Formulas. Yeah, formulas. Oh, maybe we should do Formulae. I think Formulae might be the formal way of saying it. I know that because it wasn't homebrew. They have Formulae, I think. Oh. Maybe we should start saying that. Yeah, it's kind of cool. Anyways, I do find there's a button down there because I'm building a formula, a test formula right now.

44:09and as a as a software developer this is cool but like at a certain point you're like i don't want to click and drag and do stuff necessarily and there's a button convert to custom code and now i'm looking at a javascript editor with a function javascript function is this kind of your solution for that situation where you're like yeah this thing's limiting me i need to do something outside of the ordinary and i can bypass the editor or tell me what's going on here when i click this convert to custom code because there is a asterisk there about server-side rendering Yeah. So the, so the, the whole idea of, of custom code, we call them custom actions, custom formulas.

44:46Okay. It's basically that like whenever you're, if you're building a new language, you are missing a lot, no matter what you're doing. Right. Like there's a lot of things you can do in Nordcraft without ever touching any code, but not everything. I often use the example of like, I wanted to build something that I could use. I wanted to try the Bluetooth API, right? And so I made a simple example where I could use a PlayStation controller to browse a website. And that Bluetooth was not very high on our priority list of things that Nordcraft needed to do because I've never actually used it before in my 20 years.

45:25To be fair, it hasn't been there for 20 years, right? But it's not the most used web API, right? But you might still need it for your app, right? It might be that the thing you're building needs Bluetooth connectivity, right? And so there always have to be a way to solve your problems. And the way every programming language ever, I think, has done this is through a foreign function interface. So when Node came out, it could do a lot of things, but most of the libraries were just bindings to see, right? It was just, here is the JavaScript interface. I'm actually calling some C code underneath, right?

46:04And for a long time. Over time, it kind of changed and a lot of things actually got written in JavaScript and it stayed within the same ecosystem. But initially, like, it was all a different language and it was just an interface for it. And that's the same thing we've done here, saying, well, if you want to, like, add an API, do something that Nordcraft can't do yet, right? You can create this custom action and it's essentially a foreign interface. You go and say, well, the action is going to take this kind of input. It can emit some events back. And whatever it does in between, that's entirely up to you.

46:37You can write whatever code you want, right? And it allows you to say, like, it allows us to fix and say there is no limit. Like, even if you hit a really weird edge case that your app needs to do, well, that's possible, right? If you want to bring in a third-party library that does, like, a weird graph rendering things because someone made that and you want to use that. Or if you really want to use AG Grid, right? You can use AG Grid, right? You just go and say, I'm going to define in Nordcraft and saying this div is where Nordcraft, just like you were doing React, right? This is the div where Nordcraft stops touching the content inside.

47:14And then I'm going to use JavaScript to render the rest, right? And that's perfectly possible, right? And you just build an interface so that you can work with that inside of Nordcraft. Like, again, this is not us coming up with something fantastically new. this is the same thing react does uh whenever you're like opting out of react for rendering right and it's the same thing every program's language has done for for like for an interface there are also cases where it's just like uh we ran into an example the other day it was like a markdown parser where like yeah i mean just just just use the javascript one and we had an engineer who definitely felt like he wanted to build it natively into nordcraft um but it's like yeah It's not a great tool for building like a markdown parser.

47:59That's not the point, right? JavaScript can do that just fine. But when you're building Nordcraft with Nordcraft, do you find yourself ejecting often the way that you guys have set this up or not very often? Ironically, almost never. Almost never. Like if you look at the project, and we're in the process of taking it open source, so in the coming weeks we're going to open up the editor project so anyone can dive in and see how we build it. And in there there's a lot of custom code, but almost all of it is because we made it before, like maybe a couple of years ago, before Northcraft could actually do that thing, right?

48:35So there's really not a lot of times. It's quite rare we go in and do that. Like the most recent example I had is like we rebuild our whole style panel. And because we want to support like the full CSS spec, so even if we don't have a UI for a specific type of style, you can still pop into there's a CSS panel on the side where you can go and look the actual CSS, right? And you can write CSS in there, and we want to support you doing that, right? Whatever it is. But that also means we actually have to parse all that CSS so we can figure out how to properly render it in the style panel, right? And so we had to sort of build one, sort of half open source, half build ourself, parser.

49:22And that was like a classic example of like, yeah you can definitely do that better in code right um that's that's not what nordcraft is built for at all but it is quite rare most things it just it's just easier and works better to build it directly in nordcraft it's interesting to build inside of itself how does it work like it's um i mean it's a nice experience now but um i started doing that before we had version control that That meant if you made a mistake, you broke the tool you're going to use to fix it. So I had a few times where I had to like check out Jason from a big Jason tree from the database and try and figure out what did I do?

50:05How did I fix this? So you're literally building the engine inside of Nordcraft. Is that what I'm hearing? What part are you building inside of Nordcraft? The editors. Just the editors. Okay, so the visual UI, all the UI you see is being built with Nordcraft. Yeah. Okay. So the runtime, as we call it, the one that actually executes and renders like HTML and CSS into the browser, that is built in TypeScript. And that is all open source and you can see it on our GitHub repo. And you're in the process of open sourcing more things or everything, more things? So the, yes. So we've open sourced the runtime and a bunch of sort of utility functions and a few examples that basically allows you to run your whole application.

50:56Like anything you build in Northcraft, you can run it by yourself on your own infrastructure. Right. And when you do that, all our code is, is, is like, what is the GPL? And your investors like this? They were actually fine with it. um they didn't have a problem uh i mean obviously uh i had i'd built a story before i went to them what was the story tell us so the the basic story was saying like like there is no um like we're not gonna we never thought we were gonna build a big company uh out of the no code community right because first of all it's not nearly as big as the developer community and it's per definition never going to be big enterprise customers, right?

51:42Because that's the big one. So if we want to take this thing where we think we can go, we need to get developers on board, right? And we had some and they were interested and all of them were asking, so is this going to be open source? Right. And basically saying, if we want companies to trust us with the kind of projects they're building in that size, we got to show them something, right? We got to say, well, actually, we're not going to like rock pull you halfway through and say, aha, surprise. now it's going to be twice as expensive lock-in is something that we're all thinking about and yeah if you're going to build something serious on top of there even your your user in malaysia who's got now a platform that he's making money off of and he needs some assurances that that's not going to dramatically change or somehow lock him out or whatever it happens having open source is peace of mind right exactly right um and and i i mean personally i'm not sure I would like, I would have that in mind.

52:40I would never, there's a limit to what I would build in a platform that literally, cause it's not just that like, it's some of it is like all of it. Right. It's literally your whole app that you're building. So, so if, if you don't have options, right. That, that would worry me. And I think it worries other people in the same way, but we didn't build like that from day one, mainly because, well, my experience and my understanding was that open source doesn't necessarily make you go faster. No, not necessarily. And especially in the early days, we wanted to go fast. So we didn't want to open source there.

53:17We already had in mind that this was going to be something we would do. It wasn't something that came up a lot in the early days from users. So therefore, it was like, okay, we're going to keep it close. We're going to keep going. And now there's a bit of a process in sort of separating first, what is the platform code that's our hosting code and that part of the platform that's related to our hosting service and the actual editor right so we need to separate those two apart and we also need to sort of have a open source back end for it right and that's not going to be 100 the same as the one we have that's custom built for cloudflare at the moment right that all makes sense is for web apps is it bad for websites or just not built with that in mind is it just as good of a choice or is Webflow the way to go?

54:05I think the, I mean, almost every time when people ask what should I use it for, I say that the answer is the same as you would say for React. I think that for websites, we might have a little bit of a leg up because like it's quite easy to build a website. Like React is a lot overkill and so is Nordcraft, but you don't really get, you don't experience the overkill, like the extra stuff in Nordcraft to build a website, right? it's it's kind of like building a web flow so uh it totally works for websites but it but you have options like there's a lot of other tools that can do websites as well as us right um where where it begins to change and where we really sort of land as being our sweet spot is when you start pulling in data from different data disorders or backends start making it more like interactive and dynamic right well friends it's all about faster builds teams with faster builds ship faster and win over the competition it's just science and i'm here with kyle galbraith co-founder and ceo of depot okay so kyle based on the premise that most teams want faster builds that's probably a truth.

55:24If they're using CI providers with their stock configuration or GitHub actions, are they wrong? Are they not getting the fastest builds possible? I would take it a step further and say if you're using any CI provider with just the basic things that they give you, which is if you think about a CI provider, it is in essence a lowest common denominator generic VM. And then you're left to your own devices to essentially configure that VM and configure your build pipeline effectively pushing down to you the developer the responsibility of optimizing and making those builds fast making them fast making them secure making them cost effective like all pushed down to you the problem with modern day ci providers is there's still a set of features a set of capabilities that a ci provider could give a developer that makes their builds more performant out of the box makes their builds more cost effective out of the box and more secure out of the box.

56:22I think a lot of folks adopt GitHub Actions for its ease of implementation and being close to where their source code already lives inside of GitHub. And they do care about build performance and they do put in the work to optimize those builds. But fundamentally, CI providers today don't prioritize performance. Performance is not a top level entity inside of generic ci providers yes okay friends save your time get faster bills with depot docker builds faster get up action runners and distributed remote caching for basil go gradle turbo repo and more depot is on a mission to give you back your dev time and help you get faster build times with a one-line code change learn more at depot.dev get started with a seven-day free trial no credit card required again depot.dev

57:14what about things like uh authentication you know authorization when you get into those scenarios like how does i know it's an editor at this point it's a visual interface to it but how do you is that simply just part of the programmatic ways it has behind the scenes you can enable that how do you work that kind of stuff in so because most of authentication is a back-end issue we don't handle most of it because we don't have a back-end we just work with whatever your back-end is whether you coded your own or whether you use like Superbase directly as a backend or whatever you're going. There's also some like Sano is one that more low code, no code style backend works really well with that as well.

57:55So, I mean, from our point of view, again, we're front end. So we're just doing HTTP requests to a server, right? And so what we've done around authentications is what matters for us is how we store the token in essence. Like you can, whatever strategy you have for authentication is possible, right? What we sort of nudge people towards is storing your token in a HTTP only cookie, right? Because that's generally the most secure way of handling it. And what we've done is we have a API proxy. So whenever you have an API from the front end, if you run it through our proxy, we can actually authenticate that request.

58:38So if you, let's say you need to send an authorization header with your user token to an API, that's the most common approach, right? Well, you can actually set up, well, that's what I want to send. And you don't actually have the token on the client because that's stored in an ACP only cookie from when you authenticated. But we actually put that token in before that request goes to the server. And that way, even if you have some script injection attacks, et cetera, they can actually steal your token. That's not going to fit for everyone. Sometimes if you want to do like, especially if you're doing like real-time web sockets and stuff, that's not always an option.

59:17And you do need to have the token on the client. So there are like, you can, whatever your authentication strategy is, is possible. And it sort of speaks to the general approach. Like I sometimes say we didn't really invent that much. And by that, I mean, like almost everything works the way you would expect it. If you stop looking at it as a visual tool and start looking at it as a JavaScript framework. So like when people ask, like, how do you do authentication react? It's sort of almost a half abstract question, right? Because it's like, well, however you like. And similar, like, how do you, how do you, how do you store things on the client?

59:56Well, there's local stories, there's session stories, there's indexed DB. There's all these options because it's a web browser, right? And we are a framework and we just build visual tools on top of that. But we didn't invent whole new abstracts, right? The web's pretty good. Like the HTML, CSS, it's the best we've come up with yet, I think. So we're not reinventing it. Obviously, it's not running JavaScript, but it's very much stealing everything it can in terms of function names and making sure that everything is very familiar to someone coming from that world. And again, all the browser APIs, they're the same.

1:00:33No need to install modules and bundles and things like that. Well, there's always a question of like, how much do you want to build yourself and how much do you want to use other people's code, right? So we have packages is what we call them and you can install them. And basically, so by default, when you open Nordcraft, I think people are often surprised that there's nothing there in terms of pre-built stuff for you. So if you open it up, what can you add to your page? Well, you can add a header tag or H1 or you can add a button or links. All those great HTML elements you can add. But there's no tabs.

1:01:14There's no complex media player or carousel. You can install those as packages, just like you would do in any framework, right? But that's not a built-in feature, right? You can build them yourself or you can use something made from the community, right? What is deployment like then? I suppose if it's the visual side, like is it, it's not host. I'm still trying to figure out like what exactly. where it lives i suppose you know like what tell me more i don't know how to ask this question but like are you deploying something is it living somewhere i know you said you mentioned asts in your database but how does this application how do you say deploy this whatever this is or is it always deployed it is always deployed um you're live in production when you're when you're building or staging so how how how detailed do you want to go as deep as you want okay so so that's basically i would say if a developer is thinking like okay i get it adam doesn't but i get it react but different take us there like what would a developer okay well we're dipping a bit into the developer space then um so the we built this uh our version our hosting platform on top of cloud flare because cloud flare kind of uniquely has a bunch of services that are very interesting for us um one of them is something called durable objects and what a durable object is is essentially a um a serverless worker with state.

1:02:49And so you can basically save things in memory and it'll still be there next time you ask it. And it has this weird prophecy where there can only be one instance of it deployed worldwide at the same time. And that is for most things really bad, right? Because it doesn't scale. But it is essentially how we kind of treat it like a shared file system. So whenever you create a branch We have version control that's, it's not technically Git, but like it's, we copied this as much as we could. So whenever you create a new branch, each branch has its own durable object associated with it. And the way these work, which is quite cool, is that they are always close to you.

1:03:33So if I connect to a branch, that durable object is going to be in a data center near me, whatever closest to me. from Cloudflare has like 250 or something like that, right? If you connect to the same branch, it's gonna, or if you connect to the same branch later, it's gonna move that instance closer to you to make sure you have better rewrite performance, right? But there's always gonna be only one. So whenever I'm working on a branch and I'm updating my data and sending that to the durable object, that instance always have the latest version of my project for that branch. So whenever I go and say, actually, I want to preview this one.

1:04:19I want to see what it is live. Whenever I open that, it connects to the same instance when you're on a branch, when it's not deployed. So in real time, you can always see what is there, right? Because the second I make a change, that actually gets sent, takes about seven to 16 milliseconds, right? And then that's saved. and then your application will see that. So like branch deployment, those live preview environments, that is with below 100 milliseconds from iMegaSave to you see it live, right? For the actual main, we don't do this because it's actually a good thing to have a lot of different instances all over the world for that.

1:05:05So there we are just, we have the main version of that project and that uses their cache infrastructure to make sure that every single data center has a version of that, right? And we are rendering, like whenever you make a request to a page, we are rendering that whole page based on our code, right? And we actually looked into caching and the funny thing is it didn't do much because like it renders it really quickly on this worker. So actually caching the final page for a static page didn't make it faster. Maybe on average, like three or four milliseconds, but it really didn't change much. Right.

1:05:49When you start adding data, then like when that page needs data in order to render, obviously there's a different question. Right. Does that, did that answer it? Does that make sense? It does. Yeah. But even our deployment is just saying, like all we're really doing is saying this version that we have in the database, that is now the live version. So we are moving a pointer for when we're deploying. So like deployments happen really fast as well. How are you approaching education? We hired a really great person for education, a common friend, I believe. to help us with that. Salma. Is that Salma?

1:06:34Naila. That's her role? Yeah. Okay. Is our head of education. So education is a big part of this, right? Because even though a lot of this is actually familiar to developers, once you get past the interface, right? Right. You kind of have like, there is a little bit where it has to click. We've seen a lot of people where they have like, how do I submit a form? I'm like, It's a form, right? You know how to submit a form. You just have to see that because of visual interview. You thought there was all sorts of other things, but it's the same way you think, right? There's a button inside. Click the button.

1:07:11Submits the form, right? So there's those kind of things that people often a little bit have to get over. But after that, it actually is very familiar if you've used a framework before, right? But that being said, education is still a big part of it because it is conceptually a new thing. like it isn't it isn't quite even even the the tools it looks like it isn't quite that and and and you want to think about it a little bit different right yeah so something we put a lot of uh focus on and effort into both as a sort of how do we how do we approach it um we just worked with an agency there's a it's a nordcraft only agency they only work in in nordcraft uh because they're kind of picky and like we don't want to do projects that are in northcraft so they're very focused on it we just work with them and they actually helped us rebuild our whole documentation side and as well as a lot of the technical documentation because they are incredibly good at like they they really understand the platform right um and and i think that it's if you're looking into northcraft go and check out the documentation it's it's some of the best i've seen uh as a high level attention detail they did a fantastic job on this one but also a lot of video content, a lot of sort of trying to, how do we try different medias, figure out where people learn.

1:08:33We also have these challenges we added when you first sign up. And the basic idea is, I kind of hate these like step-by-step tutorial where it's just move the mouse to the right and click the button. Right. Okay. Right. So we wanted something a little bit more fun, but that still kind of held your hand. And so our approach is challenges where it kind of sets you a challenge like you're going to build a weather app and you need to add an API, fetch some weather data and you need to add all that data to your UI and this and this and this, right? And it kind of has, it shows you the steps that there's always a chance of it showing you but it kind of like lets you try first and saying, you know, give it a shot.

1:09:18And then if you're not sure, come back, right? So we're trying a lot of different things to sort of figure out what is it that kind of gets people to get it the fastest. I noticed in your welcome email, you allow people to book a personalized onboarding session, which reminded me of, I think, Paul Graham's essay, Do Things That Don't Scale. Something in this one's not going to scale as you get popular. Is that with yourself? Is that with Salma? Is that with your? No, it's literally with me. And the thing is, the worst thing is, I think it might scale. Because no one clicks it or what? Because I don't get a lot.

1:09:58And it's one of my favorite things. I obviously at some point we can't do that. And it's probably not that far away. Like it is. But I think I have two a week of like 15 minute calls. Yeah. It's not that bad. And it's not because there aren't people. It's just, I think just this idea of like. Kind of intimidating. For some people it's a little bit. oh i don't know right developers aren't booking calls for new tools right that's that's similar so so we had it in because if someone want to do that it's generally it's been a good thing right but actually it's it's not like yeah we don't get a lot of people doing it most people very much prefer learning on their own we have a discord server we really recommend everyone going there because it's such a great place to get help and it's a fantastic community but there's also a lot of people who don't want to join a discord server for a new tool right they want to see it first and figure it out and then we'll see about community afterwards right that's fair enough well it's a cool tool i mean i'm impressed very polished seems like you thought through a lot of the things that would stop me as a developer from using something like this such as a way of ejecting such as a way of self-hosting you're obviously getting there in case, you know, Andreas and co no longer exist or get sold or whatever and things change.

1:11:18Or get really greedy. I mean, there's always options saying we just want more money, right? Yeah, or you get greedy. Yeah. Yeah, what's it costing right now? How does it work? What's the pricing look like today? So we think it's very reasonable. You can build like a lot for free. The only time we really start charging you is, well, so by default, we call it the open source plan. The database says, if you're doing a public project that anyone can see and clone, then you don't have to pay for it. As long as we have some traffic limits, et cetera, right? And if you want a custom domain for your application because you're starting to brand it, right?

1:11:55Or if you want it to be a private app that other people can't see because maybe you don't want to build an open source product, right? That's fine. Then you need to go on a paid plan. And they start at$36 per month per developer. And then once you move up to a scale-up plan, which is either when you sort of move past the traffic limitations lower or you get more than three seats, then it's$100 per seat. And is that like collaborative? I guess we haven't talked about collaboration at all, but I assume those seats are like as multiplayer. Like you can be in the same thing, doing different stuff, seeing each other move around you you can do that i would say uh that generally doesn't work as well as people think because being in the same branch like it's kind of like being the same branch in github right it's rare that really that's how you want to work you generally want to work in separate branches so uh you can you can absolutely say in the way this works like if you go into the same branch you'll see the update someone else makes almost as fast as they do right as soon as assuming you're in a similar location.

1:13:06But most of the time, people work async, right? So we, just like in Git, we check out our own branch. That's what we're working on. When we're done doing what we're doing, we'll commit that branch and publish it. If someone else did that since, we are merging their changes and our changes, right? We can see what we're doing. And again, the workflow is exactly like if you're working in a code base with Git. the big difference is that the way you like the way we actually diff the projects because there's no code therefore there's technically no git because that's file based right uh so so we had to we had to change some of the implementation details but the process and the workflows are the same cool stuff adam any other questions for andreas before we let him go i don't think so i don't think so i'm excited about it i think uh you're on something good here don't stop we want we are we are going to keep going because uh excitement only building we've got some really cool things coming uh one thing i'm really excited about is that uh one of our engineers has been working on an animation editor and and i've always felt like animations on the web it was like we we really technically had the tools for doing great animations for like a decade right Right?

1:14:24Like keyframe animations, you can do a lot just with keyframe animations and transitions. They're quite powerful. But if you go and look at people's web apps, especially SaaS apps, they're all super static. Right? They're all kind of boring. And part of it is that while we've had the tools like finally adjusting a keyframe animations and CSS, it's pretty painful. Right? I have to go and say, oh, actually, the timing is a bit off. So now I need to go and move keyframe number three. Am I going to move that 2 % or 3 %? Let's see. And then I go back and then, you know, I'm waiting for live reload.

1:15:03Like that kind of work, like adjusting animation to feel nice, that is fine-tuning work. And code is not great for that because the feedback cycle is so slow, right? So one of the really nice things is that once you have a visual tool with a fast upload, you can start actually building, like an animation keyframe editor and you can you can visualize your keyframes like as in the good old flash stage right we lost something with that went away we also gained something but um but like you can start adding in those kind of keyframes and actually really animate every aspect of something and adjust them and fine-tune them and and that i mean it's the same thing we're seeing now just something like a gradient it's just having a gradient it means that you will actually use gradients because right nobody knows how to type gradients into css you forget it the second you've done it right totally every time having a tool for those kind of things means that you actually use them and it means that the results the output actually gets like more interesting and more sort of delightful i think it's the worst of them so i'm really excited about the animation it's a i he's done such an incredible job and uh we're gonna have a ton of content and tutorials and stuff coming out when that launches.

1:16:20How do you know you're on the right track? Like what is the feedback loop? I know you mentioned the other project, how they're doing some cool stuff. I didn't hear a big name yet necessarily. How do you know you're approaching or near product market fit? Like what is that for you? So product, the hardest part with product market fit is actually for us. Cause I think we have what we call a product customer fit, right? like our customers really love it like they go and make videos about how much they enjoy this they go and talk about it um like sometimes like ad nauseum to other people and and we get complained about people going like look we get it he likes your tool but like you know just can we talk about something else sometimes right um so i had a call with someone from an agency that's like I kind of just took this because he wouldn't shut up about it.

1:17:14Okay, fair enough. Maybe they'll try it. Maybe they'll like it, right? So we have a very strong fit. The number one guiding thing for me is that we are working in this tool every single day, like the whole team, right? Like obviously some of our engineers are working on the backend and different aspects and we write code as well as part of it, right? But the vast majority of the work we do every day in the whole team is inside this tool. And because we're still a small team, we're only 10 people at the moment, right, building this thing. And because we're a small team, it's a very advanced, very experienced team.

1:17:55So these are people who've been building, like, I think our most junior has been doing it for 10 years, right? So most junior is the wrong way of phrasing it. but these are people who've been doing this for, for like a long time and they, they know how to build these things. They are, they're exactly the side of users we, we're looking for as well. And, and like, we know how this works. We, we dog food, as you say, every single day. And once you get to that bit where it clicks and you start working with other people and you figure out how all these things work, that dynamic of designer and developer working together, like the idea of letting go of that afterwards like that that feels awful like the idea of me going back to like having a design handoff with a figma design that i had to go and replicate i mean that feels so backwards right now and personally for me like i i i have like a couple of hundred apps now of projects i've built in northcraft because every time i have a new idea that's always going to be my go-to.

1:18:58Not just because I start company, but because it's just so much easier to get started. It's so much easier to get your ideas out. It's so much easier to build UI visually than it is to sit and write code. And a lot of the other bit, I find that most people I talk to, because it is a big sell, right? It is a big difference, a big shift compared to what people are used to, right? It is quite a radical idea. even though again when you think of the development and like gaming and it probably shouldn't be so radical but it is it is a big shift and and it took me two years to convince myself it was a good idea right like i i didn't believe in it for a long time i've been the hardest one to convince because why wasn't it done right what was i missing what was the thing like okay it looks fine now but what about six months down the line right is it still going to be good and and that was the motivation for starting to rebuild the editor in itself is because i needed a project that was big enough that i got that feel of like what is it is what is it like at scale and now understanding obviously 10 people you can define you can debate whether that's scale right but it's enough to give you the right idea um and now building this tool like if we did that in anything else like i i think doing that in react would slow us down a lot like that we wouldn't be able to move at the same speed um at all because like just just the fact that two of our two out of our 10 team members wouldn't be contributing directly but just feeding in designs right well that's that's that's that's like a lot already so i mean our whole team we're using it we're building all sorts of stuff in it we're constantly jumping we also know all the all the bad parts all the things that aren't as good like there's always this thing is not as good as i want it to be or this thing annoys me but you know we'll see when we get to fix it we also get to feel all the bad parts way earlier than anybody else right um but like really being inside the project having it be your daily driver for everything you do it gives you a very good idea of what it's capable of right i'm thinking i'm just kind of camping out on like this transitional period so you got this you know very uphill battle when it comes to marketing like that's what jared asked about education because he's like how do you how do you how do you convince people they should make this change that they have a problem we all know there's a we just define the problem like your co-founder had the problem i had the problem you've had the problem in the past of like designers and developers working in in the same tool and not double working or having this scenario but i'm just thinking like how not an owl i'm certainly not an owl today but who are you like who was coming into this thing initially is it developers because you've spoken about this allergy of no code and things like that so who is it that's coming in or seeing the the the light so to speak this aha moment that you know is the early adopter it's it's a good question and it is a split like there's not a one clear most people come in like when we ask them what do you identify as are you developer, designer, or something else, right?

1:22:11Most say developer. And then that's like half, around half. And then there's a 50-50 split between designer and none of the above. One of the things that's really interesting is that I think there's more to win as a designer early on, right? Because as a developer, what we're basically saying is this is a slightly nicer way of working, and you probably work a little bit faster, right? And also, again, a big part of the value prop is the fact that building UI is very valuable in a visual environment. I think the logic itself, the reason why that's visual programming is not necessarily because there's anything wrong with code.

1:22:51It's just because context switching quickly gets annoying. So my initial draft, all the logic was done with code and only the UI was built visually. And then I sort of realized that like, okay, but if I'm just like binding a value to an attribute here, it's kind of annoying having to switch to a code editor to do that. Why can't I just do it right there? and then over time that kind of kept growing into a point where I was saying, actually, I kind of want the full power of a programming language without having to context switch out of the app to a code block somewhere, right? But that wasn't really the point.

1:23:28The point was building UI and that's where I think most of the value still is. And for that reason, as a designer, you go from I make a Figma design or maybe I can make a Webflow site to I can actually build an app, right? I can build probably a symbol to start with app, right? So that's a massive value change in what you can certainly do. For developers, it's a little bit less because you could always, like anything you can build with Norcraft, you could probably already build the same thing. But at the same time, the barrier of entry is lower. Like it's easier for developers to understand because what we see people who don't come from a developer background, It's not necessarily that they have a hard time using the tool.

1:24:16It's that they hit those developer problems, right? Of saying, well, I don't actually know how to solve this problem. And it wouldn't really matter whether it was like what the medium was. It's just how do you solve the problem, right? How do you, I have a, let's say I have an array of 25 likes and I need to figure out if I like this post. So you have to search through that list of likes to figure out the one that you made, right? okay, is that, how do I do that? And the answer is like abstractly the same, whether you're doing it in Northcraft or JavaScript. But if you've never done either, right, that doesn't help.

1:24:54Certainly seems like a big win for designers who are consistently interfacing with their developers, building applications, not obviously building out other things that are not applications because that's what this is for. because you don't have the risk of your research and your baby and all your work not getting translated well and you get to work directly in a tool that is essentially as real time as real time can be to your production interface you can branch you could do all these fun things and you don't have to double the work your team doesn't have to do the double the work so from from a business standpoint it's like well we could save a lot of money and the tool is actually the one tool is the one tool.

1:25:42It's not this tool and that tool in some sort of translation period. It's in this static design pixel perfect world that has to get translated. So it sounds like designers are probably your first customers and developers, engineers following suit because they're being pulled maybe happily. I'm not sure. I'm not sure. Whenever we go, whenever we talk to companies, that's how we go about it, right? We're saying this is a tool for your designers that brings your developers in um and that's very much our strategy of course when it's just people trying it out people come in for whatever that interests them right yeah um but one of the interesting thing about the design profession is that as i said well with frameworks we we definitely push them out of the browser right they're not working that anymore but we sort of pigeonhole designers a little bit and i think design tools are maybe a bit to blame as well right because we have ui ux designers working in figma but you cannot do ux design in figma right there's nothing for you there it makes like it can do a semi-responsive website but what about keyboard interaction right like those things have to be designed what about um like there's so many aspects of ux which is until you touch and feel the application that is the user experience like So we've kind of cut a lot of that roll off and say, actually, so today in a standard dev team, developers, front-end developers, does more UX than UX designers because they're the one who actually hands on, right?

1:27:18I remember talking to my partner and saying, like, I talked to him about tab index and he's like, what is tab index? Because, I mean, he didn't know, right? Well, that's basically how you decide what order you're going to go through the interface when you press the tap key and which things can be focused, which things can't. That is a big part of UX. But there's none of that in Figma, right? And I would probably guess that a lot of especially younger UX designers today have no idea because they don't have the tools to work with that, right? By the time that becomes relevant, that is way into the developer domain.

1:27:58You also get to fast forward a lot too because I've made design choices that were incorrect. And it was evident immediately as soon as you use the real application. It's like, oh my gosh, we actually implemented it the way I wanted to. But what I designed was static. It wasn't really usable. Or in modern tooling, you can do a lot of this step through something like that. but you can sort of define some of the UX, but not all of it. And so until you see the real thing and the real thing, you're kind of making some educated guesses and hoping that your selections are right. And they weren't so wrong that you got to do a bunch of rework.

1:28:36Yeah. And we actually usually do what we sort of dubbed jokingly, the reverse handoff, which a lot of times I will build something hideous. And we actually almost made a sport out of making UI that's as ugly as possible before we hand it off to designer. because then the designer would actually do the UI, right? We just technically needed the data on the screen, right? Because when they're designing, they're designing with real data, real application right there. Like everything they're doing, right? And I mean, they'll be rearranging the stuff around and making sure it's layout, everything, right?

1:29:12But it's the real app. And the funny thing is when we talk responsive design, we always talk about like changing the width of the browser, right? but there's a lot more to it because the content changes, right? So everyone, every developer has at some point received the design that looked great and then come back and say, what do I do when the title is 120 characters? And then it's like, well, then actually, unfortunately, the whole design falls apart because it can't break line. There's not enough room and it can't overflow. And do we do a tool tip? Like these kinds of things. What happens when there are no tags on this element?

1:29:48Because then it just leaves this massive white space in the middle. all the two nodes like all these things will design change based on data when you're building dynamic applications so if you can't see the data you don't know the cases right and that's why we have these sort of like back and forth and our teams all the time of like well what about this case right well this has certainly been probably the most expensive part of most build outs in the history of web development is the glue between design and dev and implementation front and back end like all the seams where we come together and collaborate it always gets very expensive and you can save a lot of money if you have teams that are good at collaborating around those things and catching stuff early but that takes time and experience and so having a tool where you can meet in the middle, develop in the middle, and design in the middle, and get that quick feedback certainly, I think, needs to exist.

1:30:52I'm excited that y 'all are building one, and that it's going to be open source, and that it's polished and ready to be used. So I'm going to give this thing a shot. I'm going to try to build a really ugly UI, and I'm going to pass it to Adam and see if he can make it look better. Yeah. I mean, I find that all the named HTML colors are really good in this case. Like there's a lot of, yeah, there's a lot of good ones there. You don't need to go into any of this hex business. Just pick one that has a name. That's kind of the best ones. That's my strategy before I hand off to a designer. This hex business.

1:31:31That's what it is. Very cool. And Andreas, thanks for sharing with us, man. Well, thank you very much for having me. It's been a pleasure. I've been listening to the show for so long. So it's really exciting to be on it. Very cool. Glad to have you here. Absolutely.

1:31:51So I love the idea of this gaming engine, this web dev engine for developers. Having been in the trenches in design to dev workflows for many, many times, many, many years with very mixed results. It's just refreshing to see a team like this approach such a big, ambitious goal. And they're doing it. Check them out, Nordcraft.com if you haven't already. Big thanks to our friends over at Heroku for sponsoring this show. Our friends over at Depot, Depot.dev. Check them out. And of course, our friends at Fly.io. And to the Beat Freak in Residence Breakmaster Cylinder. Those banging beats. Love those beats.

1:32:35Okay, show's done. We'll see you on Friday.

1:33:07Thank you.