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

@fallenpentagon1579

8 ай бұрын

Its a pointless principle. It can be interpreted as anything making it 100% worthless

@joelv4495

8 ай бұрын

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.

@moodynoob

8 ай бұрын

​@@fallenpentagon1579spot on

@guilhermeprezzi7783

8 ай бұрын

ITS ALL ABOUT THIS!!! Where is the ultralike button? Man, all is about balance in programming. This is why define a senior enginneer!

@pistonight

8 ай бұрын

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.

@EraYaN

8 ай бұрын

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.

@joaopslins

8 ай бұрын

> 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.

@muhwyndham

8 ай бұрын

>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.

@EraYaN

8 ай бұрын

@@muhwyndham that is a correct use of SoC tho. The most basic one being kernel space vs user space and the separation between them.

@Ali009Ahmed

8 ай бұрын

@@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.

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!

@Pictor13

7 ай бұрын

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.

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.

@neociber24

8 ай бұрын

Yeah, unit tests and e2e test make easy to change things independent lf your architeture which makes refactor easier.

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.

@Voidstroyer

8 ай бұрын

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.

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.

@codedusting

8 ай бұрын

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).

@CottidaeSEA

8 ай бұрын

@@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.

@codedusting

8 ай бұрын

@@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.

I separate my concerns by never building the front end… leave that new age jazz to the kids

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.

@florquee3689

8 ай бұрын

true, and it is a hassle to maintain and develop on it in the long run

@alexandrerivest123

7 ай бұрын

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.

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.

@JakeLuden

8 ай бұрын

Spot on. MVC works great in my company’s dashboard site we’re building.

@TheJubeiam

8 ай бұрын

Theo does not know this, but testing is easier with MVC, or just good separation

@cbn1362

8 ай бұрын

It's also increases testability, instead of a god function that does everything.

@Rust_Rust_Rust

8 ай бұрын

​@@TheJubeiamTheo does not like testing either.

@TheJubeiam

8 ай бұрын

@@Rust_Rust_Rust exactly

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.

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 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.

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.

If you have 7 layers of abstraction, it's MVCCCCCCC

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 🤷‍♂

@michaelfrieze

8 ай бұрын

Theo isn't against tests though.

@ehutch79

8 ай бұрын

@@michaelfrieze kzread.info/dash/bejne/jHt_qcRqYJyTeZc.htmlsi=rmjV695faLMLl0zA

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.

“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

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.

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.

@moodynoob

8 ай бұрын

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.

@RoflMcCopter

25 күн бұрын

​@@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.

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.

@Godalming123

8 ай бұрын

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

@elie2222

8 ай бұрын

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.

Wot. Are you hating on MVC or Separation of Concerns? Or both? I think you should read the wikipedia on Separation of Concerns for a definition. You're still separating your code logically. You're just not doing strict MVC stuff. Am I not understanding this video? SO confused.

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 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.

@karaloop9544

8 ай бұрын

Love how you phrased the distinction between people wiring data and people making beauty.

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.

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.

@Atmos41

8 ай бұрын

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.

@deado7282

8 ай бұрын

​@@Atmos41Why do i need oop or MVC to test?

@karuresu

8 ай бұрын

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.

@Fernando-ry5qt

8 ай бұрын

@@deado7282 You dont actually...

@efkastner

8 ай бұрын

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”

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

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

Personally I'm a big fan of vertical slice architecture and focusing more in coupling and cohesion and balancing those

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.

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

@firasrabaia

8 ай бұрын

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'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"

@90nop

8 ай бұрын

😊😊😊😊😊😊

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

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.

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.

separation of concerns shows the concerns of separation

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.

The issue with CSS is a tooling problem. There is no technical reason why we can't check for unused/not existing classes.

If we have an edgecase where we have data which needs to be rendered differently depending on a specific package, does such a seperation make sense?

Separating your code can make it WAY more testable

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.

@karaloop9544

8 ай бұрын

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.

Omg spagetti code here we go again xD We are go back to dark 2005 PHP age

@spicynoodle7419

8 ай бұрын

echo 'welcome back!';

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've got a problem where I see the view as data. I was on a project where my edit forms were so formulaic that I was thinking of how I could make database tables storing how the edit pages would work and turning those into one edit page. I could never meaningfully grok MVC.

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.

Grandpa's off his meds again

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.

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.

If your separation of concerns doesn't separate your concerns then you've picked the wrong separation. You haven't undiscovered gravity. 😂

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.

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.

If you have to make a change in 15 places to update one thing, separation of concerns is the least of your worries.

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

In 3-5 years Theo will cause drama by suggesting that we should separate by concern.

@grezxune

8 ай бұрын

He's been around the block enough now. He's playing the long game. Job security in the making!

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/ ...

@darylphuah

8 ай бұрын

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.

When you do a proper server side render MVC shines the most. It do not appplies to component based architecture.

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.

“Everything should be made as simple as possible, but no simpler.” - Albert Einstein This video made me think of this quote.

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.

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).

@Voidstroyer

8 ай бұрын

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)

This is a very applicable video for what I'm working on right now. I'm working on writing a more generalized GUI library tin my game to replace all the explicitly written stuff and make it easier to add windows/menu/etc. For the most part it's a big gain and new windows/etc are much easier to add and ''attach'' features to, but making it a goal to have the GUI library be almost entirely agnostic of how things like rendering and input are handled is quite difficult. I'm just now trying to add support for keyboard input into textboxes, and while I think I pretty much have it figured out, it WOULD be so much easier to not try and pass input handling off to the GUI library and instead just handle those cases individually outside of the library itself in the actual game code. I'm still not entirely sure if I'm happy with how I decided to implement this feature, because it feels too much like a ''blackbox'' where unseen things might be required for things to work properly or cause things to go wrong.

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.

@RaZziaN1

8 ай бұрын

Seems like you don't understand separation of concerns. You used it wrong.

it s time for those backend guys learning css and tailwind

I think my case is a good one, I have a website builder where you can define render plugins for different frameworks like html react vue etc, there on some layer its good to have a seperate render plugin so the bulk of the code is framework indipendent (you can still have pure react etc components)

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.

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.

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.

That shirt is a compression algorithm's nightmare.

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

I have few problem , the get image function is abstract if properly with docs and types does not matter . I into ios development , there I found SoC easier for me to view the metal model of the app . Everything from state management or api struts were easier , because I know where they are . View past version also becomes much easier . Big problem is typescript does not have sound types . Most of time types acts as docs thus separation does not matter that much

I like to think about SoC in terms of function. Like my css should do just one thing style my page, HTML should just define the page. But I think they should be colocated in terms of syntax (e.g. Tailwind). The same rule applies to backend APIs as well there is a Nuxt module called server-block-nuxt and it allows you to define API routes inside your SFC and at run/build-time it gets pulled out of there and becomes an actual API route. Colocated in syntax separated in function.

I think for a proper critque of seperation of concerns you need a Brian Will style multi year multi hour video series.

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

I don't get that point when you said normally the data structure is defined by user interface. Can someone elaborate that for me. Thank in advance

There is a phrase that summarizes this, maximize cohesion minimize coupling, there are patterns that helps to achieve that goal, if you really want to sabotage your project then yes put everything in one place eagerly and mindlessly

To be honnest, if you are having to go through 7 layers of "abstraction", it's not about SoC, but just bad architecture.

I agree with the specifics of what Theo is saying, but I use "Separation of Concerns" to describe separating domain concerns, and colocate those things based on type. Is there better language to describe this? Or is "Separation of Concerns" just one of those ambiguous phases that means different things to different people?

You may be on to something here. It's been quoted that every programming design problem is solved by adding one more level of indirection. Unfortunately, each level of indirection in itself creates new problems: more complexity and less clarity. I started my programming life at the lowest and most direct level: assembly. Then I followed the herd to the heights of uber-over-engineering: extreme abstraction, indirection, layering, partitioning, and separation. Now I am drifting back towards the very beginning: directness and minimalism. It seems that most of the vaunted "architecture" that arose over the decades rarely pays out on the promises it makes.

What if you have mobile app along with the webapp? SoC would make sense.

@cocoscacao6102

8 ай бұрын

It isn't about what makes sense. It's about reaching out to the insecure public and give them conformation that you don't need to learn more. That's what gathers clicks and views, my friend.

How do you know css class is not used anywhere? It will always have dim text color and often yellow/red underline and tooltip that directly says this class is not used anywhere (and thus can/should be safely deleted).

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.

I do feel like Separations of Concerns is good and bad. Good because it’s like a clean desk, but bad because it’s like 100 clean desks.

async function Images(){ const data = await getImagesForUser(); return } M : const data = await getImagesForUser(); V: C: everything else (mostly abstracted by Next) Weather you want it or not you still have an mvc

@michaelfrieze

8 ай бұрын

One of the core innovations of React was that they made the View a function of your application's state (often represented as v = f(s)) and encapsulated this idea around components. This is what react is "concerned" with. You can do mental gymnastics and try to see react through your MVC lens and structure your code around it, but the reality is that the react team is not guided by MVC. If you ever use tailwind and shadcn-ui, you will be doing stuff like this in render: onExpand(organization.id)} className={cn( "flex items-center gap-x-2 rounded-md p-1.5 text-start text-neutral-700 no-underline transition hover:bg-neutral-500/10 hover:no-underline", isActive && !isExpanded && "bg-sky-500/10 text-sky-700", )} >

Can someone tell me what browser does Theo uses? Is it styled firefox or smth?

the word of the year for react development has got to be 'co-located'

The key takeaway here for me is that this sort of design decision needs to be made on a per project basis. There is no one size fits all solution for designing code bases of varying sizes and types in a manageable way. Strategies for managing complexity need to be adapted based on the unique characteristics of each project.

What if I don't use node for backend ? Let's say, I have a friend who writes in java, and we have to make an app together. What do you recommend ?

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

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.

Genuinely curious, is there a model you suggest using instead of the mvc? I have not been taught any other model. Btw could you make a video on this?

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.

_[cries in Laravel]_

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.

@Channelcustomization832

8 ай бұрын

The way to avoid reinventing the weel is to create abstractions. Seperation of conerns doesnt help with it.

@michaelfrieze

8 ай бұрын

But that's not really what people mean by "separation of concerns".

@ignaspan

8 ай бұрын

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.

@michaelfrieze

8 ай бұрын

@@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.

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.

“Separation of concerns” isn’t the problem so much as how web developers have historically defined “concerns”. For some reason we’ve replaced “think critically about breaking up code” with “mindlessly implement specific architecture patterns”.

@garretmh

8 ай бұрын

MVC isn’t a bad pattern. It’s a hammer and not everything is a nail.

I started learning go with htmx the moment server components come out. I'd rather build like that than use server components

I'm late to this conversation so apologise. Say I have inventory to sell, rent and hire stored modeled together in a DB. A team is responsible for the the sell part of our website (consumers like the separation of purchasing type's) To create your react components would you advocate for each team to access the db via SQL functions local to the component?

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.

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.