Whenever I talk with others who are just beginning to work with pages or sites, one of the biggest things that I notice is the gap that exists in the relationship among HTML, CSS, and JavaScript and a how to model it conceptually.
The Typical Stuff
The majority of you guys are already familiar with the three components:
- HTML is the language used to markup the data that you want to display in the browser.
- CSS provides the facilities for making the data look a certain way.
- JavaScript is a way to make things happen on a page.
Am I right? None of these are wrong, but I’d consider this to be a high-level description of what each language does. Though this isn’t necessarily wrong, it leaves something to be desired. I’d even go as far to as to say that getting a clear mental model of how these three things work can make you a better developer.
Think Different
There’s a better way to think about the relationship among HTML, JavaScript, and CSS. Rather than thinking of them as three things used to make up a page, think of them for what they do. Generalize the definitions above:
- HTML is for describing data
- CSS is for presenting data
- JavaScript is for making things happen
Make sense? Each language serves a single purpose in the context of a page. When you begin to think this way, it provides a way for you to make decisions on where certain things should go.
Decisions on Data Description and Display
For example, say you’re trying to determine if text should fill the width of the container (or the page) or should only take up the space necessary to display the width of the sentence. You’re making a decision on the description of the data so you’d use HTML.
Specifically, if you want to fill the parent element, use a paragraph – it’s block level and fills the width of its container; otherwise, use a span element – it displays inline and fills only the width of the sentence. The thing is, CSS supports display:block; and display:inline; such that is can be achieved that way, but I argue that nine times out of 10 you don’t need to use CSS.
Ultimately, this leads to writing cleaner HTML and cleaner CSS. You’re allowing each language to serve the purpsoe for which it is intended. This makes it easy to determine where a certain line of code should go based on what it will be doing.
The Joys of JavaScript
One of the biggest challenges that I hear from budding web developers is that they know JavaScript “does cool stuff” but they don’t really understand the role that it plays within the context of development.
My simple explanation is that JavaScript is responsible for making things happen. That’s it. Easy, right?
Technically speaking, it deals with events (which is really just a word for ‘something happened’ :)). This means that whenever a user presses a key, scrolls the mouse wheel, moves the mouse around the screen, clicks on some text or an anchor, then JavaScript has the ability to handle and respond to it.
In the context of development, you can think of it like this:
If the feature or function you’re planning can be described using a verb, it’s likely that JavaScript is the answer.
If you’re wondering “how do I make the page do this whenever the user does that?” then JavaScript is the answer.
Make sense?
Just Because You Can, Doesn’t Mean You Should
The thing about web development is that you have a lot of control over how you write your code. You can put styles inline on the page and nest JavaScript throughout the entire HTML document. No one is going to know and it won’t break anything, but this quickly becomes a maintenance nightmare.
My rule of thumb is this: if the language has a file extension, it should live in its own file. This means that HTML goes in its own files and links up its associated CSS files and JavaScript files.
You’re stuck trying to find where the line of code lives that is causing the problem and the debugger (be it Firebug or Dev Tools) is having a difficult time calculating the right line number. As such, time is lost trying to figure out where the problem originated and it could have been saved should a few decisions had been made and steps had been taken at the front end of the project.
Understanding how these three components actually fit together in creating a page or a site goes in a long way in furthering your development chops: you can make better decisions on what language should handle what function, you can write cleaner code, and you can organize your projects in such a way that they won’t be such a mess months into development.
Of course, it’s much easier to say all of this than to do it. At least aim for it.
Paul says
Good stuff, but one needs to be careful about the number of files that get linked to since it raises the number of HTTP requests (when the browser needs to download a file) which can really slow a site down on mobile. Can be a great idea of combine and minify your CSS/JS for deployment.
Tom McFarlin says
Totally – I’ve even shared some stuff about this before:
– Head JS For Faster Performance
– CDN JS For Cloud-Hosted JavaScript Libraries
– JavaScript Minifcation: Why and How
Dig your thoughts – thanks for the comment!