React
Backend
Angular
HTML
LitAs you might have noticed, this site was built in components. As we built the new documentation we started hiring more people to work for our company and we needed an internal wiki site to be a single source of truth for all information internal at Bit to keep everyone in sync. We decided to document the process to demonstrate thinking in components.
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.
Thinking even of this simple product as one piece, keeps us further away from initial value creation. This approach focuses on a single point of value that can only ever serve a single purpose; the bigger the piece gets, the bigger the problem becomes.
Persisting with this pattern of thinking compounds the problem; work is repeated infinitely. As more people join a team and continue this pattern, even more repetition takes place.
This amounts to unnecessary amounts of duplicated code, design sketches and product specs, with slight differences that makes them a lesser whole together. This is an ever growing debt that decreases the pace of value creation and the quality of work produced.
Even worse, repeating work is repeating decisions, reducing productivity, ending up with teams diverging to different paths for similar problems. Diverged decisions pile up to a growing burden that divides teams further apart, where collaboration is discouraged and morale deteriorates.
For a developer, that means building tightly-coupled code that is hard to reuse and limiting .
Value creation is exponentially decaying over time, ending up in silos of stagnation. For a startup, that means bounding yourself to just a few paths, creating very specific value, limiting a company's ability to pivot or adapt to change.
For an enterprise, that means every dollar spent in value creation is decreasing the value of total dollars invested. The more the enterprise invests, the less value it can create. This equation applies on the entire range, from the smallest system all the way up to the biggest one.
A component is an independent, reusable product that provides an interface for using it. Components should serve a single purpose; you begin by designing its interface to suit your own needs, increasing support for new needs from users as they come.
Components are described by names and APIs, and contain source code implementation. Components come in all shapes and sizes. They can be of different kinds like apps, pages, UI, backend services and even content. You can think of almost anything in components.
In fact, everything you see on this page has been created with components.
If you are ready to give Bit a try, head back to Quick start and kickoff you component-driven journey!
