Martinsos

Hey, great to hear from you again :)!! Oh I remember that feedback very well, it was a big thing for us at the moment (and we left you even bigger response I believe ;)), really motivated us to see somebody is sharing so much of our vision!

We would love to keep in touch, you shared a lot of great ideas with us - if you would consider joining us on Discord (https://discord.com/invite/rzdnErX) or shooting us an email at hi@wasp-lang.dev, it would be great :). Thanks again for the support!

Yes, that is what we are trying to do! And maybe even more - we are pretty excited about what using a DSL can unlock. Far in the future, we actually imagine being beyond JS ecosystem and offering a choice of languages to use, especially on the backend.

Hey, we have a demo app deployed here: https://wasp-rwa.netlify.app/ , and you can see its source code here https://github.com/wasp-lang/wasp/tree/master/examples/realw... .

Wasp is still in alpha so many things are rough or not there, including accessibility, but we do plan to handle it in the future! Here is relevant github issue: https://github.com/wasp-lang/wasp/issues/126 .

Thanks! We love Haskell, we have been playing with it for years, and when we realized we want to build a compiler, we thought Haskell is just the right fit for it, due to relatively small amount of IO and lot of complexity. That said, not everything is perfect in Haskell, and we are still learning a lot every day, but we are really enjoying it. How about you, are you considering Haskell or already using it?

If I got you right, you are talking about embedded DSL inside Javascript -> kind of like a library? Or about JS-like DSL, that is a superset of JS?

Our main drivers for creating a bespoke language were: 1. potential to create a completely tailored developer experience - as simple and nice as possible. 2. detaching from specific language - we want to be able to potentially support multiple languages in the future, especially on the backend.

How do you see it as a DSL that is still Javascript - I would love to hear more!

Great to hear that :)!!

Thanks Nikolas for answering regarding Prisma! The reason why we chose Prisma is because it is declarative, which plays really well with Wasp, and because it supports multiple types of databases - for now only relational, but as Nikolas said, in the future also nosql.

Regarding TS - you are right, TS is a better fit for this than JS! We started with JS, but plan is to switch to TS real soon, for the reasons you described. Here is the Github issue discussing this: https://github.com/wasp-lang/wasp/issues/143 .

If you don't mind me asking, how big is your team / what are you using right now to build web apps?

That is weird, the one I provided above is set to unlimited expiration time and I see people coming -> maybe you used some other link, from the page/docs that might be old? If so let me know and I will fix it!

Oho you are also building a DSL for full stack web apps, I didn't expect that :D! Consider joining our Discord (https://discord.com/invite/rzdnErX), I would love to learn more about your quack!

True, right now it is just one file, and language is a simple "configuration", declarative language, just because we didn't need more so far. This is how we started, because we wanted to focus on capturing the basic abstractions of the web app at high level, and we want to keep the language as simple as possible -> so we decided to start really simple and then extend as we need more power.

We will certainly add splitting into multiple files, and will probably go beyond that with actual modules, expressions, simple conditional logic, basic types and similar - kind of like meson (https://mesonbuild.com/Syntax.html) and Terraform. Right now we don't see it ever becoming a Turing complete language, since we don't intend to capture the low-level logic in Wasp - we feel existing solutions are better fit for that (JS/TS/HTML/CSS/...) and we would not be doing our best work there, nor would we be able to keep up with the innovation.

Although, never say never -> my mind does wander off to Mint (https://www.mint-lang.com/) every so and so, thinking if we could do something similar at some point -> but even if we do, that is further down the road.

It is a tricky problem - on one hand, we want to capture as much as you can with DSL, since that gives us power to "do more", but on the other hand, we want to give you all the flexibility you need, which means doing stuff outside of DSL, stuff that Wasp does not understand and only sees as a black box. We think we can solve this by offering multiple levels of abstraction to choose from + escape mechanisms on the right places, and we are integrating with the JS ecosystem so you can write a lot of the natively already (NodeJS, React, more in the future).

So while we still don't have this completely figured out (and I don't think we will until we get it done), we are hopeful! One cool thing is that doing our DSL also gives us a lot of freedom here, to find the best abstraction.

Awesome, ping us on our Discord (https://discord.com/invite/rzdnErX) if you will have any questions - Wasp is still in early alpha and rough around the edges (including missing flexibility), so if you get stuck anywhere let us know! Actually ping us anyway if you wish, we would love to hear how you found the experience, how hard was it to get into it.

You are right, with this kind of approach, extensibility/flexibility is the central question - we want to make Wasp really easy and simple to use, but on the other hand, complexity is needed to provide the flexibility to produce complex applications.

Right now, Wasp is already leaving big gaps to be filled in by JS/TS (Node, React), but there is also a big part that is abstracted away and hidden by Wasp. For that part, our main idea is to offer abstractions of different levels that you can choose from. For example, you can choose Wasp's RPC to communicate between backend and frontend, but nothing is stopping you to directly access request and response in your expressJS middleware if you want and write your own REST API or use GraphQL. Or, you can use our authentication system completely, or use just part of it, or completely ditch it. So there should always be a "lid" that you can remove and access the system beneath.

That said, we are still figuring this out - where to offer escape mechanisms, how to organize them, how much to abstract certain parts - there is certainly some limit to flexibility that we can offer. What is cool that having our own DSL gives us a lot of freedom here (although it is also a lot of work!).

One thing we do have in the meantime is ability to eject the code and continue with it if you get stuck with Wasp at this alpha stage -> it is actually human readable! I am not sure if we will be able to maintain that property as Wasp grows though, but we are not giving up on it for now.

Hey yes, we have been working on a React/Node app for two years some time ago, that grew to that size and some more.

I understand the skepticism, to be honest I was also pretty skeptical when we started (I am still a little bit, a healthy dose :D!), but we think now we can get to the level of flexibility of serious web frameworks - it all comes down to figuring out where the flexibility is needed.

Right now it is already pretty flexible - you can write any nodeJS logic and use any JS library, same goes for React components. What is tricky is hitting this right trade-off between flexibility and power, and we are thinking a lot about that.

So to summarize, I agree, but am hopeful!

e2e testing -> yes, that would be very cool :)! We don't have any testing capabilities yet, but will be looking into it.

Regarding bigger projects - one thing I am excited about is the possibility to model not just one web app via the DSL, but to capture multiple services - for example multiple (micro)servers - and orchestrate them. I haven't explored that direction enough yet though, since it is not the priority right now.

Woah thanks :)! We had previous experience with writing a compiler for subset of C (during uni), and I also did some learning from the "Crafting Interpreters" book, but regarding the DSL design, I would say it is actually simpler -> we just went kind of ad-hoc and are expanding syntax as we figure out what we need. I am not sure if that is the best process, I would love to learn about the better one if there is one, but it worked so far. Wasp is still pretty simple, really not much more expressive than JSON at the moment, but we hope to add more stuff soon. While we are using parser combinators right now to parse the language, which is pretty manual process, once it becomes clearer what the language looks like, we will look into capturing it with formal grammar and then use some of the more advanced tools to parse it. The book I am going through right now is "Language Implementation Patterns" by creator of Antlr, it has chapters specific for designing DSLs!

Yes, that's the idea! We first want to get the web app part working really well, and then we will be looking into adding mobile. It will certainly require extending the DSL though, to capture both web and mobile specifics, but the idea would be to keep it as general as we can.

Hey, thanks for nice words!

Dodgy install -> well true we ask you to run something, but I have seen quite a few prominent tools use this method of installation: NVM: https://github.com/nvm-sh/nvm#installing-and-updating Haskell Stack: https://docs.haskellstack.org/en/stable/README/#how-to-insta... Nextflow: https://www.nextflow.io

How would you go about it? We do plan to have packages for different distributions at some point, but unless it gets into the official repos, it is not any safer, it can still run any code and nobody checked it, am I right? Even if it was npm package, we would still have the same problem if I am correct, it can run anything? Maybe I am getting this wrong hm, I am happy to hear your suggestions!

Hm interesting question with node requirement and npm package. Long term idea is that Wasp might not have only Node backend as an option, but also other backends, and in that case it won't require Node. So that would be the main reason. Compiler itself does not need node to function, generated code needs it.

Ha the logo, we grew fond of the current one but it would be cool to also have an alternative "wasp" logo :)! Buuut if you squint and use a lot of imagination you can imagine "=}" to represent a wasp (antennae, wings and spike :D?)

Congrats :)! How does this compare to Neo4J and what would be some typical use cases?

I love how simple the solution is, I tend to over-engineer stuff like this by trying to actually make it clickable and so on, but this just works great - good example of doing the simplest thing that works!

Hey, thanks for nice words, and yes, although we are still very early and it might take some time to get there, that is certainly the plan! We plan to offer different stacks, which means different FE, BE and DB, but I think we will start with DB because that is important to people.

Btw, idea right now is that you don't have to do much (or any hopefully) setting up of DB and instead we do it for you with some decent defaults, but we have to see yet how will that work out in practice.

Thanks again, and if you would like to try out once it is ready, consider watching the repo or leaving email on webpage.

Hah, also thought it is Big Oof!

Useful! I am not looking for a job, but on the other hand I like being updated on what is out there (with respect to my interests). Which means I will not go through the jobs now, but if I could define my filter/interests and then subscribe to get an email with job roles that are best fit, every week or 2 weeks or month, that would be interesting.

Interesting experiment! I read the README and I get the basics of the idea, but it might help if you could provide more examples in the README - for example video that shows how you improved the file structure, explains how does your formatter decide how to transform files into fractal structure?

Hey, thanks for nice words! Close, it is functional but not Racket :) -> we are implementing Wasp in Haskell.

I read about Racket, and I know it is Scheme based and especially tailored for developing languages. We picked Haskell because we have previous experience in it, want to learn it better and thought it would be a good fit for writing a compiler. On the other hand, since Racket claims it is especially good for languages, I have to admit I wonder if it would be a good choice - but I just know so little bit about Racket that I can't judge.

Would love to hear what you think since you probably know more about Racket than us!

I am currently evaluating quicknews!

Except for 1000 new js frameworks being created in that period :D, I imagine (with assumption of web still existing as a platform), that the underlying core concepts are going to stay the same (data, view, control logic), while development tools will be much more advanced. Meaning that it will be easier to create "standard" web pages / apps, by connecting basic blocks or writing high-level code. And since we have LSP (Language Server Protocol) now as a standard, emacs will have fully-featured modes for all those tools/languages :D.

Hi Hendzen, I found in one of your previous comments that you have set up your emacs to have full support for c++ projects, like auto-completion and reference following and similar. I have been using Emacs for a few years now, for js/python/html/C/C++/anything else and have just started working on a larger C++ project where intelligent auto completion and navigation would help a lot. Would you mind providing some more details on how you got it set up, maybe share your init.el file? It is a Cmake project, uses ninja as a generator. Thanks!