Why Convention over Configuration Still Matters in 2026?

Software development is full of decisions. Where should a file live? How should a route be registered? Which configuration file connects a model to a database table? Where should API endpoints be defined? Which tools need to be wired together before the application can even start? Not all of these decisions create business value. This is where Convention over Configuration (CoC) becomes useful. Convention over Configuration is a software design approach that reduces the amount of configuration developers need to write by establishing sensible, predictable defaults. Instead of explicitly describing every relationship between components, the framework assumes a standard structure and lets developers override that behaviour when their application needs something different. The idea became particularly well known through Ruby on Rails and its “convention over configuration” philosophy. The important part is not that configuration disappears. The important part is that developers are no longer required to configure things that already follow an obvious convention. The Problem with Too Much Configuration Imagine creating a new page. In a heavily configuration-driven architecture, adding that page might involve creating the component itself, registering a route, updating another configuration file, and possibly modifying additional metadata. The page is new. The route is new.But the relationship between them is already obvious. A framework can reasonably infer: This file represents a page, therefore it should become a route. That removes a decision without removing control. The same idea can apply to APIs, database models, application structure, testing, and many other parts of a project. 1. Faster Development The most obvious benefit of conventions is that developers write less infrastructure code. Suppose a framework knows that files inside a particular directory represent application pages. Creating a new page becomes as simple as creating a file. Solid-Vue follows this approach with file-based routing. A file such as: src/pages/about.vue automatically becomes: /about Nested directories and dynamic filenames follow the same convention. src/pages/ ├── index.vue ├── about.vue └── users/ └── [id].vue This produces routes without maintaining a large manual routing configuration. The project structure becomes part of the routing system itself. That may look like a small convenience. Across hundreds of routes and multiple developers, however, removing repeated configuration becomes a meaningful productivity improvement. 2. Less Boilerplate and Less Ceremony Configuration has a cost. Even when each configuration change takes only a few minutes, developers still have to remember where it belongs, how it is structured, and which other configuration files must be updated. That creates cognitive overhead. Convention-based frameworks move common decisions into the framework itself. Solid-Vue applies this principle beyond frontend routing. For example, API handlers can live inside: src/server/api/ The framework scans this directory and derives routes from the file structure. A file such as: src/server/api/products/[id].ts can represent a dynamic API endpoint without requiring a separate route registration file. The developer writes the endpoint. The framework handles the repetitive wiring. 3. A Predictable Project Structure Conventions also make unfamiliar projects easier to understand. A predictable structure means developers spend less time asking: Where does this belong? Solid-Vue establishes several conventional locations: src/ ├── components/ ├── pages/ ├── layouts/ ├── stores/ └── server/ └── api/ Some of these directories are conventions rather than strict requirements, while pages and server/api are actively scanned by the framework. This distinction matters. Good conventions should provide structure without turning the framework into a prison. Developers should know where things normally go, while still being able to organise their own application when necessary. 4. Convention Does Not Mean No Configuration One of the biggest misunderstandings about Convention over Configuration is that it means configuration is bad. It does not. Configuration becomes valuable when the default behaviour is no longer appropriate. For example, suppose the convention says: src/pages/about.vue → /about That is useful because most applications do not need to explain that relationship manually. But when an application requires something unusual, explicit configuration should still be available. This is where a good framework should provide an escape hatch. Solid-Vue describes this philosophy directly: Reduce configuration, not capability. Its configuration layer provides sensible defaults while keeping the underlying Vue, Vite, Vue Router, Pinia, and H3 APIs accessible. That distinction is important. The goal is not to hide the underlying ecosystem. The goal is to avoid making developers configure things that can already be reasonably inferred. 5. Conventions Make Frameworks Easier to Learn Convention also creates a shared mental model. When every project invents its own architecture, developers must learn the architecture before they can effectively work on the application. When a framework establishes common conventions, knowledge becomes transferable. A developer who already understands the framework can open another project and immediately recognise familiar patterns. This does not eliminate the learning curve. In fact, conventions can introduce their own form of complexity: developers need to understand what the framework assumes and how those assumptions work. The difference is that the complexity is learned once and then reused across projects. 6. Less Configuration Can Mean Less Configuration Churn Large configuration files often become another part of application maintenance. Every new feature may require another entry. Every renamed component may require another update. Every new API endpoint may require another registration. With convention-based systems, some of these relationships are derived directly from the source structure instead. That can reduce repetitive configuration changes and, as a consequence, reduce one potential source of configuration drift and merge conflicts. It is not a guarantee that merge conflicts disappear. It simply means there are fewer places where developers need to manually maintain the same information. The source code becomes the source of truth. Convention vs Configuration Convention and configuration are not opposing philosophies where one must completely replace the other. They are better understood as a balance. | Approach | Strength | Trade-off | |---|---|---| | Convention | Fast setup, predictable structure, less boilerplate | Framework rules can feel “magical” | | Configuration | Explicit control and visibility | More boilerplate and maintenance | | Hybrid | Sensible defaults with explicit escape hatches | Requires good framework design | Pure convention can become frustrating when developers cannot understand or override what the framework is doing. Pure configuration can become exhausting when developers have to describe every relationship manually. The useful middle ground is: Use conventions for the common path. Use configuration for the exceptional path. Why This Matters for Small and Growing Applications This becomes especially relevant for small teams and growing businesses. Most applications do not need every architectural decision to become a project of its own. A team should be able to create a page, add an API endpoint, manage application state, and deploy an application without repeatedly designing infrastructure around those actions. This is one of the reasons Solid-Vue is built around existing Vue ecosystem tools instead of replacing them. Vue remains Vue. Vite remains Vite. Vue Router remains accessible. Pinia remains accessible. H3 remains accessible. Solid-Vue simply establishes conventions and defaults around them so developers spend less time wiring the ecosystem together. That philosophy can be seen throughout the framework: file-based pages, file-based server routes, pre-wired Pinia, conventional project structure, CLI-based project creation, and automated build/deployment workflows. The Real Value of Convention over Configuration Convention over Configuration is not really about writing fewer lines of code. It is about making fewer unnecessary decisions. A developer's time is valuable. Instead of repeatedly deciding: - where routes should be registered, - how API files should be connected, - how common tools should be wired, - or which configuration file needs another entry, the framework can provide a predictable answer. That lets developers spend more of their attention on the part that actually differentiates the application: the business logic, user experience, and product itself. Good conventions should therefore feel almost boring. You create the file. You follow the structure. The framework understands what you mean. And when the default is no longer enough, configuration is still there. That is the real idea behind Convention over Configuration: less configuration where convention is enough, without sacrificing control when convention is not enough. Top comments (0)