Web Directions Year round learning for web and digital professionals

Iterating on the Web

Every few months or so a tweet or blog post in the web development world seems to ignite a heated conversation about CSS, CSS in JS, the future of Web development, whether certain folks are out of touch, and if so how. A bit of side eye and snark. Here’s something I wrote about this topic during a now long forgotten outbreak back in 2013!

The most recent such ‘conversation’ was triggered by this tweet:

and the quiz to which it refers.

Tim Kadlec followed up with a detailed post, which doubles as a passionate defence of understanding the core technologies of web development, among them CSS.

I agree considerably with Tim, but I also understand where others who take different perspective (mostly tweets, I’ve not found a detailed post countering Tim’s) are coming from.

Developing for the Web is hard

Here’s the thing. Developing for the Web places a significant burden on developers knowledge, and I think I have a reasonable perspective on this having for many yeas been a developer for the Mac OS and Windows.

When developing for most platforms (like Mac OS, or iOS) developers have

  • A single platform to target: The OS. Developers for the Web have in theory a single platform to develop for, but in practice it’s at least several, all of which have their differences. That alone makes for a significant challenge. But wait, there’s more!
  • While Operating systems are upgraded rarely, with a long lead-time ahead of those changes, the Web platform is in a continuous state of both theoretical (the standards) and practical (the browsers implementation of them) and experimental change. Tracking these changes, and their support have always been hard work, and only becoming harder over time.
  • When developing traditional software, developers typically had a single language (C, C++, Turbo Pascal!, Objective-C, C#, Visual Basic (don’t @ me!) to be concerned with. With the Web Platform, we have HTML, CSS, JavaScript, SVG, and their curious complex interactions. As well as their backwards compatibilities, going back nearly quarter of a century (or more).

And this doesn’t even begin to address the networked architecture of Web applications (even with Service Worker, manifests and PWAs, we don’t by any means have the sort of luxury that installed apps do in terms of performance, bundling, packaging). Or that while traditionally most platforms had a quite standardised look and feel, and standard, OS supplied widgets, this is far less true of the Web.

Many have spoken about the challenge of becoming a Web developer today, and I’ll be honest, I’m not sure whether I’d be up to it (particularly at these of 51).

And then lets consider what we are building and are expected to build now, compared with what the Web looked like even 10 years ago, let alone over 20 when CSS first started to have some sort of impact.

So I have considerable sympathy for those who express frustration with complexities, who look to build layers of abstraction (React, Vue, and so on) to hide these complexities, and help developer productivity. There are many very smart, increasingly far more experienced developers than me whom I admire greatly who articulate this point of view, most of whom are far from new to developing for the Web. People like Mark Dalgleish, and Glen Maddern (who are among the most frequent speakers at our events).

Dialog not debate?

I feel there’s an important dialog missing here, one I’ve been trying to foster at various of our conferences going back some years (I’ve brought together a number of these presentations below if you want to watch them).

One the one hand (and this will somewhat simplify each ‘side’, for the sake of brevity, not disrespect to either), we have those, and I’d on balance probably include myself in this camp, who’d argue that the core technologies of the Web are precisely that–foundational, and a deep understanding of them conceptually (not necessarily an encyclopaedic knowledge of every syntactic aspect) is fundamental working knowledge for professional Web developers.

The other side would argue that just as this was true of assembly language 40 years ago, and the abstractions we’ve built above the lower level tools in the intervening years mean assembly is no longer a core technology, the growing complexity of what we build for the Web and the associated frameworks and abstractions (Vue, Angular, React) means a deep understanding of technologies like CSS, HTML and JavaScript, and specifically problematic aspects like CSS’s global scope, specificity rules and the cascade are no longer core knowledge (or shouldn’t be and need to be abstracted away).

What I do feel is lacking from this conversation is something I’ve been trying to get at in a number of the presentations and discussions we commissioned for our conferences over the last 2-3 years. Just as jQuery introduced concepts and language and platform features (classlist, querySelector, to name a couple) by highlighting the shortcomings of the DOM from a web app perspective, and compile-to-jaavscript languages like coffeescript (arrow functions) on JavaScript, what is it that CSS (in particular, it seems CSS is the recurring ‘culprit’ here) lacks, that CSS-in-JS, and other approaches are looking to work around? And how might CSS evolve to incorporate these?

Harnessing The Web’s Iterative Innovation

Because the cycle of innovation we’ve seen over decades now when it comes to its technologies has been innovation on top of the core languages and platform features like the DOM (some times this innovation takes place in the browser, sometimes in frameworks and libraries, sometimes in conventions, patterns and practices). These innovations prove the use case and value of their approach, and the ones that bring the greatest benefit are reabsorbed into the underlying languages and technologies.

No one doubts for a moment that ES today has improved dramatically due to this approach. And at a much greater rate than it did before the days of jQuery and coffee script et al.

But all this takes dialog, each ‘side’ articulating their position, listening to the other, in a spirit of trying to understand, not simply attempting, rhetorically or otherwise to win. What’s the goal here? To be right? Two win the argument, or to help the Web become the best platform it can be?

Related Presentations

It’s precisely this challenge I’ve been trying to tease out for some time with various presentations by invited experts at our conferences these last few years.

In particular at Code 2017, we had Mark Dalgleish, and Glen Maddern and Mandy Michael

Glen Maddern–The Road to Styled Components: CSS in Component-based Systems

Glen Maddern, who along with Max Stoiber (see the tweet that started all this off above from Max), took the best of CSS and the web to build a new way to style component-based systems. In this talk, Glen shared what they thought about and why they arrived where they did: styled-components

Mark Dalgleish–A Unified Styling Language

In the past few years, we’ve witnessed a massive increase in the amount of CSS experimentation, with ideas like CSS Modules and — most controversially — the rise of CSS-in-JS. But does mixing our styles and logic run counter to the original ideas of CSS? Does it break progressive enhancement?

In this talk, we’ll take an empathetic look at these new approaches, how they relate to the history of CSS, and why they might possibly hold the key to the future of CSS — all from the point of view of someone who has been writing CSS since 1999.

Mandy Michael–Traditional CSS at Scale(?)

Mandy Michael loves CSS. She believes there’s power in its simplicity and flexibility.

When the team at Seven West Media Perth redeveloped The West Australian’s digital platform in a tight 4-month deadline, they embraced the CSS they know and love with a component driven approach, utilising ITCSS, BEM and SCSS with strict linting and code review. But while she’s a long-time lover of traditional approaches to CSS, the lessons Mandy learned have led her to the ultimate question: is there a better way?


We then brought Mandy, Glen and Mark together for a further discussion of the issues their presentations had raised.

delivering year round learning for front end and full stack professionals

Learn more about us

Three days of talks, two of them in the engineering room. Web Directions you have broken my brain.

Cheryl Gledhill Product Manager, BlueChilli