11

I hear/read all the time that it is cleaner to keep your js, html and css separated. Supposedly it makes it more easy to maintain, debug. Supposedly it is more efficient, because it allows caching/minifying css and js files.

As far as I am concerned, using web frameworks (Django, Rails, ...), javascript templating libraries, ... I tend to split quite a lot a single html page into multiple reusable templates - some kind of widgets if you wish. For example I can have a news feed widget, a select multiple widget, etc ... each of them having a consistent layout throughout the different pages, and each being controlled by its piece of javascript.

With this organization - which seems to me as clean as it can get, maximizing reusability - I have trouble to understand why it would be simpler to keep all js and css in separate files. I kind of think it would be so much simpler for example :

in the select multiple widget file

  • html
  • basic css layout
  • control of direct interactions and UX enhancements with a bit of JS.

I think that way it is more reusable, much more maintainable, because you don't have to scroll through a fat js file, then switch to and scroll through a fat css file, switch again to your html file ... back and forth.

So I'd love to know how you guys organize your code, if you stick to the separation that is usually recommended.

  • Are there really good reasons to do so ?
  • isn't it that the guides on the web usually assume that you won't use any fancy tool (in which case I'd love to get more up-to-date online readings for best practices) ?
  • Is it just a matter of preference ?
Improve this question
9
  • 2
    The principle you allude to is called Separation of Presentation and Content.
    – Robert Harvey
    Dec 6, 2011 at 16:47
  • 8
    Keep in mind that if you don't separate out to files then your users will be downloading the embedded HTML and CSS on every page load instead of downloading it once and caching it.
    – Nicole
    Dec 6, 2011 at 16:57
  • @RobertHarvey : ok good reference ... But the only reason listed there for separation content/presentation is improving machine readability. However I think it doesn't matter when widgets are added to the page with JS. The basic html doesn't contain them anyways !?
    – sebpiq
    Dec 6, 2011 at 17:00
  • 1
    @Renesis : That's a big drawback, true ... however with Django for example it is fairly easy to collect your js and css from multiple templates and merge them into a single file.
    – sebpiq
    Dec 6, 2011 at 17:02
  • 2
    Meaning, you can serve a normal web page, a mobile web page and a printable page, without having to write each page by hand from scratch, just by tweaking the presentation (i.e. the CSS).
    – Robert Harvey
    Dec 6, 2011 at 17:05

4 Answers 4

Reset to default
5

I maintain this structure

For each page or control, I give it a folder for it's html page (or aspx, or php, etc). In that folder is also folders for js, xml, images and css files. Those are for page/control specific, not shared resources.

In the site root, are also js, xml, images and css folders, each of which contains site wide resources.

The site wide js and css files are rolled up server side and returned as a single js file. The page specific ones, as there is usually only one per page, are left alone.

This organizes my resources as to their scope. And while I may have a dozen js files in the root js folder, they will be returned as one js resource by combining and minifying them server side (and caching the result).

I also am not loading resources specific to pagex when I'm on pagey. The only "waste" might be in the site wide resource file, but since it's cached, and many of the resources WILL be used in multiple places, it's more efficient.

Improve this answer
1
  • 1
    Sounds good ! I hadn't thought of simply grouping the files in separate folders, and collecting them for serving ! It addresses all the problems - caching, SoC, ... - while allowing encapsulation. Great !
    – sebpiq
    Dec 6, 2011 at 18:16
2

generally the convention is to have separate files for JS/CSS/HTML to maintain a separation of content, presentation and behavior. However, if speed becomes an issue then anything goes.

Improve this answer
2
  • 1
    seperate files actually improves speed rather then degrading it :\
    – Raynos
    Dec 6, 2011 at 18:38
  • Smaller amounts of CSS and JS in the HTML file is one page request instead of three page requests, which might be better for serving a large number of pages very fast. Or at least combine them as needed - code.google.com/speed/page-speed/docs/rtt.html
    – Bratch
    Dec 6, 2011 at 21:09
1

in the select multiple widget file

  • html
  • basic css layout
  • control of direct interactions and UX enhancements with a bit of JS.

I have a organization tool (trinity) which promotes you do that.

Except that widget file is split into 3 small files, HTML, CSS and JS. This means you have your seperate files but they are still linked.

This avoids the problem of fat files but still gives you seperate files.

So simply put seperations of concerns does not mean you should have one big HTML/CSS/JS file. You should have multiple triplets of <HTML, CSS, JS> for all your re-usable encapsulated code

Now there's nothing wrong in having all of these in one file as long as they are clearly seperated.

So a widget that looks like

<div id="wrapper">
  <style scoped> CSS code </style>
  <script> JS code </script>
  HTML code
</div>

Is fine, and great. Except having everything in one files makes it far too easy for a maintainer to start mixing and matching the CSS/JS/HTML.

It makes it far too easy for it turn into spaghetti over time.

The main reason people promote seperate files is two fold

  • seperate downloads. As soon as you copy and paste any css/js code into multiple "widgets" you need to factor it into it's own file.
  • Aggressively prevends spaghetti code by not relying on the author to keep their css/js/html nicely seperated in a single file
Improve this answer
2
  • Yep ... so same suggestion as Chad ! And indeed I immediately tried it, and I am sold :) This is so much cleaner like that ... Your tool is for node right ? I should find something like that for Django...
    – sebpiq
    Dec 7, 2011 at 12:43
  • @sebpiq it's for node, but I'm porting it to the client. It's also alpha and I'm heavily working on making it an entire HTML/CSS/JS organization platform, including client/server code re-use. I personally doubt you would find anything like this on other platforms, you can port it though o/
    – Raynos
    Dec 7, 2011 at 14:45
1

Its a good practice to seperate html,css and js as it makes managing your website easier.

When you’re starting out you may only have a main index.html and a single styles.css file, but more than likely as your website grows, you’ll end up with multiple scripts and stylesheets that are specific to an individual component or endpoint.

Using separation:

  • Separate JavaScript can be Reuse it on other pages
  • Separate CSS can be Able to give the site a new fresh look easily along with reuse
  • Separate HTML can be Focus on content not look.

Also should be mentioned CSS/JS could be cached if used on multiple pages on your site

Improve this answer
1
  • ... and there are many "build tools" which can gather JS and CSS assets from (not-deployed) individual files to create the actual files that are deployed ... gathering the assets, removing (or detecting) duplicates, minifying and so-on.
    – Mike Robinson
    Apr 21, 2020 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.