The Web Development Engine  ## Metadata - Author: [[Changelog Master Feed]] - Full Title: The Web Development Engine - Category: #podcasts - URL: https://share.snipd.com/episode/528951e4-7b7b-446a-990b-8c4e1cb54f06 ## Document Notes ## Highlights - **Embrace Challenging Problem Solving** - Lean into challenges instead of always seeking the easiest solution. - Try solving problems yourself before looking for existing code or libraries. Transcript: Andreas Møller Don't choose the path of least resistance can you unpack that for us why why not what does it mean yeah absolutely so i think um i mean a little bit of context obviously if you're if you have A job and and you're you've been tasked with building something you don't always have to go the hardest possible way of doing everything but i think there's something to be set for leaning Into the challenges when they when they present themselves so if you're always like if your solution to every problem is is their library that does that without looking into how to actually Solve the problem? Or if you're the kind of person who likes to hang around Stack Overflow and see if there's an existing solution to everything. It's good to look it up, but I always would say give it a try first. And throughout my career, especially with a lot of junior developers, there's this sort of attitude that like, oh, I'll go and look here. I'll go and find it here. And a lot of the times, the part where you really learn something is when you sit down and take your time. So actually leaning into saying, this is a hard problem. It's going to be difficult to solve, but I'm going to try and figure it out. And I'm not going to look ([Time 0:04:56](https://share.snipd.com/snip/a45867d0-823a-4994-bdd8-34dedc31626a)) - **Visual Programming's Gaming Niche** - Visual programming is ancient but hasn't taken off widely outside gaming. - Gaming uniquely requires visual tools for complex projects, unlike web development. Transcript: Andreas Møller It hasn't really taken off, right? It's always died down again, except in one industry, which is gaming. Adam Stacoviak Yeah. Andreas Møller And I thought that is the weirdest thing in the whole world. So if you're building a triple A game that takes 10 years and take some of the brightest minds of our engineering industry, right? Then you can use a visual tool to build most of the game. But if you do it in 2D and it's just a website then that doesn't work and i'm like that doesn't make any sense there must be something i'm missing here right there must be something i'm not Seeing but why it is that that's the only industry where not only is it possible it is an absolute necessity without those tools you cannot compete right yeah that's interesting i've Adam Stacoviak Never developed a game before so i don't know that for sure how it works but that does make sense i mean it as a designer so i'm a i came up in design came up in user experience design product Management um i was like a product owner for the company leading and that ([Time 0:10:58](https://share.snipd.com/snip/ab4a405a-f2b4-414d-b5f2-b407b77c5156)) - **Nordcraft as Visual Language** - Nordcraft acts as a programming language with built-in framework but uses a visual syntax tree. - The code abstract syntax tree is the source of truth instead of text code. Transcript: Andreas Møller You have in the game world. How would that look if we built that for the web? Jerod Santo So go ahead, explain the tech to us, you know, exactly what it is, how it works. Andreas Møller We're all developers here so hopefully we don't get completely locked into something that it's not no so i mean um probably the simplest way of of again we use a lot this this analogy to The game engine right where a game engine is come like is a sort of big uh box of a lot of different things it has rendering engines physics engines audio engines animations engines all These things and then that's all tied into a central framework for building games that sort of powers the game loop and everything and then on top of that they have these list suite of Visual tools and most of the people working them are like a mix of some developers a lot of designers but they're all working the same tools and these tools essentially program the engine Right and we're not just talking like building characters right it's not just that they're using visual tooling for like 3d modeling etc most of the game logic is building visual scripting So in unity it's called blueprint in in um now in unity it's called i think it's just called Visual Scripting. In Unreal Engine, it's called Blueprint, right? And I didn't realize this at the time when we started, but actually like the AAA games today, most of the game logic is built with visual programming, right? Which for me was such a mind-blowing moment because like, we just rejected this every other industry. We're going, okay, that's cute. That's for Sketch. That's for children. Right. But when we look at these big, massive games we play, they've been built this way. There is a lot of code involved. There's a lot of really talented engineers working there. But a lot of the logic is built using these visual tools. And so the basic idea was, what if we build web apps the same way? So the best way of describing it on a technical level is probably that it is, in effect, a programming language with a built-in framework. But the biggest difference between, like, if you're familiar with Elm, that's actually a really good analogy as a programming language. So Elm was this programming language with a built-in framework. Its architecture was the inspiration, like the Elm architecture was the inspiration for Redux when that came out. But it was a whole language built just around the idea of building front-end apps, right? And Nordcraft is actually the same, but instead of the code part, right? Normally, when you ([Time 0:28:20](https://share.snipd.com/snip/9beef4d5-0c2a-4f60-9f07-8620287cf3c0)) - **Nordcraft Powers Real E-commerce** - A user built a Malaysian Shopify competitor using Nordcraft and processed over $10 million in orders. - This demonstrates Nordcraft's capability to power serious, revenue-generating applications. Transcript: Andreas Møller But in malaysia apparently the way shop does card payments means that it's almost impossible to use. So he built like an 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 uh concept to it and i think he he's already processed like orders for over 10 million dollars In in that one stop uh like in that project and i think like on the first day he launched within the 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 the biggest project, like the whole editor That you're using right now, we're building in Nordcraft as well, right? Gotcha. So it's like self-hosted in that way. Jerod Santo What's the language? I mean, you said you created a language and a framework together. Do you know, I mean, ([Time 0:38:30](https://share.snipd.com/snip/0b3d81b2-1b8b-4fbc-a55d-3bbfdc3eb043)) - **Programs Stored as Syntax Trees** - Nordcraft stores and edits programs as ASTs, bypassing text-based code editing. - Editing is visual and direct on the abstract syntax tree structure. Transcript: Andreas Møller Apply it, right? And 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. So when you're building a formula, you are clicking you are saying add ([Time 0:42:50](https://share.snipd.com/snip/451d495b-f09c-4b07-8763-90a196fa0497)) - **Extend Nordcraft with Custom Code** - Use custom code in Nordcraft only when you need to do something not yet supported. - Custom actions provide a foreign function interface to extend functionality. Transcript: Jerod Santo 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 is limiting me. I need to do something outside of the 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 Andreas Møller Rendering yeah so the um so the the whole idea of custom code we call them custom actions custom formulas okay uh 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 is a lot of things you can do in nordcraft without ever touching any code but um not everything i i often use the example Of like i wanted to i wanted to build something that i could use uh i wanted to try the bluetooth api right and so i made an a simple example where i could use a PlayStation controller to browse A website, right? 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. To 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 like when Node came out, it could do a lot of things, but like most of the libraries were just bindings to C, right? It was just, here is the JavaScript interface. I'm actually calling some C code underneath, right? And 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 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 add do something That nordcraft can't do yet right um you can create this custom action and it's essentially a foreign interface you go and say, 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. You can write whatever code you want. And it allows you to say, 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 you want to use that or if like 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 this div is where nordcraft just like you were doing react right this is the div where Nordcraft stops touching the content inside. And 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, and this is not us coming up with something fantastically new. This is the same thing React does whenever you're like opting out of React for rendering. Right. And it's the same thing every program's language has done for like foreign interface. There are also cases where it's just like we ran into an example the other day. It was like a markdown parser. Where I was like, yeah, I mean, just use the JavaScript one. And we had an engineer who definitely felt like he wanted to build it natively into Nordcraft. But it's like, yeah, it's not a great tool for building like a markdown parser. That's not the point, right? JavaScript can do that just fine. ([Time 0:44:20](https://share.snipd.com/snip/73c5068a-7780-4cf6-9108-3d9814333247)) - **Near Real-Time Branch Deployments** - Nordcraft uses Cloudflare Durable Objects for branch deployments and version control. - Live previews update under 100ms, providing a near real-time development experience. Transcript: Adam Stacoviak I don't know how to answer 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. It's your lab in production when you're building or staging. Andreas Møller So how detailed do you want to go? As deep as you want. Okay. Adam Stacoviak So that's basically two. 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 Andreas Møller Space then um so the we built this uh our version our hosting, on top of Cloudflare. Because Cloudflare kind of uniquely has a bunch of services that are very interesting for us. One of them is something called Durable Objects. And what a Durable Object is, is essentially a serverless worker with state. And 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 and we have version control, it's not technically Git, but we copy 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. So 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. If you connect to the same branch, it's going 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. I 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 7 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 below 100 milliseconds from I make aegaSave to UCLive, 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. So 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. And we are rendering, like whenever you make a request to a page, we are rendering that whole page based on our code. And we actually looked into caching. And the funny thing is it didn't do much because 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. When you start adding data, then when that page needs data in order to render, obviously there's a different question. Right. Does that answer it? Does that make sense? ([Time 1:01:45](https://share.snipd.com/snip/f1a95d91-efef-4be1-8a5f-07ae726900b0)) - **Learn with Interactive Challenges** - Learn Nordcraft through challenges that guide you to build real apps. - Try tasks first before consulting hints to deepen understanding. Transcript: Andreas Møller How are you approaching education? We hired a really great person for education, a common friend, I believe, to help us with that um salma that's her role yeah okay is our is our head of um education so education is a big is A big part of this right um 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 um we've seen a lot of people where they have like how how do i submit a form like it's a form right you you know how to submit a form you just have to see that because the visual Interface you thought there was all sorts of other things but it's it's the same way you think right there's a button inside click the button submits the form right so there's there's Those kind of things that that that people often a little bit have to get over but after that it actually is very familiar uh if you've used the framework before right um 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 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 nordcraft 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 Nordgraph, 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. Um, but also a lot of video content, a lot of sort of trying to, how do we, how do we try different medias, figure out what people learn. We also have these challenges we added when you first sign up. And the basic idea is I kind of hate these like step-by 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's 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. ([Time 1:06:23](https://share.snipd.com/snip/d39e7a5d-4ad8-47e6-a3ae-762a68faf631)) - **Strong Dogfooding Drives Fit** - Nordcraft team dogfoods the tool daily and sees strong product-customer fit. - Experienced developers and designers collaborate efficiently, speeding up development. Transcript: Adam Stacoviak Like what is that for you? Andreas Møller 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 okay fair enough uh maybe they'll try it maybe they'll like it right um so so we have a very strong fit the the number one guiding thing for me is that Um 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. So 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 like a long time they, they know how to build these things. They are, they're exactly the side of users we were 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 not not 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, like I think 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 like gaming and so on, it probably shouldn't be so radical, but it is a big shift. 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 like at scale? And now understanding, obviously, 10 people you can debate whether that's scale, right? But it's enough to give you the right idea. 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 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 ([Time 1:16:37](https://share.snipd.com/snip/c97b4f76-2e16-4e2f-839a-222910ef3d9e)) - **Designers Benefit Early Most** - Designers gain more early value from Nordcraft by building direct web app UIs. - Developers benefit from lower barriers and visual UI building efficiencies. Transcript: Andreas Møller I can build probably a symbol to start with app. So that's a massive value change in in what you can what you can certainly do for developers it's a little bit uh less because you could always like anything you can build with northcraft You could probably already build uh the same thing but at the same time the um the barrier of entry is lower like it's easier for developers to understand because what i 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. It'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, 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, right? And the answer is like abstractly the same whether you're doing it in Northcraft or JavaScript. ([Time 1:23:43](https://share.snipd.com/snip/2ad9e0d2-a910-4d52-b3a9-df0316c2a3cb)) - **Reverse Handoff Enhances Design** - The team does "reverse handoffs" by building ugly UI to let designers polish real, dynamic interfaces. - This improves design accuracy by showing real data and edge cases. Transcript: Andreas Møller Yeah. 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 to let the data on the screen, right? Because that, when they're designing, they're designing with real data, real application right there. Like everything they're doing, right? And, and I mean, they'll be rearranging the stuff around and, and, and making sure it's layout, the right, right? But 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 a 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 tooltip? Like these kind of things. What happens when there are no tags on this element? Because 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 in our teams all the time of like, well, what about this case? ([Time 1:28:36](https://share.snipd.com/snip/68915739-9948-486d-8f8e-4b0d7db7190f))