CHAPTER 1 Modern CSS Architecture and Front-End Development
We could attach all our styles and bind all our JavaScript to that one ID,
and still access the data attribute as normal. This would work, and it is far
more concise, but it’s incredibly unreusable. We have attached far too many
functions to one overly specific selector which means our CSS is not very
DRY (don’t repeat yourself) and we won’t easily be able to make discrete
changes to that HTML (like removing JavaScript binding, for example).
The single responsibility principle is tried and tested, and keeping your
code’s tasks granular and discrete makes your application far more flexible,
as well as much faster to work with.
Takeaway: HTML is easier to update than CSS is to refactor. If a piece of
markup has to do five jobs, it needs five hooks, be they classes, data attri-
butes or anything else.
In Closing
In this whirlwind look at more modern approaches to front-end devel-
opment, you have hopefully picked up a thing or two, as well as realized
that, despite their intentions, the things we’ve been doing for years need
constant re-evaluation. Our valiant pursuit of clean markup and semantic
classes and IDs has served to help no one, and often hindered us. To sum-
marize this all-too-brief chapter:
- Change can be good, it’s going to happen and you should learn to embrace
it, and even forge your own methods to stay ahead of the curve and
lead the next wave of Web standards. - Code needs to serve different people in different ways, so make sure you
write it with each stakeholder in mind. No one but developers cares
about your actual code, so write it for them. Users and clients just
want fast, robust, reliable and scalable websites.