The Pattern Its Own Creator Eventually Abandoned

Do you know the container/presentational pattern? It doesn’t matter either way this article is really about its history. That said, if the answer is no and you’re just getting started in front-end development, stick around. You’re in the right place.

This isn’t the only pattern out there, and it won’t solve every front-end architecture problem you’ll ever face. But it’s a foundational concept: understanding where it comes from, what it stands for, and where it falls short is genuinely valuable for any developer.

And along the way, we’ll also answer why Google still returns contradictory results when you search for “container/presentational pattern.” [3]

This isn’t a new idea. Its modern form is over a decade old. Yet its apparent simplicity means everyone seems to have their own definition. Here’s the one we’ll use as a baseline:

Presentational components: Components that only care about how specific data is shown to the user. Container components: Components that mainly care about what data is shown by which component to the use_r._

In other words, we split components into two categories: those that display, and those that decide what to display. That’s it — nothing complicated.

Except that the more you dig, the more definitions you find. They’re similar, but never quite the same — as if no official version exists. And that’s exactly the case: you won’t find this pattern on refactoring.guru, and it’s not in the Gang of Four book. There’s no authoritative source that owns and maintains the definition.

To understand where it came from, you have to go back to the article that put it on the map. In 2015, Dan Abramov published a piece [1] presenting this pattern as an elegant approach to structuring clean React architecture.

45K 👏

The article was huge. Dan Abramov co-creator of Redux and one of the most influential voices in the React ecosystem wasn’t some unknown blogger. And at the time, React was taking off fast: the Virtual DOM was generating real excitement, and the community was watching the framework’s every move.

Worth noting: this is React without Hooks.

So it made sense that Abramov’s article became the de facto reference for the pattern. But it’s important to be clear: he didn’t invent it. He just gave it a wider audience because he found it useful for structuring code.

I call them Container and Presentational components, but I also heard Fat and Skinny, Smart and Dumb, Stateful and Pure, Screens and Components, etc. These are not exactly the same, but the core idea is similar.

The concept already existed under other names. So where does it actually come from?

To find the roots, you have to go back to 2004, when Microsoft introduced the MVVM pattern (Model–View–ViewModel) [9] , itself inspired by Martin Fowler’s Presentation Model.

MVVM draws a clear line between business logic and presentation logic, decoupling the UI from its rendering. Sound familiar? Separating view from logic is exactly what the container/presentational pattern is after. The key difference is that MVVM predates the concept of components entirely.

Component-based [4,7] architecture is now the standard in front-end development : React, Vue, Angular, Svelte all build on it. But that wasn’t always the case [2].

Early front-end applications were far more monolithic, typically built around MVC structures [8]. Backbone.js, born in 2010, was one of the first popular frameworks to lean on MVC [6]. AngularJS followed with a more dynamic two-way data binding approach, edging closer to MVVM but still without a component-based architecture.

That shift didn’t happen until React arrived in 2013. From there, it set the template for virtually every framework that came after [11,12].

As components became the building block of front-end development, the MVVM pattern adapted. The separation between interface and logic remained, but it now lived inside components themselves. The ViewModel’s role was largely absorbed by component logic.

Which brings us to 2015. The container/presentational pattern gets formalized on Medium by Dan Abramov.

Then in 2019, he updates the article and walks it back. If you’ve worked with React, the reason is obvious: Hooks make the separation largely unnecessary [3].

Is “pattern” even the right word?

It’s worth pausing on this. The smart/dumb distinction was never validated by any official body. It’s a community pattern one that emerged organically as developers adapted to new tools and constraints.

In the classical sense, the Gang of Four sense a pattern is a named, documented solution with a precise context and explicit trade-offs. The container/presentational pattern doesn’t really meet that bar. No reference documentation, no authority maintaining the definition, and as we’ve seen, the person who popularized it eventually stepped back from it.

You could argue it’s less a pattern and more a shared convention: a practice that spread through use, stabilized around a central idea, but never hardened into a single definition.

Here’s where it gets interesting though. The GoF book is from 1994. Modern front-end didn’t exist yet. Today’s patterns don’t emerge from academic publications they’re born on Medium, debated on GitHub, and validated in production across thousands of projects. Does that make them less legitimate?

And this is precisely what answers the question from the introduction: why does Google return contradictory results for “container/presentational pattern”? It’s not a gap in the literature. It’s an accurate reflection of what the concept actually is. Every developer who has written about it brought their own experience, their own framework, their own reading of Abramov’s article. There’s no canonical source to settle the debate so every interpretation coexists, and Google surfaces them all.

That’s uncomfortable if you’re looking for a definitive answer. It’s fascinating if you accept that some of the most structurally important ideas in software development work exactly this way: not handed down from above, but built collectively by a community solving the same problems with the same tools.

So is the pattern dead?

Not quite. Abramov’s 2019 update only really applies to React, and the web ecosystem is bigger than one framework. In Vue, Angular, and Svelte, the question of separating logic from presentation is still very much alive. The pattern hasn’t disappeared; it’s evolved. Even in React, the separation still exists it just looks different now.

To bring it all together

This series started with the basic unit: a good component has a clear context and a single responsibility. Not too broad, not too vague. It’s the foundation everything else depends on.

The second article looked at how to organize those components the smart/dumb pattern. Atomic and molecular components handle display. Pages handle logic, HTTP calls, data transformation. Data flows down, never up. When a bug appears, you know exactly where to look.

This article adds the final layer: this pattern didn’t appear out of nowhere. It’s the product of an organic evolution in the front-end ecosystem. Understanding its history is what makes the difference between applying it mechanically and knowing when to reach for it and when not to.

What doesn’t change across any of this is the underlying goal: maintainability. A codebase nobody can make sense of six months later isn’t a codebase : it’s debt.

Front-end architecture is often treated as a secondary concern, something to sort out once the project “stabilizes.” That’s exactly backwards. The structural decisions made early in a project are the ones you live with or suffer under for years.

Source

1. Abramov, D. (2019, 17 février). Presentational and Container Components — Dan Abramov — Medium. Medium. https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
2. Barroca, L., Hall, J., & Hall, P. (2000). An Introduction and History of Software Architectures, Components, and Reuse. Dans Springer eBooks (p. 1‑11). https://doi.org/10.1007/978-1-4471-0367-7_1
3. Borenkraout, M. (2024, 2 octobre). Why you should stop using the “container/presentational” pattern in Redux. Medium. https://medium.com/@matanbobi/why-you-should-stop-using-the-container-presentational-pattern-in-redux-29b112406128
4. Component-Based Architecture and Design : A Practical Guide with Examples. (s. d.). Maruti Techlabs. https://marutitech.com/guide-to-component-based-architecture/
5. Container/Presentational pattern. (s. d.). https://www.patterns.dev/react/presentational-container-pattern/
6. Crudu, V. (2025, 23 juin). Debunking Common Myths About Backbone.js in Developer Forums. MoldStud — Custom Software Development Company. https://moldstud.com/articles/p-debunking-common-myths-about-backbonejs-in-developer-forums
7. Das, A., & Das, A. (2024a, août 25). Ultimate Guide to Component-Based Architecture in Web Development. PixelFreeStudio Blog -. https://blog.pixelfreestudio.com/ultimate-guide-to-component-based-architecture-in-web-development/
8. Das, A., & Das, A. (2024b, août 29). The Impact of Component-Based Architecture on Web Performance — PixelFreeStudio Blog. PixelFreeStudio Blog -. https://blog.pixelfreestudio.com/the-impact-of-component-based-architecture-on-web-performance/
9. Fowler, M. (s. d.). Presentation model. http://martinfowler.com . https://martinfowler.com/eaaDev/PresentationModel.html
10. Kothapalli, M. (2024). The Evolution of Component-Based Architecture in Front-End Development. Zenodo. https://doi.org/10.5281/zenodo.12772844
11. Suranga, S. (2025, 12 février). A guide to modern frontend architecture patterns — LogRocket Blog. LogRocket Blog. https://blog.logrocket.com/guide-modern-frontend-architecture-patterns/
12. Wanyoike, M. (2024, 4 juin). History of front-end frameworks — LogRocket Blog. LogRocket Blog. https://blog.logrocket.com/history-of-frontend-frameworks/
13. Polycube AI Studio. (2024, 4 novembre). Dan Abramov : pionnier de Redux et visionnaire du développement JavaScript. Best Speakers. https://bestspeakers.blog/2024/11/04/dan-abramov-pionnier-de-redux-et-visionnaire-du-developpement-javascript/