ShellCheck, a static analysis tool for shell scripts
A frontend Framework for building B2B applications running in the browser on top of REST/GraphQL APIs, using ES6, React and Material Design
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.
Pulumi - Modern Infrastructure as Code. Any cloud, any language 🚀
configuration library for JVM languages using HOCON files
Maintainable configuration files
A new Unix shell. Our upgrade path from bash to a better language and runtime.
react-admin data provider for Hasura GraphQL Engine
An experiment in structuring a NodeJS application *internally* using REST principles.
It's a DSL for full-stack web applications (by staab)
Intercal, YAML, and Other Horrible Programming Languages
news.ycombinator.com | 2021-02-26
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
reddit.com/r/coolgithubprojects | 2021-02-23
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
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 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
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.
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.
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?
wasp-lang/wasp is an open source project licensed under MIT License which is an OSI approved license.