Yesterday I posted this short post on the various social media sites I’m on:
We really don’t make enough of the fact that you don’t need JS to make a nice website. Just HTML and CSS.
And, whatever most programmers say about them, HTML and CSS are absolutely much more accessible to learn than JS ever has been or will be.
The response was mostly positive, ranging from enthusiastic agreement to people expressing surprise because they genuinely thought JavaScript was a hard requirement for making a website.
But it also drew some criticism, mainly from programmers who claimed that HTML and CSS are more complicated than JavaScript.
I’m sure they both feel more complicated to many people, but this is not because of the inherent complexity of CSS or HTML. Instead, in my experience, it’s almost always because of conficting mental models.
Also, unless you have experience teaching or training a variety of web tech (HTML, JS, CSS, SVG, etc), you likely don’t fully understand their relative learning difficulty.
Basing your assessment of which is harder on your attempts to teach yourself is especially unreliable as you aren’t an unbiased observer of your own actions or progress.
It’s hard for you to know if any given technology is hard or if you were just unlucky by stumbling into a particularly bad entry point for what you’re studying. Getting into a field with the wrong mental model means you have to first unlearn a bunch of crap before you can actually learn.
If you’re unlucky enough to start at something with the wrong mental model, it’s always going to be a struggle until you actually do the work to unlearn it. This is very hard to do on your own because we generally aren’t aware of our own worldviews.
Comparing the relative effectiveness of tech you don’t fully understand versus one you do is always going to favour the latter and does not accurately reflect the capabilities of either.
CSS vs JS is a case in point. JavaScript’s complexity tends to come from systemic interactions between language structures. For example, adding promises and async functions made the entire language more complicated because it adds a new dimension for how JavaScript structures interact with each other.
Whereas CSS complexity tends to come from interactions in the DOM. (Generalising a bit, but roughly.) The cascade, selectors, inheritance, and overall rendering are all integrally tied to the DOM. Ancestor and descendant nodes exist in a single rendering space where they interact with each other in ways that’s impossible to understand if you only have visibility into one and not the other. The complexity and predictability of most parts of CSS is directly proportional to the complexity and predictability of the DOM you’re working with.
The whole DOM, not just the segment you’re looking at.
If you come at CSS with a JavaScript-oriented world view in an environment where you don’t control the DOM you’re basically fucked as a learner and CSS will feel unpredictable and super complex.
This is why it’s generally a bad idea to teach a beginner a component system before HTML or CSS. The purpose of components – whether it’s web components or React – is to abstract away the DOM. Limiting your visibility into the DOM as a whole is what it’s for. Learning components first, then approaching CSS through the lens of the component model means you’ve just turned CSS into a black box system. Every action will have unknowable interactions and consequences. This is fine (sort of) if you already know CSS. You have the tools to dig in and discover why, say, position: sticky isn’t working for a particular component.
But to somebody learning web development for the first time, it makes CSS feel like chaos incarnate. Everything is unpredictable.
This is why you should always go back to basics when trying to learn HTML or CSS, especially if you’re an experienced JS dev unfamiliar with the two languages. Don’t try to learn them within your chosen component system.
Instead start with basic HTML and a style tag. Or go with a Codepen as Jen Kramer recommends. Make sure you have full visibility and understanding of the whole DOM-representation of the HTML in the browser during each step. Slowly build up the complexity of what you’re trying to accomplish.
Then, once you’ve got a handle on a particular aspect of CSS, you go and use it in a component.
It’s not easy – unlearning a mental model is always hard even before you get to the actual complexity of learning something new – but it’s generally going to be simpler than trying to learn CSS from scratch within the confines of a component-based system.
(The above was edited and expanded from a thread on Mastodon.)