A programming language that understands what a web app is. (by wasp-lang)

Wasp Alternatives

Similar projects and alternatives to wasp
  • GitHub repo ShellCheck

    ShellCheck, a static analysis tool for shell scripts

  • GitHub repo react-admin

    A frontend Framework for building B2B applications running in the browser on top of REST/GraphQL APIs, using ES6, React and Material Design

  • Scout

    Get performance insights in less than 4 minutes. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.

  • GitHub repo Pulumi

    Pulumi - Modern Infrastructure as Code. Any cloud, any language 🚀

  • GitHub repo config

    configuration library for JVM languages using HOCON files

  • GitHub repo dhall-lang

    Maintainable configuration files

  • GitHub repo oil

    A new Unix shell. Our upgrade path from bash to a better language and runtime.

  • GitHub repo opentracing-javascript

    OpenTracing API for Javascript (both Node and browser)

  • GitHub repo ra-data-hasura

    react-admin data provider for Hasura GraphQL Engine

  • GitHub repo inai

    An experiment in structuring a NodeJS application *internally* using REST principles.

  • GitHub repo ansible-dhall-jsonnet

  • GitHub repo quack

    It's a DSL for full-stack web applications (by staab)

NOTE: The number of mentions on this list indicates mentions on common posts. Hence, a higher number means a better wasp alternative or higher similarity.


Posts where wasp has been mentioned. We have used some of these posts to build our list of alternatives and similar projects - the last one was on 2021-02-26.
  • Intercal, YAML, and Other Horrible Programming Languages
    news.ycombinator.com | 2021-02-26
    - should I come up with my own declarative, configuration-like DSL? It would probably end up similar to Dhall, but this means I can do whatever I want - I can make it as ergonomic and custom as I want to (which I guess is both good and bad :D!). It might also allow for nicer interop with Javascript and other languages.

    In this case, we went for the last option, mostly because we felt the most important thing is ergonomics and interop, but well, I am still curious how would other directions play out. Plus at the end we didn't yet get to the point where language is more expressive than JSON (code example: https://github.com/wasp-lang/wasp).

    Maybe I am just missing a better design process, but it seems to me that with language that it is hard to say if it is good or not until you try using it.

  • Modules, Monoliths, and Microservices
    news.ycombinator.com | 2021-02-25
    Specifically I have been trying to apply it to full-stack web app development for some time now building a DSL (https://github.com/wasp-lang/wasp).

    Why do you think DSLs are not the full solution? My main thought was that having DSLs for specific areas of programming domains is the way to go. But they should have interop with Turing complete languages to implement specific sub-parts. That way DSLs can capture a lot of knowledge and best practices that we learned through years in that domain while still facilitating innovation being flexible. Such language would be very limited, more like "smart configuration languages". Some of them I have seen around are Terraform, Nextflow, Meson-build.

    APL still sounds too general and self-sufficient to me to be a solution to this (but I don't know much about it so maybe I am wrong, I just checked it out on the wikipedia).

  • Wasp: an open-source DSL for developing full-stack JS web apps
  • Monolith First
    news.ycombinator.com | 2021-02-19
    I like the "peeling off" strategy - starting with the monolith and adding microservices from the edges.

    I've been working on something that tries to make it to start with a monolith in React/Node.js relatively quickly. Still don't have much of the "peeling" support but that is something we're looking to add: https://github.com/wasp-lang/wasp

  • news.ycombinator.com | 2021-02-10
    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 .

    news.ycombinator.com | 2021-02-10
    thanks for the feedback, I agree having showcases is crucial 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!

  • Launch HN: Wasp (YC W21) – DSL for building full-stack web apps
    news.ycombinator.com | 2021-02-10
    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.

    news.ycombinator.com | 2021-02-10
    JQuery -> Backbone -> Angular -> React, own scripts / makefile -> Grunt -> Gulp -> Webpack, PHP -> Java -> Node.js, … , and we always felt that things are harder than they should be. We were spending a lot of time adopting the latest tech stack and figuring out the best practices: how to make the web app performant, scalable, economical and secure and also how to connect all the pieces of the stack together.

    While the tech stack kept advancing rapidly, the core requirements of the apps we were building changed very little (auth, routing, data model CRUD, ACL, …). That is why about 1.5 years ago we started thinking about separating web app specification (what it should do) from its implementation (how it should do it).

    This led us to the idea of extracting common web app features and concepts into a special specification language from which we could generate code in the currently popular technologies. We don’t think it is feasible to replace everything with a single language so that is why we went with a DSL which integrates with the modern stack (right now React, NodeJS, Prisma).

    Wasp lets you define high-level aspects of your web app (auth, routing, ACL, data models, CRUD) via a simple specification language and then write your specific logic in React and Node.js. The majority of the code is still being written in React and Node.js, with Wasp serving as the backbone of your whole application. To see some examples of what the language looks like in practice, take a look here: https://github.com/wasp-lang/wasp/blob/master/examples/tutor...

    The main difference between Wasp and frameworks (e.g. Meteor, Blitz, Redwood) is that Wasp is a language, not a library. One benefit of that is a simpler and cleaner, declarative syntax, focused on the requirements and detached from the implementation details.

    Another benefit of a DSL is that it allows Wasp to understand the web app’s requirements during the build time and reason about it before generating the final code. For example, when generating code to be deployed to production, 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 (or even a combination). Another example would be reusing your data model logic through all the parts of the stack while defining it just once in Wasp. DSL opens the potential for optimisations, static analysis and extensibility.

    Wasp’s compiler is built in Haskell and it compiles the source code in Wasp + React/Node.js into the target code in just React and Node.js (currently in Javascript, but we plan to move to Typescript soon). The generated code is human readable and can easily be inspected and even ejected if Wasp becomes too limiting.

    We are currently in Alpha and many features are still rough or missing, but you can try it out and build and deploy web apps! There are things we haven’t solved yet and others that will probably change as we progress.

    You can check out our repo at https://github.com/wasp-lang/wasp and give it a try at https://wasp-lang.dev/docs/tutorials/getting-started.

    Thank you for reading! We would love to get your feedback and also hear about your experiences building web apps - what has worked for you and where do you see the opportunities for improvement?


Basic wasp repo stats
5 days ago

wasp-lang/wasp is an open source project licensed under MIT License which is an OSI approved license.