[HN Gopher] Show HN: Wasp - DSL/framework for building full-stac...
___________________________________________________________________
Show HN: Wasp - DSL/framework for building full-stack web apps -
now in beta
Hey HN! Wasp (https://wasp-lang.dev/) is a simple config language
(DSL) and framework for building full-stack web apps. You describe
the high-level features you want (auth, CRUD, async jobs, ...)
using the Wasp DSL, and write the rest of your logic in React,
Node.js, and Prisma. We're focused on simplifying developer
experience and ensuring best practices. Everything is open source.
Why another full-stack framework? And why a config language/DSL? We
were still experiencing a lot of boilerplate (repetitive tasks)
using other frameworks--things like duplicating data models across
database/server/client, implementing CRUD API, setting up auth, and
choosing and stitching together all parts of the stack. There are
two main reasons for the DSL approach - 1) short-term: simpler and
cleaner DX via a declarative language that helps avoid boilerplate,
and 2) longer-tem: laying foundation for the stack & architecture
independent system. Since Wasp analyses the app's requirements in
compile time, it can decide how to generate the target code (React
& Node.js currently). In the future it could support other stacks
such as e.g. Vue/Svelte on the client and Python/Go on the server,
even allowing for mixing'n'matching. The same goes for the
architecture (dedicated server, serverless, ...). Our big vision
for Wasp is to become a stable, stack-agnostic language for
describing (web) app requirements (like SQL for databases or
Terraform for infra) that interops with the existing stack. Wasp-
lang stands for "Web Application SPecification language". Besides
the DSL, another valid approach would be to offer an SDK in e.g. JS
or Python to build Wasp AST (like Terraform and Pulumi now both
offer). We see it as another "frontend" for constructing the AST
and might also introduce it in the future. Under the hood,
everything is compiled to a client (React) and server
(Node.js/Prisma) apps and we generate static files and a Docker
image you can use for deploying to your platform of choice. Wasp
had an Alpha launch 1.5 years ago
(https://news.ycombinator.com/item?id=26091956). Now we are more
stable and feature-full. We still expect things to change, so
wouldn't recommend using Wasp for heavy production or mission-
critical systems just yet. But it has been used for hackathons,
internal tools and even revenue-generating products (https://wasp-
lang.dev/blog/2022/11/26/erlis-amicus-usecase). The current
release is our biggest since we launched (https://wasp-
lang.dev/blog/2022/11/29/wasp-beta). Besides general stability and
DX improvements, it brings support for TypeScript (https://wasp-
lang.dev/blog/2022/11/29/typescript-feature-ann...), Tailwind
(https://wasp-lang.dev/blog/2022/11/16/tailwind-feature-annou...),
async jobs via pg-boss (https://wasp-lang.dev/blog/2022/06/15/jobs-
feature-announcem...), full-stack authentication (now also with
Google) (http://localhost:3000/blog/2022/11/15/auth-feature-
announcem...), and by popular demand, Wasp LSP with VS Code
integration (https://wasp-lang.dev/blog/2022/12/01/beta-ide-
improvements). Our next focus will be on making Wasp even easier
to use (examples, starter templates, UI helpers), and we'll look
into tighter weaving of data models with the rest of the stack and
expanding the DSL with more functionalities. We're around to
answer questions and look forward to hearing everything and
anything you have to say!
Author : matijash
Score : 79 points
Date : 2022-12-08 18:05 UTC (4 hours ago)
| desireco42 wrote:
| Wow, wonderful of you to make this. It really causes a lot of
| burnout to make things over and over.
|
| I will need to play with this to make more informed opinion, but
| based on description and info on landing page, I love what you
| are doing.
|
| One thing that crosses my mind, clearly not applicable in this
| case as you are far along, but making it more interesting to
| write these specs would go a long way on improving how people use
| this. Like, I would consider some kind of markdown or at least
| TOML... something with indentation as opposed to braces.
|
| Anyhow, anything that would save me from writing boilerplate code
| is more then welcome.
|
| It would be cool if there is a standard way and then people start
| making plugins and stuff. It would have to be open source as VCs
| spoil the thing.
| matijash wrote:
| still very much open to feedback, especially when it comes to
| dev experience! We still expect the language to evolve both in
| features and the syntax. We were initially inspired by JSON and
| HCL (lang behind terraform) so I think that's what influenced
| us in the start.
| matijash wrote:
| Also just realized we don't mention it explicitly anywhere, but
| Wasp is completely open source!
| dang wrote:
| I've added this to the text above.
| aatd86 wrote:
| Interesting! When did you join YC? At what stage of the
| development of the language were you then?
| matijash wrote:
| We were in W21 batch, so Jan 21. It was just after we released
| the first version of Wasp somebody could actually download and
| try out (before that it was just the landing page with the
| vision statement + gh repo with Haskell source). We got some
| good feedback on Product Hunt and Reddit and I believe that
| also helped.
|
| We documented our adoption journey (through gh stars) here
| (https://wasp-lang.dev/blog/2022/09/29/journey-to-1000-gh-
| sta...), and we also marked the moment when we were accepted in
| YC (we actually applied 3 times in a row!).
| jstummbillig wrote:
| Hey, that's cool. Are there any plans to help with bridging the
| gap to native or do you consider that outside the scope of what
| Wasp is concerned with?
| matijash wrote:
| You mean native mobile and desktop apps? That's definitely a
| much longer-term goal (and even more unclear :) but
| theoretically, given that Wasp is being designed as stack-
| agnostic framework, it's possible which makes it really
| exciting.
|
| We thought about it a bit already and definitely not 100% of
| concepts from the domain of web apps would apply (e.g. routes
| maybe don't make sense in mobile apps), but there is still a
| lot that could be share. Maybe Wasp could also generate some
| SDK you could use from your native mobile code.
|
| That's all long-term stuff so really hard to know, but we
| imagined we'd first focus on getting to 1.0 with React & Node,
| then add support for more client/server stacks (e.g. Vue and
| Python), and then go towards mobile and desktop.
| jstummbillig wrote:
| Mobile, yeah. The only thing I feel is super important there
| is getting push notifications going and both iOS and Android
| are sadly sabotaging the Notification Web API. Other than
| that a PWA would be totally sufficient for all my use cases
| and that seems to align really well with what you are
| building with Wasp. Certainly keeping an eye on this one.
| matijash wrote:
| That's a good point, I'm not so much in mobile these days
| so weren't aware of push notifications issue. Also great to
| hear PWA can cover a lot of cases, that would definitely be
| a natural first step towards mobile.
| [deleted]
| kinos wrote:
| The only thing preventing me from jumping right onto this is the
| fact it doesn't seem to be an oauth2 provider, and it doesn't
| seem to have the verify/reset/etc jobs necessary for username &
| password.
|
| Verify/reset/etc is always what pushes me away from doing multi-
| user webapps. Its a headache every time due to needing to think
| about e-mail, and I'd love an all-in-one oauth2 provider with
| signup and etc thats super lightweight and just does everything
| through an API.
| smcnc wrote:
| Hi there! Engineer on the team here (and the one actually doing
| some of our auth and jobs stuff recently). We currently
| integrate with Google via oauth2 for social login, and plan to
| add more providers soon (GitHub coming next). The underlying
| mechanism is using Passport.js, which in turn uses oauth2 for
| most of their provider integrations, but that is abstracted so
| we can change in the future without breaking Wasp users. How
| would you envision Wasp itself being an oauth2 provider as
| beneficial vs integrating with other more popular providers?
|
| As for username & password - correct, we do not do any email
| verification and reset right now. We actually changed the name
| from email & password to username & password to reflect the
| fact that we don't have tight email integration yet in Wasp.
| However, that will be coming soon, and once we do have first-
| class email support we plan to enrich that login method to have
| email verification with password reset, perhaps magic links,
| etc.
|
| So long story short, we are trying to move quickly to add more
| auth options but be deliberate in how we integrate everything
| to ensure they all play together nicely. Please do check us out
| if it seems interesting and drop into Discord to let us know
| how we can improve to fit your use cases. Thanks!
| [deleted]
| cpursley wrote:
| Any plans for other backends like Hasura or Supabase?
| matijash wrote:
| We haven't yet thoroughly looked into it, but it could be
| possible. Especially for Supabase since they support
| integrating with Prisma
| (https://supabase.com/docs/guides/integrations/prisma) which
| Wasp uses as a db layer.
|
| I think the main question here is what experience we want to
| offer and which level of integration (e.g. with Wasp's entity
| models) we can achieve. Do you have any particular features of
| Supabase/Hasura that you'd like to use?
| dom96 wrote:
| Congrats on this new milestone! I had a lot of fun completing
| some Hacktoberfest tasks back in October for Wasp, it was a
| lovely experience.
|
| What's most interesting (to me at least, as someone that loves
| building and learning about new languages) is that Wasp is YC
| funded. Probably the first language project I have seen to be
| part of YC.
| matijash wrote:
| I think the main reason for that is that Wasp is a domain
| specific language, catering to the domain of web apps, so it
| was easier to demonstrate/present use cases and what kind of
| additional services it could offer in the future.
|
| At the beginning of our fundraising VCs were often skeptical
| towards Wasp being a "new programming language", because who
| ever monetized (directly) Python or C++? Once we changed the
| narrative a bit and started referring to Terraform (DSL and a
| successful VC case) and emphasized that Wasp is a config
| language that interacts with the existing stack (so no big
| learning curve), we started having much better conversations.
|
| Fundraising wasn't an easy journey for us (it took over 250
| meetings) and we learned a lot about how to present and also
| think about Wasp. For more details, we documented our fundraise
| in details here: https://wasp-
| lang.dev/blog/2021/11/22/fundraising-learnings
| 0xferruccio wrote:
| This looks slick! Have you thought about helping people structure
| in a more opinionated way how business logic gets run?
|
| It feels like the JS ecosystem is missing framework that helped
| define layers of an app much like Rails/Django
| matijash wrote:
| For now it's pretty flexible, we only enforce top-level dirs -
| client/, server/ and shared/ and then everything else is
| referenced through imports in .wasp file.
|
| But I agree providing some best practices on the structure
| would be helpful - I personally prefer top-level grouping-by-
| feature (e.g. "billing/" and "reports/") over grouping-by-type
| (e.g. "controllers/", "components/"), but I know some folks
| prefer by-type, especially in the smaller projects.
|
| We plan to add more starter projects and templates so that
| might be a good start. Is there anything specific you'd like to
| se enforced/suggested, based on how you like to structure your
| projects?
| 0xferruccio wrote:
| I think something around structuring business logic in easily
| testable mutations and having good ways of creating factories
| without too much boilerplate code are the main things on my
| mind!
| smcnc wrote:
| Thanks! Right now we do have an "expected" structure that
| differentiates between client/server/shared code. But as a
| former Rails person myself, I can say everyone on the team
| appreciates how "convention over configuration" plus best
| practices can really help devs and it is something we try to do
| as well. So I think we will continue to make improvements in
| this area. Feel free to give it a go and drop into Discord and
| let us know what you think!
___________________________________________________________________
(page generated 2022-12-08 23:00 UTC)