Separations of Concerns is a Lie
Вставка
- Опубліковано 14 жов 2024
- This one's very overdue. Model view controller rotted our brains and I'm scared we won't ever recover.
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4se0n3 for the awesome edit 🙏
It's just a principle and it should be balanced against other principles like "things that change together live together". Taking things too far in one direction is going to cause problems whatever you do
Its a pointless principle. It can be interpreted as anything making it 100% worthless
My current thinking is that those two concepts should live in harmony. Top level feature folders, but once you go inside the folder there's a fairly standardized structure.
@@fallenpentagon1579spot on
ITS ALL ABOUT THIS!!! Where is the ultralike button?
Man, all is about balance in programming. This is why define a senior enginneer!
Things change together live together is part of the single responsibility principlr
The thing is, Separation of Concerns is a very broad term that is at the core of computer science. For instance, it's what lets a backend developer be far less concerned with networking primitives (like addressing and routing packets). This is only a comment on the title of the discussion.
Yeah I feel like Theo is just talking about MVC apps for the web. And didn't give much thought to the rest of the stack anywhere lower than Javascript itself or outside of the web space.
> For instance, it's what lets a backend developer be far less concerned with networking primitives
Actually this would be called Abstraction, not SoC. I do agree this is a very broad term and more context is needed for any productive discussion.
>For instance, it's what lets a backend developer be far less concerned with networking primitives (like addressing and routing packets).
This is called abstraction. And while technically it does can be called SoC, do you realistically do it yourself? or you just grab any library for your specific language to do that? If so, yet again, that's not separation of concern being talked about here. We're talking organizational specific implementation of Separation of Concern, not about using library.
@@muhwyndham that is a correct use of SoC tho. The most basic one being kernel space vs user space and the separation between them.
@@muhwyndham SoC is one side effect of creating abstraction layers in anything from networking to video game development. People who work on game development for instance, can have a black box view of how OpenGL/DirectX works under the hood of their game engines. In that sense, the concerns of a graphics programmer and a game designer are separated. Abstractions and SoC aren't mutually exclusive terms. I mentioned my example to show how the term is very broad and ubiquitous in the field itself, and can go beyond MVC and web development.
There’s always a separation, otherwise we’d have one giant file with our entire codebase. What makes things understandable and maintainable is where we choose to slice those separations and the rules or guidelines on how to do that. I think where those boundaries are leads us to debate.
Some people’s ideas of ui layer are sliced differently which is why their opinions on where things like css go differ so greatly. I find things related to one component easier to reason about per component close together because that’s the area of concern. I don’t like returning html from my endpoints because it makes it harder for ME to reason about but perhaps a backend dev loves htmx and it makes it easier for them to reason about.
The separation that matters most is understandable, maintainable and highest return on investment. Unfortunately the debate isn’t soc or not soc. It’s where those boundaries of soc are. With new tech these boundaries can change and get fuzzy as we explore them and find the best way to use them. I do agree that soc as a blanket term for I don’t like your code organization is not useful though. Where and why we split is an interesting part of development.
100% agree. It seems that Theo's arguments are more tailored towards "MVC is bad for frontend“ which I agree with. But SoC is pretty much always utilized.
No separation of concerns is basically the definition of big ball of mud. I think what he's trying to advocate is vertical slice. Each architecture is valid. The importance is to understand the pros and cons of the decisions you make. Then later on when you encounter a con of your architecture you don't question everything (which it sounds like what Theo is doing here) but just remember that you embraced that con because you prioritized a different pro.
Unpopular opinion:
Separate Concerns Properly
I think both co-location and separation of concerns can exist in the same codebase.
I'd love a video about how you do structure your code? Like where do you put a lot of your complex business logic? etc... :) thanks for the great content!
Complex business is affair for Domain Driven Design. You fully isolate business logic into a separate namespace; with this domain layer having zero dependency from the rest of the app (only exception is the domain Repository interface, that gets implemented in the app namespace to provide persistence).
Separation of Concerns is paramount with this architecture and fundamental for tackling complex/broad logic. Of course it generally increases the effort necessary.
If you don’t separate concern you start thinking of everything as a React problem, overusing contextes and useEffect when in reality ui and core logic are different problem spaces.
true, and it is a hassle to maintain and develop on it in the long run
100% agree
I had to coach a team that put all the logic of their complex application into React components (not event custom hooks) and Redux Toolkit states. The first thing I thought them was the Single Responsibility Principle, which focus on the separation of concern to makes the code easier to follow (and faster to test).
Extracting logic in services, rich domain object allowed them to have UI files that focus.... on UI! Didn't have to wait a long time to get the feedback that the project was easier to navigate and the features easier to code.
1. You DONT need 15 layers of abstraction.
2. If you actually write tests, you will catch what is breaking.
But if you need to "ship fast" because you need to make YT videos on bad software practices, ignore my previous 2 points and YOLO.
Yeah, unit tests and e2e test make easy to change things independent lf your architeture which makes refactor easier.
I take a slightly different view of MVC architecture (though perhaps one that's not super common). It's a _conceptual_ split, and it doesn't determine whether it lives in your HTML, your JS, your server-side scripts, or your CSS. At least, it _shouldn't_ be used to determine that, because there's exactly where you run into these kinds of issues.
If you don't make it needlessly complex, MVC can be boiled down to the following:
- Changes in the presentation of the page don't affect the available functionality for that page and vice versa (i.e. the code that handles actions and interactions with elements on the page is not itself located in the code for the page). This is the View/Controller split.
- Changes in the data formats don't affect the functionality interacting with that data and vice versa. (i.e. you use an intermediate layer that provides access to data, so that changes to your data format don't have to affect the interface that existing code uses). This is the Model/Controller split.
- Changes in the data formats don't affect the presentation of the page and vice versa. (You can make use of the same intermediate layer here as well). This is the Model/View split.
This allows you to reason about these parts of your code independently, and making changes to one part won't break the other parts. For example, if you need to change something and want it to be backwards compatible, it's immediately clear which code needs to change to make that happen, and it's not spread all over your code base.
In JSX, an inherent separation of concerns between View and Model already exists. You can provide information to a component that tells it what should be rendered in it, the same way that you can provide a function call with arguments. There's no built-in split between Controller and View though; you can easily write any code in event attributes, or have that code extracted to a function inside that component. But once it stops working on the component itself, it should ideally be extracted outside of that component. In fact, the component shouldn't care about what functionality is attached to events at all. So rather than calling an outside function, a decent way of doing this is to just pass in a callback function as an argument, that gets called at some point during the handling of the relevant event. It's a rather flexible thing at its core.
I do think that how MVC is typically used is overly rigid and I've never liked that kind of approach. Some parts of your code inherently know about one another and you can pass that through as many layers of indirection as you like, it's still there. Code that works directly on a component should live in that component, always. The View is not just _allowed_ to contain behaviour, it often _should_ contain behaviour. Something like opening and closing a dropdown can be done entirely in the View, provided the content within is already loaded.
Whether or not you use Tailwind doesn't really matter here either, I think. It's typically a part of the View, but _how_ you make it part of the View is up to you. And this is kind of where there's something else worth noting: just because two parts live in the same layer doesn't mean they need to be tightly coupled. They _can_ be, but in that case I'd almost suggest you just write your CSS for each component independently and just use css `var`s to adjust the value of properties as required. I've tried other approaches, but the dead CSS struggle is absolutely a real one unless you take care that it's either in the exact same place or completely disconnected. And that's a problem that I don't think MVC realistically has anything to say about.
The tailwind example is a great argument for separation of concerns instead of against it. Tailwind handles the concern of defining the css and style standards and the implementation happens in the tsx files that need them. Also it handles the issue of unused styles by only compiling what is used, which solves issues that other css libraries had before it where you were adding a lot of bloat for a limited set of features.
Keep it simple, is a great mantra. I do have some util files that only have one function in them, when they could be in the feature I was developing, e.g a utils/math.ts file that just has a quantize function (for now). The problem with leaving it in the feature until I need to separate it is that other people won't even know it exists and are more likely to re-implement elsewhere if needed. As a principal dev I'm also providing a place for other devs to store their generic math functions.
On the other hand I strive to organize things for ease of understanding and ease of use (DX) over any strict technical standard/definition, and if it's clearly a function or type for that feature I'll keep it local.
MVC is not a front end topic, it’s about the server side concerns. You can have an MVC app with a REST api sending json to your react client (just think of your JSON serialization layer as your views instead of html templates or whatever it might be otherwise). In a front end context you have a lot more constrained set of concerns, as in you’re not interacting with databases or handling http requests, so I could see why MVC doesn’t map well to front end development, but on the server side it would seem really weird to write a single function that interacts directly with the database, performs business logic on the retrieved data, renders that data into html or json, and then returns an http response. I’d much rather have a class that handles the db interactions, a class for rendering the response, and then a class for handling the http response.
Spot on. MVC works great in my company’s dashboard site we’re building.
Theo does not know this, but testing is easier with MVC, or just good separation
It's also increases testability, instead of a god function that does everything.
@@TheJubeiamTheo does not like testing either.
@@Rust_Rust_Rust exactly
Agree very much. One thing that I really think came with more experience (been working with development since 1997), was to be more secure in myself to not do things "just because", but to be more confident of what is actually better. Obsessive use of patterns, abstractions and being fancy are other examples of things I used to do because I felt more senior, but when I actually got more senior (and old) I got better at knowing what's actually good, compared to what looked good.
But as always it's finding the balance that matters in the end. Ironically software development is not binary. It's a game of tradeoffs.
I agree with you but a quick word of warning if you are a new dev:
Stuffing everything in one file is not the brightest idea. Using CONTROLLERS (or data access layers or whatever the name) to get data and then pass it on to the UI - that pattern is rock solid and is also known as the MVC architecture most backend web frameworks use.
So when Theo says "MVC bad" - or "testing bad" or whatever hot take - don't throw it all away instantly.
The reason why I don't use server actions because it's coupled with my web-app and cannot be re-used with say in future - a mobile app. API routes on the other hand can be used standalone in the future with any client (not just browsers).
@@codedusting I've not done all that much with server actions and my test project was removed a while back, but couldn't you move server actions into a separate file and call that from the component just like you would with a regular custom hook? In which case it would be trivial to just replace the implementation later, which then simply becomes a different way of doing separation of concerns.
@@CottidaeSEA Yes, but then it's doing more work if mobile app is in the pipeline. Also, most companies have dedicated front-end and back-end teams so codebase separation becomes a norm.
3:03 That whole problem of not knowing what breaks after a change is already solved: tests. First Theo claims tests are not needed, and now we throw out separation of concerns to deal with problems caused by lack of tests...
I don't suggest, SoC is always the best solution, but I'd say having it as a default and only opting out when there's a reason is a solid way to go.
Tests come with their own baggage, and tests are not a guarantee that you'd catch breaking changes (every company I've worked for mandates code coverage and have an extensive suite of shitty tests, hooray for you if that's not your experience).
You're also not addressing a key point in Theo's argument - it's easier to understand and update if related stuff are close together than completely separated. I know some people say tests should be the way of documenting your code but you must have lived a very blessed life if that's your actual experience.
@@moodynoob
What exactly is the problem with separating your user model from your users controller, posts model from your posts controller, etc?
All Theo gave was the obvious view of a React dev who has never had to untangle the issues caused by several controllers doing their own versions of queries. The idea that an API shouldn't have some kind of standard expectation for query results is bizarre af to me.
I separate my concerns by never building the front end… leave that new age jazz to the kids
I have a confession to make after heard "at least a 1/4 of CSS on twitch is not being used".
For almost a year I stop using any style libraries on my apps, and I'm, being using just the style props instead classes since. And I do not regret.
The consequences I did notice was:
1: Easy to see where components repeats styles, so its easy to define wrappers to isolate these styles with meaning.
2: I'm having almost zero redundant styles
3: Every single time it feels like there is no legacy styles code, since the code affects only the place you seeing defined.
I felt no drawbacks, and it's not hard to maintain.
If you have 7 layers of abstraction, it's MVCCCCCCC
Your example has Seperation of Concerns, the data access (Model) and the data display (View). Now you have a action and that is the other seperation, what nextjs and other Meta-Frameworks do is abstract the controller away into the generated code.
It seems like a more accurate title would be "MVC is really bad at separation of concerns" compared to modern declarative UI frameworks with component-based architecture.
I cannot agree more with this video. Fantastic. Separation of concerns is also the same reason inheritance is generally not considered good. We want to avoid making a small change in one file and messing up the entire codebase at all costs.
Separations of business concerns - that is the correct terminology
However, many people don't learn UML + OOD and OOA to misunderstood which leads to more abstractions that is needed.
Boundary Control Entity is more general MVC + it describes a way components to interact between themselves.
In some cases it makes sense, in other don't
For example data grid + manipulating data in real time - you don't need abstraction.
1 db call for reading data with filter and pagination
1 db call for update/insert
and these can be build-in into the component
“Separation of concerns” doesn’t just mean by the type of abstraction like MVC. It can also refer to separating abstractions by the business domain or feature. Basically abstracting things has benefits… if done well
Your example of not using separation of concerns is the perfect example of separation of concerns haha
We don’t know how getImagesForUser works but we know what it does just by it’s name and the Images component doesn’t render anything it just gets data and gives it to a “dumb” component, basically a controller.
You don’t need MVC or MVVM or “clean architecture“ any other software organisation framework. Just organise your code so that you can read it and understand.
People saying things like "MVC bad", "OOP bad" and "testing bad" don't understand that you need the first two in order to do the third.
And if you don't test you code, there is no way you can make sure it keeps doing the job throughout years of refactoring by different developers.
@@Atmos41Why do i need oop or MVC to test?
You're totally right.
I think people get frustrated in react because all 3 parts of MVC belong to react. Still, it works better when we have a dumb View component a hook that encapsulates state (Model) and a component that composes both and connects hooks and dumb view (Controller).
You'll be able to reuse Models and Views more efficiently this way. So yes, MVC works and should be used.
Problem comes when you tried to externalize one of this parts outside of React. That's a react issue in my opinion. It doesn't work well with "pure" javascript. TanStack had to deal with this to make a library that works with any framework and, if you check that codebase, seems a bit hacky due to the fragility of today's react hooks. Solidjs, for instance, allows better MVC approaches and that's why many people feels it's nicer to use in the end.
@@deado7282 You dont actually...
Nailed it! Abstractions are really really hard to get right (I’d say they’re “impossible” to get right to a first approximation). Fewer abstractions with clear responsibilities (aka “concerns”) has always worked better and for longer in my experience. The key is what you glossed over: “Just organize your code so that you can read it and understand”
Personally I'm a big fan of vertical slice architecture and focusing more in coupling and cohesion and balancing those
Omg spagetti code here we go again xD We are go back to dark 2005 PHP age
echo 'welcome back!';
I worry for the junior developer watching this video and following his advice.
I worry about AI training on shit code humans have written.
I am a software engineer student and I am really confused so can u elaborate
@@abdelazizlaissaoui9079 If you are starting focus in this two concepts cohesion and coupling, the target is maximize cohesion and minimize coupling, take this sort of advice with a grain of salt, while coupling things at UI is not that bad doing the same at the server side will end up in a brittle structure that will be barely maintainable or scalable.
He's kind of right. But the premise of MVC is still there.
Why? If you are going to say that what he is saying is wrong, and then follow through with the why it makes me immediately believe him more than you. At least he can explain his thoughts and not just be a part of the peanut gallery.
Separation of concerns will be a pain in the ass when you're almost certain that the coupling won't change, but if they do, it'll be easier to manage. The issue arises in many projects, particularly in backend, where it's beneficial to apply some form of SoC for certain features. For example, we might currently fetch data from an API but querying directly from a database in the future. However, we also want to maintain a consistent code structure across all features, which leads us to enforce SoC principles (like clean architecture) on every feature.
Theo completely skipped the whole industry of automated quality assurance and then blamed lack of technical debt maintenance on MVC.
This problem was already solved 20 years ago, then frontend got enlightened with godsent frameworks and we are doing second round trip of the whole cycle all over again. I know a lot of people gonna disagree, but its just my opinion.
I've seen you speak good about the hooks pattern because it makes it possible to detache the state management from the UI rendering. I suppose that is separation of concearns in React.
Having a component that does everything, from fetching data/mutating, to rendering UI with user interactions can get ugly very quickly. I think what you said here can get misinterpreted as "code a whole page in just one component"
😊😊😊😊😊😊
I think I want presentation/design separate from logic/data-flows. In my teams there are people who wire data and people who make beauty. I'd like the beauty makers to be able to update presentation whenever without needing to mess with where the data goes and how it arrives.
Love how you phrased the distinction between people wiring data and people making beauty.
The scenario I keep struggling with is this: I have some tree of model data representing application state. And then I have a whole separate tree of UI components representing that state visually. The two map closely enough that it feels like I'm duplicating a lot of logic, but they don't map closely enough that they can reasonably be merged. "Controller" logic gets fragmented between the two. But introducing a controller just adds yet another tree.
I think this is what htmx is designed for. The only problem with htmx is how you handle offline functionality if that is necessary for your app. The stack around htmx I would probably use would be Golang, unoCSS, a database of your choosing, and htmx
It's okay to duplicate code. Google WET vs DRY. WET is good in many cases. Allows you to adjust each part on its own. Avoid bad abstractions. Write it twice is good in many cases.
To me, the thing that is missing is cohesion. Ideally database logic, and UI logic should be in separate functions, but still close together. It's easier if all your login stuff is close, instead of all of your database stuff
React still separates concerns. It’s just that instead of separating concerns between the presentation layer, logic layer, and data layer, they separate concerns based on domain concepts within your application. Separation of concerns becomes a bit fuzzy in terms of front end though, when the whole thing is essentially the presentation layer.
I feel like separation of concerns is still useful to promote reusability in big projects where an API needs to be reused across multiple frontend applications. It helps avoiding to reinvent the wheel (as in making sure all the correct validations are in place for the API) for every new frontend app that needs to consume/update the same data.
The way to avoid reinventing the weel is to create abstractions. Seperation of conerns doesnt help with it.
But that's not really what people mean by "separation of concerns".
Then in this case the guiding principle should be called reusability instead of SoC. From what I understand, Theo is saying that SoC is not a good enough principle on its own.
@@ignaspan exactly. We shouldn't be separating whatever we are concerned with just to separate them based on some misunderstood principle. In react, the UI is a function of state that gets encapsulated in components. These components and the state are the concern.
Now that react is blurring the boundaries between frontend and backend, the backend also becomes a part of a components concern. But I think it's important that we think of this as a BFF (backend for frontend). You can still have another separate backend that does typical backend stuff. Or if your app isn't too complex, you can do everything in Next.js or whatever.
Yes! This goes alongside over abstraction. I was having a chat with one of my devs the other day and he told me he considers splitting the code if it exceeds 50 lines - which sounds good in principle but in practice you’ve taken a bunch of code that’s only used in one place and scattered it throughout the codebase. Now I have to have a dozen files open just to understand one feature.
But surely the feature is in some kind of module/namespace. The top-level entry file gives you the high abstraction overview of what the feature does and how, if you need more details you drill down into the separate files to get the low abstraction meat of the functions as appropriate for the task at hand.
I aggree with the front-end stuff completely. The back-end one not that much as I mainly work on API back-ends and not SSR back-ends.
On express we use API layer to hold the endpoints and the middleware attached to them, on Services layer we hold the business logic and on the database layer we hold raw SQL queries and nothing else. Works pretty ok on the backend, but I do have to admit figuring out which service file to put business logic for a specific feature is always a problem and in the end it doesn't matter where it is. It does feel a bit overwhelming if there are a lot of different functions in one service file.
I have experienced separating the backend by feature when working on Django but I really hated it, maybe more because it was Django though. Django turned me off from that idea entirely.
I used separation of concerns for an S3 bucket recently. I had so much repeated code throughout an application making calls to the S3 bucket, it didn't make sense to be doing it this way.
So I created a special class for working with S3 bucket. The initial constructor was called in the beginning, sets up the tokens, and then all the functions for uploading, downloading, and existence of an object could be handled simply by making a call for those methods. Way easier and less of a headache.
Seems like you don't understand separation of concerns. You used it wrong.
Hard disagree in the scope of large applications or systems of design. Majority of web is just forms for data entry so the complexity isn't that high. So the overhead there isn't worth it if you are just hitting a quota.
But when you are focused on an ecosystem that can be composed, therefore more complexity by design. Knowing how to perform reasonable separation of concerns is key.
I disagree with making that broad statement . A proper static typed MVC approach makes it much easier to avoid the kind of bugs and performance issues that grow as your project grows in scope and scale. MVC of course, could have some more letters added to it, and controllers are much more than just routing. Once you throw out static typing, then you have spaghetti, and if you are going to do that, then it makes sense to have as much as possible in smaller componants.
MVC is primarily a backend concept so of course it won't work well in a frontend setting, especially since in this case we are talking about React (or any other frontend framework such as Vue or Svelte). The state influences what HTML is rendered (think about different HTML being rendered based on whether a user is logged in or not).
But when we go to the backend, MVC makes sense since the controller does data validation before calling the model and data transformation before calling the view. The view is just used for representing the data, typically in HTML form. For REST Api's we pretty much get rid of the view. And the model is what takes care of the CRUD aspect of your data.
SoC on the other hand is still being utilized in pretty much all apps, even React and Nextjs. Your React app is still divided into multiple components, each with their own logic. This in of itself is already a separation of concerns (just on a very high level since you can have multiple components which functionally are the same, but they just deal with different sets of data). From the frontend you would send http requests to the backend to fetch data instead of directly connecting the frontend to your database. This adds an extra layer of protection since the frontend can be directly be modified by the client, but the backend can not (unless they gain access to the server). Which is one of the reasons why people advocate for data validation on both the frontend and backend (with a minimum of backend validation since people can just directly call the API, completely bypassing the UI).
Furthermore, the invention of frontend frameworks is also a form of Separation of Concern. In the past, we just had the server which sent HTML to the client. The server was the entire app. But now we have taken the HTML part and everything that goes with it (CSS and JS) and moved it into a completely "separate" environment where now we essentially have 2 products, a backend and a frontend. This is also a form of separation of concerns. The frontend deals with client related stuff (updating the UI, animations, etc) and the server deals with raw data (CRUD)
Even in the image grid example you gave you have the separation: you have a data access layer function to load sql from database, you have a smart component (controller) that loads the stuff from DAL and passes it further to view, and you have a presentational ImageGrid component that acts like a view. It doesn’t matter that they all are in the same file or split into several as long as your build tool can analyze all the code dependencies which is not true with CSS
I agree with your other points. But the server-client separation is needed when you have multiple clients like web, android app, desktop app, etc. I know most of your audience build only web apps (including me) but for large organisations the server-client separation is kind of necessary
Yeah I agree we like have
Multiple mobile apps
Also 2 websites and other 3rd parties that uses our OpenAPI setup, so having backend separated is a must
I work on two very large apps that are being held together entirely by the grace of a variation of MVC/Observer. I resisted this for decades. But the moment you allow reactive (anarchistic) data flows, you can't understand it and control it. These two apps have a fat data pipe running through them, and it's the only way for data to move through the app. This has reduced bugs by around 95%, because bugs are just very hard to make. Extreme MVC is the best thing I've ever done. Reactiveness is great for last-minute bindings in a UI. But for major business logic, it's hell.
I did a lotta maintenance on projects whether small or enterprise ones and personally I think it all boils down to making sure your team agrees on one approach (soc, non soc hybrid... whatever floats your boat) so that your codebase makes sense as it undergoes changes
Separating your code can make it WAY more testable
People often neglect the valuable lessons from established concepts when exploring new ideas. Simply copying concepts from back-end context may be the root issue.
In React, a component acting as a controller by responding to events, coupled with a view and an externalized model through a store, essentially follows the MVC pattern. Front-end engineers should adapt ideas to JavaScript and UI challenges rather than dismissing them.
Tailwind exemplifies how adapting solid concepts can benefit new ideas, emphasizing the value of not importing CSS directly into JS components, particularly in large projects with diverse teams and stacks. This aligns with an updated perspective on separation of concerns.
I've yet to witness a large, enduring project using current frameworks, especially React.
The recurring SPA vs. MPA debate and the introduction of React Server Components reflect a tendency to reinvent without fully grasping past concepts. This lead to unnecessary problems.
Many people are gonna suffer with RSC projects in the future because of that mindset, and it will take a long time for them to understand what was the root cause...
This video appears to rationalize questionable decisions in a beloved framework. I already saw that kind of discussion 10 years ago, some people will never learn.
I liked MVC in Ruby on Rails back in the day. But nowadays, the thing that gets me the most is the folder structure it imposes - models go with other models, views with other views, etc. Same thing is often done in Java Spring Boot and others. I think the things that logically belong together should go into one folder. User Controller goes in /user/, User Model goes in /user/, User Views go in /user/, specialized CSS / JS for that goes in /user/ ...
that approach is good if your app is a simple CRUD. However once things become more complex, the "user" folder becomes incredibly restrictive on what it can accomodate.
The issue with CSS is a tooling problem. There is no technical reason why we can't check for unused/not existing classes.
Yeah, let’s have 300 components that each have 1200Loc and connect directly to db. Each doing same thing slightly differently and devs who afraid to touch them because they are entangled blob of code built over 5 years by adding extra pieces.
5:50 About you not being able to spot when a change breaks something, because of the abstractions used in the codebase - maybe you would if you weren't so much against tests Theo, that's the whole point of having tests 🤷♂
Theo isn't against tests though.
@@michaelfrieze ua-cam.com/video/ZGKGb109-I4/v-deo.htmlsi=rmjV695faLMLl0zA
it s time for those backend guys learning css and tailwind
The comment section may burst, but let me give a try in simplest term.
I like components built based on feature based pattern.
-product-feature(folder)
--components(sub-folder)
--styles(sub-folder)
--redux-slices(sub-folder)
--reducers(sub-folder)
--apis(sub-folder)
//others
-another-product-feature(folder)
--components(sub-folder)
--styles(sub-folder)
--redux-slices(sub-folder)
--reducers(sub-folder)
--apis(sub-folder)
//others
Perfect timing! I was looking down the MVC rabbit hole as a Frontend dev. I do develop with a separation of concern but not from a strict MVC point of view. It's really important that things make sense to me and I'm not just following a pattern.
The definition of "concern" is the issue.
Separation of concerns, NOT code. CSS, HTML and JS CAN have the same concern, the component!
MVC is great on the server. Front end developers don't seem to understand server side architecture and vice versa 😂
You don't want the client sending SQL directly to the DB
For how I learned MVC writing Cocoa apps it’s about having a Model that knows nothing about the View, and a View that knows nothing about the Model. That way you get reuse of much of your View and Model instead of writing bespoke new versions each feature. (The trade-off was the controller knew about both and that led to it blowing up in complexity).
A design system is a classic example of a View with no knowledge of the Model. It gives you maximum reuse of those components: your Table can be reused again and again because it’s not coupled to the feature it was originally built for.
Postgres is a fantastic example of a reusable model. It can be reappropriated for new projects without being tied to the previous project you worked on.
When people say “separation of concerns” it can be hard to know where they are coming from. The most general advice I’d give is try to make lighter pieces that aren’t coupled to everything. “God” components that control everything are usually going to be a bad time. And don’t just blindly push against “separation of concerns” assuming it’s completely outdated. My interpretation of its aim was to reduce coupling and encourage reuse.
Grandpa's off his meds again
This isn’t how i think about coding, I separate things out once it makes sense to, but only because of “context complexity.” the rule is “this thing shouldn’t care about x or y, because i don’t want to think about x or y when reasoning about this, so x and y are separate components from this.
it’s really easy to reason about MVC backends in established systems, bc you know where things are without having an intimate knowledge of the codebase. its implicit communication, useful for companies where teams aren’t stable or people will begin work from outside the team. you just don’t have to learn someone’s home-rolled SoC, which is way harder sometimes than established patterns. sometimes not, but i’d imagine most large backends benefit when they have to do a lot of business logic and have a bunch of entry points to functionality (eg, HTTP requests, distributed messages, scheduled jobs, etc)
separation of concerns shows the concerns of separation
I've tried pretty much all the different architectures and MVU comes out on top. The ability to delve into any codebase and see a complete overview of the application's state and every possible event is incredibly beneficial...not to mention that this makes testing comically easier.
This is correct.
Been programming for a while now ... and there is nothing nicer than having ALL the code related to a feature sitting on the same page. The SQL, the UI, the Comms - all in the 1 spot.
SoC is an extremely useful abstraction and mentality. Since we are talking MVC, esp. for backend development through a classic framework (e.g. SpringBoot) the MVC model actually makes tremendous sense. It allows the separation of specialties, something that Theo may not think is "a thing" - but actually, past a certain point, it certainly is. The people who build the entity model should *not* need to know how the API will expose their data - they should concern themselves with the entity model representing the architectural data plan of the application. The people who are on the other end, e.g. the frontend should *not* know what hoops the data they need must go through to reach them. All of this of course implies a clear architectural vision, design documents, proper analysis etc.
Sure, many startups would be hampered by such mentality. But when the projects reach a certain scope and you have many teams from many companies / organisations come together to create a single project, SoC *is* a real thing and *must* be a real thing. Otherwise its pure chaos.
Finally someone prominent get to the same conclusion that I have. I come from Android side of things where people are DOGMATICALLY (and I repeat, dogmatically!) Follow Uncle Bob recipe in the "Clean Architecture" principle. Including, mind you, Separation of Concern (I know that SoC is not in any principles in Clean Arch, but Clean Arch starts from the argument of making SoC works in a scalable manner).
I constantly have to fight my way through a feature because people keep trying to make more and smaller and smaller definitive layer in between data source and presentation, where it become incredibly cumbersome. All of that for the sake of Separation of Concern. "Because Separation of Concern is Scallable". Bullshit.
It used to be just MVC, Then it evolve into MVP where the P stands for Presenter, which is basically the same with Controller just that it adds additional Rules of the P should be decoupled form the V, and introducing 2 separate interface that stands between the V and the P.
Then it evolve again into MVVM where the VM stands for View Model, and now the VM should not even know the existence of View at all! Instead VM should expose immutable and obvervable variable where the View can observe to do state changes.
Then it evolve again! now with the introduction of Usecase Pattern! Now instead of VM directly communicate with Data source, it instead should consume X amount of interface that every single of the interface TO EVER. DO. A. SINGLE. THING. ONLY!!!
It's madness!
And yet, in every company that I worked for, there has been never in any moment where 2 developer can work on the same thing but on different layer. I have never seen people work on a feature where 1 developer only does the data fetching and persistence, and the other create the layout/view. I once attempted to do that in the misguided attempt to follow Separation of Concern to a T, and lands on dissastrous result.
And now what happened? Ask any native Android Dev and they will tell you that consuming API is cumbersome, because now on every single endpoint (Yes, every single!) you should create or modify 8 different thing:
- Data Source Interface
- Data Source Impl
- Repository Interface
- Repository Impl
- Usecase Interface
- Usecase Impl
- View Model
- Fragment/Activity.
And people wonder why apps nowadays consume so much RAM.
Others have mentioned this, but you seem to be under the impression that “separation of concerns” is one thing.
It’s a general principle.
Your exact example of something better is simply separating the concerns differently. Much like “locality of behaviour” is a guideline for how to separate them.
Aspects (concerns) of the code should be separated by their functionality.
In 3-5 years Theo will cause drama by suggesting that we should separate by concern.
He's been around the block enough now. He's playing the long game. Job security in the making!
Re: css "Scared to delete it". Are they not able to search the codebase for the reference? Would be nice to have a linter for css that shows "no reference" like unused deps and variables.
Separation of concerns is important but it should be about business domain concerns, not so much about technical concerns. The way I think about it is that it should be relatively easy to explain to a non-technical person what each part of the code does. This yields benefits in terms of readability and also it facilitates looser coupling. When you don't separate the concerns, you tend to get leaky abstractions, not necessarily on day 1, but the leaky abstractions start to leak into your code because the boundary between the different modules is unclear and developers can't agree on the responsibilities. Then different components may require too much communication between themselves to get the job done and this creates tight coupling and hard to maintain code. That's why it's important to stay true to the business domain; if the distinction in responsibilities is clear enough to explain to a non-technical person, then it will be clear enough for most developers to agree in an unambiguous way.
What it works best for me personally is to have the component itself as declarative as possible. And for that, separating the UI from the business logic could make a lot of sense. If I want to render a component conditionally by a really complex logic I can just create a separated file containing that logic and in the component I call the method that returns "shouldRenderComponent", and that is it. That way is easier to understand what is going on in the file, without having to scroll thousands of lines.
Then... you'll end up with team mates mistaking the intention of separating logic from presentation and they will be using your this-component-only-hook in other components
The children component should not hold the condition for its display actually, it's better to get the condition where it is being rendered and the children just accepts props that makes him display properly (avoid the all optionnal props interface)
not web dev but related: And that's why I like Qt's Model/View architecture.
You have a model (which either deals with the data directly or is an adapter; that also means that some models are literally proxies to other models (e.g. there is the QSortFilterProxyModel class which does what you think it does by the name)) and the view has the model and renders it's data.
That's pretty much it.
And well, there are also delegates but these are only needed for editing data (I won't go into detail why they are needed or the like).
Pretty nice in practice imo.
6:55
You are mostly right, but if you have an API that is requested from multiple clients/apps, it totally makes sense to have an API that is generalized
I prefer to separate business logic from presentational components. When a UI element requires business logic, I usually abstract the logic into a utility function. If the logic is more complex-such as involving reducers and multiple utility functions-I opt for a custom hook. This approach allows me to test these interactions separately from the UI element, simplifying testing and maintaining clear separation of concerns.
Additionally, designing the hook close to the UI element reduces the drawbacks of having changes scattered across the codebase. This setup minimizes cognitive load and provides better guardrails through isolated hook testing.
Wdyt about my approach?
I think for a proper critque of seperation of concerns you need a Brian Will style multi year multi hour video series.
I'm currently updating a old AngularJS proyect and the separation of consern is helping to extract the keys structures in order to continue reducing all the AngularJS code with the goal of change to a NextJS stack.
In my opinion the solution for backend changes is simple: use API versioning to prevent breaking changes in the current call. I guess it really depends on the use case but for an environment where I have to scale specific services depending on the load I prefer to have the backend separate so I don’t waste resources by scaling up something else I don’t need to.
When you do a proper server side render MVC shines the most. It do not appplies to component based architecture.
The problem is not separation but just strictly following this paradigm of applying MVC to everything you could. I agree that it introduces tons of complexity. In my opinion the developer should use their own judgement where it makes sense to separate things and usually, you only find out about that during the development process. Starting by writing most things together and then ripping them apart works the best for me
I've always felt that it makes more sense to have the code roughly separated into model-related (i.e. a database interface layer), processing-related (if needed), api-related on the backend, and user interface components. Not all these rough areas of concern makes sense both serverside and client side. In a typical system with data stored on a server and a fat client, I usually find that having a "model layer" in the frontend generally just complicates things; I'd much rather just fetch data directly from the api everywhere it's needed (and possibly add some caching logic to avoid fetching the same data multiple times and avoid multiple parallel requests for the same data) rather than having to maintain and sync a mirror of the data from the server in the client. (Because even with a bloated mirror of the server data in Redux or similar; you still have the problem of occasionally making sure this data is refreshed from the server, in which case you still need caching and duplicate-request prevention).
And only use local state in the components themselves for things that doesn't need to be reflected on the server, or only as a hack to improve responsiveness of UI elements.
I somewhat agree, especially with how the JS frameworks work nowadays.
At my previous job I worked with Django (MVT, but basically MVC) and we would have the views (which would be the "C" in MVC") and those views have templates (which would be the "V" in MVC). Those templates contain html and would have separate CSS/JS files related to this template, or worse, the css/js would be in one file for all templates in the project.
This resulted in annoying bugs from time to time, where css classes were duplicated/adjusted that would break things in other places. So in projects that were "mine", I would just write the css and javascript in the template file itself. So the HTML, CSS and JS would all live together. If the CSS/JS was getting too large (imo), I would consider moving it to a new file with similar naming.
I still like the backend to be separate though, especially because there might be complex business logic which could be large, views that should serve as and API endpoint for the outside world, editors need to understand syntax in multiple languages in the same file and some other reasons. I've started programming with PHP, where I would also just write backend code in the same file as the frontend, but once separating this, I liked it way more.
Most JS frameworks are very different compared to a framework like Django, so I understand and accept things are different when I work with them (barely). I think JS also makes it easier to not apply SOC because everything is the same language, but that might just be me.
If you have to make a change in 15 places to update one thing, separation of concerns is the least of your worries.
Separation into "backend and frontend" is a separation of concerns taken to extreme. With modern UI development "Model" just resides on your backend and is completely separated from "View" by network layer. And BTW GraphQL is essentially designed as an efficient transport protocol for models.
This is the way. It reminds me of the midwit meme. I've found that starting with the Vertical Slice architecture from the start lets you build velocity and then you can use abstractions you experience pain from not having them from the start.
Actually you know what else I just realized, this kind of thinking applies to people's jobs in the company too. Like it's usually better for a software dev to be fullstack rather than siloed strictly frontend or backend or whatnot. That way they can observe the requirements of both sides
MVC !== Separation of Concerns
Good critique of MVC, centralized state, and traditional centralized CSS - and I can somewhat agree with those critiques. It's totally valid to consider how horizontal or vertical you want your teams and architecture to be, especially as the tooling makes it easier to go vertical.
I would point out that individuals with both strong UI skills and DB skills are uncommon in the industry, so in order to work with the skills that people have, it still makes some sense to build your architecture somewhat horizontally. This becomes increasingly important with scale and complexity. It's hard to find people who are skilled in UI layout and also DBs. More so when you get to cloud infrastructure.
I would also clarify that "separation of concerns" is a broader concept than the patterns you take issue with. As you pointed out at 1:12, React allows you to separate things as you choose - and that is still separation of concerns. Every time you create a React component you are encapsulating some set of concerns and separating them from the rest of the application.
4:03 "How do you know that you can delete that class safely?"
preach. I'm gunna quote Theo on this cuz as a junior I'm not certified to say anything like this lol
If your separation of concerns doesn't separate your concerns then you've picked the wrong separation. You haven't undiscovered gravity. 😂
completely agree. don't think categories. think relationships.
Before watching this video I honestly thought the "separation of concerns" was just a design / architecture technique that you apply on a case-by-base basis. I never really thought of it as a core of software because it has no effect on how the actual computer hardware does its processing. I thought it's just a way humans can use to better communicate a problem. If applying it to a certain degree in your project makes the problem worse to understand for your team, then you don't do it.
---
8:32 "We should start separating stuff when we have problems": I've been doing that with my team for years now. Maybe it's because my projects involve a lot of short term contracts (so people are context switching or even turning over between teams often), so I'm always looking for whichever code or system is easiest to onboard for and maintain.
A lot of the times, starting with a highly split codebase detracts from being easy to maintain. Whenever we have a new feature, we try to implement it in the least parts of the code as we can, and we split only if:
- Some other component or team will import it
- The feature itself is turning into an un-readable mess and we determine splitting it is worth the added maintenance of another bit of codebase floating around
- Because like what you mentioned with the CSS, a lot of times, we can fix the un-readable mess by simply deleting the half (or more) of it that we no longer use. If we deleted something important, our automated tests should fail, and if the tests didn't fail, then we add a regression test.
- Someone shows me an actual performance benchmark with numbers or calculations that show we cannot hit runtime performance targets with the "monolith"
---
The only time I saw the separation of concerns or model view controller (MVC) really make sense was in a geospatial app. Each one of model, view, and controller mapped directly to something that you could conceptualize. The "model" was the positions or shapes of all the things your miniature Earth had. Each "controller" associated with a way to edit your model, like adding a car to a road, giving a flight path for an airplane, etc. The "view" literally mapped to a way a user could look at your miniature Earth stored on the server: you could pick from a 2D map, 3D camera view, a table of all the things that were on your virtual Earth with their latitude/longitude.
If you're only seeing your app with basically one thing (like a web page and an app that's basically just the web page wrapped in something else), then yeah I agree you can have a discussion to not follow a "perfect" MVC.
Correct me if I'm wrong but Separation of Concerns is not a specific programming pattern, but more of a principle that advocates for modularization generally. I'd argue React and Vue aren't doing away with Separation of Concerns, they're just using components as the abstraction and boundary between things rather than model/view/controller. It's the same principle, different mental model.
SoC makes sense in a monolithic application like the Linux kernel or a word processor. Web development seems to be in effect a duplication of concerns. Now you have MVC on the back end and MVC on the front end. No wonder there's so many problems.
I agree that "Separation of Concerns" shouldn't be the default. But it's a really overloaded term, and there are great places it is used. A concrete example that I just came across:
In our back-end we were generating a bunch of invoices every month to send to our clients. The simplest way to get this working is to: do a fetch of active clients from the database, loop over those and call the API of the billing service to actually create an invoice. This coupled a few concerns together, and was fine initially, but we outgrew it.
We wanted to be able to tell what invoices *would* be posted next month. So we separated the concern of "determining how to invoice our clients" from "actually invoicing the clients via an API". This is a case of 'separating concerns' but is quite far removed from what this video is talking about. Hence why I think the term is overloaded, so blanket statements will trigger or resonate with different people for different reasons.
Still, it's a good video on where Separation of Concerns in front-end may no longer be the best way to default to do things.
Modern React it's like PHP in mid 2000
I see this to a point. Especially on the front end. Coding salesforce components after working in react for a while feels like a giant leap backwards. css in separate files, templates for HTML, javascript for all the logic. bleh.
I still like separating the UI at least a bit. Display stuff goes in the component (templates, CSS, javascript), data query/api calls in a module, other shared logic in other modules. Rule of them is that if it's not going to be used anywhere else, keep it in the same file.
Amazing how I came to the same conclusion coming from an entire different background and experience (native mobile apps development)
Separation of concerns is NOT about separation by type. It's about separation by behaviour. It's about the Unix Philosophy. Do one thing and do it good. Sad that very few get it.
React separated concerns by its core. That's why React can be used for web, mobile, server and even video generation
You are skipping elephant in the room: MVC is a backend theme. And it's pretty basic. You will do something like domain driven (smaller apps), some repository patter for the model and some lean controller. Views will live in different place becouse you are using template inhretance or they will not exist (json). So you have some custom controller and some repository for querying the dB, that's all.
I would say the pattern is more valid in traditional software development than web but still has a place in web. As with anything (languages, platforms, operating systems, libraries, frameworks, etc.) your mileage may vary as each team, codebase, and app complexity varies widely. In other words, don't assume a one size fits all mentality for anything.
I started learning go with htmx the moment server components come out.
I'd rather build like that than use server components
This is why just spaghetti code all frontend and backend stuff into the Linux kernel into a single file. Who needs an OS.
Nonsense. No one is advocating for the removal of all separations. Strawman arguments seem appealing at a glance, but that's not the same as being correct.
Different responsibilities should be separated, as should distinct layers of abstraction, but we shouldn't be separating code that's tightly coupled just because it runs in different places or carries out a different type of operation.
In the MVC case, they may be different layers, but there's no abstraction between them. The model, view, and controller all must change together. They all must know intimate details about each other. Separating them introduces headaches because it doesn't actually hide anything from you. Instead, it forces you to go digging around in even more code to find the logic relevant to your current task.
If you can ever update the view without visiting the controller, it's by sheer luck. But even fixing a bug that exists purely in the view will often require you to read the controller anyway, just to determine that there's no bug on that side.