At best you will achieved a few smaller files. At worst you make working within the system a real pain.
Some practical reasons for separate files, off the top of my head:
In-lining JS, and CSS means enabling unsafe-eval, which can open up XSS vulnerabilities if you use any content from users or gathered from a source you don't control. You could also do the unsafe-hashes, but that's kind of a pain.
If you're not making a SPA, it would not be fun to copy the CSS to all of your files.
If you do not couple your CSS to your site, you can reuse it across many sites and have the same style. Say if you have separate site for your blog, but want it to look the same as your main site.
If you're working on a team splitting things up into separate files will avoid some merge conflicts.
Chances are they will not be updated all at the same time, so caching would speed up page load times, as the user would only have to download the changed files
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.
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.
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 :)
Actual workflows diverge significantly from the above. It's a matter of cohesion. Yes, co-locating each of the files (and only these files) in a single "component" directory can help ease navigation and discovery, but most of the time it's just easier to keep everything as cohesive as possible.
