No-code is the future of programming. That's great news for engineers

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • plasmic

    Visual builder for React. Build apps, websites, and content. Integrate with your codebase.

    The problem is that no-code is not well-defined. It's used to label everything from Excel to Airtable to Zapier to Webflow to Bubble to Retool.

    And within that umbrella, some of them are relevant to the HN crowd.

    Your examples, like spreadsheets for supply chain planning or DAWs for music production, are indeed disconnected from what developers touch.

    But other times, the tool very much impacts developers. For instance, I work on https://www.plasmic.app, which lets marketing teams build landing pages and other content on React websites. Here, the stakes are higher when it comes to site performance, design system consistency, component reuse, and so on. As such, developers heavily vet the tool, similar to picking a CMS, and virtually all of our customer adoption was driven by developers. (Contrast this with how developers aren't telling non-devs whether to use Excel vs GSheets, or Ableton vs Logic Pro.)

  • windmill-gh-action-deploy

    Discontinued windmill.dev's github action to deploy scripts to your workspace

    Yes you can, and you should! The included versioning is there for simplicity if you do not want the hassle to maintain your own git repo. But the real git will always be more powerful.

    There is a github action to automatically deploy from github to windmill: https://github.com/windmill-labs/windmill-gh-action-deploy

    That gh action is what I do for the public templates that hydrate every workspace on:

    https://github.com/windmill-labs/windmill

    Fun fact, the way it works is that it just tarball a subdir of your repo and send it as an input of a normal windmill script that then just extract it to your workspace (for all the diffs that it finds).

  • WorkOS

    The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  • windmill

    Open-source developer platform to turn scripts into workflows and UIs. Fastest workflow engine (5x vs Airflow). Open-source alternative to Airplane and Retool.

    Yes you can, and you should! The included versioning is there for simplicity if you do not want the hassle to maintain your own git repo. But the real git will always be more powerful.

    There is a github action to automatically deploy from github to windmill: https://github.com/windmill-labs/windmill-gh-action-deploy

    That gh action is what I do for the public templates that hydrate every workspace on:

    https://github.com/windmill-labs/windmill

    Fun fact, the way it works is that it just tarball a subdir of your repo and send it as an input of a normal windmill script that then just extract it to your workspace (for all the diffs that it finds).

  • oil

    Oils is our upgrade path from bash to a better language and runtime. It's also for Python and JavaScript users who avoid shell!

    I like this framing ... But I'll also frame my own project relative to that

    The vision for Oil (https://www.oilshell.org/) is "Just code" + one other language for "control plane" or configuration.

    That is, Oil puts all the "glue", which is often YAML these days, under the category of "shell". The YAML often contains shell, and is sometimes generated by Go templates when logic is needed, so "just shell" is simpler.

    So I basically agree with you that "No code" is ambitious for most problems -- "Just code" would be better.

    But I also think "Just code" is ambitious. Because what do you do about load balancing policies, scheduling policies, authorization policies (collaboration), SSL certificates, backup policies, deployment, build, tests, performance, monitoring, etc.

    You can try to make it all "data", and that certainly works for many simple apps. But when simple apps are successful (have many users), they turn into complex apps that need control flow, iteration, and abstraction in their control plane or configuration.

    Otherwise you get a combinatorial explosion of "hard-coded policies" in the platform, e.g. a little YAML flag to specify and algorithm for every piece of policy that any user could possibly want.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts