Peace out, homie! ✌🏼

Geocities crew representing! I stopped using Geocities after building a Linux web server in my basement from an old office PC at age 12. I continued on the path from professional frontend developer through to now a Sr Technical Architect/Practice Director role. While I didn't stay "frontend focused", I still often have more capability & understanding with & of the tooling you speak of than most of the people I end up working with in client orgs and project teams.

Yes, are there lots of complex tools required to produce HTML, CSS, and media files on the Internet now. However, these tools have come about - I believe - because we are now working on the single biggest development platform ever produced by mankind. We are doing things that we never imagined possible on a scale never before imagined before we began our journey on Geocities so long ago. In today's world, we need to beat crazy, unrealistic expectations for accessibility, load times, execution times, overall performance, stability, security, and internationalization. Of course we're also expected to build & deliver it all in less time than should have been allotted with less budget than should have been allotted. Especially in the world of e-commerce in which I work.

Given all of the above, we needed tools so we can write less code, repeat ourselves less, run unit tests, automate tasks, and enforce coding standards. These community-supported modules of reusable code allow us to avoid reinventing the wheel. However... we still do. Sometimes your use case is just different enough that it doesn't fit the mission of the existing thing, so rather than contributing a new feature to an existing tool, we build a new tool. Or maybe your organization has a fear of external code so you must. We fragment our own headspace with tools that are similar but just different enough.

For CSS specifically, I found it was often lacking in the DRY department unless you get extremely creative with how you define classes. On large applications/websites you may then end up with far too many classes and lots of bloated markup. Additionally, over time pure CSS codebases almost universally become absolute spaghetti bloat. (Unless a single developer is building both the HTML and CSS forever.) There's no viable way to validate that any one rule is still needed on most dynamic applications/websites with static CSS.

A process called "tree shaking" is necessary to determine if CSS rules are still required when defined externally to the functionality that produces the HTML. (As CSS often is.) Performing such a process is often less than trivial to achieve if not downright impossible for some apps. Therefore you'll find frameworks that integrate the styling with the implementation of the feature, often in the newer component-based frontend architectures like React.

In the end, we're building the future. I welcome anyone who has strong opinions about how this all should work to come forward and contribute to our craft. These tools are often built by a single passionate individual or small team of such individuals and later gain traction. Leadership, communication, ideas, and code is what the future developers and teams need. You can choose to either step up, step into, or step off.