The Publishing Project

First Look: Bazel build system

Google has an interesting build system for their internal applications and projects called Blaze. Bazel is the open-source version of that project. According to its documentation, Bazel offers the following advantages: High-level build language. Bazel uses an abstract, human-readable language to describe the build properties of your project. Unlike other tools, Bazel operates on the concepts of libraries, binaries, scripts, and data sets, shielding you from the complexity of writing individual calls to tools such as compilers and linkers Bazel is fast and reliable. Bazel caches all previously done work and tracks changes to both file content and build commands.

Playwright, a better Puppeteer?

I love Puppeteer, it’s almost the perfect tool to test sites and do screenshots of the projects we’re working on. It was originally a Chrome only tool, meaning it would only work with headless Chromium; it then graduated to working with headless Firefox as well… but Safari/WebKit is missing. This is the most basic example of using Puppeteer. It will navigate to a site and create a screenshot of the above-the-fold content. We can use Puppeteer to navigate the pages and simulate interactions const puppeteer = require(‘puppeteer’) const screenshot = ‘github-chromium.png’; (async () => { const browser = await puppeteer.launch({

Event Delegation

One of the things that took me a while to fully understand is event delegation and the associated concepts of event bubbling and event targeting. The idea is that, when we add an event listener to an element, there are multiple events triggered and not just on the element the event is attached to. If we take the following HTML. How can we attach a single event so that it will work in all li elements and those we might add in the future? <ul id=”menu”> <li>item 01</li> <li>item 02</li> <li>item 03</li> <li>item 04</li> <li>item 05</li> <li>item 06</li> <li>item 07</li>

Understanding Performance

The hardest thing for me to do when working in the performance space is to understand what the metrics represent and whether we should aim for top performance or where to draw the line of “this is good enough”. Part of this is based on the little touches we can put on our sites like animations or elements other than content, how they will affect performance and whether those effects will be felt equally across the users of the site. The metrics I try to meet and what they mean The best performance metrics around, I think, are Google’s Core

Handling Responsive Images in CSS

When researching material for another post I came across an image-set attribute in CSS. I thought it would be interesting to take a look at how it works and whether it has any limitations we should be aware of. Using image-set as the value of the background-image attribute we can add a set of images that use rules similar to what the HTML responsive images would use. .img { background-image: url(examples/images/image-regular.jpg); background-image: -webkit-image-set( url(examples/images/image-regular.jpg) 1x, url(examples/images/image-large.jpg) 2x, ); } The idea is that, if the browser supports the image-set attribute (unprefixed or not), it will then take the appropriate image