Launch HN: Wasp (YC W21) – DSL for building full-stack web apps

Yes, that's the idea! We first want to get the web app part working really well, and then we will be looking into adding mobile. It will certainly require extending the DSL though, to capture both web and mobile specifics, but the idea would be to keep it as general as we can.

thank you, fixed! The correct link is https://wasp-lang.dev/docs/

Woah thanks :)! We had previous experience with writing a compiler for subset of C (during uni), and I also did some learning from the "Crafting Interpreters" book, but regarding the DSL design, I would say it is actually simpler -> we just went kind of ad-hoc and are expanding syntax as we figure out what we need. I am not sure if that is the best process, I would love to learn about the better one if there is one, but it worked so far. Wasp is still pretty simple, really not much more expressive than JSON at the moment, but we hope to add more stuff soon. While we are using parser combinators right now to parse the language, which is pretty manual process, once it becomes clearer what the language looks like, we will look into capturing it with formal grammar and then use some of the more advanced tools to parse it. The book I am going through right now is "Language Implementation Patterns" by creator of Antlr, it has chapters specific for designing DSLs!

You are right, with this kind of approach, extensibility/flexibility is the central question - we want to make Wasp really easy and simple to use, but on the other hand, complexity is needed to provide the flexibility to produce complex applications.

Right now, Wasp is already leaving big gaps to be filled in by JS/TS (Node, React), but there is also a big part that is abstracted away and hidden by Wasp. For that part, our main idea is to offer abstractions of different levels that you can choose from. For example, you can choose Wasp's RPC to communicate between backend and frontend, but nothing is stopping you to directly access request and response in your expressJS middleware if you want and write your own REST API or use GraphQL. Or, you can use our authentication system completely, or use just part of it, or completely ditch it. So there should always be a "lid" that you can remove and access the system beneath.

That said, we are still figuring this out - where to offer escape mechanisms, how to organize them, how much to abstract certain parts - there is certainly some limit to flexibility that we can offer. What is cool that having our own DSL gives us a lot of freedom here (although it is also a lot of work!).

One thing we do have in the meantime is ability to eject the code and continue with it if you get stuck with Wasp at this alpha stage -> it is actually human readable! I am not sure if we will be able to maintain that property as Wasp grows though, but we are not giving up on it for now.

right now Wasp DSL is pretty much the config file, it isn't much more expressive. Short term benefit is that this way we can provide nicer & more intuitive syntax (config files like json/yaml can quickly become very nested and hard to read).

Longer term, we plan to add support for inline-JS, so you could e.g. mix JS and Wasp code (instead of just referencing js imports as it works now). We will also add some basic language constructs (expressions, conditionals, multiple wasp files) so we might get more similar to e.g. Starlark or Terraform's DSL.

Hey yes, we have been working on a React/Node app for two years some time ago, that grew to that size and some more.

I understand the skepticism, to be honest I was also pretty skeptical when we started (I am still a little bit, a healthy dose :D!), but we think now we can get to the level of flexibility of serious web frameworks - it all comes down to figuring out where the flexibility is needed.

Right now it is already pretty flexible - you can write any nodeJS logic and use any JS library, same goes for React components. What is tricky is hitting this right trade-off between flexibility and power, and we are thinking a lot about that.

So to summarize, I agree, but am hopeful!

e2e testing -> yes, that would be very cool :)! We don't have any testing capabilities yet, but will be looking into it.

Regarding bigger projects - one thing I am excited about is the possibility to model not just one web app via the DSL, but to capture multiple services - for example multiple (micro)servers - and orchestrate them. I haven't explored that direction enough yet though, since it is not the priority right now.

hah that would be cool! One reason we are excited about the DSL approach is that it allows us to 'capture' web app's requirements in a declarative structure separated from the implementation.

As you mentioned, that means it could be possible to generate Wasp DSL via other means as well, not just by writing it down directly (e.g. via a visual editor), and some specific parts could be even assisted by AI.

thanks for the feedback, I agree having showcases is crucial for showing what can actually be built with Wasp.

We ourselves built a copy of Medium with Wasp - feel free to see it deployed here (https://wasp-rwa.netlify.app/) and check the code here (https://github.com/wasp-lang/wasp/tree/master/examples/realw...)

For the super simple example with less code check out TODO app built with Wasp: https://github.com/wasp-lang/wasp/tree/master/examples/tutor... (check out main.wasp and then the code in ext/ folder)

Hope this helps!

thank you, that is what drove us too! But we also believe the key is in keeping integrations with the existing tech, e.g. React/Node.js so it is still possible to express more custom logic where it is needed.

If I got you right, you are talking about embedded DSL inside Javascript -> kind of like a library? Or about JS-like DSL, that is a superset of JS?

Our main drivers for creating a bespoke language were: 1. potential to create a completely tailored developer experience - as simple and nice as possible. 2. detaching from specific language - we want to be able to potentially support multiple languages in the future, especially on the backend.

How do you see it as a DSL that is still Javascript - I would love to hear more!

It is a tricky problem - on one hand, we want to capture as much as you can with DSL, since that gives us power to "do more", but on the other hand, we want to give you all the flexibility you need, which means doing stuff outside of DSL, stuff that Wasp does not understand and only sees as a black box. We think we can solve this by offering multiple levels of abstraction to choose from + escape mechanisms on the right places, and we are integrating with the JS ecosystem so you can write a lot of the natively already (NodeJS, React, more in the future).

So while we still don't have this completely figured out (and I don't think we will until we get it done), we are hopeful! One cool thing is that doing our DSL also gives us a lot of freedom here, to find the best abstraction.

Awesome, ping us on our Discord (https://discord.com/invite/rzdnErX) if you will have any questions - Wasp is still in early alpha and rough around the edges (including missing flexibility), so if you get stuck anywhere let us know! Actually ping us anyway if you wish, we would love to hear how you found the experience, how hard was it to get into it.

Oho you are also building a DSL for full stack web apps, I didn't expect that :D! Consider joining our Discord (https://discord.com/invite/rzdnErX), I would love to learn more about your quack!

True, right now it is just one file, and language is a simple "configuration", declarative language, just because we didn't need more so far. This is how we started, because we wanted to focus on capturing the basic abstractions of the web app at high level, and we want to keep the language as simple as possible -> so we decided to start really simple and then extend as we need more power.

We will certainly add splitting into multiple files, and will probably go beyond that with actual modules, expressions, simple conditional logic, basic types and similar - kind of like meson (https://mesonbuild.com/Syntax.html) and Terraform. Right now we don't see it ever becoming a Turing complete language, since we don't intend to capture the low-level logic in Wasp - we feel existing solutions are better fit for that (JS/TS/HTML/CSS/...) and we would not be doing our best work there, nor would we be able to keep up with the innovation.

Although, never say never -> my mind does wander off to Mint (https://www.mint-lang.com/) every so and so, thinking if we could do something similar at some point -> but even if we do, that is further down the road.

we are not totally sure yet (since we are now focusing on getting the project to the stable stage), but we think the most straightforward way would be to provide our own, "one-click" deployment/hosting service. On the other hand, since we are providing an e2e solution we think there could be multiple spots for providing extra value on top of the language, but we have yet to explore it.

Thanks! We love Haskell, we have been playing with it for years, and when we realized we want to build a compiler, we thought Haskell is just the right fit for it, due to relatively small amount of IO and lot of complexity. That said, not everything is perfect in Haskell, and we are still learning a lot every day, but we are really enjoying it. How about you, are you considering Haskell or already using it?

Great to hear that :)!!

Thanks Nikolas for answering regarding Prisma! The reason why we chose Prisma is because it is declarative, which plays really well with Wasp, and because it supports multiple types of databases - for now only relational, but as Nikolas said, in the future also nosql.

Regarding TS - you are right, TS is a better fit for this than JS! We started with JS, but plan is to switch to TS real soon, for the reasons you described. Here is the Github issue discussing this: https://github.com/wasp-lang/wasp/issues/143 .

If you don't mind me asking, how big is your team / what are you using right now to build web apps?

Hey, Nikolas from the Prisma team here!

As of today, we indeed only support relational databases (Postgres, MySQL, SQL Server, SQLite) but we are already working on a connector for MongoDB[1] and plan to expand to more DBs in the future, here's the open issue to support DynamoDB[2].

Hopefully Prisma becomes an option for you once we support your favorite DBs!

[1]: https://www.notion.so/prismaio/Prisma-Roadmap-50766227b77946...

[2]: https://github.com/prisma/prisma/issues/1676

thanks for your feedback and questions! yes, it (build-time reasoning) is also the most exciting thing for us, really excited to see what can be done.

I also totally agree on being harder to debug, that is the challenge that comes with abstraction - at this stage we are not doing very much about it (mostly just propagating errors from server/client) but it is something we'll definitely need to focus on as Wasp matures.

We chose Haskell because we had some previous experience with it and thought it would be a good fit for building a compiler (doesn't have a lot of realtime IO so we can keep the code simpler). Haven't yet tried OCaml or Rust (heard Rust is somewhat more low-lvl) but I believe they would be viable alternatives too.

Re long-term doing Wasp - also agree, we believe this is a full-time job so that is why we joined YC and got the initial funding so we can focus on it longer term.

Re Apache v2 vs MIT - thanks for letting us know! We haven't yet put much investigation into it but will definitely need to do it soon.

Hey, we have a demo app deployed here: https://wasp-rwa.netlify.app/ , and you can see its source code here https://github.com/wasp-lang/wasp/tree/master/examples/realw... .

Wasp is still in alpha so many things are rough or not there, including accessibility, but we do plan to handle it in the future! Here is relevant github issue: https://github.com/wasp-lang/wasp/issues/126 .

Exactly!! Ah I love to hear this :D. Sure, we would love to -> consider joining us on Discord (https://discord.com/invite/rzdnErX) and you can ping us there whenever you want, or you can also shoot us an email at hi@wasp-lang.dev and we can continue from there :).

would be awesome to chat!

Yes, that is what we are trying to do! And maybe even more - we are pretty excited about what using a DSL can unlock. Far in the future, we actually imagine being beyond JS ecosystem and offering a choice of languages to use, especially on the backend.

We know about Hasura -> it sounds like a cool idea! First we will be focusing on conquering React/Node combo, but it will be interesting to explore if there is an opportunity to include solutions like Hasura. What part of logic do you imagine happening in Hasura, and what in Wasp? I guess in this case Wasp would mostly be handling frontend right?

I will have to check out React Admin, I haven't heard about it yet.

Yeah this feels a little bit like a declarative configuration file for Hasura/Firebase (which is already a good idea). Looking forward to seeing how far you can take the frontend stuff!

Hey, great to hear from you again :)!! Oh I remember that feedback very well, it was a big thing for us at the moment (and we left you even bigger response I believe ;)), really motivated us to see somebody is sharing so much of our vision!

We would love to keep in touch, you shared a lot of great ideas with us - if you would consider joining us on Discord (https://discord.com/invite/rzdnErX) or shooting us an email at hi@wasp-lang.dev, it would be great :). Thanks again for the support!

I get where you are coming from! It does feel like that sometimes when building Wasp - a lot of technologies we are layering on top of, sometimes we need to let them leek out, sometimes we want to hide them, and sometimes we have to play around them - it is a lot of work to put all that together to play nicely, and it will never stop shifting, even if we "make it" it is always going to be constant effort keeping up. On the other hand, I can't imagine tackling this in another way. Designing a web app is not complex for no reason - it is complex because web apps are complex. They are multi-user systems that work over distributed architecture, that need to maintain persistent state, look good, be scalable, be fast, work on all kinds of different browsers/devices/screens, be secure, ... . When you also add all the innovation that is happening in the current system, the idea of build a bespoke solution from the ground up sounds next to impossibly hard. Even Wasp sometimes feels impossibly hard to do, and it is still of much smaller scope than completely bespoke solution. I would love to hear your ideas on this though - I certainly haven't been thinking a lot in this direction, merely due to discarding it upfront as a possible approach.

Btw, one thing that Wasp does in alignment with your idea of bespoke solution, is that it brings DSL that is in big part detached from the technology used for the implementation of the specific parts (JS/React/Node/...), meaning that if we get it working with existing technologies, we have one foot on the solid ground and can work from there to see which other, "smaller" problems can be tackled next, potentially ending up with a set of solutions that together create one new, bigger, bespoke solution.

I love the idea you are describing, it is very much our initial (and maybe final) vision that we had when we started working on Wasp! But, our vision of the best approach for the current moment is somewhat different, let me explain below.

Web apps are complex beasts, and we believe there is a reason for multiple DSLs being used today (HTML, CSS, React/Vue/... as embedded DSL, Prisma as schema DSL + db access embedded DSL, Terraform, ...): it is easier to solve the problem by splitting it into subproblems and then solving each one of them with specialized language/DSL, than figuring out one DSL that works for everything. Even if we found one DSL that works for everything, it would at the end likely be a combination of multiple DSLs unified in one language.

So, if we decided to solve it all at once with Wasp, we would be solving N problems at the same time, and would need to beat whatever is the current best solution in most of the areas to be compelling enough to be used. At the same time, we would be competing with the whole web dev ecosystem that has shown in the recent years to innovate and progress very quickly.

That is why we believe more in the current approach we are having: by utilizing existing solutions for sub-problems, solutions that work relatively well and are on the edge of what we know is the best way of solving those sub-problems, and building our DSL in the space in-between, where the most of the friction is happening, we are bringing value where it matters the most while also riding the web dev ecosystem wave, instead of fighting it directly.

This doesn't mean that we can't expand Wasp with additional sub-DSLs if we figure out at some moment that, e.g. we have a better abstraction than React that would fit really well in Wasp - we can still do all that, but we can do it step by step, while still progressing in the meantime.

Also, this might not be very clear in the docs, but the idea of Wasp is not be tied just to React - idea is to also support Vue, Svelte, and whatever is coming next, when defining components. Also, idea is to support not just NodeJS, but also Go, Python and similar on the backend (maybe you could even combine them).

Regarding learning -> is it better for a web dev to learn complicated Wasp language and how to write view logic in it and how to write db access logic in it, or to learn a simple, smaller Wasp language and how to write view/db logic in React/Prisma? I think the second, since complexity is going to be similar in both cases due to Wasp becoming more complex in the first case, to be able to describe both view and db, while in the second case you are learning technologies that you can also use outside of Wasp later or you maybe even already know them.

Just to make it clear, what you are suggesting, to have 1 DSL for all -> I love it, it is our initial vision, and one I would very much like to be possible. We actually started that way with our prototype, but soon concluded that we need to divide and conquer (well, more like delegate in this case) if we are going to win this battle. We started with having elements in DSL like button, forms, but we left those to React for now -> however, we will probably try getting back to that in the future, if we manage to establish some footing first.

To answer the specific questions:

1. Yes! We are planning to relatively soon allow mixing of JS and Wasp logic, mostly for the purpose of making the code more readable and easier to organize. Describing lower-level details of the web app with Wasp, e.g. page content, elements, text -> that we would also like to do, but probably further in the future.

2. We initially started with our own syntax for describing schemas -> then we moved to Prisma since they have a DSL that works well. Right now we are working on our own Prisma DSL parser (almost done!), so that we can reason about those schemas independently of Prisma. Next step would be having our own syntax, which would make us independent of Prisma, as you said -> and ye...

oh wow, that's really great to hear! Would love to get more of your feedback once you tried it - feel free to join our Discord channel (https://discord.com/invite/rzdnErX) or email me directly at matija@wasp-lang.dev if you'll have any questions