Forem: Greg, The JavaScript Whisperer

apple macos time-machine

Greg, The JavaScript Whisperer — Mon, 15 Sep 2025 17:25:53 +0000

Quick tip: disable throttling to quickly create a backup

sudo sysctl debug.lowpri_throttle_enabled=0

Let's GET perfy

Greg, The JavaScript Whisperer — Sat, 07 Jun 2025 02:57:06 +0000

Oh hello again, been a minute, howzit?

So I thought I'd write a post about performance; I been kinda weirdly obsessed for at least 15 years; I think I got hooked by legends like Paul Irish and Addy and Bruce L back in the day.

Anyway I previously shared my first perf talk in Cape Town, from 15 years ago... and my original website which somehow still scores 100s across the board in lighthouse.

I thought I'd share some ideas and tools I've tried more recently and some blueprints for next level performance. I really love solving 'unsolvable' issues with creative, wild, out the box thinking.

So basics first easy wins, thing like http/2/3 speedy protocol, this is easily achievable with a reverse proxy tool like Caddy covered here, slick, modern, concise and performant https://jswhisperer.uk/post/caddy-2/ or something excessively verbose, and old like nginx (kinda like comparing Vue to React I've heard ...kidding)

Along with the basics like cache headers and compression headers brotli, gzip

lz-string

\
Probably many cases would be covered by good server compression, brotli, gzip, etc, and proper headers. something like this However there are some great cases where the server can't help you, or maybe you don't control it.

What about HTML Web Storage API's especially on mobile? Why not be a good Samaritan and compress before storing in localStorage, indexedDB etc; hell even cookies. Added benefit much less friendly to tamper with for your average joe.

Next hidden gem that I think will become mainstream soon Protocol Buffers! (I only use things before they become cool) Often called Protobuf. It's been but on a pedestal for over a decade Actual results have and real world usage at least in the javascript world have been a bit dismal ...like slower than built in JSON.parse.

However the last couple years show some promise. There is which is this very compliant, and runs in the browser; but probably if youre looking to implement protobufs you are focused on speed?

Some fast research revealed some libs that might help like pbf

A low-level, lightweight protocol buffers implementation in JavaScript.

Server side some tricks might include streaming responses; including Server Sent Events with something like Hono

Another trick would be to proxy/intercept static assests with a reverse proxy like Caddy that is quicker at serving files than node.js

Images

so there’s been a lot of improvements in image performance since my last post. There are new formats that knock traditional jpg, png, and gif out the park with savings. Mainly the widely adopted webp and the very cool avif.

The other amazing available optimisation is properly or responsively sized image sources with the <Picture> element

<picture>
  <source srcset="mdn-logo-wide.png" media="(min-width: 600px)" />
  <img src="mdn-logo-narrow.png" alt="MDN" />
</picture>

and there is #ServiceWorkers# of course

test

Greg, The JavaScript Whisperer — Sat, 31 May 2025 19:39:04 +0000

gist-hub.pages.dev

ServiceWorkers Cache everything!!!

Greg, The JavaScript Whisperer — Fri, 09 May 2025 20:13:51 +0000

As a performance addict, I went all in on ServiceWorkers for better or worse.

I've been digging Astro lately, I keep eyes on Nuxt, VitePress and similar though.

This article will actually target any vite based project including all the above ones.

So ServiceWorkers have more API's and capabilities than any one man could cover, but our interest now is the CacheStorage API It's similar to storage APIs you might be familar with like localStorage etc, with one caveat; It can and will intercept http requests.

This, used correctly, is super cool! So say we request a large image or file "/largeImage.png" even with the best CacheHeaders there can be a delay in the response, not so with the CacheStorage API.

We will intercept the request and respond with a locally browser stored version and depending on our ServiceWorker strategy possibly check for a fresher Network (external) version. This also immediately enables Offline support. Because we intercept these requests, we do not need to be online at all.

Neat!

So using VitePWA you might have a config like

  AstroPWA({
      srcDir: "src",
      includeManifestIcons: false,
      includeAssets: [
        "**/*",
    ],

      pwaAssets: {
        config: true,
      },
      maxEntries: 500,
      workbox: {
        globPatterns: ['**/*.{js,html, png, jpg, jpeg, svg, webp, avif, js, woff, woff2, txt, ttf }'],
        runtimeCaching: [
          {

            urlPattern: /\.(?:png|jpg|jpeg|svg|html|js|avif|webp|woff2|woff|webp|js|txt|ttf)$/i,
            handler: "CacheFirst",
            options: {
              cacheName: 'main',
              expiration: {
                maxAgeSeconds: 60 * 60 * 24 * 365,
                maxEntries: 500,
              },
            },
          },
        ],

        cleanupOutdatedCaches: true,
        maximumFileSizeToCacheInBytes: 5 * 1024 * 1024 * 5 * 99,

      },
      devOptions: {
        type: "module",
        enabled: true,
        navigateFallbackAllowlist: [/^\//],
      }
    }),

This is probably not optimal at all, in-fact it definitely isn't, but I'll explain it. So the top-level includeAssets is AFAIK a pre-cache of resources, it might be pointing at your /public folder framework depending. It's better to actually specify resources then my wild cache it all **/*. Why, because the first page load will be slow, and cache things not even related to the page the user is viewing. (As a crazy person, I use this, and no amount of therapy will change me.)

Now runtimeCaching this is pretty cool, it's basically grabbing resources as they are requested "at runtime"; basically anything external and not in your "/public" folder. This is probably one should lean on more then the includedAssets. This has some powerful options like strategy, handler: "CacheFirst" is probably the best IMO. Find many more here.

Ok let's move on to a side-note more about PWA capabilities generating PWA Assets, so basically the webmanifest and appropriate icons. This makes your App/Website installable to a Desktop/Android/iOS.

So you might include PWA-assets-generator pnpm add -D @vite-pwa/assets-generator

You can now use it like
pwa-assets-generator --preset minimal-2023 public/logo.svg
or add as an npm script like

{
  "scripts": {
    "generate-pwa-assets": "pwa-assets-generator --preset minimal-2023 public/logo.svg"
  }
}

or many framework integrations will have an option like:

 AstroPWA({
 pwaAssets: {
        config: true,
      }
})

nuxt would be similarly:

export default defineNuxtConfig({
  modules: ['@vite-pwa/nuxt'],
  pwa: {
    pwaAssets: {
        config: true,
      }
  }
})

Which will read a config file and automatically generate on build.

Let me know any questions or thought! or critiques!

And how do we quickly see all our Cache Storage entries?

an example of all responses from my blog:

Browser Compression Options 2025

Greg, The JavaScript Whisperer — Fri, 09 May 2025 16:02:24 +0000

I was exploring the MDN docs and stumbled onto the newer CompressionStream API which enables a couple encodings to compress data streams; namely the popular classic GZIP, and a basic Deflate.

This is a neat first step for the client, but better newer compression encodings exist; these may be forth-coming to the native api one day; Brotli and ZSTD come to mind as the top current ones.

I wanted to test out all the available options I could find to see for myself. So first I searched and was able to find these libs:

High level I reckon ZSTDjs, ZSTDwasm, and then Brotli are top performers... here a screenshot of my findings

and the repo:

https://github.com/jswhisperer/compression-compare

Future Work for CompressionStreams API, seems like ZSTD and Brotli are green-lit, but how long for browsers to implement is unknown

src

Invoker Commands API

Greg, The JavaScript Whisperer — Wed, 07 May 2025 20:06:29 +0000

Invoker Commands API
The Invoker Commands API provides a way to declaratively assign behaviours to buttons, allowing control of interactive elements when the button is enacted (clicked or invoked via a keypress, such as the spacebar or return key).
src

What does that mean though? Basically we have a possibly growing amount of declarative HTML that can add interactivity, without javascript 🤯

If you're a old and kind of clever like me this might trigger happy memories of the <marquee>Do you believe in love after love</marquee>
element

HTML attributes

commandfor
Turns a element into a button, controlling the given interactive element; takes the ID of the element to control as its value.

command
Specifies the action to be performed on an element being controlled by a control , specified via the commandfor attribute.

src

and an example from MDN

<button commandfor="mydialog" command="show-modal">Show modal dialog</button>
<dialog id="mydialog">
  <button commandfor="mydialog" command="close">Close</button>
  Dialog Content
</dialog>

So what's interesting about the above example, at least to me is it actually runs with javascript disabled!?! So only built in the browser commands will work, but I think this is cool. Really primitive elements that add a better UX to the user can now run in environments without javascript. Also this pattern has better Accessibility out of the box.

You can also write your own custom js events and handlers...

Creating custom commands

<button commandfor="my-img" command="--rotate-left">Rotate left</button>
<button commandfor="my-img" command="--rotate-right">Rotate right</button>
<img id="my-img" src="photo.jpg" alt="[add appropriate alt text here]" />
js
Copy to Clipboard
const myImg = document.getElementById("my-img");

myImg.addEventListener("command", (event) => {
  if (event.command == "--rotate-left") {
    myImg.style.rotate = "-90deg";
  } else if (event.command == "--rotate-right") {
    myImg.style.rotate = "90deg";
  }
});

Thought I'd fork this article

DEMO


<button commandfor="modalexample" command="show-modal">
  Open modal dialog
</button>
<dialog class="modal-content" id="modalexample" class="">
  <h2>Welcome to the Modal!</h2>
  <p>This modal window is created using only HTML and CSS!</p>

  <button commandfor="modalexample" command="close">Close Modal</button>
</dialog>

/* Modal container - hidden by default */
.modal {
  position: fixed;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  background-color: rgba(0, 0, 0, 0.6);
  opacity: 0;
  pointer-events: none;
  transition: opacity 0.3s ease;

  /* Center the modal content */
  display: flex;
  align-items: center;
  justify-content: center;
  z-index: 100;
}

/* When the modal is targeted via URL hash, make it visible */
.modal:target {
  opacity: 1;
  pointer-events: auto;
}

/* Modal content box */
.modal-content {
  background-color: white;
  padding: 2rem;
  border-radius: 6px;
  width: 90%;
  max-width: 500px;
  max-height: 90vh;
  overflow-y: auto;
  box-shadow: 0 5px 30px rgba(0, 0, 0, 0.2);
}

/* Backdrop close link - covers the entire screen */
.modal-backdrop {
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  cursor: default;
  z-index: -1; /* Place behind modal content */
}

dialog:modal {
  transition: all 1s ease;
  overlay: auto !important;
}
/* Keyframes for dialog and popover elements */
@keyframes fadeIn {
  from {
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}
@keyframes fadeOut {
  from {
    opacity: 1;
  }
  to {
    opacity: 0;
  }
}

/* Keyframes for the backdrop pseudo-element */
@keyframes backdropFadeIn {
  from {
    background: hsl(0 0% 0% / 0%);
  }
  to {
    background: hsl(0 0% 0% / 50%);
  }
}
@keyframes backdropFadeOut {
  from {
    background: hsl(0 0% 0% / 50%);
  }
  to {
    background: hsl(0 0% 0% / 0%);
  }
}

dialog::backdrop {
  transition: all 1s ease;
  opacity: 1;
  transform: scaleX(1);
}

[dialog] {
  font-size: 1.2rem;
  padding: 10px;

  /* Final state of the exit animation */
  opacity: 0;
  transform: scaleX(0);

  transition:
    opacity 0.7s,
    transform 0.7s,
    overlay 0.7s allow-discrete,
    display 0.7s allow-discrete;
  /* Equivalent to
    transition: all 0.7s allow-discrete; */
}

/* Needs to be included after the previous [popover]:popover-open
     rule to take effect, as the specificity is the same */
@starting-style {
  [popover]:popover-open {
    opacity: 0;
    transform: scaleX(0);
  }
}

/* Transition for the popover's backdrop */

[popover]::backdrop {
  background-color: rgb(0 0 0 / 0%);
  transition:
    display 0.7s allow-discrete,
    overlay 0.7s allow-discrete,
    background-color 0.7s;
  /* Equivalent to
    transition: all 0.7s allow-discrete; */
}

[popover]:popover-open::backdrop {
  background-color: rgb(0 0 0 / 25%);
}

/* Nesting selectors (&) cannot represent pseudo-elements, so this 
     starting-style rule cannot be nested. */

@starting-style {
  [popover]:popover-open::backdrop {
    background-color: rgb(0 0 0 / 0%);
  }
}

#modalexample {
  animation: fadeOut 0.5s forwards;
  &::backdrop {
    animation: backdropFadeOut 0.5s forwards;
  }
  &[open] {
    animation: fadeIn 0.5s forwards;
    &::backdrop {
      animation: backdropFadeIn 0.5s forwards;
    }
  }
}

https://github.com/jswhisperer/re-modals

I'm not 100% overall on how I feel about that though, maybe it helps lower level with creating interactive elements... Maybe it feels like too little too late, time will tell.

QuickTip: CacheStorage list all

Greg, The JavaScript Whisperer — Wed, 07 May 2025 01:43:59 +0000

I really like one liners, especially for shell or console commands.

Anyway I couldn't find how to view all entries in CacheStorage [so I made one]

SSE cool starter with CloudFlare Workers and Hono server

Greg, The JavaScript Whisperer — Wed, 07 May 2025 01:42:01 +0000

SSE or Server Side Events is a cool newer web tech to efficently send data in a push / subscribe pattern.

Here's a cool starter with CloudFlare Workers and Hono server I made for a quick start in the most performant way possible 😊

https://github.com/jswhisperer/SSE-full-honojs-example

MacOS Apps I use

Greg, The JavaScript Whisperer — Mon, 28 Apr 2025 21:24:38 +0000

Draft-y but will keep adding

https://github.com/AppPolice/AppPolice

https://www.caffeine-app.net/

https://brave.com/

https://iina.io/

https://www.raycast.com/

https://github.com/waydabber/BetterDisplay

https://brew.sh/

https://code.visualstudio.com/
https://vscodium.com/

https://www.getmailspring.com/

https://apps.apple.com/us/app/say-no-to-notch/id1639306886?mt=12

https://iterm2.com/

Webmentions Revisted

Greg, The JavaScript Whisperer — Thu, 13 Mar 2025 01:54:45 +0000

When writing your blog, many, like myself,f would like comments from our readers. Comments, likes, reposts and similar let the author know what readers think and cultivate great new conversations or provide invaluable feedback and even criticism on which we can learn from and grow.

I first wrote a very light article on the implementation of Webmentions 5 years ago here.

I'd say, to my knowledge, there haven't been huge strides or adaptation of them in the mainstream web. There does seem to be traction in the FED web.

What is the FED web? from brid.gy fed and here fediverse and here on the verge

Bridgy Fed is a decentralized social network bridge. It connects the Fediverse, the web, and [bluesky]("https://bsky.app/profile/jswhisperer.bsky.social") . If you're on one of these networks, you can use Bridgy Fed to follow people on other networks, see their posts, and reply, like and repost them. Likewise, they'll be able to see you and your posts, too. Click here to get started, or read on for more information and setup details.

So last time I wrote about integrating with Gridsome "The Jamstack framework for Vue.js" and a GrapQL solution; I've since moved my blog to Astro

Astro is pretty cool, but this article isn't about it right now. It is another important Static Site generation tool.

const webmentionsUrl =
    'https://webmention.io/api/mentions.jf2?domain=example.uk&token=token'
const response = await fetch(webmentionsUrl)
const json = await response.json()
const webmentions = json.children.filter((mention: { [x: string]: URL[] }) =>
    mention['wm-target'].includes(pageUrl)
)

You might then render the results in your framework of choice as below. I've added rich data or microformats2 Microformat Microdata covered in my SEO starter article

<html>
<ul>
    <li itemscope="" itemtype="http://schema.org/UserComments" data-astro-cid-qesbhxo5="">
    <small>
        <time itemprop="commentTime" datetime="2025-01-24T10:15:16Z">January 24, 2025</time>
    </small>
        <div itemprop="creator" itemscope="" itemtype="https://schema.org/Person"
            class="u-author h-card">
            <div itemprop="name">Gregory</div>
                <a itemprop="url" href="https://jswhisperer.uk/author/greg"
                aria-label="author url">
                <picture>
                    <source srcset="greg.CZmlD_1D.jpeg" type="image/webp">
                    <img src="greg.CZmlD_1D.jpeg"
                        alt="Gmoney" data-astro-cid-qesbhxo5="true" width="800" height="800" loading="lazy"
                        decoding="async">
                </picture>
            </a>
        </div>
        <div class="information" data-astro-cid-qesbhxo5="">
            <div>
                <p>
                    replied on: <time datetime="2025-01-24T10:15:16Z">January 24, 2025</time></p>
                <blockquote itemprop="commentText">Wicked cool</blockquote>
            </div>
        </div>
    </li>
</ul>
</html>

The last step for me is having my static blog trigger a build for new Webmentions. I'm using Cloudflare Workers, but it's the same process for Github Pages / Workers, Vercel etc.

Take your webmention.io webhook

plug it into your static host

and Enjoy

code-server by coder

Greg, The JavaScript Whisperer — Tue, 05 Nov 2024 20:30:17 +0000

code-server by coder

This project provides a version of VS Code that runs a server on a remote machine and allows access through a modern web browser.

Find the project repo here

What is it in my humble simple language? It’s been called a “runner” in GitLab; but essentially it running the code and terminal command on a remote machine. That can be in the cloud, on docker or natively install on your own machine.

Many people will not need this functionality, the costs of cloud hosting and processing might not be appealing. My use-case is I like to code on really underpowered machines. One of those is my beloved 2012 macbook air 11” with 2 cores. It light as a feather sits on my lap nice and looks like some sort of knife.

*Sidebar: this has to be the thinest apple product to date, I don’t care what they say about the iPad! 05.3cm vs 1.7cm-0.3cm with keyboard and monitor 🕵️‍♀️ ….and my other goto coding machine is a Raspberry Pi.

## Running code-server on your host machine

So however you get it installed start the server, I'll be quoting macos and homebrew but see all the example setups on the same page. With homebrew it would be

brew install code-server
brew services start code-server
# Now visit http://127.0.0.1:8080. Your password is in ~/.config/code-server/config.yaml

and opening the config.yaml would look something like this:

bind-addr: localhost:8080
auth: password
password: password
cert: false

At this point you could navigate to http://localhost:8080 and see a vscode instance in your browser! you will be prompted for the password.

What's missing so far, is the SSL cert and https:// hosting, this is important / cool because firstly you shouldn't have a tunnel to your local machine unencrypted and cool because they provide a PWA

Even better and what I opted for is a reverse proxy with Caddy if you are on the homebrew path you can \
brew install caddy then you will find the config here on macos /opt/homebrew/etc/Caddyfile

For a quick start you can edit your hosts file sudo nano /etc/hosts/ and append a url you would like such as \
127.0.0.1 coder.localhost the .localhost holds special meaning to caddy and certs.

Now to the reverse proxy we can create one in the Caddyfile like so

coder.localhost, mbp.local {
    reverse_proxy 0.0.0.0:8080
}

I've added my mac host name also to be served on my LAN with https. Repeat this proxy and /hosts setup on your remote machine (minus mbp.local) you can now access and run you host instance on your remote machines.

You can even code on you mobile phone or ipad etc through "https://mbp.local" or your hostname.

You can take this one step further and access from anywhere in the world with something like ducksdns if you go down this route, you should implement some security, Caddy has all you need JWT protection IP allowlisting and more.

Hacking WKWebview and WebContainers // or WebContainers are we there yet?

Greg, The JavaScript Whisperer — Fri, 01 Nov 2024 18:21:17 +0000

I started writing about the shiny new wasm-y not quite open source tech called webcontainers by stackblitz, but having hacked the crap out them I reckon right now they aren't quite mature enough for production use.

Here's some of the rough edges you might hit...

They are on a private server, your project, firewall or company might block this hard depencie *.webcontainers.io and https://nr.staticblitz.com to name a couple I see.
For all the hype they do not seem able to actually listen to any request outside the webpage like a POST (more in a sec)
They are behind AWS Cloudfront (fine) but you can't edit the headers or CORs policies at all
they work around iframes which can be a basket of worms with permissions and policies like CSP.

and lastly I think it's worth having a look at the open issues of any library or project; that alone isn't the end all and be all of decision making. It is expected a new library get a surge of issues that need to be triaged.

The last indicator this isn't ready for prime time is if they are ignoring or don't have capacity to review PRs they might not be fully invested. Of course it's my duty to open PR's and contribute where I can.

I had a whole doc around embedded webview in a Rust lang context and my coo workaround. To summarise it was how WKWebview does not at all support navigator.credentials web api or the shiny new "Passkeys" not so quick read if you got a weekend to play here