Show HN: Wasp – DSL/framework for building full-stack web apps – now in beta

Hey HN! Wasp (https://wasp-lang.dev/ https://wasp-lang.dev/) is a simple config language (DSL) and framework for building full-stack web apps. You describe the high-level features you want (auth, CRUD, async jobs, …) using the Wasp DSL, and write the rest of your logic in React, Node.js, and Prisma. We’re focused on simplifying developer experience and ensuring best practices. Everything is open source. Why another full-stack framework? And why a config language/DSL? We were still experiencing a lot of boilerplate (repetitive tasks) using other frameworks—things like duplicating data models across database/server/client, implementing CRUD API, setting up auth, and choosing and stitching together all parts of the stack. There are two main reasons for the DSL approach - 1) short-term: simpler and cleaner DX via a declarative language that helps avoid boilerplate, and 2) longer-tem: laying foundation for the stack & architecture independent system. Since Wasp analyses the app’s requirements in compile time, it can decide how to generate the target code (React & Node.js currently). In the future it could support other stacks such as e.g. Vue/Svelte on the client and Python/Go on the server, even allowing for mixing’n’matching. The same goes for the architecture (dedicated server, serverless, …). Our big vision for Wasp is to become a stable, stack-agnostic language for describing (web) app requirements (like SQL for databases or Terraform for infra) that interops with the existing stack. Wasp-lang stands for “Web Application SPecification language”. Besides the DSL, another valid approach would be to offer an SDK in e.g. JS or Python to build Wasp AST (like Terraform and Pulumi now both offer). We see it as another “frontend” for constructing the AST and might also introduce it in the future. Under the hood, everything is compiled to a client (React) and server (Node.js/Prisma) apps and we generate static files and a Docker image you can use for deploying to your platform of choice. Wasp had an Alpha launch 1.5 years ago (https://news.ycombinator.com/item?id=26091956 https://news.ycombinator.com/item?id=26091956). Now we are more stable and feature-full. We still expect things to change, so wouldn’t recommend using Wasp for heavy production or mission-critical systems just yet. But it has been used for hackathons, internal tools and even revenue-generating products (https://wasp-lang.dev/blog/2022/11/26/erlis-amicus-usecase https://wasp-lang.dev/blog/2022/11/26/erlis-amicus-usecase). The current release is our biggest since we launched (https://wasp-lang.dev/blog/2022/11/29/wasp-beta https://wasp-lang.dev/blog/2022/11/29/wasp-beta). Besides general stability and DX improvements, it brings support for TypeScript (https://wasp-lang.dev/blog/2022/11/29/typescript-feature-announcement https://wasp-lang.dev/blog/2022/11/29/typescript-feature-ann...), Tailwind (https://wasp-lang.dev/blog/2022/11/16/tailwind-feature-announcement https://wasp-lang.dev/blog/2022/11/16/tailwind-feature-annou...), async jobs via pg-boss (https://wasp-lang.dev/blog/2022/06/15/jobs-feature-announcement https://wasp-lang.dev/blog/2022/06/15/jobs-feature-announcem...), full-stack authentication (now also with Google) (http://localhost:3000/blog/2022/11/15/auth-feature-announcement http://localhost:3000/blog/2022/11/15/auth-feature-announcem...), and by popular demand, Wasp LSP with VS Code integration (https://wasp-lang.dev/blog/2022/12/01/beta-ide-improvements https://wasp-lang.dev/blog/2022/12/01/beta-ide-improvements). Our next focus will be on making Wasp even easier to use (examples, starter templates, UI helpers), and we’ll look into tighter weaving of data models with the rest of the stack and expanding the DSL with more functionalities. We’re around to answer questions and look forward to hearing everything and anything you have to say!