HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
wasp-lang
wasp
TypeScript2020–2025
wasp-lang / wasp

wasp

The batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.

8Distinct people
37Mentions
1Explicit recommenders
18.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The batteries-included full-stack framework for the AI era. Develop JS/TS web apps (React, Node.js, and Prisma) using declarative code that abstracts away complex full-stack features like auth, background jobs, RPC, email sending, end-to-end type safety, single-command deployment, and more.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

Aider is one of my favorite AI agents, especially because it can work with existing codebases. We've seen a lot of good results from folks who used it with Wasp…

matijash used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year37 dated mentions

Observed mentions: 2020-02-22 18:15:52 UTC to 2025-07-20 21:10:37 UTC.

0369122020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 11 mentions; 1 submissions, 10 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 4 mentions; 0 submissions, 4 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 5 mentions; 1 submissions, 4 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC11110
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC1028
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC404
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC413
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC514
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC312

What Hacker News says

37 sources
Yeah, both RedwoodJS and BlitzJS appeared at about the same time as we started Wasp (https://github.com/wasp-lang/wasp), with the same mission of being Rails/Laravel for JS. We were excited to see that several instances of the same core idea appeared at the same time, and it gave us validation that we're on the right path. A bit sad about Redwood moving away from the original vision, but interested to see where this new direction takes it.
In The Future of Redwood Launches Today
Wasp (https://github.com/wasp-lang/wasp) has actually worked out quite well! It just crossed 10k stars on GitHub and is currently the fastest-growing full-stack framework for React & Node.js. It's being used in both startups and enterprises. Although Wasp has its own DSL/compiler, the secret to its adoption is probably that it works with the existing stack, like React & Node.js. From the developer's perspective, it feels like a framework; the "compiler" part is just what gives it its superpowers.
In Ask HN: Would you use a Low-effort Microservice Builder?
I have no idea what other folks are doing to stabilize it. For me, I needed a ton (hundreds of thousands) of JS/TS(X) files parsed and ingested into other data pipelines and the segfaults were constant^. If you had a system where single files were only parsed on-demand via separate worker thread and the consequence of a segfault was the text appearing monotone, I'm sure you'd be alright. ^One example: https://github.com/wasp-lang/wasp/blob/main/waspc/data/Gener...
In Let's create a Tree-sitter grammar
Although AI has been all the rage lately, I was actually always excited the most by building a compiler. After a few years of dabbling with it, I created one together with my brother: https://github.com/wasp-lang/wasp It is a DSL (a simple config language for building web apps) so not that complicated as a Turing-complete language, but still a lot of concepts remain. As a good starting resources for building your own compiler I'd also recommend Crafting Interpreters, super nicely explained and fun to go through: https://craftinginterpreters.com/
In Let's Build a Compiler (1988)
I know it is common to think that Haskell is used only in academia and side/weird-projects, but there is a decent amount of companies using Haskell - e.g. we use Haskell in production for developing a DSL / web framework for building web apps (https://github.com/wasp-lang/wasp)! I participated teaching students Haskell on my alma mater this year and "what can Haskell be used for" was a common question, with genuine expectation that the answer will be it is limited to only specific use cases. I would answer that it can be used anywhere where languages like Java, C#, Go, and similar can be used -> it is a general programming language that uses garbage collector! And while somewhat harder to learn due to abstractions that we are all not used to, it is a delight to express business logic in it once you get to know it well. The biggest factor
Read the rest
for deciding if Haskell is a good fit for the problem is probably ecosystem support -> are there enough libraries and tools to support efficient development in a specific problem domain. In our case, we are building a compiler/transpiler, and Haskell is well-known for great support in that area, so it was a no-brainer. We were actually also considering Rust, but we just had no need for that level of memory control and rather decided to go with language where we don't have to think about that (Haskell).
In Rust vs. Haskell
Absolutely, but if I had to rank Open Source projects by "enjoyment level to work on", I would rank a 10+ year old Java project primarily used by enterprise companies quite low on my list! Compare that to something like Bun.js[0] which is "sexy" and written in a "cool" programming language (Zig). Or Wasp[1] which is built with Haskell and is trying to define a new programming language designed to make common dev patterns less painful. Those projects are naturally going to soak up smart people that have extra energy to share because they hate their day job but need to pay their bills. (imo) Who is left that wants to bang their head against a legacy codebase like Log4j? Maybe somebody that feels there is "clout" to be had from it? (Spitballing here, I honestly don't know!) 0: https://github.com/oven-sh/bun 1: https://github.com/wasp-lang/wa
Read the rest
In Log4Shell Still Has Sting in the Tail
Our compiler is split into Analyzer which produces AppSpec, which is the central intermediate representation, and then Generator, that based on AppSpec produces the react / node web app. So yes, you could use just Analyzer to produce AppSpec, and then write your own generator that will based on that AppSpec generate your own code! AppSpec currently exists only as Haskell in-memory data structure, but it could be relatively easy serialized via JSON and then imported in some other language. You can see more about this in this README, there is a nice diagram showing parts of compiler (Analyzer, AppSpec, Generator): https://github.com/wasp-lang/wasp/tree/main/waspc#readme . The reason why we already ensured this split was because the plan is in the future to have multiple different Generators, and also to allow users to write either their who
Read the rest
le Generators or plugins that modify AST (AppSpec). We haven't explored this further yet, and probably won't push much in this direction until we get to Wasp 1.0, but we certainly want to work on it more in the future!
In Show HN: Wasp – DSL/framework for building full-stack web apps – now in beta
Our compiler stack is in Haskell so we initially started with Parsec (parser combinator library) and then eventually switched to Happy (parser generator that Haskell uses itself) since at first we didn't have a formal grammar defined so that made us write a lot of code for every little addition to the language (it's a simple declarative DSL, https://github.com/wasp-lang/wasp). The problem we're now facing with Happy is that it doesn't really have support for error recovery. We're trying to implement LSP so recovery is important in order to have proper syntax highlighting and error reporting in an IDE. Wondering how well ANTLR covers this, I was quite surprised to find out that Happy has so little support for it.
In Lessons from Writing a Compiler

Showing the 15 most recent of 37 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.