Dublin Library

The Publishing project

Creating a Custom-Admonition Web Component

I love the way Lea Verou's web site looks, particularly the way the admonitions look on her site. I looked at t he CSS she used for the admonitions and thought it would be fun to create my own version that mimics the style of her admonitions. Along the way I decided to move it to a custom element and to keep the code dry by creating a base admonition and use custom versions to extend it. This way, I have more flexibility on styles and I can easiy create new types of admonitions without having to duplicate code. This...

Continue reading →

From Markdown to PDF: A PrinceXML Pipeline

In From Markdown to PDF: Pandoc/from-markdown-to-pdf-pandoc/, we explored how to use Pandoc to convert Markdown into PDF. While Pandoc is a powerful tool, it has limitations in terms of styling and layout control; it uses LaTeX under the hood, which can be difficult to customize and often locks dependencies into what's available in the TeX ecosystem. > Note: This post does not cover installation or setup of Pandoc, Saxon-HE, or PrinceXML. Please ensure these tools are installed and available in your environment before proceeding. Below is a summary diagram of the pipeline stages and file flow: mermaid graph TD AMarkdown...

Continue reading →

From Markdown to PDF: Pandoc

When I first thought about automatically geneerating PDF version of my blog posts, I thought it would be easy: Just create a shell script that would run Pandoc to convert each document into its PDF equivalent. First discovery: Pandoc uses LaTeX to do the conversion. Second discovery: LaTeX is very strict on how it wants its input formatted and how it reacts when it isn't. This led to the two scripts that will be discussed in this post. In a later post I will discuss a different alternative using XSLT, CSS and PrinceXML as an alternative PDF generation alternative. Software...

Continue reading →

Why do we need a virtual file system in Node.js?

Node.js developers frequently encounter situations where working with the real filesystem creates friction: Testing: Unit tests that manipulate files need cleanup, deal with disk I/O latency, and struggle with isolation. Tests often stub the fs module entirely, losing the ability to test file-system-dependent logic realistically. Development: Building tools like bundlers, code generators, and template engines often need to generate files temporarily. Managing temporary directories becomes boilerplate. Filesystem isolation: Applications sometimes need to isolate filesystem operations by scoping accessible paths so user-provided workflows cannot freely access the host filesystem. In-memory workflows: Dynamic environments like browsers with WebAssembly or serverless platforms may...

Continue reading →

Reviewing WordPress 7.0

I stopped using WordPress in 2022 because the project was moving in a direction that no longer matched my needs. I still check new releases to see how the platform is evolving and whether enough has changed to make me consider switching back. WordPress 7.0 "Armstrong" was released on May 20, 2026. According to the documentation, it marks a fundamental shift in how WordPress operates. More than a visual refresh or a handful of new blocks, 7.0 positions WordPress as an AI-first application platform. For this review, I focused on features most likely to affect everyday WordPress users and intermediate...

Continue reading →

Yes, you can write 'wrong' CSS

Jens Oliver Meiert wrote an interesting article on SitePoint: There Is No "Wrong" in CSShttps://www.sitepoint.com/there-is-no-wrong-in-css/. He offers four reasons why CSS can't really be "wrong": 1. If It Works, It Works 2. The One Who Suffers Is You 3. It’s Easy to Change 4. Barriers for Users Are a Web Platform Responsibility I agree with part of his argument, but I think the conclusion is too broad. Whether CSS is "wrong" depends on what standard we apply: In this post, "wrong" means predictably creating avoidable user barriers or high change risk. 1. Rendering is the floor, not the standard. 2....

Continue reading →

JavaScript and TypeScript Promises

A Promise is an object representing the eventual completion or failure of an asynchronous operation and its resulting value. It acts as a proxy for a value not necessarily known when the promise is created. They are not always intuitive to reason through, especially for developers new to asynchronous programming. This post covers the core concepts, lifecycle, and best practices for using promises effectively in both JavaScript and TypeScript. Core concepts and lifecycle Every Promise exists in one of three mutually exclusive states: Pending: The initial state; the operation has not yet completed. Fulfilled: The operation completed successfully. The promise...

Continue reading →

JavaScript and TypeScript Streams: Advanced Patterns

This is a follow-up to JavaScript and TypeScript Streams 2026 Edition/javascript-and-typescript-streams-2026-edition/ and covers advanced material removed from the previous Streams post. This post focuses on the moments when "normal" streaming code is technically correct but still fails under scale, latency, or reliability pressure. If your current workload is modest, you can safely skip most of this. If you run ingestion pipelines, large-file processing, media workflows, or long-lived stream services, these patterns are often the difference between stable production behavior and slow-burn incidents. Important Note on Scope This is a selective toolbox, not a checklist. Use the sections that match the...

Continue reading →

The Fetch Ecosystem

When the Fetch API first arrived, it provided a modern, Promise-based alternative to the clunky XMLHttpRequest. Today, in 2026, Fetch has evolved far beyond a single method. It is now a comprehensive ecosystem of APIs designed to handle massive background downloads, optimize resource loading, and ensure data consistency across unreliable networks. This post explores the complete suite of Fetch-related APIs available in modern browsers, providing TypeScript implementations to help you build resilient web applications. The Core Fetch API The Core Fetch API remains the foundation for network requests in the browser and Node.js. It revolves around the fetch method and...

Continue reading →

JavaScript and TypeScript Streams (2026 Edition)

Streams are the safest default when data can be large, continuous, or unpredictable. Instead of buffering everything in memory first, streams process data chunk by chunk. The goal is not to memorize every stream API detail. It is to build a reliable mental model and use a small set of battle-tested patterns in production. This post focuses on: Choosing between Web Streams and Node streams Bridging both APIs in Node.js Applying backpressure correctly Building transform pipelines for common tasks Streaming with fetch Handling cancellation and failures Who This Is For If you already use async/await, work with APIs/files, and write...

Continue reading →