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.
Congrats on reaching the 1.0 runway! The core deps policy is the item I'd watch most closely. For a framework that sits on React, Node and Prisma, "1.0" really means a promise about how fast you follow their major versions and how long you support the old ones. A short published stability contract (what semver covers, the deprecation window, and a codemod for the 0.x to 1.0 jump) would probably do more for adoption at bigger companies than any single new feature. Excited to see native Windows support land too.
I research AI tools, APIs & agents — comparing specs, pricing and real user reports — then publish honest rankings so you don't waste money. Research-first, never sponsored fluff.
Five years in beta before calling it 1.0 is the honest part — most frameworks would have shipped the label years earlier. The Spec move is what I'd actually watch: admitting the custom language was a mistake and moving to TypeScript without giving up the managed-experience vision. Do the Full Stack Modules survive that move intact, or is that where the 1.0 scope gets hardest?
I write about Next.js + TypeScript + AI engineering, with a focus on making sites discoverable to LLMs and AI search. Long-form notes at mudassirkhan.me
moving the spec from a custom language to TypeScript is the part i would watch, because the config now gets typechecked and linted like the rest of the app. what bites with declarative app specs in my experience is the escape hatch: the moment someone needs behavior the spec cannot express, they drop to raw code and the generated layer and the handwritten layer start drifting. we kept one typed seam between the two and put tests on that seam. for the 1.0 compatibility promise, what exactly is covered, the Spec API only, or the generated output shape too?
The DSL-driven, convention-over-config approach is the same bet we keep making on the desktop side: in Electron projects, window definitions, IPC channels, and build configs end up duplicated across every new app, and a small manifest that declares which window talks to which channel removes a whole class of wiring bugs. Five years in beta before 1.0 is a credible signal — the hard part is not the features but keeping the abstraction stable enough that existing projects trust an upgrade. Looking forward to seeing how the managed deployment story generalizes beyond web-only targets.
Good luck with the upcoming v1.0 release.
Also,
I wish everyone would use this definition!
I vote for "complete stack" as a new expression :D
agreed :)
Great work! 🚀
I’m really looking forward to seeing where Wasp goes with 1.0, especially the TypeScript Spec and Full Stack Modules.
Excited to follow the journey! 😸
Congrats on reaching the 1.0 runway! The core deps policy is the item I'd watch most closely. For a framework that sits on React, Node and Prisma, "1.0" really means a promise about how fast you follow their major versions and how long you support the old ones. A short published stability contract (what semver covers, the deprecation window, and a codemod for the 0.x to 1.0 jump) would probably do more for adoption at bigger companies than any single new feature. Excited to see native Windows support land too.
🔥🔥🔥
Five years in beta before calling it 1.0 is the honest part — most frameworks would have shipped the label years earlier. The Spec move is what I'd actually watch: admitting the custom language was a mistake and moving to TypeScript without giving up the managed-experience vision. Do the Full Stack Modules survive that move intact, or is that where the 1.0 scope gets hardest?
moving the spec from a custom language to TypeScript is the part i would watch, because the config now gets typechecked and linted like the rest of the app. what bites with declarative app specs in my experience is the escape hatch: the moment someone needs behavior the spec cannot express, they drop to raw code and the generated layer and the handwritten layer start drifting. we kept one typed seam between the two and put tests on that seam. for the 1.0 compatibility promise, what exactly is covered, the Spec API only, or the generated output shape too?
Clean architecture is easy to maintain in a slide deck; the real test is how gracefully the system degrades under cascading production failures.
Minimizing abstraction layers and owning your critical runtime path will always outperform adding more third-party glue.
White Anglo-saxon Protestant?
Super excited for this! Just having Auth module that is easily extensible and comes as a part of a framework is already a big thing for me.
🙌🙌🙌 it’s coming!!
Nice stuff!
The DSL-driven, convention-over-config approach is the same bet we keep making on the desktop side: in Electron projects, window definitions, IPC channels, and build configs end up duplicated across every new app, and a small manifest that declares which window talks to which channel removes a whole class of wiring bugs. Five years in beta before 1.0 is a credible signal — the hard part is not the features but keeping the abstraction stable enough that existing projects trust an upgrade. Looking forward to seeing how the managed deployment story generalizes beyond web-only targets.
Can't wait to see it reach v 1.0!