Rails is better low code than low code

Original Article ↗ Hacker News Discussion ↗

Low‑code and no‑code platforms promise fast app building through visual tools, but many developers argue they break down quickly once requirements evolve, are hard to version and maintain, and often lock users into proprietary ecosystems. Commenters contrast this with mature web frameworks like Ruby on Rails, Django, or Phoenix, which require more upfront expertise but scale better, are fully inspectable, and integrate with standard tooling for testing, deployment, and refactoring. A recurring theme is knowing when to prototype with low‑code (especially for non‑engineers) versus starting directly in a conventional framework or even a “boring” tech stack, particularly now that LLMs can accelerate work in traditional languages.

What “low code” means and common tools

  • Defined broadly as drag‑and‑drop / visual tools (Power Apps, Access, SSIS, Zapier, Make.com, Salesforce, FME, APEX) where most work is configuration; often with an “escape hatch” to real code (e.g., JavaScript, VBA, lambdas).
  • Some argue Excel and Access are the original and most successful low‑code platforms; also domain tools like Simulink, Houdini, game/shader node graphs.
  • Others ask for tools that generate clean, ejectable code in a mainstream language, not opaque runtimes.

Strengths and limits of low/no‑code

  • Very fast for simple internal tools, prototypes, or when non‑developers need self‑service automation.
  • Ubiquity and zero‑install friction (e.g., spreadsheets, SharePoint/PowerAutomate) are major advantages.
  • Pain points: duplication-heavy GUIs, poor refactorability, hidden complexity, weak version control, lock‑in, scaling/maintenance nightmares, and security/compliance blind spots.
  • Some see them as effective for organizations where IT can’t meet demand; others say such “shadow IT” later has to be rewritten or absorbed by central IT.

Rails vs low code (and other frameworks)

  • Many agree Rails (and similar frameworks like Django, Phoenix, Elixir, ASP.NET) already feel “low code” due to scaffolding, conventions, batteries‑included features, and rich ecosystems.
  • Rails praised for: rapid greenfield CRUD development, predictable structure, easy onboarding, and Ruby’s metaprogramming/monkey‑patching for extension.
  • Critiques: long‑lived large Rails apps can devolve into tightly coupled “big balls of mud,” especially with fat models and heavy magic; refactoring and upgrades can be risky.

Static vs dynamic typing and LLMs

  • Strong disagreement over dynamic languages (Ruby, Python, JS) vs statically typed ones (C#, Rust, Kotlin, TypeScript, etc.).
  • Pro‑static camp: static types catch LLM hallucinations and library breakages earlier; dynamic ecosystems can hide breaking changes until production.
  • Pro‑dynamic camp: tests plus flexibility suffice; Ruby’s dynamism simplifies testing and monkey‑patching; static typing can feel like unnecessary drag.
  • Some argue LLM‑assisted coding reduces the appeal of low‑code, and may favor languages/models with strong type information and good training coverage.

Broader perspectives

  • Several note that low‑code/RAD ideas (4GLs, VB, Delphi, Access) have cycled for decades; the underlying complexity never disappears.
  • Consensus: right tool depends on who builds/maintains it, expected lifetime, complexity, and organizational constraints; knowing when to stop using low‑code and rewrite is crucial.