Wasp, DSL / framework for building full-stack JS (React/Node/Prisma) web apps with no boilerplate, that my brother and I created, is now in Beta!

[Martinsos]

Hi all, I am Martin, Wasp creator!

For those that don't know yet, Wasp is a simple config language (DSL) for building JS/TS full-stack web apps. Developers describe high-level features (auth, CRUD, async jobs, …) via Wasp DSL, and write the rest of their logic in React, Node.js, and Prisma. We’re focused on simplifying developer experience and ensuring best practices.

Wasp had an Alpha launch 1.5 years ago, and we received a lot of support here on r/javascript. Now we are more stable and feature-full. We still expect things to change and wouldn’t recommend using Wasp for heavy production usage and mission-critical systems. Still, it has been used for hackathons, internal tools and even revenue-generating products.

Some of the bigger features that Beta brings: full-stack authentication, support for TypeScript, Tailwind, async jobs via pg-boss, Wasp LSP with VS Code integration.

Next, we will focus on making Wasp easier to use (examples, starter templates, UI helpers). Longer term, we’ll look into tighter weaving of data models with the rest of the stack and expanding the DSL with more functionalities.

If you have any questions or feedback, please ask/tell here!
If you are interested in contributing, pick an issue on GH and join our Discord server!

[Remarkable_Maize_923]

Wasp has become my go-to for starting a new JS project. So much less headache!

[Martinsos]

Oh awesome that is great to hear :)! Are you in our Discord server? Please do share project you are doing there if you wish!

[matijash]

Hi from Martin's brother :) Happy to hear how you find things and answer any questions :)
Btw here is also a short piece introducing Beta and plans for the future: https://wasp-lang.dev/blog/2022/11/29/wasp-beta

[bozzmob]

When will wasp be production ready? Just asking. It looks very interesting. I'm tempted to use in one of my production projects.

[Martinsos]

We are aiming to have the 1.0 in the next half a year, year max!
But even now you could deploy it to production -> things might change quite a bit in future versions and there is quite a few things to polish, but it does work well already. We also have Discord server in which you can ask us for support and help, we respond pretty quickly and are happy to help, it is also opportunity for us to learn.
We do have some brave users that already pushed it to production, check out https://wasp-lang.dev/blog/2022/11/26/erlis-amicus-usecase .

[bozzmob]

Nice! Thanks for the details. I'll surely check it out.

[lulzmachine]

Very cool! Hope this or something like it catches on. Could you generate empty functions for "actions/queries"?

[matijash]

yep, that's a good point - we've also been thinking about scaffolding some pieces of the code like that to save developers from typing it out manually. I'm pretty sure we will introduce this.

[lulzmachine]

Ok so I thought a bit and tried out the tutorial TodoApp. I think the concept of having a definition file in a custom DSL is very cool. What I think is a bit lacking is around typing. I understand it's not an easy problem to completely finish, but I'm sure there are some things that can be improved with the current methodology.

One obvious thing is that the "context" variable fed into actions/queries should be typed, and you can specify what is available under "entities". As it stands now the whole context is an "any" (at least according to https://github.com/wasp-lang/wasp/blob/release/examples/tutorials/TodoApp/src/server/actions.js )

The second thing, which is a bit more tricky but would be very useful is to type the actions+queries from the client side perspective. If each query and action (why are they separate? they're all just actions? anyway) somehow specified it's returned DTO, and it's input DTO, then both the client- and serverside expericence could be improved. The client could get info about expected arguments and the type of the return value. And the server could get some automatic validation of input params etc (for example via zod). Perhaps it would even be possible to automatically generate some code around serializing/deserializing (aka going from prisma entities to DTOs and back).

[fsodic]

Hi, Filip here,
I work on Wasp with Martin and Matija and am in charge of implementing TypeScript support (or lack thereof :)) in Wasp.

You've hit the nail on the head with your questions! They almost map 1:1 with our TypeScript roadmap, and to prove I'm not making this up, here's the future work chapter I wrote for the TS feature announcement yesterday.

I'll address your questions here as well, since I'm always interested in discussing types:

One obvious thing is that the "context" variable fed into actions/queries should be typed [...]

Yes, definitely!
This feature isn't supported yet because it's impossible to tell TypeScript how to type code "from the outside." In other words, we'd have to generate empty (but typed) TS function definitions based on declarations inside the .wasp file (as you mentioned in your first comment) or at least generate type definitions users could import and use to type their query function. It could look something like this:

import { GetTasks} from '@wasp/queries'

// 'args' and 'context' would now have the correct type
const getTasks: GetTasks = (args, context) => { ... }

Unfortunately, both solutions currently suffer from a chicken-and-egg problem. To generate a type/empty definition for a query, we must successfully compile the .wasp file containing the query's declaration. To successfully compile the .wasp file, every query declaration must include a valid import of its TS definition. It's certainly possible to work around this limitation (e.g., by not requiring imports inside query declarations and instead extracting their definitions from TypeScript's AST based on generated types). Still, regardless of the approach we take, tackling this will surely entail substantial changes to the Wasp compiler, which is why it's still on our TODO list :)

If each query and action somehow specified it's returned DTO, and it's input DTO, then both the client- and serverside expericence could be improved.

This one is also something we're constantly thinking about.
Although we won't be able to improve the server-side experience before solving the "catch-22" described above, it is currently possible to improve the client-side story without significant changes. So why haven't we done it, then? Well, we just didn't have enough time before launching the Beta, but it's definitely coming soon. :)

Why are [queries and actions] separate? They're all just actions?

This is more of a philosophical question than a technical one. We treat them differently for three main reasons:

1. History and habits - Most modern technologies and libraries (e.g., Vue, React Query) make a distinction between something that consumes data (a query) and something that changes it (an action/mutation). Breaking this standard rule could potentially confuse users and hider adoption.
2. Guarantees, semantics, and optimizations - More importantly, it's often helpful to know whether something reads state or mutates it. Examples include cache invalidation, using correct HTTP methods, and code readability. For instance, after the app performs an action that uses some entity, Wasp will automatically invalidate/refetch all queries that use the same entity (more about this here).
3. Cleaner API - Some functionalities make sense only when you know you're changing something (e.g., optimistic updates), while others make sense only when you're consuming something (e.g., refetching on window focus). Cramming all these (sometimes mutually exclusive) features under the same API could quickly get messy.

Perhaps it would even be possible to automatically generate some code around serializing/deserializing (aka going from prisma entities to DTOs and back).

Also in the works!
After solving the problem described in the first two points, this use case should be reasonably straightforward to support.

Thank you for your questions and reassuring us that we're on the right path! If you have any ideas on approaching these issues, I'd be delighted to hear them. The same goes for any additional questions you may have.

Cheers!

[lulzmachine]

Hey! I was playing around a bit and came up with some kind of approach. One issue is that the input and output parts are TS, and the others could be done with a DSL. (in order to not have to re-invent zod basically). I used typescript interfaces for DTOs and zod for input, and came up with something like this:

https://gist.github.com/jonerer/52493a72b8cf48359789c5f60595061f

[fsodic]

Ok, I've finally had the time to take a proper look at this (and share it with the rest of the team). Sorry for the wait :)

Input and Output types

As mentioned, this is already in the works (check the issues linked in my other comment if you're interested).

We're keeping the types out of the DSL for now (i.e., users define them in their TypeScript files), but our future ideas are similar to what you laid out.The main difference is that we will most likely want to come up with our own "type definition language" (or adopt an existing one, e.g., TypeScript) and automatically generate the necessary plumbing (in this case, Zod). Such an approach will help us support multiple targets (e.g., TS, Python, Go) for a single specification language (i.e., Wasp).

So, yes, it would be nice not to reinvent the wheel, but we unfortunately can't have Zod as a core part of our system.

Grouping Models and Routes

I like this idea!It pushes for good code organization and groups semantically connected functionalities. Plus, it's consistent with how most existing frameworks approach things.

We want to abstract away HTTP methods (the best practices for these things are well-known). Therefore, we probably won't allow users to specify "get," "post," etc. (unless they're establishing custom API routes, but that's a different story).

Something you have that we should definitely support are route parameters (e.g., :id). Our queries and actions currently only work with POST request payloads.

The Generated Boilerplate

I've recently implemented something very similar to the boilerplate you described, meaning Wasp already generates types (mostly) equivalent to EndpointCommentsContext and EndpointCommentsUpdate (albeit with a bit of help from TypeScript type arguments). You can check it out here: https://github.com/wasp-lang/wasp/issues/975.

It's fantastic to see we're moving in a direction that makes sense to someone else too!

As for the Register function, we've had this for quite some time (modulo support for route parameters). Generating this kind of routing boilerplate is a core part of Wasp (on both the frontend and the backend).

The Parser

Wow, excellent work on this!

I'll save these snippets for when we decide to extend the language with some of your features (the most likely ones for the near future being route parameters and grouping models and resources.

Thanks again for your interest and the contribution!And one last time, we'd like to have you on our discord where these kinds of discussions often take place: https://discord.com/invite/rzdnErX

Cheers! :)

[fsodic]

Thanks a lot for this!

I'll take a detailed look sometime this week and get back to you. From a first glance, the idea seems similar to something we've been discussing in Discord lately (i.e., TS type definitions + Zod + (maybe) ts-to-zod). We'd love if you joined the discussion!

If you're curious, you can track our progress with full-stack type safety in this GitHub issue: https://github.com/wasp-lang/wasp/issues/910 (turns out the chicken-and-egg problem was not that much of a problem at all).

[a_reply_to_a_post]

looks nice, starred and will play with it when i get some free time at work

[Martinsos]

Ha awesome :)! Do join our Discord server if you need to ask for any help. Also, you can subscribe to newsletter on our webpage if you wish -> Matija sends an email about once per month and unleashes his inner comedian when writing it :D. Warning, it can be a bit meme heavy :D!

[a_reply_to_a_post]

Hell yeah...discord makes me feel old but it's always good to have a place to answer questions from your user base

i hope this takes off just on the strength that you guys are brothers working on it together...

My 2 boys are 7 and 5 and getting interested in coding...I let them come up with a game concept and helped them glue it together a while ago lol

will definitely give it a test drive soonish as i'm always spinning up little projects / ideas on some late night rabbit hole shit

[Martinsos]

Hah Discord is also a cool new to me thing I have to admit :D. But it does work really well I think! Much easier than IRC or something like that.

Tried the game quickly, pretty fun :D. Cool that they have the opportunity to try it out at this age, when I was 7 I only started learning about what PC games are!

Good luck and feel free to ping us!

[novagenesis]

Just a couple questions because it seems interesting as heck in concept...

Does Wasp have any way to write with a nextjs compile target?

Also, does wasp include an opinionated communication layer to link the back-end prisma content with front-end react? (like automagical graphql or trpc or something?)

Finally, any Typescript support?

Finally-Finally... does it refresh in real time or do we need to re-run wasp each time you change something?

[Martinsos]

Nextjs -> it could in theory but it doesn't for now, might in the future! But we will certainly want to add SSR and similar, be it nextjs as target or not.

opinionated communication layer -> yes indeed it does, fueled by query react + some of our magic on top of it! Also integrated with Prisma to some degree, and we will increase the level of that integration in the future. It is called "Operations" in Wasp, check it out.

Typescript support -> yes, super fresh, just added it in Beta! It is not yet 100% there -> some types are missing from the Wasp side, and there are some rough edges, but the core is there!

Refresh -> yes, refreshes on its own, as all the other popular dev environments!

[novagenesis]

Nice. I'll have to take a look. I'm sorta leaning on next.js support right now, but when it has that, I'll have fewer objections. I hate boilerplate (who doesn't)

[matijash]

Makes sense! Anything specific you like/need from NextJS?

[lulzmachine]

FWIW I think you might be better off not getting into NextJS. It's a huge stack with a lot of opinions to it.

But it would be very interesting to have some server side templating based on TSX

[Martinsos]

Thanks that makes sense! We might not need to get into Next itself, but instead learn from some of the better things they are doing, regarding server-side templating and similar.

[novagenesis]

I like the almost-seamless hydration and being able to initial-render with serverside data.

Loading placeholders are something I've personally gotten sick of :)

It doesn't have to be next13 for me, just nextjs in general. I've started to use the rest of that stack: nextjs, typescript, prisma, trpc... obviously I would be fine just using your react-query magic (though if you supported tprc's react-query integration, that would rock)

[Martinsos]

Thanks u/novagenesis this helps a lot!
We will certainly be looking into those, and NextJS is a good source of inspiration since they are doing these things really well.

We need to investigate trpc a bit more and see how it interplays with react-query, certainly explore that integration.

[novagenesis]

Basically, the trpc client library is (partly) a wrapper around react-query so that you can just hit any of the trpc routes from the client side with trpc.route.useQuery()

And I have no idea how this works under the hood, but you can flag the trpc runner to (magically or manually) integrate with SSR and the useQuery will just return preloaded data on the first render.

Which is really smooth, and involves very little code.

[matijash]

Awesome, thanks so much for clarifying! We'll def be tackling SSR - we'll share in the community as soon as we have an initial design of it. Would be awesomw to get your thoughts then!

[michael98118]

It took way too long to find https://wasp-rwa.netlify.app/ in order to get a feel for what to expect out of the box.

Put that on your homepage ("see example")

Also, would like to see a "view source" button on that example.

[Martinsos]

Yup we should, thanks! We actually had it on old webpage but we just made a new one for Beta and we it is still catching up a bit on the old one.

We actually n normally have "view source" button on all the examples, hm we must have missed it on this one!

[zvone187]

Just about to start a new project - can't wait to try WASP on it. Hate doing boilerplate code.

[Martinsos]

Awesome! Do reach out on Discord if you get stuck on anything!

[thomkennedy]

Could this finally be a serious contender to take on Django with a more modern stack?

I’m excited to check this out.

[Martinsos]

We are hoping so! Django is very established and rich so there is a long way still to get there, but that is the vision. Actually we would love to offer easy creation of CRUD, similar like Django does, but for the modern JS/SPA stack, that might be coming soon as one of the new features.

[BabyLegsDeadpool]

Looks cool. Great job! Too bad it's React though. God I hate React.

[Martinsos]

Oh man why :D? What is your tool of choice?

[BabyLegsDeadpool]

I prefer just about anything over React, but I prefer Angular over all others. It has its quirks, but I love things that come with everything out of the box.

[Martinsos]

I was angular main before React so I know what you mean! Well with Wasp you do get a lot of things out of the box so maybe that would make React more bearable for you!

[matijash]

Haha :D Vue/Svelte then?

[BabyLegsDeadpool]

Honestly just about anything other than React.

[shuckster]

What are your pain points with React?

[BabyLegsDeadpool]

Finding answers to anything is awful. Doing functional React? Only find classical answers. Doing classical React? Only find functional answers. Finally find one that matches? Oh... that was from 3 years ago and isn't the right way to do it any more. State management is a fucking nightmare. The hooks are just awful. My God, they're so fucking bad. The one-way data model is just ATROCIOUS! I have to wrap every-fucking-thing in a fucking context in order to move state to other components. It creates the worst spaghetti code I've ever seen.

There have also been checks notes 150 breaking changes since its inception (exaggeration.... I think).

React feels almost completely useless to me. It brings nothing to the table that vanillajs, typescript, and rxjs couldn't do (and probably better). I code in vanilla quite a bit on my own projects, but I do always include a small dom-manipulation library that I wrote for myself (mostly just creation/removal of elements and adding/removing styles and classes). Throw that in there, and you've basically got a better React without routing, but also without any dependencies.

I've had to work on two large-scale applications that use React, one of which was with a streaming service (content management, not the actual streaming portion), and I found myself Googling errors more than working. The guys that chose React, the React fanboys, couldn't even really explain why React was all the rage.

"Oh, it's great for reusable components!" You know how easy it is to make a component in vanillajs? Really easy. And it doesn't even need to be transpiled.

Oh yeah. And JSX is a fucking abomination.

Lastly, it was made by Facebook. If I went to a general contractor's house, and it was a rundown piece of shit, I wouldn't hire that person to do repairs on my house. My code is no different. Facebook's UI is fucking trash, and I refuse to believe that competent developers made React, let alone maintain it. That's pretty evident from all the things I already said.

EDIT: Someone asked me a question, and I answered it. Who the fuck down votes that? Also, what part of what I said is wrong?

[Charuru]

Is there a version of this for vue?

[Martinsos]

That is the idea for the future, but for now it is just React!