3 ms·

> It also encapsulates your Python, HTML, JavaScript and CSS into one file. After years and years of hearing people much more knowledgeable than recommend sepe

> It also encapsulates your Python, HTML, JavaScript and CSS into one file. After years and years of hearing people much more knowledgeable than recommend seperation of concerns and me actually following it, I find this "feature" horrifying. So my honest question to you, people who used similar frameworks, is this really helpful? How is this not confusing and not a source of undebuggable code?

samwillis 4y ago
I have a blog post in the works to go into depth the thoughts about this. The gist though (copied from the introduction): -- Proximity of related concerns is as important as separation of concerns. Whilst it is important to keep your backend logic, front end JavaScript, HTML, and styles separate, it is also incredibly useful to have related code in close proximity. Front end toolkits such as Vue.js, with its single file components and newer "utility class" based CSS frameworks such as Tailwind, have shown that keeping related aspects of a component in the same file helps to reduce code rot, and to improve the speed at which developers gain an understanding of the component. -- Really the intention is that you can keep small parts of CSS/JS close to where it is being used. Larger functionality, particularly anything reused, you would still break out into separate files. The creator of htmx refers to this as "Locality of Behaviour", they wrote a good post on it (https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/)
nisegami 4y ago
If you take a "concern" to be domain-defined rather than architecture-defined, then this approach separates concerns effectively.
upupandup 4y ago
> After years and years of hearing people much more knowledgeable than recommend seperation of concerns You should never ever just trust experts or popular advice at face value. You have to test it out. If you are not doing a large project with many people, you certainly do not need to have files all over the place.
acjohnson55 4y ago
Separation of concerns is a really important concept, but I also think it's very often misinterpreted. The real question is where are the inherent couplings within a system? In places where they exist, collocation is a very good thing. Separation of concerns is best applied parts of the system with low inherent coupling. In the case of web UI, the controller logic, document structure (HTML), presentation (CSS), and client-side interaction logic (JS) often have very tight inherent coupling, to the point of needing to relate to each other through shared identifiers (e.g. DOM classes, variables). Collocation generally allows you to scrap boilerplate declarations and work on an entire UI component in one screen of source code, rather than bouncing between tightly coupled files. In my experience, this is a huge productivity boost and aid in understanding code other people wrote.

samwillis 4y ago

I have a blog post in the works to go into depth the thoughts about this. The gist though (copied from the introduction): -- Proximity of related concerns is as important as separation of concerns. Whilst it is important to keep your backend logic, front end JavaScript, HTML, and styles separate, it is also incredibly useful to have related code in close proximity. Front end toolkits such as Vue.js, with its single file components and newer "utility class" based CSS frameworks such as Tailwind, have shown that keeping related aspects of a component in the same file helps to reduce code rot, and to improve the speed at which developers gain an understanding of the component. -- Really the intention is that you can keep small parts of CSS/JS close to where it is being used. Larger functionality, particularly anything reused, you would still break out into separate files. The creator of htmx refers to this as "Locality of Behaviour", they wrote a good post on it (https://htmx.org/essays/locality-of-behaviour/ https://htmx.org/essays/locality-of-behaviour/)

nisegami 4y ago

If you take a "concern" to be domain-defined rather than architecture-defined, then this approach separates concerns effectively.

upupandup 4y ago

> After years and years of hearing people much more knowledgeable than recommend seperation of concerns You should never ever just trust experts or popular advice at face value. You have to test it out. If you are not doing a large project with many people, you certainly do not need to have files all over the place.

acjohnson55 4y ago

Separation of concerns is a really important concept, but I also think it's very often misinterpreted. The real question is where are the inherent couplings within a system? In places where they exist, collocation is a very good thing. Separation of concerns is best applied parts of the system with low inherent coupling. In the case of web UI, the controller logic, document structure (HTML), presentation (CSS), and client-side interaction logic (JS) often have very tight inherent coupling, to the point of needing to relate to each other through shared identifiers (e.g. DOM classes, variables). Collocation generally allows you to scrap boilerplate declarations and work on an entire UI component in one screen of source code, rather than bouncing between tightly coupled files. In my experience, this is a huge productivity boost and aid in understanding code other people wrote.