Wasp 1.0 is coming

The time has come: Wasp 1.0 is now officially in the works! ETA: ~6 months.

Even though still young in framework-years, Wasp has been around for some time now (>5y), with over 100 releases, user stories ranging from startups to Fortune 500 companies, $5M raised in funding so far, and a team of currently 8 people and growing behind it plus all the awesome people from our community (waspeteers).

And yet, for years now, we kept Wasp in Beta. Read on to learn why, what changed, and what you can expect from 1.0.

Get an email when Wasp 1.0 lands!

The freedom of Beta

For a long time, we didn't have an exact set of features in mind that would allow us to say Wasp is now 1.0.

We always knew what we wanted though, and believed we would recognize it when we got there: the "fullstackiest", managed experience of building web apps there is. The experience of writing only the code you care about, at the level of detail you want, and the rest being taken care of for you. All expressed purely in code, flexible, free and easy to deploy anywhere.

That led us to some unconventional choices when designing Wasp:

• We designed our own custom declarative language for describing a web app at a high level (the "Spec") and its own custom compiler. (psst, that was a bit of a mistake though).
• Our definition of "full-stack" is broader than usual for JS frameworks, fully capturing frontend, backend, database, and deployment, and really everything that falls in between.
• Even though it is currently based on React + Node + Prisma, the underlying machinery has always been designed to allow adding support for other stacks in the future, in large part thanks to the aforementioned Spec and compiler.

Being in Beta gave us the freedom to explore all these concepts unhindered by the weight and responsibility of maintaining a >=1.0 version of a framework (although we did end up following a lot of "production" practices already in Beta: looking at you, brave people who couldn't be stopped from deploying to production).

Ready for 1.0

What makes Wasp ready for 1.0 now? After all this time, I dare say the picture crystallized into something much clearer.

• We found the right shape for the "Spec" (went from our custom language to TypeScript) without giving up on our vision (this was a big one!).
• We developed an intuition for how to balance managed experience with flexibility.
• We collected a lot of feedback on all the major features of Wasp (Auth, RPC, Jobs, Routing, API, Entities, Deployment, etc) and know what people care about and how to get there.
• We are now fully committed to bringing the Full Stack Modules to life, the crown of the "fullstackiest" experience we are aiming for.

We can now see the exact road, paved with GitHub issues, to Wasp 1.0, and it feels right.

The roadmap

You can check the exact roadmap on GitHub. It consists of epics, and each of those further develops into sub-epics and specific issues.

Roughly, we can break down the epics in the roadmap into:

• General polish (DX).
• Rework of core features (Routing, Auth, RPC, etc).
• Production readiness work (core deps policy, perf/scaling docs, native Win support, etc).
• Novel features (Full Stack Modules, RBAC, etc).

General polish (DX)

While in Beta, we focused a lot on innovating and testing different ideas, and often prioritized those over the rough edges.

However, when accumulated, rough edges become annoying, so one big class of tasks for 1.0 is a lot of smaller, targeted improvements, mostly DX focused.

Some of these are: making Wasp work better with agent orchestrators, nicer output in the terminal, nicer docs, faster npm install, etc.

Check Epic #2884 for more details.

Rework of core features

We never lacked ideas on how to make each of the core Wasp features better (Auth, RPC, Jobs, Email Sender, WebSockets, API, Deployment, etc), but for many of these it was hard to prioritize them while working on bigger framework-spanning improvements (e.g. Spec).

For 1.0, we will bring each of these to a new level! Most of the ideas are already written down in a lot of detail in related GitHub issues, and while some features will require only a smaller touch-up, some will go through a major rework.

For example, Auth will move away from Lucia and add highly requested features like account merging, 2FA, magic links, passkeys, etc. Also, as it currently stands, we will almost certainly reshape it into a more modular implementation that will, next to Wasp Auth, allow using BetterAuth, Clerk, WorkOS or any other auth provider that can implement our auth interface.

Another big one is Deployment: we are looking to simplify wasp build to produce a single server, which will unlock many other things. We are also exploring the smoothest option out there for free hosting of Wasp apps and will be adding it as one of the options in our one-command deploy: wasp deploy <provider>, while also making the current options (Fly, Railway) more robust.

For a full list, see the major features planned for 1.0 in our roadmap.”

Production readiness work

These are non-feature-specific tasks related to bringing Wasp to the level we expect from a >=1.0 framework.

A big one is the core deps policy: from 1.0 onwards we will have a strict policy on how current we keep our core deps (e.g. never more than 6 months behind the latest, which keeps us up to date while avoiding bleeding-edge hiccups).

Then there are docs on performance and scaling: while a lot of this just comes down to the underlying stack (React, Node, Prisma), some of it is also Wasp specific, and we want to make it very clear and easy to understand what you can expect from Wasp in this regard.

And also native Windows support! Wasp works on WSL on Windows, but having it run directly on Windows is something you would expect from a 1.0 framework, right?

Check Epic #2888 for more details.

Novel features

And finally, we are not giving up on innovating just because we are closing in on 1.0.

The star here is FSMs (Full Stack Modules): the ability to define and distribute modular, vertical slices of your web app, e.g. Stripe payments, file upload, AI chat, etc. Imagine libraries, but frontend + backend + database + Spec + even deployment in the future, all type-safe and configurable. It's something we are extremely excited about and have been slowly preparing for quite some time now. We wrote more about the idea in JavaScript still can't ship a full-stack module.

FSMs might not sound like a 1.0 thing right off the bat, but we see them becoming so integral to how Wasp apps will be built that we want to have them, and their effects on Wasp's API, in place before 1.0.

By the way, we are open to ideas for a better name since LLMs keep thinking we are talking about Finite State Machines.

And then we have some more exciting ideas (well, popular requests really) like RBAC (Role-Based Access Control), a modular database layer that would allow support for Drizzle, Wasp Studio (visual representation of your codebase + Wasp dev tooling), etc. These are more of a stretch goal and might or might not yet be fully stable in 1.0, but we would love to at least have them as experimental features by then.

You can find these under the Ideas column.

See you there

We won't be waiting to ship all of these improvements as one big release; instead, we will constantly be releasing as we merge them, so you will be hearing from us quite a bit as we go and will be able to benefit from them immediately. Once we complete all of them, we will declare Wasp 1.0.

If you have any additional ideas on what you would love to see in Wasp 1.0, let us know on our Discord or on GitHub!

That's it, the destination is locked in: next stop, Wasp 1.0! See you there!