Brian: PodRocket is sponsored by LogRocket, a frontend monitoring and product analytics solution. Don't know what that is? Go to logrocket.com. Thanks. Brian: On today's episode, Ben interviews Martin Šošić about Wasp, a programming language he built his twin brother Matija. You may recall seeing it at the top of Hacker News when it launched a couple months ago. Let's get started... Ben: Hey Martin, how's it going? Martin: Hey, hi, Ben. Good, how are you? Ben: I'm doing great and really excited to have you here and learn about Wasp. To get started, could you just give us a quick introduction to what is Wasp and how does it help you build better web apps? Martin: Wasp is a programming language for building web apps 10 X faster. For example, if we want to build something like Instacart, right now you need to know a dozen different technologies, connect them all together, figure out best practices. And basically Wasp makes this much easier, while it still lets you use your favorite tools like React, Node, similar. And Wasp is actually a programming language, as I mentioned, but not a complete like Turing specific like Python or something. It's actually a simple configuration language. Ben: Got it. Digging in there a bit, Wasp configuration language, you describe it as a DSL, so that's domain specific language, right? And as I understand it, basically you can define the structure of your app in the Wasp language and then it generates the code in React and Node and sets up all the underlying configuration. Is that relatively accurate? Martin: Yeah. No, no. That's very accurate. Nice job. I mean, exactly what you said. Basically the idea is to capture the high level logic, this DSL that is Wasp. And the idea behind that is that a lot of boring boilerplate and glue between React, Node, Redux and so on is removed. Basically for example, in this high-level language, you'll say something like, "I want authentication with Google. I want three pages, I want this deployed to AWS." And if you don't have any specific, crazy requirements, which you could specify if you want, if you don't, that's basically enough to get you completely started and working. And as I said, what basically happens is our language, DSL Wasp, compiles together with React and Node files that you provide next to it, compiles into pure JavaScript or TypeScript code. That is the result. And then basically that code is deployed and so on. Although the generated code is not something you really care about, it's in the background, same like C++ compiles into Assembly or something. Ben: Got it. Is the idea that you would write your whole web app, all of your application logic in the Wasp language? Or is the idea that you define the structure of the app, Wasp spits out the JavaScript or TypeScript files, and then as you go beyond the basic functionality of your app and you're customizing how it works, then you're just editing the JavaScript code. Martin: I mean, you never touch the generated stuff that's in the background, but your source code is a mix of Wasp files and all the usual JavaScript like React, Node, JS, you have some CSS files. Wasp just pops in their source code, then removes a lot of stuff for you by specifying it in one simple Wasp file or a couple of them. Ben: What is the generated JavaScript code that Wasps spits out? What does that code do? Is that the API layer code? What is the function of that code that you're not touching? Martin: Wasp right now is aiming to be a full-stack solution, which means frontend back-end and it even covers the communication with the database similar to what Meteor was doing or even Ruby on Rails like full-stack solution. I think the closest solution is Meteor. And the generated code consists of two main parts, frontend and back-end. And then you also have the part that cares about the database. Ben: Got it. And so I'm curious to understand why go with a DSL approach, creating a new language versus the all JavaScript approach that a lot of other popular full-stack frameworks like Blitz or Redwood, or even like NestJS, they're all JavaScript. Why go with the approach of creating a new language? Martin: Sure. No, I think that's a very good question. Basically there's two of us working on this, me and my twin brother Matija and we have been building web apps for a long time, and I've used a lot of different technologies. I know first one was of course, PHP, Backbone, Angular, React at the end. And a lot of tools on the back-end, frontend and now Grunt, Gulp webpack, everything. And one thing that was peculiar to us was that a lot of technologies are changing, everything is changing, but what remains the same is what you need to build. The web app 10 years ago was the same thing, basically it was some CRUD, it was authentication system, excess control, pages, view logic, and so on. Our thought was going into direction of, okay, you know what? We are always describing the same things in the newer technology, which is cool. Martin: Technology has to advance, but why do we always have to learn complicated stuff to basically implement something relatively simple. I actually remember explaining that to a bioinformatician that point, how it takes two months to build a web app, certain capacity. And I just couldn't explain it. Why does it take two months? Because it doesn't make sense. It sounds simple, right? Then why DSL? Starting from that, our idea was, all that basic stuff that is common in all of their applications, why not capture that into something that's not surely bounded to implementation because JavaScript is implementation, right? You can implement your web app in JavaScript, in Python, in Ruby, whatever. But basically the language you are using to describe it, "I want four pages, I want this route to go there." It's not surely any how connected to that specific technology. Martin: The idea was, how about we create a very simple language, which looks almost like JSON, but with some extra things that you described, super easy stuff like that. And then you can pick whatever technology you want to implement the specific logic. If we have some complicated component, UI, fine, React is probably the best solution right now for that. Same like CSS is, although it's not great, it's still the best solution for describing the styling, so I think that was the main idea behind it. I mean, Matija and I, we have computer science background, Masters in computer science and we have been building languages before, during university. I guess it was also somewhat closer to us that we might try doing something like that. And comparing it to Blitz and Redwood, we love Blitz and Redwood because they're very similar to us. They're also trying to provide you a way to build a monolithic web app where a lot of the things is already decided for you. Very easy to start. A lot of things provided out of the box, but our idea was, there is no reason to be stuck in JavaScript. We can go one level above. We can do stock during compile time, and I could go deeper into this. I will stop here and then you can ask me more questions. Ben: No, no, I'm curious to hear you continue because I understand at high level, why go with the DSL. But there are a lot of drawbacks, right? It is something new for people to learn and JavaScript for better or worse is the language of the web. As of now, it's the only choice realistically for building the frontend of a web app. Obviously a back-end, you have Python and Ruby are a million different choices, but JavaScript is frontend at this time, maybe down the road with WebAssembly and some of these other technologies that are starting to make progress, there is a future where there are many choices on the frontend, but today JavaScript. You were starting to say something there and curious to hear that. Martin: I mean, main idea behind the DSL is, as I kind of mentioned, is that we are not bound to a specific technology. JavaScript is right now the main language on the frontend, but on the back-end, people are using a lot of things. Some languages are better for some things. Some are not. Our idea was also why would you have to be in JavaScript on the back-end? If you want Go, you could use Python. Wasp supports just JavaScript. But for us, it's relatively simple to support also different languages, so this, for example, one idea. Another thing is that with DSL, I mean, as you mentioned, it is one more thing to learn, but actually it's super simple to learn. I guess I'm a programmer, so it's probably not like as simple, but for me it's almost like human language. Martin: When you look at it because it's super simple. It's basically, you have a key word, page, you have a key word, routes. There's nothing to get wrong there. Actually with DSL, we believe we can get the optimal ergonomics you can possibly get because we are designing this language. For example, Ruby on Rails, of course, they're not any more such full-stack solution as it was maybe before, when everything was on the server because they are in Ruby they sent to JavaScript at the fronend and so on. I mean, client happened on the frontend and there's no way for framework and Ruby to capture all that in a super nice and ergonomical way, although they're actually doing it pretty well still. With the DSL, there is just no constrictions. We can do whatever we want. If we want to capture multiple back-ends, microservices, whatever, we could also do that. I would say at this early point, there is not so much difference between us and the Redwood and Blitz, but our big vision is that with the DSL we are kind of paving the way to have a lot of power to do whatever we want basically both regarding ergonomics and how far can we go with Wasp. Ben: I won't talk through the core components of any kind of modern web app and talk about the tools you chose that are implemented under the hood in Wasp. For example, it sounds like React is kind of your default choice for view layer, Node for service side code environment. I think you use Prisma for a database querying, so curious to talk through those choices, any other default choices that you chose, I'm curious about off layer, API layer. Could we talk through some of the tools you chose to build on and why? Martin: Sure, Sure. I mean, you said everything correctly. I mean, for us, it makes sense to have a technology or something that's used for view logic. Then you have a logic on the back-end. You have something to deal with the database and for that, we have basically three things, React, Node and Prisma. I mean, there is no reason why we couldn't do something else also, but we just chose the solutions that are used the most right now. And that's mostly it. I mean, I think using the Node with React makes a lot of sense because it enables people to use just one language, and Prisma is interesting. I think Prisma is great for us. They're really good fit because they're also actually using some kinds of DSL. They actually have a Prisma schema language for describing the database models and so on. Martin: And for us, this was just perfect because our idea was actually to do something similar on our own. We would have, part of DSL will be about describing the models. We actually call them entities. And then you can use them both in your database, into the code and Prisma is already doing that with the Prisma Schema language, so that was awesome. We basically just integrated Prisma directly into our language and you're writing Wasp. And then you just write a little bit of Prisma schema language and then you go on. That was a great fit. I mean, we were actually exploring GraphQL also as a solution for describing this staff because they also have a way to describe models and so on. But I mean, at this point we found them to be maybe somewhat too general for our use case. Prisma was the better fit and regarding the communication between the frontend and back-end. Martin: Right now we are going full monolith, which means there is no API that's officially exposed. I think probably soon we will have it official. This is what our API looks like, so you can consume it from the outside, but right now we are using a form of RPC. Basically you define the function in Node and suddenly you can call that same function on the frontend. And what we basically do it in the background is we provide the REST API and functions on the frontend, which are consuming that REST API. It's actually very similar to what Blitz is also doing. Ben: And what's your approach to authentication and security around accessing those APIs? Martin: Right now we provide authentication directly in Wasp. You have a special keyboard, which is Auth, and just say Auth and able to use, you specify a keyboard which describes the provider. Right now it's only email and password and we generate the whole authentication for you. In the background we are using JWT tokens, so nothing super fancy. I mean, I think there's the best solution. And it's so far, I mean, the idea is of course to provide possible integrations with Auth0 or maybe some external providers and provide more authentication options with Google, Github and so on. We still don't have it yet but that's on the roadmap. Ben: On that subject of roadmap, curious to hear what does the next year look like for Wasp and what are some of the kind of larger projects or features coming to Wasp that you're excited about. Martin: For us I think that what we are excited the most is just simplifying the app development as much as possible. And I guess this is where DSL excites us a lot. There's a ton of things to work on because Wasp is still in alpha, I would say even in early Alpha. One big thing for us that's happening right now is that we just finished a Y Combinator pitch. And right now we are actually fundraising. The plan is actually with the funds raised to hire a couple of engineers and then with that core team develop toward 1.0 in the next year. And the main features, I mean, it's mostly just getting to 1.0. It's mostly providing features that we are still missing. Right now we have support on the JavaScript. We certainly want to support TypeScript, we want to have service side rendering, a lot of the stuff I already mentioned. And since we are building a DSL, there is actually some extra work around the tooling to get it working properly, like support in Visual Studio Code and so on. We have something right now, something I pitched in one day, but that's not good enough, so the idea is of course the build a proper language server, it follows things through protocols. Ben: I'm curious, completely different tangent, what was it like participating in Y Combinator? And would you recommend applying and you know, if accepted going to Y Combinator or for other framework or DevTools type companies? Martin: Of course, Matija and I have been in startup scene for some time now. And Y Combinator is one of the top accelerators out there. I mean, there's a lot of benefits. The biggest benefits are networking because you meet a lot of ambitious people who are building something. A lot of them are very technical and you can have interesting discussions, both on the business and tech side. Plus you get awesome mentors who have seen similar things many, many times, and they can help you very quickly. For us we started Wasp from the problem we had before, because we had been building a lot of web apps and we wanted to make it easier for others. Our idea is that if Wasp is to become something really big, that it will be good to create a business around it so we can support it with a core team of engineers and so on. Although I think that's a particularly, but Wasp is open source, but the idea is to provide additional products on top of, for example, for enterprise use cases and so on. Ben: Yeah. That was going to be my next question. You may not have a completely concrete answer for this, but curious, long-term plans, how to monetize this. And so it sounds like enterprise features. Do you have any kind of specific enterprise features in mind or it's something where you're now focusing on just building a great product, getting a lot of users and then kind of figuring out how to monetize the enterprise side down the road? Martin: Yeah. I mean, I think both is correct. We have an idea of what the monetization be, but right now we are focusing on, I think in the next year it will be just getting to 1.0 and getting the community and something that people find valuable and use every day and so on. Regarding the monetization, idea is to follow what others are doing. Maybe the closest is Terraform, by the way Terrafrom is also DSL, so that's cool. Having an open source and then providing enterprise features. For example, what Terraform is doing, they have a Terraform cloud, which is either hosted by them or you can host On-Prem for your organization. And very initial idea for Wasp is to go with something similar. I mean, one cool thing is with DSL and so on, we are capturing the whole end to end portfolio, of developer. And the idea is, then we can also provide the smoothest and nicest experience of hosting it, monitoring it, logging the errors and so on. And that would be the idea behind Wasp cloud and in the enterprise, something similar, but then with all the needed integrations and probably single sign-on and features like that. But as I said, that's something we are still learning about. Ben: And one question I think about when trying to get especially enterprise tech companies to adopt a new tool is the risk of getting locked into something that is proprietary to an extent. And I know it's open source, but just curious, if I build my app in Wasp and then, you stopped developing Wasp for whatever reason down the road, how locked in am I, or do I have the ability to eject, so to speak, all of the JavaScript and React code and just build on that? Martin: Sure. I mean, on the one hand it's open source. That's correct. On the other hand, we actually have an eject option. As I mentioned before, Wasp is generating the code. Cool thing is that code is not super scrambled, so it's actually human-readable and right now it looks pretty nice, so you can actually eject it, then go with that code and continue. I mean, it's not 100% as if a senior engineer wrote it, but it's probably like 90%, which is I think very good. Maybe there's some small adjustments here or there. I have to admit it will be a challenge, keeping that in the future with all the advancements on the Wasp, but so far we succeeded, so we are optimistic. Ben: Curious to learn a bit about your approach to building community and driving adoption. How are you promoting Wasp? How are you generating interest? And maybe what are some of the challenges there on the promotion side? Martin: Sure. This is an interesting topic. I mean, Matija and I, we are developers and I will say our initial strategy some time ago was, build it and they will come. But we learned at some point, that's not necessarily true and some promotion does help, but I will say with Wasp we are not doing anything very unusual. We are mostly active on Reddit, on Hacker News posting there about our progress. Also trying to, of course, participate in stuff that is not forced. And that is mostly it. I mean the greatest success we had on Reddit so far, and we had a top post on Hacker News and we were also number one on the product hunt, product of the day. And right now we have our district community where we are collecting all the people who want to participate in Wasp, so that's great. I think we have about 200 members right now. I mean, we are still learning a lot here about, managing the community and engaging people and so on. But I think for now we are super happy. And what we are also trying to do, we are actually trying to ramp up on that right now, produce basically valuable content on our blog and then share that, which is cool because on the one hand you help people and on the other hand, you get them to learn about you. Ben: We talked a bit earlier about competitors. We've actually had folks from Blitz and Redwood on the podcast. And I really enjoyed learning about those tools in the past. And curious to hear a bit more your pitch to why go with Wasp versus Blitz or Redwood or, there's a couple of others even that I don't even know about, but I know there's a lot of people innovating in this space. Martin: No, no, that's a good question. I mean, to be honest, when I learned about Redwood and Blitz, I was actually excited because it meant somebody else thinks this is a good direction. That's great because competition is in that sense always good. I mean, I think it's good to have competition. We are all, I guess, learning from each other. And I think this is a huge space, as I said, we have somewhat different philosophy than Redwood and Blitz due to using this DSL approach. And to be honest, I think it's time. It will take us in different directions. I think it will be clear every time, what are the bigger differences. As I said, I'm super excited about them doing that. And I think they're really providing a lot of value to developers, but we are also trying not to compare ourselves too much, just do our thing. And that's it. Ben: Cool. And more broadly outside of Wasp and your roadmap, what are you most excited about in the world of web dev and over the next few years? Like what are you hoping to see? Martin: Actually, I'm very excited about Prisma. We are using them, I know, but I really like how they're simplifying everything. I mean, for me, I have done a lot of web development, but I have also been doing other kinds of development; back-end, frontend, even some embedded development. And the main thing for me is I always want to spend as much time I can on writing business logic and as little time on writing stuff that somebody else already wrote, boilerplate, configuration and so on. I'm excited about all the solutions that are basically solving that, removing all the boring stuff. In that sense, I'm excited about Redwood, I'm excited about Blitz, Prisma, Vercel, Gatsby, all of them are I think, going in that direction. Ben: Martin, thanks so much for coming on the podcast. It's been really cool learning about Wasp and I'm definitely going to check it out. Martin: Awesome. No, thank you for inviting me. I mean, I have been reading a lot of LogRocket blog posts, so I was very excited to be here. Thank you. Brian: Hi. Thanks for listening. Please remember to like, subscribe, email me if you want, even though none of you do. Go to logrocket.com and try it out. It's free to try then it costs money, but we'll see you next time. Thanks.