Comment by namelosw

A bad metaphor I just came up with: You're cutting a birthday cake. If you do the horizontal cuts you could at best have like 4 cuts and it's very hard. If you do the vertical cuts you could easily have like 16 cuts for everyone.

Because the horizontal way separates the concern the wrong way, or more precisely, the non-scalable way.

The idea is the same way that backend architectures are migrating from layered architectures to microservice or DDD alike architectures.

HTML, CSS, JavaScript separation of concern: 3 layers. Layered architectures: presentation, application, domain, infrastructure etc. There's only O(1) number of layers, so it's not scalable enough for modern applications. You can came up with more layers, but it's still O(1) and would be more strechy, despite the business and codespace are growing fast. People will struggle because everytime they change one layer, they have to find the corresponding other layers of code - it starts to defeat the purpose of separation where it should help people not caring other layers when modifying code.

A more critical separation of concern is to have O(n) separation: you can different domains like products, inventory, sellers, account managment, custommer support etc. If your business continue to grow, you could have more of them. And more importantly, it's much easier to separate teams into pizza-sized teams than layered separation.

Don't get me wrong, layered architectures are still useful. In fact, most of the DDD implementations are layered. But there's mental overhead when you introduce separation. Communities like React and Vue decide that it makes sense to merge layers in Front-end for local reasoning over separation, and accoding to my experience it works well (because I find it's very common to modify HTML, JavaScript, and CSS at the same time before I even started to use React).