docs: add history page

src/content/docs/docs/about/alternatives.mdx

@@ -1,139 +1,113 @@
 ---
-title: Alternatives
+title: History
 sidebar:
   order: 3
-  badge:
-    text: WIP
-    variant: caution
 ---
 
-import { FileTree } from '@astrojs/starlight/components';
+import { FileTree, Aside } from '@astrojs/starlight/components';
 
-History of architecture approaches
+import StaticImage from '../../../../shared/ui/static-image/StaticImage.astro';
 
-## Big Ball of Mud
+Feature-Sliced Design has evolved from years of architectural patterns in frontend development. None of these approaches were wrong for their time; FSD draws on and refines their ideas for the specific demands of frontend applications. By exploring this history and related approaches, you'll gain a deeper understanding of why FSD structures code the way it does. This knowledge will help you avoid common pitfalls, make better decisions, and apply FSD more effectively in your projects.
 
-> What is it; Why is it so common; When it starts to bring problems; What to do and how does FSD help in this
+<Aside>
+  Please note that this is an overview, and some details might be omitted for brevity.
+</Aside>
 
-- [(Article) Oleg Isonen - Last words on UI architecture before an AI takes over](https://oleg008.medium.com/last-words-on-ui-architecture-before-an-ai-takes-over-468c78f18f0d)
-- [(Report) Julia Nikolaeva, iSpring - Big Ball of Mud and other problems of the monolith, we have handled](http://youtu.be/gna4Ynz1YNI)
-- [(Article) DD - Big Ball of mud](https://thedomaindrivendesign.io/big-ball-of-mud/)
+## Why frameworks alone aren't sufficient
 
+Frameworks and libraries do an excellent job handling technical details like rendering and data fetching, offering reusable and isolated building blocks such as components. However, this foundation isn't enough to tackle architectural challenges on its own. As projects grow, you need to compose these blocks effectively to manage increasing complexity, facilitate team collaboration, and enable smooth knowledge sharing.
 
-## Smart & Dumb components
+## Horizontal slicing
 
-> About the approach; About applicability in the frontend; Methodology position
+One of the earliest methods for organizing frontend code involves dividing it by technical layers, such as `components`, `pages`, `utils`, and `stores`.
 
-About obsolescence, about a new view from the methodology
-
-Why component-containers approach is evil?
+<FileTree>
+- src/
+  - app/
+  - pages/
+  - components/
+  - utils/
+  - stores/
+</FileTree>
 
-- [(Article) Den Abramov-Presentation and Container Components (TLDR: deprecated)](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
+This structure remains popular in frameworks like Next.js, Nuxt, and Astro.
 
+This structure fits naturally when an application's main concern is separating technical responsibilities and the domain is simple. As applications grow in domain complexity, grouping code by business area becomes more valuable, and folders like `components` can expand without providing isolation between modules.
 
-## Design Principles
+In FSD terminology, code scattered across technical folders rather than grouped by business area is known as [desegmentation](/docs/guides/issues/desegmented/), a code smell FSD helps avoid. FSD keeps the idea of layers but orients them around logical responsibility rather than purely technical categories.
 
-> What are we talking about; FSD position
+## Presentational and container components
 
-SOLID, GRASP, KISS, YAGNI, ... - and why they don't work well together in practice
+Popularized by Dan Abramov in React's early days, this pattern (also known as smart and dumb components) divides components into two categories: presentational (dumb) components, which handle appearance, and container (smart) components, which manage functionality.
 
-And how does it aggregate these practices
+| Presentational                  | Container                          |
+|---------------------------------|------------------------------------|
+| Regular DOM and styles          | Minimal DOM, no styles             |
+| No dependency on stores         | Interact with stores and pass data/callbacks to presentational components |
+| No data fetching or mutation    | Act as data sources for presentational components |
 
-- [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Design Principles)](https://youtu.be/SnzPAr_FJ7w?t=380)
+This pattern gave class-component-era developers a clear mental model for separating appearance from behavior, and a good way to reuse logic without introducing inheritance. Its boundary lived at the component level: containers held behavior, presentational components held appearance.
 
+As frameworks matured, that same separation could be expressed more flexibly within components themselves. Hooks in React, composables in Vue, runes in Svelte, and signals in Angular let domain logic live alongside UI without class-based containers, so the pattern's component-level distinction became less necessary. Even its creator now views it as a product of its time.
 
-## DDD
+FSD preserves the underlying goal of separating appearance from behavior, but moves it from the component level to the architectural level. The `ui`, `model`, and `api` segments keep UI, business logic, and data handling apart without forcing a container/presentational split on individual components.
 
-> About the approach; Why does it work poorly in practice
+- [(Article) Dan Abramov - Presentational and Container Components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0)
 
-What is the difference, how does it improve applicability, where does it adopt practices
+## Design principles
 
-- [(Article) DDD, Hexagonal, Onion, Clean, CQRS, ... How I put it all together](https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/)
-- [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Clean Architecture, DDD)](https://youtu.be/SnzPAr_FJ7w?t=528)
+Over the past few decades, numerous design principles have emerged, including SOLID, GRASP, KISS, YAGNI, and DRY. Some, like GRASP, are geared toward object-oriented design, while others, such as KISS and DRY, apply more broadly.
 
+These principles remain valuable and are embraced by developers of all backgrounds.
 
-## Clean Architecture
+Their strength is generality: they describe what to value rather than how to structure a specific feature. That same breadth means they can occasionally pull in different directions, as when strict DRY competes with KISS or YAGNI.
 
-> About the approach; About applicability in the frontend; FSD position
+FSD doesn't replace these principles. It operationalizes them for frontend, turning abstract guidance into concrete structure: how to organize a feature, when to decompose, what to prioritize, and where dependencies may flow.
 
-How are they similar (to many), how are they different
+- [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Design Principles)](https://youtu.be/SnzPAr_FJ7w?t=380)
 
-- [(Thread) About use-case/interactor in the methodology](https://t.me/feature_sliced/3897)
-- [(Thread) About DI in the methodology](https://t.me/feature_sliced/4592)
-- [(Article) Alex Bespoyasov - Clean Architecture on frontend](https://bespoyasov.me/blog/clean-architecture-on-frontend/)
-- [(Article) DDD, Hexagonal, Onion, Clean, CQRS, ... How I put it all together](https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/)
-- [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Clean Architecture, DDD)](https://youtu.be/SnzPAr_FJ7w?t=528)
-- [(Article) Misconceptions of Clean Architecture](http://habr.com/ru/company/mobileup/blog/335382/)
+## DDD, Onion, and Clean Architecture
 
+<StaticImage path="/img/alternatives/080-explicit-architecture-svg.png" alt="explicit architecture" />
 
-## Frameworks
+Unlike patterns like MVC, these approaches emphasize modeling the business domain while separating infrastructure and UI code.
 
-> About applicability in the frontend; Why frameworks do not solve problems; why there is no single approach; FSD position
+These approaches were designed for backend systems, where the domain model, infrastructure, and application layers separate more cleanly. They introduced ideas FSD draws on directly: domain-centric modeling, concentric layers with inward-flowing dependencies, and bounded contexts.
 
-Framework-agnostic, conventional-approach
+The challenge in adopting them wholesale on the frontend is that logic and UI are tightly intertwined there, and the patterns lean heavily on inversion of control, particularly IoC containers, which frontend component models don't naturally provide.
 
-- [(Article) About the reasons for creating the methodology (fragment about frameworks)](/docs/about/motivation)
-- [(Thread) About the applicability of the methodology for different frameworks](https://t.me/feature_sliced/3867)
+Feature-Sliced Design adapts these ideas to that context. Its `entities` layer and `model` segment structures business entities and rules independently, similar to DDD's entities and bounded contexts, while slices provide vertical modularity. The layered structure mirrors Onion and Clean Architecture's concentric layers, with inner layers like `entities` and `features` handling core domain logic and use cases. Dependencies still flow inward, but without heavy IoC containers, making the principles practical for component-based frontend apps.
 
+- [(Article) DDD, Hexagonal, Onion, Clean, CQRS... How I put it all together](https://herbertograca.com/2017/11/16/explicit-architecture-01-ddd-hexagonal-onion-clean-cqrs-how-i-put-it-all-together/)
+- [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Clean Architecture, DDD)](https://youtu.be/SnzPAr_FJ7w?t=528)
+- [(Article) Alex Bespoyasov - Clean Architecture on frontend](https://bespoyasov.me/blog/clean-architecture-on-frontend/)
 
 ## Atomic Design
 
-### What is it?
-In Atomic Design, the scope of responsibility is divided into standardized layers.
-
-Atomic Design is broken down into **5 layers** (from top to bottom):
-
-1. `pages` - Functionality similar to the `pages` layer in FSD.
-2. `templates` - Components that define the structure of a page without tying to specific content.
-3. `organisms` - Modules consisting of molecules that have business logic.
-4. `molecules` - More complex components that generally do not contain business logic.
-5. `atoms` - UI components without business logic.
+<StaticImage path="/img/alternatives/atomic-design-abstract-concrete.png" alt="atomic design" />
 
-Modules at one layer interact only with modules in the layers below, similar to FSD.
-That is, molecules are built from atoms, organisms from molecules, templates from organisms, and pages from templates.
-Atomic Design also implies the use of Public API within modules for isolation.
+Developed by Brad Frost, Atomic Design views the UI as a hierarchy of building blocks, ranging from atoms (basic elements) to molecules (simple components), organisms (complex modules), templates (layouts), and pages.
 
-### Applicability to frontend
+Atomic Design was designed for design systems, where the goal is a coherent, reusable UI vocabulary organized by composition. It remains the popular approach in that context, and its focus is intentionally on UI and UX.
 
-Atomic Design is relatively common in projects. Atomic Design is more popular among web designers than in development.
-Web designers often use Atomic Design to create scalable and easily maintainable designs.
-In development, Atomic Design is often mixed with other architectural methodologies.
-
-However, since Atomic Design focuses on UI components and their composition, a problem arises with implementing
-business logic within the architecture.
-
-The problem is that Atomic Design does not provide a clear level of responsibility for business logic,
-leading to its distribution across various components and levels, complicating maintenance and testing.
-The business logic becomes blurred, making it difficult to clearly separate responsibilities and rendering
-the code less modular and reusable.
-
-### How does it relate to FSD?
-
-In the context of FSD, some elements of Atomic Design can be applied to create flexible and scalable UI components.
-The `atoms` and `molecules` layers can be implemented in `shared/ui` in FSD, simplifying the reuse and
-maintenance of basic UI elements.
-
-<FileTree>
-- shared/
-  - ui/
-    - atoms/
-    - molecules/
-</FileTree>
-
-A comparison of FSD and Atomic Design shows that both methodologies strive for modularity and reusability
-but focus on different aspects. Atomic Design is oriented towards visual components and their composition.
-FSD focuses on dividing the application's functionality into independent modules and their interconnections.
+FSD adopts its composition hierarchy in the `shared/ui` segment for reusable UI primitives, then extends the same thinking to the rest of the application. Layers and segments give business logic the same structured, composable treatment that Atomic Design gives to UI elements.
 
 - [Atomic Design Methodology](https://atomicdesign.bradfrost.com/table-of-contents/)
-- [(Thread) About applicability in shared / ui](https://t.me/feature_sliced/1653)
-- [(Video) Briefly about Atomic Design](https://youtu.be/Yi-A20x2dcA)
 - [(Talk) Ilya Azin - Feature-Sliced Design (fragment about Atomic Design)](https://youtu.be/SnzPAr_FJ7w?t=587)
 
-## Feature Driven
+## Feature-driven architecture
+
+Feature-driven architecture serves as a direct predecessor to Feature-Sliced Design, emphasizing the organization of code around domain-specific features. This approach prioritizes grouping related functionality such as UI components, logic, and data handling into self-contained feature modules. By doing so, it aims to improve modularity, scalability, and maintainability in growing applications.
 
-> About the approach; About applicability in the frontend; FSD position
+In FDA, features are typically isolated units that encapsulate everything needed for a particular business capability, reducing dependencies and making it easier for teams to work on different parts of the application independently. This can include feature-specific components, services, and state management, all aligned with user stories or business requirements.
 
-About compatibility, historical development and comparison
+While FDA provides a strong foundation for domain-centric organization, it can sometimes lack the granular layering that FSD introduces, such as explicit separation of shared utilities, entities, and UI concerns. FSD builds upon FDA by adding these layers and slices, offering more precise guidelines for decomposition and reuse.
 
 - [(Talk) Oleg Isonen - Feature Driven Architecture](https://youtu.be/BWAeYuWFHhs)
 - [Feature Driven-Short specification (from the point of view of FSD)](https://github.com/feature-sliced/documentation/tree/rc/feature-driven)
+
+## See also
+
+- [(Article) Oleg Isonen - Last words on UI architecture before an AI takes over](https://oleg008.medium.com/last-words-on-ui-architecture-before-an-ai-takes-over-468c78f18f0d)
+- [(Report) Julia Nikolaeva, iSpring - Big Ball of Mud and other problems of the monolith, we have handled](http://youtu.be/gna4Ynz1YNI)