I've spent the past 5 years with various blends of SASS, CSS, CSS-in-JS, Redux, Rx, React, Material-UI and a few other bits and bobs (and several years of front end dev with other tech before that, too).

I prefer by far keeping the CSS (or SASS) separate from the rest. React's mix of JS and HTML-ish is very comfortable, but I can't say I love it more than "native JS + some kind of templating". However, I'm absolutely certain that I prefer the CSS left outside the rest. My reasons include:

- you (probably) don't have to recompile the whole JS app to get your style changes - it's much easier to see the relevant JS when you don't have to skip over CSS or lengthy class names - it's much easier to see how bits of CSS relate to one another when they're in the same file (which I'll admit can make _some_ parts of that job harder, some of the time) - when the browser's dealing with "proper" CSS, you can use the browser tools to test changes before updating the source files, skipping around the DOM, watching all the selected elements change (which doesn't always happen when you have CSS Modules style scoping going on) - code editor tooling is usually better - you don't have to remember whether you're writing your CSS in native CSS, snake-case, or JS style camelCase (I know some of the recent CSS-in-JS tech helps here, but why add a library to do something the browser already does?) - you don't need to add libraries to do something the browsers already do

I find the single file preferable because it's less clutter. Less open files in the editor, less jumping between documents, and easier to reason about in code review and when dealing with merge conflicts (since the context of the changes are present in front of you instead of in another file somewhere). If you're editing 3 components at once that's 3 files open instead of 9. The benefits of this are more noticeable when you're trying to debug a frustrating issue but you're not exactly sure where exactly it originates in the code (files open but maybe they don't all get closed as you peruse through, more .

I also find that in a well-architected application, very large components with lots of markup and styles are rare compared to compact and reusable components used to compose the more complex ones which ultimately means the more complex ones also need less styles and markup; really big components might need to exist in some circumstances, but usually it's a code smell. 1 file also means there is less uptake necessary when bootstrapping new components, you don't need to create 3 new files with matching filenames and import statements (yes, you could get an IDE or a script to do it but its just one less thing to think about with the 1 file approach).

Finally, IMO, in the case of components the distinction is more superficial than logical, breaking up a single unit into 3 highly coupled modules that cannot be imported and reused anywhere else feels unnecessary. You wouldn't break up a class with 3 large methods into 3 different modules and import those into the class module.

In the case where I do have to edit a really large files with lots of coupled logic, my editor allows me to view the same file in multiple views at different positions.

I am with you on that. I recently had to write a bunch of Vue and scrolling up and down really annoyed me. But, fortunately it is becoming a moot point a bit, at least in React world, with more focus on presentational components. Right now I am working on a project where there is a UI Kit and the application is a separate entity and I really-really like this approach. With the `styled-system` library this produces quiet sane-looking styled code. Not sure how it translates into Vue world, but I would say - make presentational components with as little logic as possible.

I really don't care.

This is one of those things that usually boils down to arbitrary personal preference, often buttressed by people working backward from their desired result to construct objective-sounding "maintainability" rationales.

Pick a style and stick to it within the project's codebase. There's no wrong answer here, except "the only right answer is the way I personally prefer". I wish we had Prettier for file structure.

Yes, and for a very mundane reason. When an application is long-lived there’s inevitably some bit rot where one layer (template, style, or JavaScript) gets removed for some reason, and one or more of the corresponding layers is accidentally left in the code. This is especially likely to be CSS.

With single file components it’s much easier to track the dependencies and rebuild / scrap chunks of code without leaving cruft around accidentally.

In over 10 years I've never worked somewhere where anyone was trying to prune unused CSS, especially in the traditional approach where you just have large .css files that become append-only.

Not until I experienced component-level CSS did I see it happen since now it's relatively trivial to see unused CSS.

i would buy this argument, because i have seen this happen with WPF/XAML (person deletes the markup and code-behind, but accidentally leaves the viewmodel), except that in the webcomponents world i would imagine you'd have all three files living alone in a folder named after the component.

How is that possible when templates, style and js live side by side in a folder dedicated to that component only?

In my personal experience, generally yes given that you are able to carve your application logic into acceptably sized components. IMO what works best is not so much a hard single-file rule, but rather a looser single-location principle. If the component's logic is massive and necessitates many files, create a folder for that component and put them all in there. If a component is this large then it can also be a helpful signal that perhaps application logic could be factored differently so as to produce more easily understandable units. If there is enough discipline and alignment amongst the project developers, then the single-location thing lets you take advantage of making big logic easier to grok by allowing separation while keeping stuff that all belongs under a single umbrella grouped together.

Apparently, either people here do not use Vue or have not read the docs.

__Vue actually allows you to split the sections into seperate files if you require it.__

Source: https://vuejs.org/v2/guide/single-file-components.html#What-...

Can't you have the code-behind in a separate tab even if it's just a different part of the same file?

i guess, but then you've got a dependency on a specific text editor's behavior. for WPF/XAML, the markup and code-behind are two separate files, so you can use any text editor you want, but VS2019 shows them "grouped" together so you can open both files at once.

> do single-file components _actually_ work better for you than having the script, markup, and styling in three separate files?

Absolutely not for me, I much prefer Angular's style of separate files living in a dedicated folder. With Vue, I also find myself constantly scrolling up and down.

I guess it depends on the components size.

Small straight forward components -> sure.

Mid-sized components -> maybe.

Large component -> No, but probably you it's a good idea to see if they can be shrunk.

But I only have played around with this tech, so no real experience.

I've found that when the components are very large, I can almost always do something better (smaller components). I've done a couple of big Vue projects now.

For me, keeping all those things even closer together (react with hooks and some inline event handlers + css-in-js or tailwind) is so much better that I have no interest in single file components.

We are currently rewriting out frontend app, so can't talk about long term experience.

I don't see much of a benefit of having everything in a single file vs. many. We are going to split them up, as soon as they become unwieldy and people ending up spending too much time reading code not relevant for the task at hand.

What I do see a lot of benefit in, is having everything in one language (Typescript in our case) instead of three and all the IDE capabilities like autocomplete, linting, refactoring, etc. that come with it. But to be fair, I haven't done frontend in a while, so I'm not up to date what the state of the art integrations for html/css/js look like in comparison.

A couple of years ago I loved SFCs in Vue. Now I hate them with a passion.

The approach only works for very small components, not for real world use cases.

If it's all contained and does not impact any other component, absolutely.

That to me is the killer-feature.

but scoping everything to the component can be done just as easily with three separate files.

Over which you have to navigate by opening, closing, switching tabs etc.

I frequently find myself overwhelmed with the sheer number of files such a convention generates.

But the strengths of the single-file approach reveal themselves when you have a lot of small components - it enables you to just glance at a file and immediately know what's going on.

Also it puts a psychological barier against large, bloated components.

> it puts a psychological barrier against large, bloated components

this is the most compelling argument for me... but i still find myself having to work with overly-large components written by others. and that's when i end up doing lots and lots of scrolling and losing my place.

i guess that's the difference. single-file components are superior iff you have good team rigor around component size.