Launch HN: Wasp (YC W21) – DSL for building full-stack web apps

ignoramous · on Feb 10, 2021

> ...understand the web app’s requirements during the build time and reason about it before generating the final code. For example... it could pick the most appropriate architecture based on its understanding of the web app and deploy it to serverless or another type of architecture.

Wowzer! For me, this is the main benefit. I'm a big believer in low-code platforms like darklang, because the fundamental truth that bugs are a function of both SLoC and underlying infrastructure is never going to change, and one solution to that is to automate as much of it as possible.

The only problem I see is that these automations that eliminate code and abstract away the infrastructure often result in a new class of harder-to-debug or worse never-seen-before bugs. And so, building a language that "solves software engineering" may require a lot of patience and perseverance. With that in mind, how long do you plan to keep at it? How long term are you thinking you'd be doing this? I mean, you could still be working on wasp-lang whilst working full-time elsewhere... but then, that requires a different level of commitment when the business around it has failed.

> Wasp’s compiler is built in Haskell

Two questions, if I may: Why Haskell? Did you also consider OCaml (à la Rust) at some point?

Edit: I see wasp-lang is MIT licensed. Why not Apache v2 (or even MPL v2)? Especially since MIT lacks patent-grants clause.

Excited to see how wasp-lang evolves. Thanks!

matijash · on Feb 10, 2021

thanks for your feedback and questions! yes, it (build-time reasoning) is also the most exciting thing for us, really excited to see what can be done.

I also totally agree on being harder to debug, that is the challenge that comes with abstraction - at this stage we are not doing very much about it (mostly just propagating errors from server/client) but it is something we'll definitely need to focus on as Wasp matures.

We chose Haskell because we had some previous experience with it and thought it would be a good fit for building a compiler (doesn't have a lot of realtime IO so we can keep the code simpler). Haven't yet tried OCaml or Rust (heard Rust is somewhat more low-lvl) but I believe they would be viable alternatives too.

Re long-term doing Wasp - also agree, we believe this is a full-time job so that is why we joined YC and got the initial funding so we can focus on it longer term.

Re Apache v2 vs MIT - thanks for letting us know! We haven't yet put much investigation into it but will definitely need to do it soon.

ignoramous · on Feb 10, 2021

> Re long-term doing Wasp - also agree, we believe this is a full-time job so that is why we joined YC...

All good, but what I really meant was, what happens when that funding money runs out and/or there's no business around wasp-lang to corner more investment?

> Re Apache v2 vs MIT...

Golang's BSD 3-Clause + patent-grant; and Rust's dual-licensed MIT (for compatibility with GPL v2, I believe) + Apache v2; whilst Clojure is EPL v1, though EPL v2 (+ the GPL compatibility clause) may also be a decent weak-copyleft choice for a programming language (ianal).

See also:

https://fossa.com/blog/open-source-licenses-101-apache-licen...

https://opensource.com/article/17/9/facebook-patents-license

matijash · on Feb 10, 2021

Get it now! The big part in our opinion is growing a community of people using Wasp for their projects - if we manage to do that, we'll definitely be motivated to continue, funding or no funding. We are of course motivated to build a business on top of Wasp, but for now still focusing on the product.

Thanks for the info about licenses, awesome overview!

abraxas · on Feb 10, 2021

I get the sentiment. I understand the problem. The amount of disjointed tools that need to be strung together to build the proverbial todo list in the modern web ecosystem is beyond ridiculous. So much so that most of the people at my company seem to be spending most of their time adopting tools rather than building software.

What I quibble with is your solution. This is another layer on this cake of complexity that tries to hide the ugliness beneath rather than truly simplify. This sort of wrapping is rarely successful because eventually one of the underlying bits refuses to do its thing just as you’d hope and the house of cards comes tumbling down.

I don’t think the crappiness of the cloud and webdev “stacks” can be rectified without a do over. I think it may need a rethink from the OS all the way up. Maybe right down to the hardware layer.

I don’t think what’s there now is salvageable if we are hoping for a true shift in productivity.

Martinsos · on Feb 11, 2021

I get where you are coming from! It does feel like that sometimes when building Wasp - a lot of technologies we are layering on top of, sometimes we need to let them leek out, sometimes we want to hide them, and sometimes we have to play around them - it is a lot of work to put all that together to play nicely, and it will never stop shifting, even if we "make it" it is always going to be constant effort keeping up. On the other hand, I can't imagine tackling this in another way. Designing a web app is not complex for no reason - it is complex because web apps are complex. They are multi-user systems that work over distributed architecture, that need to maintain persistent state, look good, be scalable, be fast, work on all kinds of different browsers/devices/screens, be secure, ... . When you also add all the innovation that is happening in the current system, the idea of build a bespoke solution from the ground up sounds next to impossibly hard. Even Wasp sometimes feels impossibly hard to do, and it is still of much smaller scope than completely bespoke solution. I would love to hear your ideas on this though - I certainly haven't been thinking a lot in this direction, merely due to discarding it upfront as a possible approach.

Btw, one thing that Wasp does in alignment with your idea of bespoke solution, is that it brings DSL that is in big part detached from the technology used for the implementation of the specific parts (JS/React/Node/...), meaning that if we get it working with existing technologies, we have one foot on the solid ground and can work from there to see which other, "smaller" problems can be tackled next, potentially ending up with a set of solutions that together create one new, bigger, bespoke solution.

abraxas · on Feb 11, 2021

I don't have solidified idea for reinventing web dev but I'm oscillating between two opposing strategies. One would be to have a micro app server in hardware - think RPi nano or even less, where each http session gets a dedicated "box" thus returning to the model of development that reduces everything to a single user, single process system. Persistence becomes a challenge. Ideally it would be a truly shared hardware component or alternatively it would be a swarm of tiny disks that can be queried independently and in aggregate.

The opposite idea would be to build a single OS on top of distributed hardware that presents resources in a truly unified fashion where the illusion of programming and deploying to a single machine is unbroken and none of the underlying abstractions leak up. Think VMware but in reverse.

The other thing that must be done over is the DOM/JS paradigm. It's so absurdly and ridiculously complex for what it does that it makes most developers laughable unproductive. There is no reason there couldn't be an environment like Delphi or VB but geared to the web developer. Wasm is a ray of hope here as its cutting loose the inane JS/DOM paradigm and finally offering a plain programmable canvas to the browser for the first time since the demise of Flash an Java applets before it.

Martinsos · on Feb 11, 2021

The idea of single OS sounds great! Sounds like the future of the Cloud.

DOM/JS -> I think it now mostly came down to the paradigm of reactive programming, with React / Vue / Svelte. What about Delphi and VB, what was so good about them?

abraxas · on Feb 11, 2021

it was easy to reason about. It was basically a canvas and UI components wired with callbacks. It didn't have the state management stuff of Redux but it was dead simple to reason about anyway despite everyone rolling out their own "state" objects.

But the whole idea of mutating UI by changing the DOM via a script is a pile of needless complexity for 99% of the apps out there. A simple canvas with GUI components that fire callbacks would be way easier for most developers to work with.

catchmeifyoucan · on Feb 10, 2021

This seems really awesome. I read the sample project, and was able to understand it really fast. It honestly would make our engineer onboarding really fast! Since it's all in one simple place. And the architecture is standardized.

The authentication model is what I liked most.

I think the biggest blocker is the use of Prisma however. I've never heard of Prisma before, and I'd have no problem using it. But I use DynamoDB for practically everything, not sure how that translates to that world.

The second concern is that most of projects are written in Typescript. I'm not sure how this works with TS. I'd hate to write an entity twice - for example, a user entity, and a user interface in TS. Because they have to be typed anyways.

nikolasburk · on Feb 10, 2021

Hey, Nikolas from the Prisma team here!

As of today, we indeed only support relational databases (Postgres, MySQL, SQL Server, SQLite) but we are already working on a connector for MongoDB[1] and plan to expand to more DBs in the future, here's the open issue to support DynamoDB[2].

Hopefully Prisma becomes an option for you once we support your favorite DBs!

[1]: https://www.notion.so/prismaio/Prisma-Roadmap-50766227b77946...

[2]: https://github.com/prisma/prisma/issues/1676

Martinsos · on Feb 10, 2021

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?

momothereal · on Feb 10, 2021

Looks cool!

Do you have any examples or have experience with larger projects? For example, my React app has dozens of pages and some complex routing, and the backend has 50+ endpoints and talks to different databases, RabbitMQ, etc.

When I see "shoe that fits all" solutions like this I'm honestly skeptical about the degree of freedom I get for more complex architecture needs. I've found frameworks like Next.js usually give you the freedom you need because it's basically pure JS.

Also, this seems like it has a good opportunity to automatically integrate e2e/integration testing.

Martinsos · on Feb 10, 2021

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.

vinodkd · on Feb 11, 2021

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?

Martinsos · on Feb 11, 2021

I love the idea you are describing, it is very much our initial (and maybe final) vision that we had when we started working on Wasp! But, our vision of the best approach for the current moment is somewhat different, let me explain below.

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.

hopia · on Feb 10, 2021

I thought you were on to something really nice last year, and left you a long list of feedback on Indiehackers: https://www.indiehackers.com/post/launched-landing-page-for-...

Nothing makes me happier than seeing you guys having come so far since then and having stayed so determined!

Martinsos · on Feb 10, 2021

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!

bgdnpn · on Feb 10, 2021

I have been thinking of something similar for the last few weeks: most apps are 80% the same components (as you were saying "auth, routing, data model CRUD, ACL"), but these get re-written or at least re-engineered again and again.. wouldn't it be cool to define your apps' main components as a sort of DSL and then generate a starting poitn? And here you are. This is so interesting.

Would love to have a short chat about this in the near future, if you have time!

Martinsos · on Feb 10, 2021

Exactly!! Ah I love to hear this :D. Sure, we would love to -> consider joining us on Discord (https://discord.com/invite/rzdnErX) and you can ping us there whenever you want, or you can also shoot us an email at hi@wasp-lang.dev and we can continue from there :).

matijash · on Feb 10, 2021

would be awesome to chat!

yaseer · on Feb 10, 2021

This is pretty neat. Programming languages are about working with the correct abstractions for your problem domain.

It's about time we had a high level DSL for working with web abstractions.

matijash · on Feb 10, 2021

thank you, that is what drove us too! But we also believe the key is in keeping integrations with the existing tech, e.g. React/Node.js so it is still possible to express more custom logic where it is needed.

mwcampbell · on Feb 10, 2021

Can we try a demo app somewhere, without having to build it ourselves? I'd like to see how you handle user-visible concerns such as accessibility.

Martinsos · on Feb 10, 2021

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 .

mwcampbell · on Feb 10, 2021

I'm happy that you already had an issue open for accessibility. Thanks!

This demo app isn't bad. The biggest problem I've found so far is that a screen reader user doesn't hear anything when a client-side page load happens. This is a common problem with SPAs, and there isn't a great solution for it. The best you can do right now is use an off-screen ARIA live region to announce something like "navigated to [page name]". Sometime though I'd like to work with the web standards community to standardize a better solution.

Martinsos · on Feb 11, 2021

I have to admit with shame I know sparingly little about the accessibility when building web apps, but with Wasp we think it could be a really valuable feature to offer - guaranteed best accessibility practices - it should be integral part of Wasp.

Why doesn't screen reader detect it -> because URL does not change? What if SPA updates URL via history API, does that help? off-screen ARIA region sounds like something we could generate with Wasp automatically.

Once we reach some level of stability, we plan to put more effort into accessibility -> if you wish, write a comment on our GH issue and we will be happy to include you in the effort when we work on it, help from somebody experienced with accessibility would be great.

cubano · on Feb 10, 2021

Great job guys and love hearing stories about brothers working together.

So like the main problem with this is like the long standing one of time...while I would actually love to work with a better way to build webapps with modern stack elements, no matter what relearning to do everything in Wasp will take at least a month.

What if after all the time you discover an issue with the framework that prevents you from being able to complete your project?

Is it possible to extend the included base libs and work natively if need be?

I guess as long as devs have the ability to push Wasp aside and work directly with the libs, there is nothing that you could not eventually do.

Just some quick thoughts but Im gonna give this a whirl this week.

Martinsos · on Feb 10, 2021

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.

nicoburns · on Feb 10, 2021

What's your story on extensibility? My experience with such tools if that they're great while you stay within the bounds of what they support, and quickly become a nightmare when you (usually quite quickly) hit into their limitations.

As a junior dev I'd have loved this. Now, every instinct is telling me stay away.

Martinsos · on Feb 10, 2021

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.

fny · on Feb 10, 2021

Why did you decide to create a bespoke language rather that create a DSL that's still JavaScript?

Martinsos · on Feb 10, 2021

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!

akshaybhalotia · on Feb 11, 2021

Totally unrelated to the post but chaotic-neutral question: are you folks similar looking twins? If yes, have you ever done this or thought about going to work in place of the person and see how long you could get through the day? Would love to hear anecdotes if any!

Martinsos · on Feb 11, 2021

Haha, ok this is certainly an unexpected question :D! No, we are not identical twins, we are fraternal, meaning we have different DNA and look apart. So we were never able to pull of that kind of stunts :D! But, even if we were, we couldn't really pull it off since we work together since ever so people would realize one of us is missing :D.

The usual situations we get into is that people at the beginning can't remember which one has which name. Luckily, often it is also not important hehe :D.

The worst situation we had so far was probably when we were applying for our first year of uni - our applications looked so similar that they thought it was the same application sent twice by mistake, so they took into account only one of the applications! Luckily we realized on time that something is wrong and were able to appeal :D.

akshaybhalotia · on Feb 11, 2021

Certainly an unexpected answer too!

Working together must be a different kind of fun. Cheers to that.

matijash · on Feb 11, 2021

thanks for the twin love, love the question! :)

haha yes, we are not identical (although similar at first look) so no huge (fun) misunderstandings, but we have similar names and same initials so that caused confusion several times. Whenever I got more points on the exam Martin would suspect they mixed us up and go check :D.

Otherwise it is really rewarding to work with a brother! We can agree really quickly and can skip all the formalities and pleasantries when making decisions since we know each other so well. Would definitely recommend :)

Martinsos · on Feb 11, 2021

And we can have a good fight knowing that the other one is not going anywhere :D.

jonstaab · on Feb 10, 2021

Very cool project! I love stuff like this. I actually started a very similar fun project last week[0]. It's very much just a thought experiment, but the most interesting thing about it (I think) is the use of dynamic rather than lexical scope to control state. It's also designed to be extensible using python, js, and html.

I did take a quick look at the Wasp real-world app and was sort of disappointed. It seemed like a single file with lots of weird syntax that pulls in a regular old React app. Is there something I'm missing?

[0] https://github.com/staab/quack

Martinsos · on Feb 10, 2021

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.

jonstaab · on Feb 10, 2021

I'd love to join the discord and contribute my two cents, looks like the invite is expired though. Also, I hadn't seen Mint, that also looks like an awesome project.

Martinsos · on Feb 10, 2021

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!

0xferruccio · on Feb 10, 2021

I’ve tried to find something like this for a long time! You’re bringing the ease of deploying and building a web app with Rails + Heroku to the JS ecosystem

Martinsos · on Feb 10, 2021

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.

nwsm · on Feb 11, 2021

Looks interesting! Is there no live hosted example site built with Wasp? I didn't see links for deployed versions of the realworld or TodoApp examples which would be nice.

(edit: I found a Medium clone linked on their homepage: https://wasp-rwa.netlify.app/)

Is there any distinction in the language for client- vs server-side routing?

Martinsos · on Feb 11, 2021

Actually we have an example, you can see it lower on the landing page! Here is link to deployed real world app: https://wasp-rwa.netlify.app/ , while source code is here: https://github.com/wasp-lang/wasp/tree/master/examples/realw... .

Right now we have only client server routing really, while server side routing is abstracted away and replaced with RPC - but we will make sure soon to provide better customization support there too.

sanmak · on Feb 10, 2021

To author, the app looks like an efficient way to build an app but would be better if you can add some more examples to showcase wasp-lang actual power. Examples with basic workflow will suffice.

For someone who want to build something fast and prevent themselves from repetitive tasks, they need to be very sure before jumping into a new wasp-lang codebase.

matijash · on Feb 10, 2021

thanks for the feedback, I agree having showcases is crucial for showing what can actually be built with Wasp.

We ourselves built a copy of Medium with Wasp - feel free to see it deployed here (https://wasp-rwa.netlify.app/) and check the code here (https://github.com/wasp-lang/wasp/tree/master/examples/realw...)

For the super simple example with less code check out TODO app built with Wasp: https://github.com/wasp-lang/wasp/tree/master/examples/tutor... (check out main.wasp and then the code in ext/ folder)

Hope this helps!

sanmak · on Feb 11, 2021

Thanks it does.

I suggest to open a showcase section in your repo. It'll open up a channel for contributions from those who wants to build apps on top of wasp-lang.

Martinsos · on Feb 11, 2021

Hm that sounds interesting! Did I get you right, would that be a section in our README.md named "Showcase" where we would list projects made with Wasp?

zibbity-rw · on Feb 10, 2021

This is brilliant! Do you have any resources or thoughts to share on designing DSLs? Mad respect for people doing this.

Martinsos · on Feb 10, 2021

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!

zibbity-rw · on Feb 10, 2021

Thank you!

matijash · on Feb 10, 2021

we also have a DSL design channel in our Discord - feel free to join and start the discussion, we'd be happy to learn from you and also help if we can! https://discord.com/invite/rzdnErX

herunan · on Feb 11, 2021

Looks really great! Will give it a try. You already have a stamp of approval from a Rails dev.

matijash · on Feb 11, 2021

oh wow, that's really great to hear! Would love to get more of your feedback once you tried it - feel free to join our Discord channel (https://discord.com/invite/rzdnErX) or email me directly at matija@wasp-lang.dev if you'll have any questions

alex-wallish · on Feb 10, 2021

Very cool project. How do you plan to monetize it? I don't see mention on the site

matijash · on Feb 10, 2021

we are not totally sure yet (since we are now focusing on getting the project to the stable stage), but we think the most straightforward way would be to provide our own, "one-click" deployment/hosting service. On the other hand, since we are providing an e2e solution we think there could be multiple spots for providing extra value on top of the language, but we have yet to explore it.

teryyy · on Feb 10, 2021

consulting/support might be another avenue for monetization

cpursley · on Feb 10, 2021

Would be great to see this paired up with Hasura as the backend (also written is Haskell). I'm using Hasura with React Admin (configuration based admin framework) and it's a huge time saver.

bradyo · on Feb 10, 2021

Yeah this feels a little bit like a declarative configuration file for Hasura/Firebase (which is already a good idea). Looking forward to seeing how far you can take the frontend stuff!

matijash · on Feb 10, 2021

thanks for sharing, definitely sounds like an interesting combo! How is your experience with Hasura/Firebase, anything you found cumbersome?

Martinsos · on Feb 10, 2021

We know about Hasura -> it sounds like a cool idea! First we will be focusing on conquering React/Node combo, but it will be interesting to explore if there is an opportunity to include solutions like Hasura. What part of logic do you imagine happening in Hasura, and what in Wasp? I guess in this case Wasp would mostly be handling frontend right?

I will have to check out React Admin, I haven't heard about it yet.

cpursley · on Feb 11, 2021

Hasura can stand up almost of your backend without a single line of code on top of Postgres. The parts that Hasura can't handle you implement with your back end language of choice.

- https://marmelab.com/react-admin/

- https://github.com/hasura/ra-data-hasura

Martinsos · on Feb 11, 2021

Thanks I will take a closer look!

pella · on Feb 10, 2021

Question:

Mobile App (iOS/Android) - generation is on the roadmap?

( using same metadata(DSL) )

Martinsos · on Feb 10, 2021

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.

insomniacity · on Feb 11, 2021

Every other tool in this space is in NPM - why do I have to trust your install script?

Martinsos · on Feb 11, 2021

Hey, the thing is Wasp is not written in JS, so while we could use NPM, we would be forcing it in a way - at the end it would come down to shipping bash script as part of our npm package and just running that bash script from package.json commands/scripts. Second thing is, that while Wasp is dependent on node right now, which then serves as an argument to use npm as installation mechanism, we plan to remove dependency on node by dockerizing everything in the future (it is step toward detaching Wasp from specific implementations), so we lose that argument.

That said, we have not completely ditched idea of using NPM as installation mechanism, but we haven't convinced ourselves yet - maybe we should give it more thought though. What do you think is the benefit of using NPM vs our install script? Why would you trust NPM package more? Both NPM package and our install script are open source and you can see the code, both have equal execution privileges on your machine - why would you trust NPM package more?

insomniacity · on Feb 15, 2021

Fair point on the future direction.

SE says it better than me: https://security.stackexchange.com/questions/213401/is-curl-...

Particularly the first link, which outlines how to return different things depending on whether it's being piped into bash or not: https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Martinsos · on Feb 16, 2021

Thanks for sharing this! Reading this, there seem to be a lot of opposing opinions, but it seems to come down to curl being as safe as other methods, with the main problem being trusting the server from where the script is downloaded.

In our case, server is github so that is allright, but script is on master, so that is tricky because we might update it at any moment, so you should check it once it is downloaded. That is a concern for sure, and there are ways to remove that concern.

One thing that goes to our benefit though is that we are not requiring `sudo`.

Thanks for pointing all this out, we will certainly be looking into better ways to install Wasp in the future!

borellvi · on Feb 10, 2021

Congratulations for the launch! How are you finding Haskell? Why did you pick it?

Martinsos · on Feb 10, 2021

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?

sharemywin · on Feb 10, 2021

What is the benefit of a DSL versus a configuration file?

matijash · on Feb 10, 2021

right now Wasp DSL is pretty much the config file, it isn't much more expressive. Short term benefit is that this way we can provide nicer & more intuitive syntax (config files like json/yaml can quickly become very nested and hard to read).

Longer term, we plan to add support for inline-JS, so you could e.g. mix JS and Wasp code (instead of just referencing js imports as it works now). We will also add some basic language constructs (expressions, conditionals, multiple wasp files) so we might get more similar to e.g. Starlark or Terraform's DSL.

pella · on Feb 10, 2021

Please add an extra AI layer generating WASP DSL !

GPT-3 -> WASP -> Web APP

matijash · on Feb 10, 2021

hah that would be cool! One reason we are excited about the DSL approach is that it allows us to 'capture' web app's requirements in a declarative structure separated from the implementation.

As you mentioned, that means it could be possible to generate Wasp DSL via other means as well, not just by writing it down directly (e.g. via a visual editor), and some specific parts could be even assisted by AI.

bnr · on Feb 10, 2021

That link does not work, Page not found: https://wasp-lang.dev/docs/tutorials/getting-started

matijash · on Feb 10, 2021

thank you, fixed! The correct link is https://wasp-lang.dev/docs/