I am a contributor to date-fns, as I helped in implementing Indonesian locale and format ISO and RFC standards.
As an application scales larger, it is prone to 2 problems: 1) visibility of the underlying components, and 2) speed of the development.
As for the first point, in the codebase, there might be a lot of components that set up the existing application. When someone joins the project, it takes quite a bit of time to understand what components exist and what do not, including its varieties. Storybook helps in this case by being able to provide a “design system” for the components used by an application. As the component codes are visualized through the screen, it will cut a lot of time during engineers’ onboarding. This can also help to prevent redundant components from being developed.
The speed of the development is also vastly improved. Nowadays, most package bundlers use a development server with automatic reload on file change. When the application gets bigger, the loading time gets slower too, as it re-compiles whole application in-memory. Using Storybook, we can breakdown the components that we want to develop and have the change reloaded in the blink of an eye as these components are isolated. On top of that, validation gets easier too as Storybook allows static bundling. For example, when a PR is pushed, the CI builds the Storybook bundle and deploys it to a certain domain.
With jQuery, if you want to control an element, you only need to select the component with the $ sign before manipulating it. You can't really do so in React, because you'll need to jump into the React code and figure out yourself. What if you have minimal knowledge of React? Can we make React more accessible -- content-wise?
The answer is yes! We can utilize custom events to control the bundled React application from the outside.