Web apps built with Ruby on Rails
Ruby on Rails is seeing renewed interest, highlighted by a new curated directory of live Rails-powered web apps and enthusiasm around Rails 8 features like the “solid” stack, built-in auth, Hotwire, and Kamal deployment. Commenters contrast Rails’ batteries-included, opinionated approach and developer productivity with ecosystems like Django, Laravel, Go, and especially Next.js/Node, debating trade-offs in performance, architecture, typing, and frontend integration. Hosting and tooling options—from Heroku, Fly.io, and Render to SQLite vs. Postgres and job queues—also come up as developers weigh Rails’ suitability for solo projects, CRUD-heavy SaaS, and long-term maintainability.
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.