For the last year and a half, my twin brother and I have been working on Wasp: a new programming language for developing full-stack web apps with less code.
Wasp is a simple declarative language that makes developing web apps easy while still allowing you to use the latest technologies like React, Node.js, and Prisma.
In this post, I will share with you why we believe Wasp could be a big thing for web development, how it works, where we are right now and what is the plan for the future!
Why Wasp?
You know how to use React, know your way around HTML/CSS/…, know how to write business logic on the backend (e.g. in Node), but when you want to build an actual web app and deploy it for others to use, you drown in all the details and extra work - responsive UI, proper error handling, security, building, deployment, authentication, managing server state on the client, managing database, different environments, ....
Jose Aguinaga described in a fun way the unexpected complexity of web app development in his blog post "How it feels to learn JavaScript in 2016", which still feels relevant 4 years later.
We are building Wasp because even though we are both experienced developers and have worked on multiple complex web apps in various technologies (JQuery -> Backbone -> Angular -> React, own scripts / makefile -> Grunt -> Gulp -> Webpack, PHP -> Java -> Node.js, …), we still feel building web apps is harder than it should be, due to a lot of boilerplate and repetitive work involved in the process.
The main insight for us was that while the tech stack keeps advancing rapidly, the core requirements of the apps are mostly remaining the same (auth, routing, data model CRUD, ACL, …).
That is why almost 2 years ago we started thinking about separating web app specification (what it should do) from its implementation (how it should do it).
This led us to the idea of extracting common web app features and concepts into a special specification language (Wasp), while the implementation details are still described via a modern stack (right now React, Node.js, Prisma).
Our vision with Wasp is to create a powerful but simple language where you can describe your web app as humanly as possible.
We want to make the top of that iceberg on the image above as pleasant as possible while making the bottom part much smaller.
In such language, with just a few words, you can specify pages and their routes, specify which type of authentication you want, define basic entities / data models, describe basic data flow, choose where you want to deploy, implement specific details in React/Node, and let Wasp take care of connecting it all, building it and deploying it.
Check here for the complete example.
Why a language (DSL), aren’t frameworks solving this already?
Frameworks (like e.g. Ruby on Rails or Meteor) are a big inspiration to us.
However, we want to take things one step further - by designing a language specialized for the domain of web apps (a DSL) we can get rid of a lot of boilerplate and provide a cleaner & simpler developer experience.
On the other hand, we are not trying to replace everything with Wasp nor think that would make sense - just the opposite, Wasp acts as a “glue” between your React and Node.js code, saving you from the grunt work while allowing you to keep the flexibility of writing your own code.
The majority of the code is still being written in React and Node.js, with Wasp serving as the backbone of your whole application.
Another benefit of a DSL is that it allows Wasp to understand the web app’s requirements during the build time and reason about it before generating the final code, and this is what we are especially excited about.
For example, when generating code to be deployed to production, it could pick the most appropriate architecture based on its understanding of the web app and deploy it to serverless or another type of architecture (or even a combination).
Another example would be reusing your data model logic through all the parts of the stack while defining it just once in Wasp.
DSL opens the potential for optimizations, static analysis, extensibility, and unparalleled ergonomics.
How does it work?
Wasp compiler compiles the .wasp/React/Node.js source code into just React/Node.js target code.
Currently, Wasp supports only Javascript, but we plan to add Typescript soon.
Technical note: Wasp compiler is implemented in Haskell.
While right now only React and Node.js are supported, we plan to support multiple other technologies in the future.
Generated code is human readable and can easily be inspected and even ejected if Wasp becomes too limiting.
If not ejecting, there is no need for you to ever look at the generated code - it is generated by Wasp in the background.
Wasp is used via wasp CLI - to run wasp project in development, all you need to do is run wasp start.
Where is Wasp now and where is it going?
Our big vision is to move as much of the web app domain knowledge as possible into the Wasp language itself, giving Wasp more power and flexibility.
Ultimately, since Wasp would have such a deep understanding of the web app's requirements, we could generate a visual editor on top of it - allowing non-developers to participate in development alongside developers.
Also, Wasp wouldn't be tied to the specific technology but rather support multiple technologies (React/Angular/..., Node/Go/...**.
Wasp is currently in Alpha and some features are still rough or missing, there are things we haven’t solved yet and others that will probably change as we progress, but you can try it out and build and deploy web apps!
What Wasp currently supports:
- ✅ full-stack auth (email & password)
- ✅ pages & routing
- ✅ blurs the line between client & server - define your server actions and queries and call them directly in your client code (RPC)!
- ✅ smart caching of server actions and queries (automatic cache invalidation)
- ✅ entity (data model) definition with Prisma.io
- ✅ ACL on frontend
- ✅ importing NPM dependencies
What is coming:
- ⏳ ACL on backend
- ⏳ one-click deployment
- ⏳ more auth methods (Google, Linkedin, ...**
- ⏳ tighter integration of entities with other features
- ⏳ themes and layouts
- ⏳ support for explicitly defined server API
- ⏳ inline JS - the ability to mix JS code with Wasp code!
- ⏳ Typescript support
- ⏳ server-side rendering
- ⏳ Visual Editor
- ⏳ support for different languages on the backend
- ⏳ richer wasp language with better tooling
You can check out our repo at https://github.com/wasp-lang/wasp and give it a try at https://wasp-lang.dev/docs -> we are always looking for feedback and suggestions on how to shape Wasp!
We also have a community on Discord, where we chat about Wasp-related stuff - join us to see what we are up to, share your opinions or get help with your Wasp project.
Top comments (14)
Do you think it would make sense to have interfaces between wasp and in order to allow people to keep their stack but ease the way they build their apps with their stack using wasp? What challenges do you see with this idea?
Edit: I think this is what you aim for, I just want to ask how flexible you want people to choose their stack?
If I got you right, it is exactly what we are trying to do: so you define stuff in Wasp, but then you can use React to implement stuff and there is an API between Wasp and React, so you can import things you defined in Wasp into React and use them there. And you can also import your React stuff in Wasp and use it there, so it goes in two directions really.
Right now it is React and Node, but we want to add more of it: this means not just React but for example also Vue and Svelte. And for the backend, maybe even other language next to Node -> for example Python or Go. That is something we could do. However, for now plan is to focus on React / Node combo and get it working really well and then we can expand :).
Makes total Sense from a strategic pov. You got me right - having Bindings to several layers of Frontends, Database etc. would be awesome. I could even think of an interfsce to RoR or Meteor, because from my POV the DSL Just defines the general Domain concepts and does not necessarily know how these concepts are implemented and thus you could define connectors for anything to implement them, right?
In theory yes! It really depends on how much we detach the DSL from the implementation. Right now we are not detaching us as much as we might possibly like :D, just because it would slow us down a lot - instead we are going with relatively coupled approach, in the sense it is somewhat coupled to React / Node. But, once we get that working, we will look into generalizing it.
When speaking about frameworks like Meteor or RoR: we could have generators that based on the DSL generate stuff in Meteor or RoR. Right now we have just one generator: React/Node/Prisma generator.
However, using Meteor and RoR as building blocks that connect/interface with DSL is not the way we are going right now, because DSL we are building right now is about the same level of expresiveness as is Meteor and RoR, so blocks should be lower-level (like React, Node, Prisma, ...). I think Meteor and RoR could become valid "blocks" if we raise the abstraction of DSL to the level of e.g. microservics and similar, which we are not planning for now.
I might have explained this badly or misunderstood you, please let me know if this makes sense or not!
Not Bad at all, makes all Sense. Thank you! Will keep an eye on this!
Sounds really inteesting ☺️. will have a look. Best of luck.
A colleague and me have worked on a very similar idea but not actually solving it at a language level but a composable actor system that can work in backend and frontend with decorators.
Thanks Alvaro! That sounds interesting, do you have any materials on it? For example a blog post or maybe a github repo? I would love to check it out! Maybe get some good ideas for Wasp.
Good luck! 👍
Thanks Mir :)!
This is nice effort to make development more simple. Great job lads and keep up the good work!
Thanks, that is exactly what we want to do :)!
Just out of curiosity, why did you choose to implement the Wasp compiler in Haskell?
It is a combination of reasons -> on one hand, brother and I have been playing with Haskell for some time and wanted to use it on a bigger project. On the other hand, Haskell is a really good fit for writing compilers, and has a good ecosystem of libraries that support the use case of building a compiler. If not in Haskell, I think we would probably consider doing it in TypeScript, which would make sense from the side that Wasp users are mostly coming from the JS background.
Interesting, kind of reminds me of RoR! Anything specific you had in mind when sharing this?