| I love new languages, and I love that you have all the basic elements of webapps as first class citizens. ....and then I saw that the page is still written using React and db access uses Prisma. They are not dependencies, you have to now about them, and their syntax and how they work. What is the incentive for me as a developer to learn both them and wasp? Especially since there are multiple places where the wasp layer is a thin layer over the underlying capability supported by those dependencies. Dont get me wrong. I say go bigger and make it a full-fledged DSL that generates react and prisma code without making them __visible at all__. That way nobody has to learn anything but wasp. Sure, you will be limited by whatever your underlying implementation layer is, but you can now switch from them easier, and its likely to last longer (there __was__ a time before React, and like will be one after too). Can you be the +1 layer that people dont have to look under? More specifically: 1. Can you have inline .js files? Even better: Can you bring the page content _into_ wasp's syntax? It currently says a webapp has pages and routes, how about expanding to say a webapp has components, elements and text? 2. Same question for storage schemas and migrations. Would that help with NoSQL integrations (vs expecting Prisma to support them)? 3. Can you eliminate the "Note:" sections in https://wasp-lang.dev/docs/language/basic-elements? Those are the leaks in the abstraction called wasp. And if the answer is no, then should there be a better abstraction? |
Web apps are complex beasts, and we believe there is a reason for multiple DSLs being used today (HTML, CSS, React/Vue/... as embedded DSL, Prisma as schema DSL + db access embedded DSL, Terraform, ...): it is easier to solve the problem by splitting it into subproblems and then solving each one of them with specialized language/DSL, than figuring out one DSL that works for everything. Even if we found one DSL that works for everything, it would at the end likely be a combination of multiple DSLs unified in one language.
So, if we decided to solve it all at once with Wasp, we would be solving N problems at the same time, and would need to beat whatever is the current best solution in most of the areas to be compelling enough to be used. At the same time, we would be competing with the whole web dev ecosystem that has shown in the recent years to innovate and progress very quickly.
That is why we believe more in the current approach we are having: by utilizing existing solutions for sub-problems, solutions that work relatively well and are on the edge of what we know is the best way of solving those sub-problems, and building our DSL in the space in-between, where the most of the friction is happening, we are bringing value where it matters the most while also riding the web dev ecosystem wave, instead of fighting it directly.
This doesn't mean that we can't expand Wasp with additional sub-DSLs if we figure out at some moment that, e.g. we have a better abstraction than React that would fit really well in Wasp - we can still do all that, but we can do it step by step, while still progressing in the meantime.
Also, this might not be very clear in the docs, but the idea of Wasp is not be tied just to React - idea is to also support Vue, Svelte, and whatever is coming next, when defining components. Also, idea is to support not just NodeJS, but also Go, Python and similar on the backend (maybe you could even combine them).
Regarding learning -> is it better for a web dev to learn complicated Wasp language and how to write view logic in it and how to write db access logic in it, or to learn a simple, smaller Wasp language and how to write view/db logic in React/Prisma? I think the second, since complexity is going to be similar in both cases due to Wasp becoming more complex in the first case, to be able to describe both view and db, while in the second case you are learning technologies that you can also use outside of Wasp later or you maybe even already know them.
Just to make it clear, what you are suggesting, to have 1 DSL for all -> I love it, it is our initial vision, and one I would very much like to be possible. We actually started that way with our prototype, but soon concluded that we need to divide and conquer (well, more like delegate in this case) if we are going to win this battle. We started with having elements in DSL like button, forms, but we left those to React for now -> however, we will probably try getting back to that in the future, if we manage to establish some footing first.
To answer the specific questions:
1. Yes! We are planning to relatively soon allow mixing of JS and Wasp logic, mostly for the purpose of making the code more readable and easier to organize. Describing lower-level details of the web app with Wasp, e.g. page content, elements, text -> that we would also like to do, but probably further in the future.
2. We initially started with our own syntax for describing schemas -> then we moved to Prisma since they have a DSL that works well. Right now we are working on our own Prisma DSL parser (almost done!), so that we can reason about those schemas independently of Prisma. Next step would be having our own syntax, which would make us independent of Prisma, as you said -> and yes, I believe we will be getting back to that relatively soon! Mostly with purpose of making it as simple and easy as possible. But now we will be armed with the knowledge of what worked well regarding Prisma DSL (PSL), what didn't, and what should work differently for Wasp.
3. That is a very good point, we should make that a rule: eliminate assumptions/caveats that we have to warn our users about - those are leaks in abstraction. I believe we can, but if not, I agree, we should look into modifying how we abstract those parts.