Web apps built with Ruby on Rails

Purpose of the “We Use Rails” site

• Directory of web apps built with Ruby on Rails, offering more technology detail and (claimed) fewer false positives than generic tech-detection sites.
• Encourages submissions from app owners; some users want traffic/usage-based sorting and compare it with other Rails directories.

Rails adoption and ecosystem

• Examples mentioned: GitHub–scale apps plus others like Canvas LMS, Cookpad, various SaaS and business apps.
• Some regions are described as “Rails deserts” in the job market, with .NET, PHP, Python, and Node dominating.

Rails 8, productivity, and “renaissance”

• Multiple comments say Rails 8 rekindled enthusiasm, especially for solo developers.
• Praised “solid trifecta,” built‑in auth, Kamal deployment, Hotwire/PWA support, and sqlite-backed features.
• Scaffolding still seen as a “cheat code” for quickly producing stable CRUD apps.

Comparisons with other stacks

• Django: some see it as similarly productive; preference often comes down to liking Ruby vs Python.
• Go: valued for low-dependency code that works well with LLMs; others say Rails provides productivity via conventions and batteries-included tooling.
• Node/Next.js: some argue Next.js is de facto “Rails for JS,” but critics note commercial lock‑in and weaker “omakase” integration, especially on the backend.
• Laravel is praised as the most Rails-like in PHP land, with cohesive queues, scheduling, notifications, etc.

AI tools and language support

• Reports that Copilot works especially well with Python (pytest, Django) and less reliably with Go.
• For Ruby, some point to LangChain/Boxcars but others say the AI/ML ecosystem is weaker than for Python or Go.
• Several argue Rails’ conventions and extensive Q&A history make it a strong LLM target despite that.

Deployment, hosting, and databases

• Suggestions for simple Rails hosting: Heroku, Fly.io, Render, Docker-based platforms, and Kamal on a VPS.
• Debate over sqlite vs Postgres: sqlite praised for new Solid-based features and simplicity; others prefer Postgres for easier remote querying and tooling.

JavaScript integration in Rails

• Long-running frustration with changing JS stories in Rails (Prototype → asset pipeline → Webpacker → importmaps, plus coffeescript phase).
• Some like Stimulus and Turbo/Hotwire as “just enough” structure; others dislike them and prefer using JS sparingly or via importmaps and selective components.

Static typing, maintainability, and architecture

• Strong disagreement around dynamic Ruby vs static typing. Some see dynamic types as unacceptable for large systems; others cite typing add‑ons (RBS, Sorbet) or point to productivity benefits.
• Concerns about large Rails monoliths, heavy dependency trees, and teams mixing UI, business logic, and data access in ways that complicate APIs.
• Experienced developers recommend keeping complex domain logic outside Rails’ core layers to preserve maintainability.

Performance, scalability, and outages

• The directory site briefly struggled under HN traffic; some blame Rails, others attribute it to normal underprovisioning/caching issues.
• Pro‑Next.js commenters argue static CDN caching would have prevented this; critics call such claims hype and say Rails/Django apps can match performance with proper setup.