5 ms·

Personally I've always been kind of confused by the common best practice of separating everything. React and Vue single file components made so much sense to me

Personally I've always been kind of confused by the common best practice of separating everything. React and Vue single file components made so much sense to me. I guess if I were to rationalize my position, I'd say it's because I have a hard time finding related things when they're separate. If a button or "a" tag have a special click handler, I want to know when looking at it. If it just has classes, then I don't know if that are for style or if they're for behavior. I know there are some conventions out there where you prefix classes with "js-" etc, but if you just use "onclick" then it's obvious and you don't need a convention.

tiborsaas 5y ago
It's fine if you have a few colors, but with 50+ lines of SASS/component I'd rather have them separately. > I have a hard time finding related things when they're separate. Store them in the same directory? I agree on the events/business logic that they make sense to couple with the template code.
- scns 5y ago
  And have to switch between three files back and forth?
  - klibertp 5y ago
    What? How is that a problem, why would it be something that's best avoided, and why simply displaying all three files at once in one of a million ways available is not a solution?
    - kingdomcome50 5y ago
      I don’t see any added value of separating pieces of a component into different files. The CSS, JS, and HTML are all logically coupled no matter how you organize them. At best you will achieved a few smaller files. At worst you make working within the system a real pain.
      - klibertp 5y ago
        I don't see a difference between switching between files and switching between positions in a file which is longer than a page or two. In both cases the switching is not free - unless you do something about it (like spliting panes/windows in your editor; bonus: it works for both separate files and long files in the same way!). It's also trivial (well... depending on the IDE/editor I guess) to make it open all 3 files when any one of them is opened and/or to make a command to cycle between files, similarly to how you can switch between .c and .h files in most environments. For files where the logic, structure, and styling fits on a single page - yeah, splitting it into separate files doesn't make much sense. > At worst you make working within the system a real pain. That's what I don't understand - what pain? That it's better not to work with it using nano or notepad? It simply looks like a pain I would never experience, and I'm wondering if I'm right.
        RussianCow 5y ago
        > I don't see a difference between switching between files and switching between positions in a file which is longer than a page or two. Exactly! By putting everything into one file, you give the reader the option of splitting their view if they want, or looking at the file all in one pane; with multiple files, you have to have each file open independently. Editors give pretty nice ways of navigating to specific functions/methods/points within a file these days, so traversing a large file is not really an issue IME. Personally, I don't understand the fascination with splitting everything into super small files; given the large number of files I generally have open in my editor, I'd rather look at one file with 1k lines of code than 3 files with 100-500 each. With separate files, if I'm trying to debug something that touches three different components, I need to have 9 files open instead of just 3.
        klibertp 5y ago
        This really depends heavily on how you use your editor, on its specific features. For example, you qualify the "navigating to specific definition" with "within the file", but in my editor jumping to definition across multiple files works exactly the same way as within a single file, and due to a stack of jumps that you can pop, there is usually no need to know or care in which file you are currently, or were previously. Similarly, you mention "large number of files you have open in your editor" as if that was a problem of any kind. For me, it isn't - I have 60+ files open frequently, but I have quite a few ways of searching for/jumping to a specific file, buffer, or content that I want to see, and I never need to cycle through open files or tabs. Most of the time I don't have to care if the file is open - there's literaly no difference in the method(s) of getting to a file because of its state (open or not). The differences between my and your environments mean that our preferred workflows differ, too, because what can be problematic for you can be easy for me, and vice versa. That being said, I also don't advocate "splitting everything into super small files". Splitting a file that is less than a "page or two" (I see 61 lines of code on one page, so less than 120 loc) is a mistake and should be done only in special circumstances, while files that grew larger than 500 loc should be refactored if it makes sense. Files over 1k loc have to be split. That's the policy we use at work, and I think it results in a pretty nice and easy to navigate code bases. Back to the editors, though: as long as the codebase uses a convention - any convention - consistently, you can make it nice to work with, by altering your environment to match the convention. This is where the more configurable and easier to script editors win big time - if there's something in the codebase you don't like, and can't change, you can script it out of sight and out of mind easily. Coming from such an editor, I personally don't have a strong opinion on how the codebase should be structured (which includes the lenghts of files) - I do have some preferences, but I'm not very attached to them. That's just to signal that I'm not the one of people "fascinated" with splitting files for the sake of it :)
  - tiborsaas 5y ago
    I usually split my IDE to multiple planes. A 4k, large monitor helps though :)
  - arodyginc 5y ago
    For their demo https://imba.io/ https://imba.io/ they put styles in a separate file, how so?
  - progx 5y ago
    Or up and down in one file.
- Mavvie 5y ago
  With something like Svelte, I see no reason an editor couldn't let me choose if I want to see the JS/HTML/CSS in the single file (as it is on disk) or split it up into separate editor tabs for me.
lhorie 5y ago
Personally I think it's not so much about separation of concerns/technologies per se, it's that this debate boils down to a different debate under the hood: the one about folder-by-type vs folder-by-feature[0]. The gist is that folder-by-feature is generally preferrable because it requires less context switching (in the literal sense of jumping between multiple different far away folders and scanning each for the thing you're looking for) Single file components force you to organize code in a folder-by-feature structure, to a large extent. You can use folder-by-feature structure alongside with separation of technologies, it's just not that common to see it because the tooling to support it is not quite as optimized. [0] https://softwareengineering.stackexchange.com/questions/338597/folder-by-type-or-folder-by-feature/338601#answer-338610 https://softwareengineering.stackexchange.com/questions/3385...
- cableshaft 5y ago
  > You can use folder-by-feature structure alongside with separation of technologies, it's just not that common to see it Angular is a pretty good example of this. The HTML, CSS, unit tests, and code are all in separate files, but they have the same base name and are grouped together in the same place.

tiborsaas 5y ago

It's fine if you have a few colors, but with 50+ lines of SASS/component I'd rather have them separately. > I have a hard time finding related things when they're separate. Store them in the same directory? I agree on the events/business logic that they make sense to couple with the template code.

scns 5y ago
And have to switch between three files back and forth?
- klibertp 5y ago
  What? How is that a problem, why would it be something that's best avoided, and why simply displaying all three files at once in one of a million ways available is not a solution?
  - kingdomcome50 5y ago
    I don’t see any added value of separating pieces of a component into different files. The CSS, JS, and HTML are all logically coupled no matter how you organize them. At best you will achieved a few smaller files. At worst you make working within the system a real pain.
    - klibertp 5y ago
      I don't see a difference between switching between files and switching between positions in a file which is longer than a page or two. In both cases the switching is not free - unless you do something about it (like spliting panes/windows in your editor; bonus: it works for both separate files and long files in the same way!). It's also trivial (well... depending on the IDE/editor I guess) to make it open all 3 files when any one of them is opened and/or to make a command to cycle between files, similarly to how you can switch between .c and .h files in most environments. For files where the logic, structure, and styling fits on a single page - yeah, splitting it into separate files doesn't make much sense. > At worst you make working within the system a real pain. That's what I don't understand - what pain? That it's better not to work with it using nano or notepad? It simply looks like a pain I would never experience, and I'm wondering if I'm right.
      - RussianCow 5y ago
        > I don't see a difference between switching between files and switching between positions in a file which is longer than a page or two. Exactly! By putting everything into one file, you give the reader the option of splitting their view if they want, or looking at the file all in one pane; with multiple files, you have to have each file open independently. Editors give pretty nice ways of navigating to specific functions/methods/points within a file these days, so traversing a large file is not really an issue IME. Personally, I don't understand the fascination with splitting everything into super small files; given the large number of files I generally have open in my editor, I'd rather look at one file with 1k lines of code than 3 files with 100-500 each. With separate files, if I'm trying to debug something that touches three different components, I need to have 9 files open instead of just 3.
        klibertp 5y ago
        This really depends heavily on how you use your editor, on its specific features. For example, you qualify the "navigating to specific definition" with "within the file", but in my editor jumping to definition across multiple files works exactly the same way as within a single file, and due to a stack of jumps that you can pop, there is usually no need to know or care in which file you are currently, or were previously. Similarly, you mention "large number of files you have open in your editor" as if that was a problem of any kind. For me, it isn't - I have 60+ files open frequently, but I have quite a few ways of searching for/jumping to a specific file, buffer, or content that I want to see, and I never need to cycle through open files or tabs. Most of the time I don't have to care if the file is open - there's literaly no difference in the method(s) of getting to a file because of its state (open or not). The differences between my and your environments mean that our preferred workflows differ, too, because what can be problematic for you can be easy for me, and vice versa. That being said, I also don't advocate "splitting everything into super small files". Splitting a file that is less than a "page or two" (I see 61 lines of code on one page, so less than 120 loc) is a mistake and should be done only in special circumstances, while files that grew larger than 500 loc should be refactored if it makes sense. Files over 1k loc have to be split. That's the policy we use at work, and I think it results in a pretty nice and easy to navigate code bases. Back to the editors, though: as long as the codebase uses a convention - any convention - consistently, you can make it nice to work with, by altering your environment to match the convention. This is where the more configurable and easier to script editors win big time - if there's something in the codebase you don't like, and can't change, you can script it out of sight and out of mind easily. Coming from such an editor, I personally don't have a strong opinion on how the codebase should be structured (which includes the lenghts of files) - I do have some preferences, but I'm not very attached to them. That's just to signal that I'm not the one of people "fascinated" with splitting files for the sake of it :)
- tiborsaas 5y ago
  I usually split my IDE to multiple planes. A 4k, large monitor helps though :)
- arodyginc 5y ago
  For their demo https://imba.io/ https://imba.io/ they put styles in a separate file, how so?
- progx 5y ago
  Or up and down in one file.
Mavvie 5y ago
With something like Svelte, I see no reason an editor couldn't let me choose if I want to see the JS/HTML/CSS in the single file (as it is on disk) or split it up into separate editor tabs for me.

lhorie 5y ago

Personally I think it's not so much about separation of concerns/technologies per se, it's that this debate boils down to a different debate under the hood: the one about folder-by-type vs folder-by-feature[0]. The gist is that folder-by-feature is generally preferrable because it requires less context switching (in the literal sense of jumping between multiple different far away folders and scanning each for the thing you're looking for) Single file components force you to organize code in a folder-by-feature structure, to a large extent. You can use folder-by-feature structure alongside with separation of technologies, it's just not that common to see it because the tooling to support it is not quite as optimized. [0] https://softwareengineering.stackexchange.com/questions/338597/folder-by-type-or-folder-by-feature/338601#answer-338610 https://softwareengineering.stackexchange.com/questions/3385...

cableshaft 5y ago
> You can use folder-by-feature structure alongside with separation of technologies, it's just not that common to see it Angular is a pretty good example of this. The HTML, CSS, unit tests, and code are all in separate files, but they have the same base name and are grouped together in the same place.