A unique thing about Wasp is that we built it around the central "specification" language (DSL) that lets you express the high-level of your app, for which we wrote our own compiler and language server in Haskell. You write 90% of logic in popular web tech (React, Node.js, Prisma), but specify the "full-stack" part of it in the DSL.

While we loved the idea of a custom language for optimal ergonomics and declarative nature of it, and had great time building it, we realized with time how hard it is to develop all the tooling around it while also building the framework, and also started getting constrained by its simplicity for some of the new ideas we have developed through time, of where we wanted to take Wasp.

So, 5 years since the start (wow feels like 2y), we made a big change: we replaced our custom DSL with the eDSL (embedded DSL, a library) in TypeScript!

So Wasp still has its spec(ification), stack-agnostic and standalone (runtime), but now you write it in TypeScript, with all the Turing-complete and side-effect goodiness, which allows things like splitting spec into multiple files, writing helpers, checking env vars, implementing your own file-based routing if you want, ... . And, also enables a lot of exciting stuff we plan to build upon it, like extensible spec, and full-stack modules.

For the full-story, please check out the attached blog post I wrote, and I am happy to answer any questions here!

Comments URL: https://news.ycombinator.com/item?id=48035573

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47987153

Points: 28

# Comments: 3

Btw, AI actually works great for it. I am sure part is that the Wasp's DSL exists for some time now, but it actually worked well for the very start, because the DSL was quite simple (similar to JSON) and AI knows how to generalize very well.

So I wouldn't discourage people from writing DSLs because of AI -> AI can understand them very well -> but for the reasons of missing out on all of the benefits of using a strong host language and doing it as an embedded DSL in it. If you are doing your own, completely standalone DSL, you will need to implement a compiler, editor extensions, LSP, maybe module system if you need it, maybe package system/manager if you need it, ... . Although when I think about it, that is also easier now with AI, than it was before! Hm yeah actually maybe custom DSLs are a good idea these days, with AI doing most of the job for you. I still wouldn't go back to custom DSL for Wasp however because biggest thing for us is probably familiarity -> custom DSL just scares people off.

Comments URL: https://news.ycombinator.com/item?id=47540823

Points: 2

# Comments: 4

Comments URL: https://news.ycombinator.com/item?id=43364929

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=37856419

Points: 3

# Comments: 1

As for getting somebody on-board -> we hired a couple senior / intermediate devs that had no or introductory knowledge of Haskell, and all of them so far got up to speed in a month or so, while not learning exclusively Haskell but also the rest of the codebase at the same time, so normal learning process in the new company. So I wouldn't say at all that learning Haskell for them was an issue, but I am certain that big factor here was that they are generally experienced in other languages. That said, we do keep our codebase pretty tidy and simple (no super crazy Haskell features).

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 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).

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 whole 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!

Comments URL: https://news.ycombinator.com/item?id=33804475

Points: 6

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=33774996

Points: 2

# Comments: 0

The fact that it is a DSL gives me a lot of freedom to implement whatever might be the best solution, so I am trying to think about it from the ground up.

Below are my thoughts so far, to start the discussion - I would love to hear yours!

1. Where is complexity coming from?

The problem arised with SPAs because UI logic moved from the server to the client, while server remains the source of the data. Therefore, we are sending more data over the network, and we have to be smart about what we fetch, and we need to cache it -> so complexity happens there.

2. Solutions: Implicit vs explicit cache

Implicit (Apollo, react-query): focus on operations, cache is implementation detail. Explicit (Redux, MobX): focus on the cache which you have to explicitly model.

3. RPC + meta data as a core solution?

Insight #1 -> Before the SPAs, we were dealing with the data via just logic on the server -> function calls.

Insight #2 -> Implicit cache solutions are becoming more popular than explicit ones -> operations > cache ~> functions.

So, currently best solutions seem to be converging toward how it was in the past, before the problem ever arised. Can we abstract the client-server state management to again feel like just calling functions?

If so, some form of RPC might be the solution. However we can't just ignore additional complexity, but maybe we can solve that by adding some meta-data to our functions, and that is it? It sounds true to the core problem and relatively simple.

This is somewhat abstract, here is how I implemented this specifically in the DSL for now: https://wasp-lang.dev/docs/language/basic-elements#queries-and-actions-aka-operations .

This is it shortly, let me know how you see it!

Comments URL: https://news.ycombinator.com/item?id=26401748

Points: 2

# Comments: 0