In the world of web dev, component-driven development (CDD) has become almost synonymous with component-driven user interface. This limited use of the term is quite unfortunate as it has conceptually distanced us from better software design and development strategies that are by no means exclusive to UIs.

This article discusses CDD in its wider sense and introduces Bit as a revolutionary (OSS) tool that’s made exactly for this development strategy.

Bit works well with bit.dev, a cloud component hosting and CI, and uses it by default. However, you can set it to use your own hosting.

What do I mean by CDD/CBD?

Component-based development is the structuring of software out of components or modules, where each component addresses a specific concern and exposes a well-defined interface for other components to communicate through.

Components can be of all types and shapes, for frontend and backend, UI and non-UI, they can be simple units or complex composites.

Do we really use CDD as a development strategy?

CDD checks many important NFR boxes. It makes our code more reusable, more maintainable, more testable, and easier to understand and debug.

But if that’s the case, and CDD is all sunshine and roses, why do we see such limited use of that development strategy?

For example, what’s usually considered as a “proper implementation” of CDD is to have one team develop and share a small set of UI components, the “design system”, for other teams in an organization to use. Each team carries on this bottom-up development process, where components are used to compose more complex composite components. However, that all happens “in private”. Compositions, i.e, composite components, usually remain in their own hosting project, “hidden” from other teams/projects.

To fully enjoy the benefits of CDD — to accelerate development, and maintain high standards of code, components need to be shared and collaborated on across the entire organization. This process cannot be limited to just a small team “prescribing” a small set of components to the rest of the organization.

Collaborating on individual components is hard

Achieving cross-project component collaboration is not easy. It requires solving a long list of challenges. How should these components be collaborated on?

Should you use a separate repository for each component? How will you maintain consistency in their development environment setups? How do you update a ‘feature’, a composite component, when its building blocks are each source-controlled separately?

Perhaps you should use a monorepo for all components? How do you set different permission levels for different components in the same repository? How do you make sure builds are running only when and where they are relevant?

The list of challenges hardly stops here, but you get point.

Using Bit for component-driven development

Bit is an end-to-end solution for component-driven development that solves all major challenges presented by that development strategy.

It offers three main features critical for component development and component collaboration:

• Isolated component development — including isolated rendering, tests, and builds.
• Component source-control — essentially, git for individual components.
• Component dependency management —auto-generated component dependency graphs, and smart dependency management. That includes two types of dependencies: node packages and other components.

Independent components: the new building blocks

An independent component is a component that is independently developed, source-controlled, and collaborated on.

Independent components are developed and versioned in Bit workspaces and pushed to ‘remote scopes’, remote hosting for components, where they’re made available to be consumed and collaborated on in other Bit workspaces.