IV. Conclusion

Last updated Jun 24th, 2020

This is page four of a guide on Client-Side Architecture basics. Start at page one.

The work isn't over

I know this article expressed a lot of new ideas. To be completely honest, I spent about three months thinking about this off and on, and I'm likely going to spend some time revising it and trying these ideas out with real-world projects.

Stay tuned for updates on this. If you subscribe to the newsletter, I'll let you know when I publish major updates.

Let's look at what we've covered.

A new client-side development philosophy

Zooming out, we started with this:


And then zooming in, we landed on this:


Let's recap the statements I've made.

Model-View-Presenter isn't good enough for our needs anymore

The problems we're solving on the client-side are much more complex than they were 20 years ago. Because of that, the starting point for an architecture probably can't be MVP.

Design principles have persisted for a long time to help us write better software

I honestly think that reading books and learning from the past is one of the best ways to avoid future mistakes. Design principles are great. You don't need to always follow them, but know the rules before deciding whether you want to break 'em.

There are no silver bullets

There really aren't. With this advanced client-side architecture, what we introduce in structural quality, we lose in developer experience based on the potential learning curve involved. But ask yourself this question: is the complexity related to nature of the problem itself, or is it just related to the way we're solving it?

This is for developers where "use what works for you" is daunting, and would like a good conceptual starting point for an air tight React architecture

I'm really excited about these ideas. I've been milling around with this for a couple of months now but I think it's really important today. If you're a developer that has been told to use "what works for you", that's still incredibly good advice. But if you run into any of the pain-points in your React project like suddenly facing issues adding features, changing code, and feeling like things have turned to mush, this might help.

Next steps

We shouldn't stop here. Here are a few thoughts to chew on. Feel free to ask questions and leave suggestions on ways I can make this guide more helpful.

Choosing a stack: Given this philosophy, what factors into deciding upon a stack? Compatibility? Developer experience? Maintainer(s) activity?

Organizing code: How do you organize code within a React project? What principles are at play?

Dealing with prop drilling: If we have these clear-cut layers, doesn't that mean we'll have to do a lot of prop drilling?

Test-Driven Development: Can we discuss testing in more detail? What does a test-driven approach to client-side application development look like in 2020? Should we write BDD-style acceptance tests with React Testing Library and Jest? Or should invest into testing for functional correctness using E2E tools like Cypress.io?

Real-life project: What does this look like in practice?


Liked this? Sing it loud and proud πŸ‘¨β€πŸŽ€.


Commenting has been disabled for now. To ask questions and discuss this post, join the community.

2 years ago

Hi, this series of posts are really great. I have been thinking how to change our code base to be testable/maintainable. Sadly it’s not React but your posts inspired me a lot.

I will make some proposals and share with the team shortly.

thank you so much!

Jonathan Celio
2 years ago

Awesome posts!

I wonder how could be a real life app using this architecture.

2 years ago

Hi Khalil, the past months I've been struggling and squeezing my head around how to apply a clean architecture to the front-end, I really want to say THANK YOU, you are definitely connecting all the dots of my mental graph, not only with this serie, with your whole blog.

Nick Z.
2 years ago

Wonderful. Here goes another piece of internet gold.

Juan Villegas
2 years ago

Solid advice here, keep these coming!

a year ago

I tried to follow the clean architecture principles in this project. https://stackblitz.com/edit/vitejs-vite-p8voy6

The codebase is relatively small. My main concern is how things will play in a larger one with lots of interconnected dependencies.

a year ago

Awesome content. Would be awesome to see this architecture in a real app structure. Thanks for the content, Khalil!

a year ago

Great writing!

a year ago


a year ago

Thank you for the article. It was very interesting to read. But I have a concern regarding that approach: you suggested keeping the page root component as a Presenter component that glues the model to the view. That means that if a part of the global state was changed, then all the page components will be re-rendered (as they are children of the presenter component). Or you have to implement the memoization logic, what can be avoided if you keep state closer to the UI that renders it.

Stay in touch!

About the author

Khalil Stemmler,
Software Essentialist ⚑

I'm Khalil. I turn code-first developers into confident crafters without having to buy, read & digest hundreds of complex programming books. Using Software Essentialism, my philosophy of software design, I coach developers through boredom, impostor syndrome, and a lack of direction to master software design and architecture. Mastery though, is not the end goal. It is merely a step towards your Inward Pull.

View more in Client-Side Architecture

You may also enjoy...

A few more related articles

Client-Side Architecture Basics [Guide]
Though the tools we use to build client-side web apps have changed substantially over the years, the fundamental principles behind...
II. Principles
I. Architecture
III. Layers

Want to be notified when new content comes out?

Join 15000+ other Software Essentialists learning how to master The Essentials of software design and architecture.

Get updates