Why the Full-stack Framework of the Future is a DSL

Hi, everyone. My name is Vince. I'm part of the founding team at Wasp. I'm responsible for developer relations there, and I'm here today to make the claim that the web framework of the future will be a DSL. But before we begin talking about DSLs or why you should even care about them, I'd like to enlist the help of two of my good pals here, Keanu Reeves and Micky Rourke.

Now, they're going to help us figure out an important difference between SQL and JQuery. You're probably thinking, okay, that's easy. The obvious answer is that SQL is a database language while JQuery is a front-end library. But I'm talking about something a little more specific than that. Let's look at, for example, at the difference between 2006 and 2023. Keanu Reeves there, he's still looking humble, adaptable, moisturized. He's ready to take on any new role, and he's probably just about as popular as he was when he started his career. And in that sense, he's got a lot in common with SQL. On the other hand, Micky has more in common with JQuery. That's unfortunate because it seems like both of them have their best years behind them. So you might be thinking, what the hell does this actually have to do with a presentation about DSLs and web frameworks? Well, the simple point is, is that SQL is a DSL and JQuery isn't. So we'll go deeper into this point later, but until then, just keep this comparison in the back of your mind.

Because first, we're going to start with a short exercise to put some things into perspective. And it's a pretty simple exercise. We're just going to imagine we're in the planning phase of building a full stack web app. And we could use literally any app as an example. But this is basically my brain whenever I have to think about a demo app to build. So we're going to switch to a code editor and start planning out our to-do list app in some pseudocode. All right, so here's a plan. And we could choose any kind of syntax we want. I'm going to just make up some pseudocode that's similar to JavaScript or JSON or something. So let's define a class and we'll call it to-do list. And then let's think about what kind of things, I mean, we're planning an app here. So what kind of things do we need to take note of? And I guess like the first thing, obvious thing is a title, we can call it to-do list app, very imaginative. And the next thing might be, since it's a to-do list app, we need to define some database models, right? So let's define a model called Task.

And models usually have an ID, and we'll just make that an integer. And a to-do list task will have some kind of description, right? Like mow the lawn, do the laundry. So that'll be a string. And we want to relate these tasks to the user. So we'll put a user ID property here and relate it to a user model and their ID.

Now that we have that out of the way, let's do the user model as well. And of course, we'll also give an ID integer. And let's just keep it simple. And we'll do a property called Tasks, which is an array of related tasks that they've defined. OK. And since this is for a full stack app, we need to define some endpoints for our task, right? So we'll call that Task Endpoints. And yeah, this is a simple app. And so we basically need our essential CRUD endpoints. So we've got get all or fetch all. We want to create a task. And maybe we want to update a task, right? Cool.

We also want to consider the client. So we need a root component maybe. So let's say client root. And yeah, this is a simple app. So we'll just import a React page there. And we'll just call it main page dot TSX. And maybe we can give it the root of, let's say, client root. Client root. And that'll be the client root. And then we want to authenticate people, right? We want to authenticate users so that their tasks are associated with that user. And so we'll go ahead. And since this is a developer-facing demo, let's just say we want GitHub social auth. That's the only auth we want. All right.

Cool. So here we've got a pretty simple plan for an app written out in this pseudocode. And the thing that I'd like to point out is how cool would this be if this were actually working code? What if we could just really define things this way, like auth for example, and get full stack GitHub auth? We would have client components generated for us, like the GitHub auth button, login button, to the server functions we need to authenticate users on the server, and even the database models.

Well, it turns out that we actually can do this. And we have. This is what we've done with Wasp. And here's what that to-do app we just described actually does look like with Wasp. And it's done using syntax that's pretty similar to the pseudocode we just wrote. And this is achievable because we've implemented a DSL in Wasp.

Now you might be thinking, oh no, OK, here's another framework we have to learn, a bunch of new technologies out the window again. Why can't you just leave what isn't broken alone? But the goal with Wasp isn't really to reinvent the wheel here just to improve upon it, kind of like Dwight says. We already have some really great web dev technologies at our disposal, like React, Node.js, and Prisma. And these are exactly the technologies that Wasp leverages in its framework. So Wasp DSL simply acts as the glue that brings all these together in a more efficient way.

Along with your React, Node.js, and Prisma business logic, we define a high-level description of our app in very similar syntax to our pseudocode there, which is in the Wasp config file. And then this all goes into our compiler, which is an approach that's unique to Wasp. And it spits out the whole project, front end, back end, and deployment code for us. So you actually get a full-featured and production-ready app with full-stack auth, client routes, a standalone Express.js server, Postgres database, Cron jobs, a bunch of other stuff. In the future, we even plan to support different stacks and different architectures, even. So before we explain more about Wasp, let's get back to DSLs and talk a bit more about them.

So if we think back to our little planning example there and the pseudocode that we wrote, we were basically inventing our own little language there. But this is a very, very specific kind of language. You can't use it to do all the things a general purpose language like C or a language like even JavaScript can. It's only meant to do a single thing. In fact, it's so specific that it's meant to be used in only one domain, like full-stack web apps in this case. And that's what a DSL is. It's a domain-specific language. Wasp is just one of many DSLs though. And as developers, we're already familiar with quite a few of them. You're probably familiar with this bad boy here.

This is RegEx, and it's checking for an email address format. So RegEx is a DSL. SQL, as I mentioned in the beginning of the presentation, is also a DSL. These days we're more likely writing it in the form of an ORM, like Prisma or SQLite, something like that. But it's still with us after all these years, just like our good friend Keanu. So SQL is a DSL.

Or this obvious example from the world of React is JSX, which is also a DSL. Okay, so we've established what a DSL is, and that you actually use them quite often. But why? Why would we want to create a new specialized language that only works for a very specific thing, instead of just using those general programming languages that can do all that stuff and more? Well, just like Dwight says, we believe that improvement is possible, at least in the case of building better web apps. Do we really need to be specifying, for example, auth, routing, CRUD operations, and all these things over and over again? No. With DSLs, you can just say what you want, and it happens.

So let's see how. Here's our RegEx example from before. We just said what we want here. We don't really care how it's being validated or in which order, what the mechanisms are. We just say what we want, and we get back the result that we're looking for. So if we weren't using RegEx in this case, and rather just plain JavaScript, for example, then you'd have to write something like this, right? And this is what the how might look like, rather than the what. You have to specify every little detail of the check. It's long, and it's pretty tedious. SQL is also a very interesting example. Again, this is the what. You just have to specify what you want, and you don't care how you get it. On the other hand, in the background is the how. So SQL is a DSL, and you just have to say what you want, and all this happens. Not only is the SQL query engine performing the correct search algorithms for you, but it also knows how to optimize your query for speed, which is pretty amazing that it's able to pack all that knowledge and process into such a short command.

And although this is a simple JSX example, we can imagine how messy this would get with a more complex example, right? So JSX is saving us from having to specify exactly how things should happen. So why do we need a DSL for WebDev, though? I mean, we've got tons of libraries, lots of frameworks that can do all this stuff without a DSL already. Do we really, really need this? Plus, you might be thinking, next year, AI will be able to take care of all that boilerplate for us, right? So what's the point? Well, even with all that, this is a Google search I did yesterday, and despite all the advancements we've made in WebDev, it almost seems to be getting more convoluted than easier, This is a sentiment we hear devs express quite often. So there's a lot that can still be done. Why then would DSLs be the possible solution to all this WebDev messiness? Let's go over three reasons why.

So the first reason is pretty much just a summary of what we've covered. DSLs let us say what we want, not how. And they can do this because they're specialized, because they're focused on that one domain and they're not focused on the implementation. For reason two, good DSLs are like Keanu. They age really well, right? And that's because they are tied to the domain again, which is that problem and not the implementation or the solution. For the third reason, let's turn to another friend of ours, Paul Graham, founder of YCombinator. And I'm just going to read this tweet for you. I expected technology to make programming less laborious, as it does to most things. But I have to admit, I expected it to happen by programmers switching to more powerful languages rather than continuing to write programs full of boilerplate. But having AIs generate most of it. So Paul's right there, right? We're entering an era where AIs will be our coding assistants. And we need abstractions that allow us to collaborate easily with them. DSLs give them, the AIs or the LLMs, a clear set of instructions and path towards development while giving us something that's easy to read and maintain. This is where DSLs really shine and maybe currently overlooked. So we could say that a good DSL is an ideal abstraction for AI, but that's missing the bigger picture actually. The point is that whatever benefits humans will also benefit AI. So reason number three could be best put this way. It allows both people and AI to use higher level abstractions and requires them to have less expert knowledge. Why is that? That's because this expert knowledge is embedded in the DSL, kind of like the SQL example we saw. This means that we get code that's easier to understand and maintain for both people and AI.

So as an example, let's just imagine a full stack app generated in JavaScript versus a DSL. The DSL code, excuse me, for auth would look something kind of like this or actually like this, because this is actual Wasp code, Wasp auth code. On the other hand, the boiler plate ExpressJS code for authenticating a user would look something like this. And it seems obvious which one would be easier to write, debug, maintain, regardless of AI or human.

So to sum up, web development has a lot of room for improvement and you often know what you want, but you have to spend a lot of time describing how it should be done. Meanwhile, the perspective of the user, the main parts and concepts of web apps have remained the same for a long time. But the technologies we use to implement them continuously change. Therefore, the solution space is changing pretty fast, but the problem space doesn't. So all this makes web development a perfect candidate for using a DSL. And this is exactly the problem Wasp solves. It saves us from spending so much time on the how and by letting us just tell it what we want and getting that in return.

So as I mentioned before that Wasp is a relatively new full stack web app framework for React, Node.js and Prisma, and we've already amassed over 14,000 stars on our two main open source repos. And you can see the star history here. A lot has come pretty recently, but regardless, we've had over 40,000 apps created using Wasp and lots of happy users pouring into Discord and places like that where they're leaving testimonials kind of like this, where I'll highlight this one part here where this user said, in my opinion, Wasp is as game changing for me as React has been many years back. Wasp's simplicity and how well the DSL captures most full stack engineering tasks is pure genius. So you see a user realizing that this ability to say what instead of how is really powerful. So let's go back now to that to do app we started imagining and show off some of the strengths of a DSL in action.

All right, so you'll see here that back in the plan. If I just quickly scan back or switch back between the Wasp config file and the plan, you'll notice a lot of similarities there. So that was deliberate. I deliberately wrote the pseudocode in a fashion that's similar to Wasp so that you would get the idea here is that you can really do things like this, define GitHub auth and you get full stack auth as simple as writing GitHub, for example. Let's go through the main.wasp file real quick and see what else we've got. Yeah, we've got that client route there. We've got, again, our database models like a task and a user. And we can get all of our endpoints there by just defining CRUD and linking it to the database model or entity that we want. We've just gone ahead and told it we want get all, create, update and delete operations. So those will always be associated with the task entity. And we actually don't have to write any backend code because this will take care of all of it for us. Besides that, we've got our routes in a similar fashion to how it was done in the plan or the pseudocode. But we can do other things like we can say we want this to be a...

Only authenticated users can get to this route, right? To this route route. So that will take care of client side authentication for us as well. So cool. So let's switch over to the browser now and let's see this. We've actually got this app running and so let's kind of see it in action.

So here it is. Here's the login page and you can see we don't need to find GitHub Auth. So we've got the GitHub Auth button there. But maybe I want to make a change. Maybe I want to add a simple username and password login method. And once the app recompiles, we should see on the front end the sign in form pop up. And there we go. We've got it. I mean, I've already logged in. So I'll just go ahead and log in with that username and password. And you see I've already populated it with some to-dos. And I could say like, today I want to present at Node Congress. And yeah, just to check that these are actually persisting to a database and going through the ExpressJS server. Let's switch to the Database Studio. And here we go. Right. So if I refresh that, you can see that our new task that we just entered there, present at Node Congress. And let me just go ahead and I'll delete it from there. And we'll go back to our app and, yeah, it's gone.

So cool. That's pretty much how Wasp works in a nutshell, and you can do so much more. You've got cron jobs, you've got full stack type safety, and you've also got email sending and all these things that are taken care of via the config file and via the DSL in Wasp. Another really cool thing that we can do because we have this config file and this DSL is that Wasp understands your entire app. And we have a little experimental feature like this one, where we've actually got a visualization of the whole app. And this is just the beginning because you can do a lot of things with stuff like this, but this shows you the power, again, of DSL to do interesting things.

So here you can see the whole app from back end up to the routes and pages. And you can see, right, that main page is authenticated. The app is using an SQL, SQLite database instead of Postgres, which you could also use. And it's got a GitHub Auth and a user and a task entity. So that's a pretty cool kind of extra nice feature about using a DSL.

Cool. And if you want to get started with Wasp, we also have two cool projects that might pique your curiosity a bit more than just a to-do app. And those are OpenSaaS and Mage. And OpenSaaS is a production-ready, completely free, open source SaaS template, whereas Mage is an AI agent that will generate a full stack app prototype for you based on a simple prompt.

So like I said, OpenSaaS is a free, open source SaaS template, and it's on par with some of those paid SaaS boilerplates you've probably seen. It comes with Stripe subscriptions, admin dashboard, plausible or Google analytics, AWS S3 file uploading, OpenAI API examples, plus it's fully documented and we support any questions and users in our Discord. So that's really cool, if you're interested in that, want to build a SaaS.