Lambdragon with Aldo Bucchi
Aldo Bucchi introduces Lambdragon, a pure code platform extending TypeScript to let developers build entire startups without leaving their code editor.
Episode Description
Aldo Bucchi introduces Lambdragon, a pure code platform extending TypeScript to let developers build entire startups without leaving their code editor.
Episode Summary
Aldo Bucchi joins Anthony Campolo and Christopher Burns to explain Lambdragon, a pure code platform built on TypeScript that aims to let developers create complete applications—web apps, mobile apps, CLIs, databases, and more—without ever leaving their code editor or writing configuration files. Rather than building an entirely new language, which historically leads to adoption problems, Lambdragon extends TypeScript with enhancements to the compiler, bundler, and IDE while maintaining full compatibility. The team is launching in stages, starting with Dragon Build, a build tool that can shrink complex monorepo codebases by 30 to 50 percent and eliminate most configuration overhead. Bucchi discusses go-to-market strategies including greenfield project adoption and a strangler pattern for migrating existing codebases, while also situating Lambdragon within a broader ecosystem of companies like Pulumi, Temporal, Serverless Cloud, and Cloudflare that are each pushing toward pure code experiences in different niches. The conversation touches on business models, vendor lock-in philosophy, the importance of developer experience as a competitive moat, and how a blog post by Swix about self-provisioning runtimes helped crystallize public interest in the pure code movement that Bucchi had been championing for years.
Chapters
00:00:00 - Introducing Lambdragon and the Pure Code Vision
Anthony Campolo sets up this condensed episode as a companion to a longer discussion about the history behind Lambdragon. Aldo Bucchi wastes no time explaining the core concept: a pure code platform where developers never leave their code editor, eliminating CLIs, configuration files, and context-switching entirely. The idea is that if you designed a language from scratch considering all requirements—data, APIs, microservices, deployment—you could encode everything into the language itself.
However, Bucchi acknowledges that creating an entirely new language leads to adoption dead ends, citing projects like Dark Lang, Ectasy, and Eve that became isolated ecosystems. The solution Lambdragon pursues is extending TypeScript without breaking compatibility—adding capabilities to the compiler, bundler, and IDE so developers can theoretically build an entire startup in a single file. While nobody would actually work that way, the point is that the language provides enough built-in capability that external tooling becomes unnecessary.
00:03:15 - From Big Vision to Staged Releases
Bucchi candidly discusses the challenge of marketing such an ambitious vision, noting that the code looks deceptively simple and familiar, making it hard for people to grasp the value underneath. Advisors and mentors helped him realize the solution was breaking the vision into smaller, deliverable pieces rather than trying to launch everything at once.
The first product, Dragon Build, targets the exploding complexity in the monorepo space by applying innovations from the broader pure code research to shrink codebases by 30 to 50 percent and dramatically improve build speeds. Bucchi positions this against existing tools like Rome and Turborepo, claiming Lambdragon offers something more opinionated that no other tool can match. He also previews a second stage around infrastructure as code, referencing Serverless Cloud, Cloudflare Workers, Pulumi, and AWS CDK as evidence that the space is already moving toward pure code approaches for cloud infrastructure.
00:06:09 - Go-to-Market Strategy and Migration Paths
Christopher Burns asks whether Lambdragon targets new projects or parachutes into large existing companies. Bucchi explains that greenfield projects are the ideal starting point since the platform uses a cleaner code layout with consolidated dependencies and more flexible test organization. For existing projects, the team offers two approaches: an automatic rewriting tool for well-structured TypeScript monorepos, and a strangler pattern where Lambdragon is added as a single package inside an existing monorepo setup.
The strangler pattern allows teams to gradually migrate code into the Lambdragon-powered package without disrupting their current Yarn Workspaces, NX, or Lerna setup. Bucchi expresses a preference for this incremental approach in large projects where full rewrites are rarely practical due to accumulated workflows and institutional knowledge beyond just the codebase itself.
00:08:27 - Business Model and Open Source Strategy
Chris asks about pricing and open source plans, prompting a lighthearted correction—it's Lambdragon, not Lambda Dragon, symbolizing JavaScript and TypeScript infused with dragon DNA. Bucchi outlines the business model: the build tool will be open source, while the long-term revenue comes from a cloud deployment platform. Potential paid features include collaboration tools for large teams, CI integration, build caching, and premium IDE features.
The current fundraising round aims to establish a strong foothold in the tooling market through developer adoption, positioning Lambdragon not as another monorepo tool but as an alternative to monorepos entirely. Bucchi frames the broader mission as an inevitable simplification of development, comparing it to how Netlify and Vercel abstract away complexity. He argues that if you keep removing unnecessary layers, you eventually arrive at pure code—a fixed point where nothing more can be stripped away.
00:12:32 - Competition and the Pure Code Landscape
Burns asks whether competitors will emerge and whether Lambdragon can capture market share. Bucchi welcomes the question, identifying Pulumi, Temporal, Serverless Cloud, and Cloudflare Workers as companies already moving toward pure code from different angles. He describes how Temporal abstracts workflow infrastructure, how Pulumi speaks to DevOps professionals, and how Serverless Cloud targets full-stack JavaScript developers more directly.
Bucchi acknowledges his team is small and currently strong only on the technical side, which is exactly why they're raising capital and actively searching for co-founders with product and marketing expertise. He sees the pure code space as having room for multiple winners across different niches rather than a single dominant player, but believes Lambdragon's comprehensive vision—spanning build tools, infrastructure, and application frameworks—gives it a unique position to claim the broadest territory.
00:16:41 - Vendor Lock-in, Developer Experience, and Runtime Optimization
The discussion turns to lock-in strategy, and Bucchi explains his philosophy evolves over time. In the tooling phase, lock-in comes purely from providing a superior experience since developers can always rewrite. The deeper moat comes later through runtime optimization—a black box that learns from usage patterns and dynamically optimizes function placement, data co-location, and edge caching based on observed behavior, similar to how Java's just-in-time compiler became an irreplaceable competitive advantage.
Bucchi envisions a future where developers write the same simple code whether building a small app or something at Facebook's scale, with the platform handling all infrastructure decisions automatically. This self-optimizing runtime represents the ultimate lock-in: not through restricting developers, but through accumulating optimization intelligence that would take competitors years to replicate.
00:21:29 - Swix's Blog Post and the Pure Code Zeitgeist
Anthony Campolo asks about a pivotal blog post by Swix (Sean Wang) that seemed to galvanize interest in the pure code concept. Bucchi credits fifty percent timing and fifty percent Sean's communication talent, noting that his large reach allowed the ideas to blanket the JavaScript community simultaneously rather than diffusing through smaller channels. The post's release coincided with Serverless Cloud's launch, creating a perfect moment of convergence.
Bucchi reflects on spending a decade discussing these ideas with limited traction before the blog post suddenly filled his inbox with people saying they finally understood his vision. He broadens the pure code discussion beyond self-provisioning runtimes to include the application layer—web frameworks, mobile apps, and CLIs—noting that the ongoing turbulence around rendering modes in frameworks like Redwood and Astro will eventually settle, making it feasible to incorporate web development into the pure code paradigm. The episode closes with social media handles and pointers to the companion long-form episode.
Transcript
00:00:00 - Aldo Bucchi
I need to be able to condense it more because we always run over the 30 minutes.
00:00:14 - Anthony Campolo
Aldo, welcome to the show. This is a bit of a unique thing we're doing here for FSJam. We're actually going to be airing two episodes simultaneously. We did a long previous conversation about the history and motivations of your new project, Lambdragon, but we wanted to also do a slightly more condensed explanation of what it is, how it works, and give people just the high-level of what Lambdragon is.
00:00:40 - Aldo Bucchi
I appreciate the exception that you're making. Anthony and Chris, in our previous talk, we just rambled and we went down a few rabbit holes, but I think it's important to try and summarize it.
So what we're building at Lambdragon is what we call a pure code platform. A pure code platform is actually a very simple concept. The idea is you open your code editor and you don't leave it, and you can create a whole startup without having to open a CLI, without having to change a single line of configuration.
And this should be entirely possible, right? So if you were to create a language from scratch and you consider all of the requirements, data, different kinds of products and different kinds of channels and microservices and all that, and you were to consider them from the beginning, you should, in theory, be able to create a language that has all of these things. Therefore, you don't need to do anything else, right? Just like languages have functions and classes and variables that are immutable and we keep adding features, in theory you could add more and more and more features until everything is considered.
[00:01:38] Unfortunately, you can't really do that. You can't just create a new language from scratch. I mean, you can, but you will end up with something that is really hard to share with the world.
So there are great projects out there that have tried to do this, like Dark Lang and Ectasy and Eve. There's a whole line of programming languages that try to do more, incorporate data, persistence, APIs, HTTP. But the problem is that they end up being a world unto themselves and they have an adoption problem.
So you have a conflict. You want to create a new language to incorporate all these features, but you can't really create a new language, otherwise it won't work. So what's the middle ground there? What could you actually do?
What you could do is take a programming language that already exists, like TypeScript or Java or Go or something like that, and you could extend it without breaking compatibility, without making it into a new thing. You could extend it somehow to include all of these requirements.
[00:02:25] What Lambdragon is, is a pure code programming platform for TypeScript, where we've taken the language and we've extended it very slightly. We don't change the syntax or anything. We just add new tricks to the compiler, to the bundler, to the IDE, so that you can create a complete startup with, let's say, a web application, a static site, three databases, server-side logic, transactional logic, an npm library, a CLI, an Electron app, a mobile app, whatever you want. Everything.
You can create that in a single file of code without leaving. You don't even need to leave the file to build or test. It's all there. Of course, you will never end up creating everything in one file. You can still split it and you can use modules and all that, but you don't have to. That's the point. The language gives you enough. That's what Lambdragon is. That's our vision. And that's something that we have already been working on for two or three years.
[00:03:15] And even in the prototypes three years ago, we were already achieving incredible results. Now the problem with the vision is so big that it's hard to get there, not just technically. There are a lot of technical challenges, but it's also hard to market something like this because it feels very alien. It's hard for people to get their head around. When you look at the code, it looks so familiar and so simple that you don't necessarily see all the value.
So we started running into this kind of problem a while ago. But along this journey, I've learned from great advisors and mentors and some of my investors and friends. I've learned we can take this big vision and we can split it into small pieces. That's what we're doing now. So we have this big vision that we're going towards, and we're going to get there in the next five years, and the whole world is going to move to pure code, and I'm 100% sure of that. In the meantime, we are going to start releasing limited versions of this platform to perform specific tasks.
[00:04:06] So the first one is called Dragon Build. It's a build tool that allows you to take your very complex monorepo. And by applying some of the innovations that we had to develop for the bigger pure code idea, by applying these innovations, you can shrink your code base by 30 to 50%. You can eliminate most of the configuration. The build speeds go through the roof. It's very easy to navigate.
That's why the way I've been talking about this first stage has been all about complexity and hypercomplexity, because I think that is the problem that we can solve in this stage. You have this explosion in complexity now in the monorepo space as a reaction. We have tools like Rome and Turborepo and a bunch of other build acceleration and consolidated toolchains appearing. We are going to give you another tool that is slightly more opinionated, but it does things that no other tool can do.
That's kind of our first stage, and that's where I want to focus now. The second stage is also kind of starting to unravel as we speak around the infrastructure as code world.
[00:05:04] So you have Serverless Cloud, which just launched the Runtime on the Cloud service. You have Cloudflare, which also has some sort of runtime on the cloud. You've had Pulumi for a long time with infrastructure as code derived from high-level languages like Java and Go, so you don't need to write a YAML file or an HCL or a Terraform file. You write code and then that gets translated. The AWS CDK is also trying to consolidate that, so providing a pure code layer on top of CloudFormation and so on.
So that space is already moving forward, and we also have technology there. But for this stage we're going to focus on the build side of things. That's kind of what we've arrived at at this point.
And by the way, we're fundraising now and we're in the middle of a fundraising week that's going amazing. If I sound a little tired, it's because I am. I've been pitching ten, 15 times a day sometimes, and it's been amazing. It's been amazing. I have to say, it's not just that we're going to get funding, it's also just going through this process and pitching all these bright minds and getting feedback and getting challenged at every turn.
[00:06:04] It has really forced me to work on the strategy and especially on the go-to-market side. I'm very happy about where we are right now.
00:06:09 - Christopher Burns
I'm really interested in talking about the go-to-market strategy. Are you saying with Lambdragon you want to help companies from the start of their project? Or are you saying we're going to deploy and parachute down to the top 5% of companies and really solve the biggest issues that they have?
00:06:25 - Aldo Bucchi
The easiest answer to that is always greenfield projects. New projects use our tool. We're going to focus on that one first, because if you really want to get all of the advantages that you can get from using our platform, the code layout is slightly different. We remove a lot of the barriers that appear in monorepos.
So you can have a single source tree, and the way you can add tests and mix the tests with your code, you have much more freedom in that sense. The way you manage dependencies is also different. So you don't need to have like 60 different package.json files. There's a different way where you can consolidate them and then add smart rules in cases where you need to deal with conflicts. The way you would split your projects into packages is different. So for example, you would have an npm library or npm libraries and then a website, or that also goes away. If you really want to take advantage of what you can do with our tooling, it's better to start from scratch.
[00:07:13] It's a cleaner layout that gives you much more freedom and speed. Having said that, there are two ways that we can approach existing projects.
So one of them is we have a tool that allows you to rewrite automatically starting from some standard monorepo layout. So if you're using TypeScript and you have your project references done right and all that, this rewrite is automatic. There might be some corner cases, but they're usually isolated and they're easy to understand. That's one way of doing it.
The other way is you can actually add Lambdragon into your monorepo as a package, so you don't need to throw anything away. Let's say that you're using NX, or you're using Yarn Workspaces or Lerna or whatever, like any of the many tools now for monorepo management. You don't need to change that. You just create one package that is now going to be powered by Lambdragon, and it plays well with everything else. But now you can start slowly migrating code into this package that is linear, that gives you a better experience.
[00:08:06] In that sense, it's kind of a strangler pattern, right, where you slowly start migrating things until there's nothing left to migrate. That's my preferred choice for large projects. Obviously, having the freedom to rewrite a complete project happens rarely because it's not just the code, right? You also have issues that are pointing to places and you have some knowledge and workflows. But if you can, you should rewrite. If you can't, then you can do this one.
00:08:27 - Christopher Burns
You quickly mentioned the Lambdragon build tool. Is there going to be an open source hook into Lambdragon, or is it all paid for features? I guess the biggest question that I have is how is a developer going to integrate into it? How will they know how much they pay for what they pay for? Are we looking at a license kind of model with Remix, or are we looking at more of a SaaS-based Netlify Gatsby Cloud model where they would pay to build your application?
00:08:59 - Aldo Bucchi
Yeah. So first it's called Lambdragon. Lambdragon. It's not a lambda dragon. It's actually a little lamp with dragon DNA. It symbolizes the fact that we are taking JavaScript and TypeScript and we are adding dragon DNA. We are splicing technology into this existing stack.
I don't know, it started a little bit as a joke, and then it just has a life of its own. Now the little dragon is driving the company.
00:09:21 - Christopher Burns
What can I say, I am dyslexic, but yes, it is Lambdragon.
00:09:25 - Aldo Bucchi
No, no, no, it's good, it's good. We get a chance to explain to the rest of the world.
So in the end, we're going to have a cloud. If you deploy to our cloud, that's our business model, right? But in the beginning, especially right now, we're going to release the build tool. Only the build tool is going to be open source. Of course we have time to figure it out. But right now what we're looking at are the usual candidates there.
So one is collaboration. So for large companies that are using this, they're going to need some tools related to CI and collaboration, build caching if necessary. There is also an IDE. You guys know me from developing IDEs. That's my claim to fame in this group. I'm a tooling developer and I love developer experience. Our IDE is going to be loaded with a lot of features, and some of those features we might choose to charge. We don't know yet. I don't think we need to make that decision right now.
[00:10:09] So for us, the main goal of this phase and the reason why we're raising this round at this point is to get a strong foothold in the tooling market from a traction point of view, and we know exactly how to do that. We're going to augment it slightly to create an alternative to monorepos. We're not going to be another monorepo tool. We're proposing something else.
As the company evolves, we're going to go through different product offerings. The end game is actually building a runtime that's a story for another day. We have time to go there. I've worked in R&D all my life, and when you work in R&D, you learn something: you can, in theory, build the future.
Right now, I could build a future on my machine, provided that I have enough time to study and I find the right people and I know the right questions. I could build the future right now. Maybe I already have it here, but it doesn't matter because it's just me. What you need to do now is carry the world with you to this new reality.
[00:10:58] And that is the challenge of our company. We have a very clear idea of where we are going to end up, which is an inevitable thing, by the way. It's not something that we creatively propose. It's something that we uncover by understanding the forces at play here.
Every startup that you have on your show in some way is simplifying some workflow. All of the dev tools startups, all of the cloud abstraction startups, Netlify and Vercel, they're also simplifying on top of someone else, right? They are just making it easier for a developer. And how do they do that? They remove what's not needed. They realize that there are some things that for certain users can be abstracted. That's the whole game.
If you keep pushing this and you keep going and you give it enough iterations, what you will arrive at is a point where there's nothing left that can be removed. And there is a fixed point as well that you need to consider. And this is something that's given by the environment.
[00:11:47] Now JavaScript and TypeScript will continue growing and will only become more and more relevant. And this is not just because they're popular now, but it's also because web technologies are embracing them and are based on this. So look at what's happening with Deno and the APIs and how they're matching the browser API.
So we are arriving at a point where it's clear and it's been clear for a long time, but it's manifesting itself that web technologies are going to take over development. Every newcomer to the software world these days learns JavaScript. Nobody says, I'm just going to be a Python developer and I'll never touch this. It just doesn't work that way. So the end game is JavaScript, and TypeScript must include these missing features so that development can be simplified and microservices and cloud programming are built in.
00:12:32 - Christopher Burns
You've spoken about the future market, about how within the next five years, we're going to see a pure code movement. Do you expect other companies to pop up? Do you think you're currently ahead of such companies that will pop up in this space? And do you think you have the time and knowledge to take a majority share of the pure code market?
00:12:54 - Aldo Bucchi
Of course, I expect companies to show up. I love your question. This is the whole game here. Let's assume that what I said is true. Let's start there. Let's assume that this is going to happen and it's going to happen within five to 10 years. So it makes sense to start a company now that tries to claim this throne.
There are other companies already moving in this direction. So I mentioned a few. If you look at Pulumi, they've been working on pure code for infrastructure for a long time. They've done some technological progress. They have, of course, the infrastructure part more figured out. Now you have Serverless jumping in. Then you have something like Temporal that is coming at it from a different point of view, but they're also chasing the same idea. In the case of Temporal, what they are abstracting from you is if you want to create long-running workflow processes, you don't need to set up a workflow engine anymore. You use Temporal and then you can say, thread sleep one week, and they will take the stack and they will take whatever is reachable from the heap and, who knows how they're doing it, but they will resume this job later for you.
[00:13:50] So from a developer point of view, that is a pure code experience. You are now thinking in terms of code, but the result of writing that code means that there's a lot of infrastructure deployed for you. But the intent is described in code.
So I expect this phase to be not crowded because there are some technical challenges and ideological kind of clarity challenges around it. But by no means is my company going to be the only one. I think that there's going to be multiple winners in this space first. There are different markets, so Temporal is a good example. If Temporal succeeds in going after companies that are currently looking at workflow engines and they think about workflow engines, then they could eat that whole market, which is huge. I mean, look at all the users that use Amazon Simple Workflow Service, for example. And by the way, the founder of Temporal has been working on this famous project for a while. Temporal might choose to just focus on that niche with a pure code strategy.
[00:14:40] Then Pulumi might choose to stay closer to DevOps. Pulumi technology speaks to DevOps people that were used to building CloudFormation templates and used to writing Terraform by hand almost some time ago, and they are now looking at this.
They could also choose to go higher to application developers, but it's harder to change the tone of the whole company to talk to these people. And you could already see that playing out with Pulumi Cloud. Pulumi Cloud is very similar to Serverless Cloud, but it doesn't speak as clearly to full-stack JavaScript developers, mainly because Pulumi is associated with so much more right on the DevOps side.
So it feels like when you read it as a JavaScript developer, even if you understand Pulumi Cloud, you still feel like you don't understand anything because it's surrounded by all of this. But if you look at Serverless, it's simpler. And then you have Cloudflare. They're also following a similar approach with Workers, the way they are enabling persistence there. And then you have other players like Netlify or Vercel, which from the surface might seem that they are not doing this.
[00:15:41] But if you look at how in the case of Next, creating a function is now easier, it gets easier every time. In the case of Netlify, again, you just write it and put it in the right place and it will work. You could also argue that that's a pure code approach. You just need to know where to put it. There are some conventions, right? But the conventions are slowly getting smaller and getting closer to what programming feels naturally.
Now, why do I think we could have the capacity to take over this space? I am going to build that capacity. Of course.
Right now we are a very small team. We have an advantage on the technical side of things and clarity, but there's so much that we're missing and that's exactly why we're raising this round. And then we're going to go for an even bigger one to bring in the right co-founders and level up.
So also, I want to put the announcement out there that we are actively interviewing co-founders, trying to find someone who is as experienced as I am on the technical side, but on the product and marketing sides, so that we can level up and have a really world-class team because this is a huge opportunity to claim this throne.
[00:16:40] It will be a nice thing.
00:16:41 - Christopher Burns
Are you going to look for a strong vendor lock-in or more of an open standard? I.e., are you going to be the jack of all trades of the industry like Netlify, or are you going to try and do more vendor lock-in with Next.js and Vercel?
00:16:55 - Aldo Bucchi
If I look at the roadmap, the answer to this changes over time. So in the beginning with tooling, you can't really force people to lock in because you don't own any of their data. All you can do is provide a solution that's so much better that they choose to stay with you. And then there's always going to be a cost to change. So in theory, you could always rewrite your Next.js app on something else.
There are two reasons you choose not to. The first one is maybe the features are better and that's the positive one. And the second one is there's a cost associated to the rewrite. Companies usually try to have a good balance of these two. Ideally you want to always win on the feature side, but of course, the rewrite cost creates a barrier that some people are not willing to cross unless the pain increases.
But I think even though the specific strategy and answer to this is going to change over time, there is one guiding principle here that I want to keep in mind all along, and that is that the developer experience has to be incredible and has to be as close to the user as possible.
[00:17:49] So what we will really own is how it feels to code, how it feels to open your editor, start writing, and that feeling of immediacy. Regardless of how we make that happen, in the beginning it's going to be the build tool; later you're going to have more elements.
But that feeling, that experience, for lack of a better word, but that's what it is. That should be the main lock-in.
If you look at what Serverless Cloud is doing, Serverless Cloud has its own runtime. It's a black box. We don't know what they have and they will improve it over time. They say you write your code this way. You use these APIs. We'll make it happen. Evidently, people initially are going to write things that don't run well. They're going to do a loop and write to the database 150 times, or 150,000 times, right? And the platform will get sluggish. But Serverless, in theory, will learn from this.
[00:18:34] They will improve that. They will see the usage pattern, and they will make their platform somehow smartly optimized for this. And over time, after enough of these optimizations, your black box starts becoming irreplaceable. It's not easy for just anyone to say, I'm going to do the same thing. Well, it turns out it's going to take you a few years.
That's the other lock-in, right? So you have the lock-in on the experience end. That's the positive one. And the other one is the optimization of the runtime, and of each little piece of the whole life cycle having moved so far that there's just nothing that can compare to what we're doing at this point.
And there's a real opportunity here, just like Java has the just-in-time compiler. And for a long time in the enterprise, that was their claim to fame. There's so much work that has gone into optimizing server workloads on Java that it's a no-brainer. Go for this, right?
[00:19:24] It took them a long time to get there. Once they got there, they were able to capitalize on that position. We are entering a similar space here because these runtimes are going to be invisible from people. They become black boxes effectively. And there are different optimization challenges that we have here.
So for example, in a serverless world where an application can be composed of functions that don't necessarily run at the same runtime or even at the same time, there's a lot of freedom to move things around. On the infrastructure side, do you co-locate all functions? Do you co-locate functions with the data? Do you co-locate some of these on the edge closer to the users? Do you cache the results here or there?
And most of these choices, the best way to make them is going to be dynamically by observing the actual runtime behavior. So in that sense, it gets really close to how these runtimes optimize the just-in-time compilers. They optimize themselves. So it's a whole field there.
When I look to the future, I imagine that we will really be able to provide an experience where it doesn't matter if you're writing a very simple application or you're writing Facebook. The experience is still code and we'll take care of the rest. We'll figure it out for you.
00:20:27 - Anthony Campolo
It's really interesting hearing just within the last month how much the way you talk about this has kind of shifted and changed, because we've been talking about this kind of in the background for like going on a year now. I've been following all these projects that you talked about.
I actually wrote a blog post about Serverless Cloud right when it was released, and the traffic I got on that did about 50x my regular blog posts. So it's a lot of interest in this space. Two others that I'm looking at that I find pretty cool are Serverless Stack, which is also using CDK pretty heavily, and then Wasp Lang, which has built their own DSL. That's like a full stack Prisma React kind of app combined with like a Terraform infra as code kind of thing. So those are really cool.
Interested in getting both of those teams on here to talk about that, but there was a blog post released recently by Swix. Swix, who was on back in episode 12, used to work at Amplify and now works for Temporal, which you mentioned here, and it seems like that blog post was a watershed moment for you.
[00:21:29] So I'm really curious how it was able to capture this conversation in a way that seems to have really got people paying attention. What do you think it was that really captured the zeitgeist there?
00:21:40 - Aldo Bucchi
50% timing, 50% Sean's talent. Sean is an excellent communicator, and the terms he picked, the way he told the story, the problem statement. It's hard to write something better, I think. And also he has large reach, so when he puts something out there, it immediately gets a large chunk of the people in our space, right, in the JS space, to look at this one thing all at the same time. And that has a lot more power.
You might even come up with a better explanation, but if you can only reach a small group and then somebody takes that idea and mutates it, reaches the next group, you don't have consensus. So his ability to blanket reset, put a term out there and then get everybody looking at this term, and right around the time where Serverless Cloud came out, so all of these things came together.
And the result of this moment was that I have been talking about this one way or another for a very long time, even longer than I had my startup.
[00:22:30] So let's say I've been talking about this for ten years, and then five years strongly, and then the last three years incessantly. With the startup, I haven't been able to reach people. I am able to sometimes fascinate them and get them interested, but they don't really get the insight and the aha moment. Some of them do, but most people, they're just like, "Okay, get back to me when, I don't know, something happens."
After he wrote the article, my inbox just filled up and the people I talked to, they were like, "Oh, so this is what you were talking about?" It helped. It really helped.
So it talks about self-provisioning runtimes, which is a big part of what we're talking about, right? It's looking at the code, trying to immediately realize where to run it, what hardware to provision, maybe even where to run your code. And that's part of the pure code movement. The other part is everything else. It's not just about the runtime.
[00:23:16] There's also building and the product. It's not just about creating an API and having the runtime be smart behind the API. It's also what you do in front of the API. You want to build a web app. You want to build a mobile app. So there's a whole space around frameworks, the application side of things that hasn't been incorporated into this pure code thinking.
Wasp, in that sense, is doing that for web apps. They're saying, let's try to apply a pure code approach for web applications, but it's just the beginning for that space. There's a lot of work that can be done there. We're also tackling that one when it comes to CLI frameworks, command-line interface frameworks. That's easy. There are not that many ways to build a CLI.
Mobile apps are slightly harder, but still the mobile app is shipped to the phone all at once, so there are some things that are established already. But when it comes to web apps, it gets really complicated, as we all know, right?
[00:24:04] We've been working on Redwood for two years, and as we get closer, most of the back and forth, not just in Redwood but every other framework in the space, has been around the rendering modes. Pre-render, lazy, pre-render, lazy, server-side render. And they keep changing the names, right?
00:24:20 - Anthony Campolo
Yeah. Oh my God, it's so confusing to me.
00:24:23 - Aldo Bucchi
Right. So imagine now on top of that, you throw this idea of pure code. One more thing to consider.
So I think the application frameworks are going to be the last thing to be incorporated, but we can already start with some of them, some of the things that are more clear. And I have the feeling that this era of exploration of the different architectures for web development is going to come to an end. This cannot go on forever, right? We already see some consolidation here, so maybe we are at the point where it's feasible to say, let's take the three or four best approaches that exist, and let's assume that those are going to be the ones moving forward.
I think we already see that. Still not quite like what Astro did now coming out. I think it's going to shake things around a little bit more, but it's going to stop at some point.
00:25:06 - Anthony Campolo
Awesome. Well, since we have last talked, you have actually started tweeting. So why don't you let our listeners know where they can find your tweets?
00:25:13 - Aldo Bucchi
I did. Yeah, it's been quite an experience after eight years. Oh man, there are so many new buttons. I feel like a grandpa. I want to use the Twitter. What do I click here? Can you tell me, young Anthony, how to do this?
00:25:25 - Anthony Campolo
That's funny. Yeah. So what's your Twitter handle? And then there's also a Lambdragon Twitter now, right?
00:25:30 - Aldo Bucchi
Yes. Aldonline is my Twitter handle. Aldonline, with one O, aldonline. That was my nickname when I was in high school. I was actually coding when I was 15, so people didn't know what I was doing looking at a computer, because what else could you be doing looking at a computer at that time? You didn't even have porn at that time. Don't let your mind go there.
It was like, what could you be doing? I was just coding. The Lambdragon handle is @thelambdragon. I tried to get @LambDragon, but it's taken and Twitter doesn't release it. It's suspended, so I don't know. But they don't release handles. So we're stuck with @thelambdragon. The other option was @LambDragonHQ, but I prefer @thelambdragon.
00:26:09 - Anthony Campolo
I like the Lambdragon. Yeah, I think the Lambdragon is good. I like that a lot.
00:26:12 - Aldo Bucchi
Yeah, it's more aggressive. It's like a mythical creature. The dragon is talking to you.
00:26:16 - Anthony Campolo
Yeah. For anyone who found this conversation interesting, we'll have another one airing at the same time that has a much longer history and discussion of what's going on here, but we'll have a lot of links in the show notes. And you also did a recent stream with Swix right after the blog post dropped. So we'll link to that as well. So you got a lot of material out there now. You're definitely out of stealth mode.
00:26:38 - Aldo Bucchi
Awesome. Thank you, Anthony. Thank you, Chris.