React
Harmony
NodeJS
Angular
VueBit is a build system for composable software. It makes the composition of applications from independently versioned components seamless and fast.
The core innovation of Bit is the Bit Component, a container for composable software components. You can think about it as a next-generation package. It is extensible, portable and seamless to maintain.
People often use Bit to run a Monorepo, a Polyrepo or Distributed architecture.
Bit is designed for incremental adoption, and can be added to most codebases in few minutes.
Using the composable model allows for a higher level of granularity, promoting the modularity, sharing, reuse, and maintainability of your software. It also preserves great, everlasting developer experience and keeping your codebase small.
If you are looking to build a unified platform, you should head to Composable Platforms.
You can use Bit to run a Monorepo. It facilitates the build, development, and release of modular architecture, allowing you to handle multiple packages in a single repository.
When a repository expands to encompass several hundred components, many often transition to a Polyrepo approach.
The polyrepo approach involves utilizing multiple repositories where components are interdependent. With Bit, transitioning components and splitting them across repositories becomes seamless. Components can be effortlessly 'Ejected' from one repository and 'Imported' into another.
Typically, developers pivot to a polyrepo setup when a monorepo expands to the point where maintenance, onboarding, and collaboration become challenging. Here is a chart demonstrating a Polyrepo setup with Bit:
Bit makes it easy to contribute to components even from a different repositories. Components are no longer limited to maintained from just a single Workspace:
After expanding to multiple repositories, many often adopt a distributed approach. In this setup, some of the components are maintained in temporary workspaces tailored for specific tasks or initiatives.
Using Bit in a Distributed approach, you can imports the requisite components for a particular task or initiative into a disposable workspace, presents the modifications, and then proceeds to release. It preserves a great overlasting developer experience keeping your codebase small.
It is useful to conbine approaches and maintain some of the compoennts in this approach, which keeping other in repositories.
You can find useful links to distributed workflows below:
You may have observed that this site is composable. As we expanded our documentation, our team also grew, prompting the need for an internal wiki—a consolidated hub for all Bit-related internal information, ensuring alignment among team members. We opted to chronicle this journey to illustrate the essence of composable thinking.
Using the Component Highligther in the example below, you can see how components maintained across various workspaces, business domains and repositories are effortlessly combined into a single performant and composable application, that can be deployed, or used as a package.
Welcome to your component-driven wiki app!
This is the first component-driven wiki! Content pages are MDX components, and you can use any type of component from inside any wiki page.
Here is an example using our What is Bit component:
Bit stands at the intersection between product and engineering. It helps you take complex product requirements, and break them down into independent, and reusable pieces called "components". It allows you to create components and compose them with each other. Components are described by names and APIs, and contain source code implementation. They can be of different kinds like apps, pages, UI components, backend services and even content. You can think of almost anything in components.
It is common to think of components that function as full applications, as "large", whereas components that function as simple elements, like a 'button', as "small". For us, both types of components are "the same size", but each has a different responsibility. An app is a very concrete component. It has many dependencies and just a few (if any) dependents. A button, on the other hand, is very abstract. It has just a few dependencies and many dependents. Having this sort of dependents-to-dependencies ratio indicates that a component is highly-reusable.
If you are ready to give Bit a try, head back to Quick start and kickoff you component-driven journey!
