We keep hearing the same comparison:
Harper feels like Ruby on Rails.
That comparison did not come from a positioning exercise. We were not sitting in a room trying to make Harper sound like Rails. It came from developers, advisors, analysts, and technical leaders trying to describe what feels different about building with Harper.
And the more we hear it, the more obvious the point becomes.
The comparison is not about Ruby. It is not about MVC. It is not about scaffolding CRUD apps or recreating Rails in JavaScript.
It is about a product philosophy.
Rails won because it had opinions.
It made choices for developers. It gave teams a coherent way to build. It reduced the number of architectural decisions required to get from idea to working application. It proved that the right constraints can make great developers faster.
That lesson matters again because software development is entering another major shift.
AI is changing who, or what, makes implementation decisions. Agents are beginning to generate code, wire services together, create workflows, and make architectural choices on behalf of teams. In that world, opinionated systems become more valuable, not less.
When humans are building software, good conventions reduce decision fatigue.
When AI agents are building software, good conventions become guardrails.
They shape what gets generated, how pieces fit together, and whether the result is a coherent application or just a pile of working parts.
That is why Harper keeps getting compared to Rails.
Just like Rails, Harper brings an opinionated, integrated model to a part of the stack that has become far too fragmented: distributed application infrastructure.
Rails Made the Path Obvious
Rails changed web development by making the common path clear.
Before Rails, every project started with a sea of open questions. Which ORM? Which templating engine? How should directories be structured? How should URLs map to code? Where should the configuration live? How should dependencies be managed? How should tests be organized? How should the database schema evolve?
Rails answered those questions with defaults.
Active Record. ERB. Routing conventions. Configuration patterns. Migrations. Testing defaults. Project structure. Naming rules that made the pieces work together.
That was the breakthrough.
Rails did not make developers faster by giving them infinite flexibility. It made them faster by reducing meaningless flexibility. It removed decisions that most teams should not need to make from scratch.
The best developers still had room to customize. But they started with a coherent system rather than a blank page.
That is what “convention over configuration” really gave us: speed, clarity, and shared understanding.
The magic was not just Ruby. It was not just MVC. It was not any single abstraction.
The magic was that Rails made application development feel like one integrated experience.
The Stack Became the Framework
Modern applications have changed around the framework.
Rails has continued to collapse more of the application tier into the framework itself. Rails 8 and the Solid stack are a perfect example. Cache, queue, jobs, real-time updates, routing, authentication patterns, and deployment have all become more integrated, more conventional, and less dependent on separate services.
That is exactly the Rails philosophy at work.
But the data tier remains different.
Even when Rails absorbs more infrastructure into the application experience, the database is still a separate process. Often it is a separate machine. At scale, it may be a separate region. And as more parts of the application depend on database-backed primitives, more of the system routes through that same boundary.
Solid Cache removes the need for Redis in many cases, but it still stores cache data in the database. Solid Queue removes the need for a separate queue service, but jobs are still stored in the database. Solid Cable brings real-time messaging into the Rails pattern, but the backing state still lives in the database.
That consolidation is a win. Rails has already moved the ecosystem toward fewer external services and stronger defaults.
But it also reveals the boundary Rails cannot fully close on its own:
The app tier and the data tier are still separated by a network hop.
Every request that needs data crosses it. Every query crosses it. Every job, cache read, message, and update that depends on the database crosses it. Replicas and multi-region deployments can improve scale and resilience, but they also make the topology more complex.
This is the next layer of decision fatigue.
The developer is no longer just asking how to structure the app. They are asking where data should live, where logic should run, how far each request needs to travel, how state moves across regions, and how the system behaves when the data boundary gets stretched.
Rails made the app tier coherent.
The data tier is the remaining frontier.
AI Raises the Cost of Bad Defaults
This problem gets sharper in the AI era.
AI agents are very good at producing code. They can generate endpoints, write functions, create schemas, connect services, and propose architectures quickly.
But without strong conventions, they can also create systems that technically work and architecturally sprawl.
An agent can add a service because a service seems reasonable. Add a cache because performance matters. Add a queue because async work is needed. Add a table because state has to go somewhere. Add another API because something needs to call something else.
Very quickly, the application becomes a collection of generated parts.
This is where the Rails lesson becomes newly important.
Rails gave human developers a paved path. AI-native development needs paved paths even more.
If agents are going to make more implementation decisions, the platform needs to encode better architectural defaults. It needs to guide decisions about data, logic, messaging, caching, and locality. It needs to make the coherent path easier than the fragmented one.
AI does not eliminate the need for opinionated platforms.
It increases it.
Why Harper Keeps Getting Compared to Rails
Harper is not Rails.
It is not a Ruby framework. It is not trying to recreate MVC. It is not asking Rails developers to abandon what made Rails great.
The comparison is philosophical, not literal.
Rails brought convention, integration, and a coherent developer experience to web application development. Harper brings that same philosophy to distributed application infrastructure.
Harper is a unified application platform that combines database, caching, messaging, and application logic into a single high-performance runtime. Instead of forcing teams to assemble separate systems for each backend concern, Harper gives developers a more integrated way to build and run distributed applications.
That is where the Rails-like feeling comes from.
Rails made the application feel coherent.
Harper makes the distributed backend feel coherent.
Rails reduced the number of decisions required to build a web app.
Harper reduces the number of systems required to build a distributed app.
Rails gave developers a productive default path.
Harper gives developers and AI agents a stronger architectural path for data, logic, messages, and caching.
That is also why the Node.js and JavaScript foundation is not a barrier to the comparison. Developers are not saying Harper feels like Rails because they think it is Ruby. They are saying it because the experience reminds them of what Rails got right: strong opinions, integrated primitives, and a system that helps you move faster by making better decisions on your behalf.
JavaScript simply makes that model accessible to the modern application ecosystem. It gives teams a familiar language for writing logic inside a platform that is doing much more than running Node.js code.
The important thing is not that Harper is built on JavaScript.
The important thing is that Harper is built with opinions.
The Difference Is Fewer Seams
Consider a commerce application.
A product page seems simple until it has to be fast, dynamic, personalized, and globally available.
Some content is stable: product descriptions, images, specifications, editorial copy. Some content changes constantly: price, inventory, promotions, recommendations, loyalty status, delivery estimates, and customer-specific offers.
The traditional answer is to spread those concerns across a growing stack.
The app handles the request. The database stores the source of truth. The cache accelerates hot reads. A queue handles updates. Workers process changes. The CDN caches what it can. Custom invalidation logic tries to keep everything from lying to the user.
Again, none of these tools are bad.
But the team is no longer just building a product page. It is maintaining a distributed coordination system.
A more opinionated platform changes the shape of the problem. Data, logic, messaging, and caching can live in one runtime. Application behavior can be placed closer to the data and closer to the user. Updates can move through the system without every team having to rebuild its own coordination layer.
The value is not merely fewer tools.
The value is fewer seams.
Fewer places where the developer has to stop building the product and start designing infrastructure. Fewer places where an AI agent can make a technically reasonable but architecturally messy choice. Fewer places where performance, consistency, and developer velocity are traded against each other by default.
That is the “oh, I get it” moment for Rails developers.
The same reason Rails felt magical for building web applications is the reason an opinionated distributed runtime feels powerful now.
It gives you a path.
Distributed Apps Need Their Rails Moment
The lesson of Rails was that coherent systems win.
Developers move faster when the platform makes good decisions. Teams build better software when the common path is clear. Applications are easier to reason about when the pieces are designed to fit together.
That lesson is becoming more relevant with AI.
As applications become more distributed, and as AI agents participate more directly in building them, the need for opinionated architecture will only grow. The future will not belong to teams that assemble the most tools. It will belong to teams that can turn ideas into coherent, high-performance applications the fastest.
Rails gave developers convention over configuration for web apps.
Harper brings that idea to distributed application infrastructure.
And once you see that, the comparison becomes hard to ignore.
Top comments (0)