Thanks a lot for your support, really appreciate it! :) Yeah, this is definitely something a lot of developers are thinking about and would like to have, and this promise has materialised in many more or less successful forms (e.g. Ruby on Rails when there were no SPAs) over the years. We're also very excited about this and think now is the best time ever to achieve, given all the awesome and mature technologies we can build on top of (React, Node, Prisma, ...).
And the concept is super promising, sort of a high level declarative language which hides away all of those tedious details. which are essentially the same anyway from project to project - with the goal to be able to focus on the unique business requirements of an app, rather than spending time on boiler plate and reinventing the wheel.
This is sort of the "holy grail" of software/app/web development, and it has been attempted numerous times, but ulitmately none of those efforts really took off ... curious to see if this time around it could be a different story.
So what if I'd want to use, let's say, Vue instead of React - does the language support that, and if so, how? I also see new 'frameworks' popping up that are built on top of React, such as Remix which is now really getting popular - how difficult (or easy) would it be to integrate or support that?
Yes, that is exactly what we are thinking with Wasp! Right now, in Alpha, Wasp supports only React and Node.js + Prisma. Our goal is to add support for Typescript next and then bring it with that stack to the stable 1.0. With that in place, we plan to look into adding support for more FE libs (probably Vue) and also BE (e.g. Python).
Next/Remix is also a great point - we're looking into how to integrate it best - either by supporting them within Wasp or by replicating pieces of functionality they offer (e.g. SSR). That's still something we're not yet totally clear about, depending on what kind of DX we can offer with each approach.
Re difficulties of integrating with different languages/libraries - Wasp DSL is built in a way which makes it absolutely possible, but it is definitely a lot of work. In the beginning we will probably implement support for each independently, and then see if we can recognize common patterns we can extract.
Ideally, you should try to make this stuff pluggable, allowing "third party" devs to develop 'plugins' for those other languages or frameworks, WITHOUT having to touch the core of Wasp - which means you wouldn't need to do all of this work yourself ...
But, I understand that that's easier said than done - you may need to implement some of these yourself first, in order to gain an understanding on how a "plugin" system might work :)
That is exactly what we were envisioning! We imagined a plugin/module system where developers could themselves implement certain integrations & features. We could expose Wasp AST (data structure that emerges after the initial parsing) so they could modify and expand it.
It's still very high-level thinking, but we also described it in bit more details in this issue on Wasp repo: github.com/wasp-lang/wasp/issues/227
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks a lot for your support, really appreciate it! :) Yeah, this is definitely something a lot of developers are thinking about and would like to have, and this promise has materialised in many more or less successful forms (e.g. Ruby on Rails when there were no SPAs) over the years. We're also very excited about this and think now is the best time ever to achieve, given all the awesome and mature technologies we can build on top of (React, Node, Prisma, ...).
If you want to give it a try check out our Alpha Testing Program: wasp-lang.notion.site/Wasp-Alpha-T...
Yeah I'd like to ...
And the concept is super promising, sort of a high level declarative language which hides away all of those tedious details. which are essentially the same anyway from project to project - with the goal to be able to focus on the unique business requirements of an app, rather than spending time on boiler plate and reinventing the wheel.
This is sort of the "holy grail" of software/app/web development, and it has been attempted numerous times, but ulitmately none of those efforts really took off ... curious to see if this time around it could be a different story.
So what if I'd want to use, let's say, Vue instead of React - does the language support that, and if so, how? I also see new 'frameworks' popping up that are built on top of React, such as Remix which is now really getting popular - how difficult (or easy) would it be to integrate or support that?
Yes, that is exactly what we are thinking with Wasp! Right now, in Alpha, Wasp supports only React and Node.js + Prisma. Our goal is to add support for Typescript next and then bring it with that stack to the stable 1.0. With that in place, we plan to look into adding support for more FE libs (probably Vue) and also BE (e.g. Python).
Next/Remix is also a great point - we're looking into how to integrate it best - either by supporting them within Wasp or by replicating pieces of functionality they offer (e.g. SSR). That's still something we're not yet totally clear about, depending on what kind of DX we can offer with each approach.
Re difficulties of integrating with different languages/libraries - Wasp DSL is built in a way which makes it absolutely possible, but it is definitely a lot of work. In the beginning we will probably implement support for each independently, and then see if we can recognize common patterns we can extract.
Ideally, you should try to make this stuff pluggable, allowing "third party" devs to develop 'plugins' for those other languages or frameworks, WITHOUT having to touch the core of Wasp - which means you wouldn't need to do all of this work yourself ...
But, I understand that that's easier said than done - you may need to implement some of these yourself first, in order to gain an understanding on how a "plugin" system might work :)
That is exactly what we were envisioning! We imagined a plugin/module system where developers could themselves implement certain integrations & features. We could expose Wasp AST (data structure that emerges after the initial parsing) so they could modify and expand it.
It's still very high-level thinking, but we also described it in bit more details in this issue on Wasp repo: github.com/wasp-lang/wasp/issues/227