Tags: modularity

10

sparkline

Web Components in 2018 - Blog | SitePen

A good explanation of web components, complete with some code examples.

Web Components are not a single technology. Instead, they are series of browser standards defined by the W3C allowing developers to build components in a way the browser can natively understand. These standards include:

  • HTML Templates and Slots – Reusable HTML markup with entry points for user-specific markup
  • Shadow DOM – DOM encapsulation for markup and styles
  • Custom Elements – Defining named custom HTML elements with specific behaviour

Bad Month for the Main Thread - daverupert.com

JavaScript is CPU intensive and the CPU is the bottleneck for performance.

I’m on Team Dave.

But darn it all, I just want to build modular websites using HTML and a little bit of JavaScript.

On container queries. — Ethan Marcotte

Unsurprisingly, I completely and utterly agree with Ethan’s assessment here:

I’ve written some code that’s saying, “Once the screen is this size and the element appears in a different, smaller container, use a narrower layout on this element.”

But, well, that’s weird. Why can’t we apply styles based on the space available to the module we’re designing, rather than looking at the shape of the viewport?

I also share his frustration with the “math is hard; let’s go shopping” response from browser vendors:

There’s an incredible clamor for container queries, with folks from every corner of the responsive community asking for something that solves this problem. So personally, I’d love to see at least one browser vendor partner with the RICG, and get properly fired up about this.

We had to drag browser makers kicking and screaming to responsive images (to this day, Hixie maintains it’s not a problem that needs solving) and I suspect even more activism is going to be needed to get them to tackle container queries.

Callback Hell

At first when I was reading this JavaScript coding guide, I thought “Isn’t this exactly what promises address?” but that is then addressed further down:

Before looking at more advanced solutions, remember that callbacks are a fundamental part of JavaScript (since they are just functions) and you should learn how to read and write them before moving on to more advanced language features, since they all depend on an understanding of callbacks.

Fair enough. In any case, what you’ll find here is mainly good advice for writing modular code.

MaintainableCSS - an approach to writing modular, scalable and maintainable CSS | By Adam Silver

Adam Silver has written a free online book all about writing maintainable CSS. It dives straight into naming things and takes it from there.

MaintainableCSS is an approach to writing modular, scalable and of course, maintainable CSS.

Web Components and progressive enhancement - Adam Onishi

Adam and I share the same hopes and frustrations with web components. They can be written in a resilient, layered way that allows for progressive enhancement, but just about every example out there demonstrates a “my way or the highway” approach to using them.

We were chatting about this in the Design Systems slack channel, and it helped clarify some of my thoughts. I’ll try to poop out a blog post about this soon.

A Code Review, Or Yet Another Reason to Love the Web | Brad Frost

I love this back and forth between Brad and Jonathon. I think they’ve both got some good ideas:

  • I agree with Brad that you can start marking up these kind of patterns before you’ve got visual designs.
  • I agree with Jonathon that it’s often better to have a generic wrapper element to avoid making assumptions about which elements will be used.

Semantic CSS - Snook.ca

Snook has been on a roll lately, sharing lots of great insights into front-end development. This is a particularly astute post about that perennial issue of naming things.

The (other) Web we lost

John shares his concerns about the increasing complexity involved in developing for the web.

An essay on W3C's design principles - Contents

Bert Bos's 2000 Treatise (published in 2003) is a must-read for anyone involved in developing any kind of format. "This essay tries to make explicit what the developers in the various W3C working groups mean when they invoke words like efficiency, maintainability, accessibility, extensibility, learnability, simplicity, longevity, and other long words ending in -y."