Raymond Camden

Adding Google Auth to TinyJS

2026-10-12T18:00:00+00:00

A few days ago I posted about my experience playing around with TinyJS. This is a very light "web to desktop app" platform for - well - building desktop apps. Its simplicity and similarity to PhoneGap (at least for the desktop) has got me interested in seeing what I can build with the project. One of my ideas would be improved with a login system so I naturally looked into adding a "Login with Google" feature. While this was mostly straightforward, I ran into some oddities and figured I'd share it here.

I went into this exploration with a basic idea of how I'd approach it:

Create an app in the Google Cloud console to represent my app, getting the client id and secret.
Generate a link using the standard OAuth flow
For my redirect URL, use a custom URI scheme (like mycustomapp://) so that on redirect from Google, it would open the app automatically
The response would include the code I'd exchange for an access token (and refresh token), at which point I could get the user's profile and have their name and email address. I'm only thinking of that as my mental model for this little POC is just login, not using other Google services.

Right away I hit a couple of snags.

Google's OAuth flow specifically blocks the use of a custom URI scheme. Instead, you need to hit a locally running web server which would handle getting and verifying the code. I've actually seen this before, you end up with a new tab in your browser that says you can close the tab, but I had never implemented it before.
The next bit isn't a snag per se, but in my research, I found that in most places, your desktop app can include just the client id, but for Google, you must include the secret as well. Obviously that makes me nervous as heck, but again, this is apparently a well known thing for desktop apps that authenticate with Google. While I don't feel 100% certain about this, I asked multiple agents, Googled, and so forth, and they all seemed to be in agreement. Absolutely correct me in a comment below if I'm wrong.

Alright, so with all of that in mind - I want to once again thank the author of the program for pointing me to the platter demo which implements the local web server mentioned above. I was able to point my coding agent to that when working through the demo.

I have not put my code into a GitHub repo, but will include everything below. As this was just a POC I didn't feel like it was necessary, but if you want a zip, just ask. Nicely. Or not. I'll still send it.

The Code

Ok, let me start with the simplest part, the HTML. I'm not using Alpine for this, or any real CSS. It's just this:

<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>__NAME__</title>
<link rel="stylesheet" href="style.css">
</head>
<body>

<main>
  <h1>Google sign-in Test</h1>
  <a id="login-link" href="#">Login with Google</a>
  <section id="profile" aria-live="polite" hidden>
    <h2>Signed in</h2>
    <p><strong>Name:</strong> <span id="profile-name"></span></p>
    <p><strong>Email:</strong> <span id="profile-email"></span></p>
  </section>
  <p id="login-error" role="alert" hidden></p>
</main>

<script src="app.js"></script>
</body>
</html>

I've got a login link (blank, that gets filled in later), a section that's displayed when you are logged in, and a block for errors. The login link should be hidden as well (I'll explain why later), but again I was trying to keep this simple.

Now let's look at the JavaScript, and this is a bit of a mess. With a proper framework like Alpine it would be better organized, but it gets the job done.

const CLIENT_ID = "safe but why not be sure";

const REDIRECT_URI = "http://127.0.0.1:8765/callback";
const TOKENS_KEY = "google-oauth-tokens";

async function makeLoginUrl() {
  const b64url = (buf) =>
    btoa(String.fromCharCode(...new Uint8Array(buf)))
      .replace(/\+/g, "-").replace(/\//g, "_").replace(/=+$/, "");

  const verifier = b64url(crypto.getRandomValues(new Uint8Array(32)));
  const challenge = b64url(
    await crypto.subtle.digest("SHA-256", new TextEncoder().encode(verifier))
  );
  const state = b64url(crypto.getRandomValues(new Uint8Array(16)));

  // keep these for the token exchange step
  sessionStorage.setItem("pkce_verifier", verifier);
  sessionStorage.setItem("oauth_state", state);

  const params = new URLSearchParams({
    client_id: CLIENT_ID,
    redirect_uri: REDIRECT_URI,
    response_type: "code",
    scope: "openid email profile",
    access_type: "offline",
    prompt: "consent",
    code_challenge: challenge,
    code_challenge_method: "S256",
    state,
  });

  return `https://accounts.google.com/o/oauth2/v2/auth?${params}`;
}

document.addEventListener("DOMContentLoaded", async () => {
  const loginLink = document.querySelector("#login-link");

  try {
    const savedTokens = await tiny.app.secrets.get(TOKENS_KEY);
    if (savedTokens) {
      try {
        const session = await tiny.api.call("restoreSession", {
          tokens: JSON.parse(savedTokens),
          clientId: CLIENT_ID,
        });
        await tiny.app.secrets.set(TOKENS_KEY, JSON.stringify(session.tokens));
        showProfile(session.profile);
        return;
      } catch {
        await tiny.app.secrets.delete(TOKENS_KEY);
      }
    }
    await prepareLogin(loginLink);
  } catch (error) {
    showError(`Google sign-in failed: ${error.message}`);
  }
});

async function prepareLogin(loginLink) {
  const url = await makeLoginUrl();
  const state = sessionStorage.getItem("oauth_state");
  const codeVerifier = sessionStorage.getItem("pkce_verifier");
  loginLink.href = url;
  loginLink.target = "_blank";
  loginLink.rel = "noopener";

  loginLink.onclick = async () => {
    try {
      const session = await tiny.api.call("waitForCode", {
        port: 8765,
        state,
        codeVerifier,
        clientId: CLIENT_ID,
      });
      await tiny.app.secrets.set(TOKENS_KEY, JSON.stringify(session.tokens));
      showProfile(session.profile);
    } catch (error) {
      showError(`Google sign-in failed: ${error.message}`);
      await prepareLogin(loginLink);
    }
  };
}

function showProfile(profile) {
  document.querySelector("#profile-name").textContent = profile.name || "Not provided";
  document.querySelector("#profile-email").textContent = profile.email || "Not provided";
  document.querySelector("#profile").hidden = false;
  document.querySelector("#login-link").hidden = true;
  document.querySelector("#login-error").hidden = true;
}

function showError(message) {
  const errorOutput = document.querySelector("#login-error");
  errorOutput.textContent = message;
  errorOutput.hidden = false;
}

I start off with a utility function to generate my login link. Note that redirect URI - it's going to be hosted by my app via the backend script and makes an assumption on a port that's free. A better version would try a set of ports to see which can be used.

In my DOMContentLoaded block I've got multiple things going on.

First off - I look at a secure storage system for an existing access token. This is documented in the secrets and auth section of TinyJS's docs. If the values exist, a call to the backend is made to try to verify the values and treat the user as already logged in.

If this fails, or the values weren't there, we:

Get the login URL and update the DOM
Tell the backend to fire up the HTTP server
And then wait for a success.

The final two functions just display the profile or an error. Now let's look at the backend:

// Yes, I said it was safe, still, why share it here?
const GOOGLE_CLIENT_SECRET = "my secret brings the boys to the yard";

async function exchangeCodeForToken({ code, codeVerifier, clientId, port }) {
  const response = await fetch("https://oauth2.googleapis.com/token", {
    method: "POST",
    headers: {
      "content-type": "application/x-www-form-urlencoded",
    },
    body: new URLSearchParams({
      code,
      client_id: clientId,
      client_secret: GOOGLE_CLIENT_SECRET,
      redirect_uri: `http://127.0.0.1:${port}/callback`,
      grant_type: "authorization_code",
      code_verifier: codeVerifier,
    }),
  });
  const tokens = await response.json();
  if (!response.ok || tokens.error) {
    throw new Error(tokens.error_description || tokens.error || `Token request failed (${response.status}).`);
  }
  return tokens;
}

async function refreshAccessToken(refreshToken, clientId) {
  const response = await fetch("https://oauth2.googleapis.com/token", {
    method: "POST",
    headers: {
      "content-type": "application/x-www-form-urlencoded",
    },
    body: new URLSearchParams({
      client_id: clientId,
      client_secret: GOOGLE_CLIENT_SECRET,
      refresh_token: refreshToken,
      grant_type: "refresh_token",
    }),
  });
  const tokens = await response.json();
  if (!response.ok || tokens.error) {
    throw new Error(tokens.error_description || tokens.error || `Token refresh failed (${response.status}).`);
  }
  return tokens;
}

function expiresAt(tokens) {
  const expiresIn = Number(tokens.expires_in);
  if (!tokens.access_token || !Number.isFinite(expiresIn) || expiresIn <= 0) {
    throw new Error("Google returned an invalid access token response.");
  }
  return Date.now() + expiresIn * 1000;
}

async function getUserProfile(accessToken) {
  const response = await fetch("https://openidconnect.googleapis.com/v1/userinfo", {
    headers: {
      authorization: `Bearer ${accessToken}`,
    },
  });
  const profile = await response.json();
  if (!response.ok) {
    throw new Error(profile.error_description || profile.error || `Profile request failed (${response.status}).`);
  }
  return {
    name: profile.name || "",
    email: profile.email || "",
  };
}

async function restoreSession(tokens, clientId) {
  if (!tokens?.access_token || !tokens?.refresh_token || !tokens?.expires_at) {
    throw new Error("Saved sign-in is incomplete.");
  }

  let refreshedTokens = {};
  if (tokens.expires_at <= Date.now() + 60000) {
    refreshedTokens = await refreshAccessToken(tokens.refresh_token, clientId);
  }

  const updatedTokens = {
    access_token: refreshedTokens.access_token || tokens.access_token,
    refresh_token: refreshedTokens.refresh_token || tokens.refresh_token,
    expires_at: refreshedTokens.access_token
      ? expiresAt(refreshedTokens)
      : tokens.expires_at,
  };
  const profile = await getUserProfile(updatedTokens.access_token);
  return { profile, tokens: updatedTokens };
}

async function waitForCode(port, expectedState, codeVerifier, clientId) {
  return new Promise((resolve, reject) => {
    let server;
    let timer;
    let settled = false;
    let processing = false;

    const stopServer = () => {
      if (timer) clearTimeout(timer);
      if (!server) return;
      const activeServer = server;
      server = null;
      try {
        activeServer.close();
      } catch (error) {
        console.error("Failed to close OAuth callback server:", error);
      }
    };

    const finish = (error, code, closeImmediately = false) => {
      if (settled) return;
      settled = true;
      if (timer) clearTimeout(timer);
      if (closeImmediately) stopServer();
      else setTimeout(stopServer, 1000);
      if (error) reject(error);
      else resolve(code);
    };

    const escapeHtml = (value) => String(value)
      .replace(/&/g, "&amp;")
      .replace(/</g, "&lt;")
      .replace(/>/g, "&gt;")
      .replace(/"/g, "&quot;")
      .replace(/'/g, "&#39;");
    const htmlResponse = (message, status = 200) => new Response(
      `<html><body><h3>${escapeHtml(message)}</h3></body></html>`,
      {
        status,
        headers: {
          "content-type": "text/html; charset=utf-8",
          "content-security-policy": "default-src 'none'; style-src 'unsafe-inline'",
        },
      }
    );

    server = tjs.serve({
      port,
      fetch: async (request) => {
        let url;
        try {
          url = new URL(request.url);
        } catch {
          return htmlResponse("Invalid callback request.", 400);
        }

        if (url.pathname !== "/callback") return htmlResponse("Not found.", 404);
        if (settled) return htmlResponse("This login request has already been processed.", 410);
        if (processing) return htmlResponse("This login request is being processed.", 409);
        if (url.searchParams.get("state") !== expectedState) {
          return htmlResponse("State mismatch. Return to the app and try again.", 400);
        }

        const oauthError = url.searchParams.get("error");
        if (oauthError) {
          finish(new Error(oauthError));
          return htmlResponse("Login failed: " + oauthError);
        }

        const code = url.searchParams.get("code");
        if (!code) {
          finish(new Error("OAuth callback did not include an authorization code."));
          return htmlResponse("Login failed: authorization code was missing.", 400);
        }

        processing = true;
        try {
          const tokens = await exchangeCodeForToken({
            code,
            codeVerifier,
            clientId,
            port,
          });
          const profile = await getUserProfile(tokens.access_token);
          finish(null, {
            profile,
            tokens: {
              access_token: tokens.access_token,
              refresh_token: tokens.refresh_token,
              expires_at: expiresAt(tokens),
            },
          });
          return htmlResponse("Login complete. You can close this tab.");
        } catch (error) {
          finish(error);
          return htmlResponse("Token exchange failed: " + error.message, 502);
        }
      },
    });

    timer = setTimeout(() => {
      finish(new Error("Timed out waiting for the OAuth callback."), null, true);
    }, 120000);
  });
}

export const api = {
  restoreSession: ({ tokens, clientId }) => {
    if (!clientId) throw new Error("Google client ID is required.");
    return restoreSession(tokens, clientId);
  },
  waitForCode: ({ port, state, codeVerifier, clientId }) => {
    if (!codeVerifier || !clientId) {
      throw new Error("OAuth code verifier and client ID are required.");
    }
    return waitForCode(port, state, codeVerifier, clientId);
  },
};

This one's a bit of a beast, but some are fairly standard. Both exchangeCodeForToken and refreshAccessToken are standard OAuth stuff. Ditto for getUserProfile. The important bit is waitForCode. This is where the small web server is kicked off that attempts to handle the redirect back from Google. I said up front I used AI to build most of this and I have to be honest, I'm glad I did as this part would have taken me quite some time.

All in all - it works great. The only real issue is a nit-picky one - when the app loads you see the login link for a second before the stored auth is verified. A bit of UX magic there would handle that.

There's an important part left out of this that I'll need to tackle next - which is how I would take the verified identity here and pass it to a remote service in a secure way such that the remote service can also verify it ("Yes, this was Raymond Camden") before performing an action.

Tiny Apps with TinyJS

2026-10-08T18:00:00+00:00

About a year ago, I was still running my live stream (Code Break) and my final three streams all covered one topic - building desktop applications with non-native code. I covered Tauri (HTML on the front, Rust on the back) and Flet (all Python). Recently I came across another option, tinyjs.

TinyJS (technically the name is "tinyjs" but I can't make myself use the lowercase in my writing like that ;) is a lot like PhoneGap/Apache Cordova. Your application is the system web view shipped along with the ability to make system calls via a bridge to txiki.js. This bridge gives you full access to the file system and more, like any other native app.

Unlike PhoneGap, this is just for desktop apps, which is fine, but I think the biggest selling point is the size of the bundled app - typically around 6 megs. That's tiny versus something like Electron.

It's got hooks into everything a desktop app could need, like native dialogs and OS menus and such. It can write securely to the OS's credential store, use SQLite, and even handle application updating.

I've just begun playing with it recently and I've got a few ideas for apps I want to build, but I thought I'd share a quick demo. This one's a bit ugly, and to be clear, that's on me. As it's a web view, you've got full control over how the end result looks. I was just going for something quick and dirty in my test.

First Steps

After doing a quick install, you can scaffold at the command line with:

tinyjs new appname

By default this scaffolds out a vanilla application (no React default, woot!) with a few files and folders - the important ones (at least initially while testing and learning) are:

frontend - the UI/UX layer (HTML, CSS, JS)
main.js - a "backend" file that lets you build services you expose to your front end code. This is where you do "system" stuff your frontend JavaScript can't do.

As an example, your backend code could use this:

export const api: Record<string, TinyApiHandler> = {
  hello: async ({ name }: { name: string }) => 'hi ' + name + ' — from the backend',
};

Which would then be available in the frontend as await tiny.api.call('hello', {...}).

Running the app is done via tinyjs dev which will load the app and enable HMR. In my testing, reloading was incredibly quick, but I didn't build anything large (yet).

Working with Alpine

The CLI has got a number of different scaffolds you can use, including Alpine. (And I should say - huge thanks to tarwin, the creator - who answered a lot of my questions via email and added stuff I asked for left and right!) I scaffolded one like that and one thing I'll note - the scaffold for different frameworks will differ a bit from the simple app you get by default. Each project has a tinyjs.json file which has metadata for the project, including where your backend file is and how the frontend works.

For my simple test, I wanted to check a few things. First, is CORS still enforced when using fetch? The short answer is yes, it is. The longer answer is that doesn't matter as you can use tiny.fetch instead. I thought it would be fun then to build a simple "RSS to HTML" application where I could enter an RSS feed and render the items.

I copied the browser distributable for the rss-parser project and simply included it in my HTML via a script tag. Here's the entirety of that file:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>RSS Parser</title>
  </head>
  <body>
    <section id="center" x-data="hello">
      <h1>RSS Parser</h1>
      <input x-model="url" placeholder="RSS feed URL" /> <button @click="parse">Parse</button>
      <template x-if="items.length > 0">
        <div>
        <h2>Items</h2>
        <ul>
          <template x-for="item in items" :key="item.link">
            <li>
              <a :href="item.link" target="_blank" x-text="item.title"></a>
            </li>
          </template>
        </ul>
        </div>
      </template>
    </section>
    <script src="/src/rss-parser.min.js"></script>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

That's all regular Alpine.js stuff, nothing fancy there. Now for the JavaScript:

import './style.css';
import 'simpledotcss/simple.min.css';

import Alpine from 'alpinejs';

Alpine.data('hello', () => ({
  name: 'world',
  url: 'https://www.raymondcamden.com/feed.xml',
  items: [],
  async init() {
  },
  async parse() {
    const parser = new RSSParser();
    let req = await tiny.fetch(this.url);
    let res = await req.text();
    let feed = await parser.parseString(res);
    this.items = feed.items;
  },
  async ask() {
    // Every function in the backend's api object is callable from the page.
    this.reply = await tiny.api.call('hello', { name: this.name })
  },
}))

Alpine.start()

A few things to note here - I've got some junk in the file still, like the ask function which was a leftover from the scaffold. The important bit is the parse function. The RSSParser object has the ability to parse a URL, but it uses fetch and is blocked by CORS. So instead I get the XML via tiny.fetch and pass it to parseString. And that's literally it. Here's a screenshot of the application running:

More Info

The docs obviously are a great place to start, and if you're curious about more of how it actually works, there's a good explanation of that as well.

My next demo is going to be testing an OAuth login flow with the application. The project supports registering custom URL schemes which is typically how that's handled so it should be possible, but I want to test it out myself of course. :)

Photo by Lukas Blazek on Unsplash

Adding My Latest CodePens to My Blog

2026-10-06T18:00:00+00:00

I've been a fan of CodePen for many, many years, and it's one of the few services I spend money on to help support. A few months back, they released an entirely new version that dramatically improved the service (CodePen 2.0) and it just made me more happy I was a supporter. Just a few days ago they announced more changes including a full API. I thought it would be fun to add a display of my recent pens. Yes, I thought that would be fun, because that's the kind of nerd I am.

Adding Dynamic Content to a SSG

It has been a very long time since I blogged about anything related to static site generators. There's no particular reason for that, but I figure this is a good time to bring up the topic again, specifically about how static sites can include dynamic content. There's two main paths to this.

The first is getting content at build time. For Eleventy, this is done with data files that are executed at build time and can return ad hoc data for use in your templates. As an example of that, the list of books I'm reading on my Now page are gathered via a GraphQL query:

const HARDCOVER_BOOKS = process.env.HARDCOVER_BOOKS;

export default async function() {

    if(process.env.SKIP_REMOTE_DATA) return [];
    if(!HARDCOVER_BOOKS) return [];
    let req;

    let body = `
    {
    user_books(
        where: {user_id: {_eq: 65213}, status_id: {_eq: 2}}
    ) {
        book {
            title
            image {
                url
            }
            contributions {
                author {
                    name
                }
            }
        }
    }
    }
    `.trim();

    try {
        req = await fetch('https://api.hardcover.app/v1/graphql', {
            method:'POST', 
            headers: {
                'authorization':HARDCOVER_BOOKS,
                'Content-Type':'application/json'
            },
            body:JSON.stringify({query:body})
        });
    } catch (e) {
        console.log('Hardcover API error', e);
        return [];
    }

    let data = (await req.json()).data.user_books.map(ob => ob.book);
    /* normalize authors */
    data = data.map(b => {
    b.authors = b.contributions.reduce((list,c) => {
        if(c.author) list.push(c.author.name);
        return list;
        },[]);
        return b;
    });

    return data;

};

The list of books returned there can then be rendered in my page template:

<div class="films">
{% for book in hardcover_books  %}
  <div class="film">
  {% if book.image != null %}
  <img src="https://res.cloudinary.com/raymondcamden/image/fetch/c_fit,w_216/{{book.image.url}}" alt="Cover of {{ book.title }}">
  {% else  %}
  <img src="https://res.cloudinary.com/raymondcamden/image/fetch/c_fit,w_216/https://static.raymondcamden.com/images/no_cover_available.jpg" alt="No Cover Available">
  {% endif %}
  "{{ book.title  }}" by {{ book.authors | join: ', ' }}
  </div>
{% endfor %}
</div>

As you can tell by the class names, I use the same logic for the films I've watched. In both cases, the data doesn't change terribly often so I'm ok with it being a bit out of date. I also publish something to the blog every week so it's never too far behind.

That's option 1. Option 2 is to use JavaScript and an API. That ensures the content is always 100% up to date but it has other trade offs. Some APIs don't have CORS support and APIs requiring keys that can't be in client-side code. In that case, I simply use a serverless function which Netlify makes pretty simple.

Getting my Pens

Ok, so given that I've decided to fetch my CodePens via JavaScript on the front-end via a serverless function, I first created a key in CodePen's settings, added to my Netlify configuration, and then wrote a quick and dirty function:

import { Context } from '@netlify/functions'

export default async (request: Request, context: Context) => {
  try {

    const CP_KEY = process.env.CODEPEN_KEY;

    const req = await fetch('https://api.codepen.io/v2/pens?sort=updated&direction=desc&access=Public&template=false&per_page=10', {
      method: 'GET',
      headers: {
        'Authorization': `Bearer ${CP_KEY}`,
        'Content-Type': 'application/json'
      }});
    
    let data = await req.json();

    // now lets do some mapping 
    data = data.map((pen: any) => {
      return {
        title: pen.title,
        url: pen.urls.editor,
        created_at: pen.created_at,
        updated_at: pen.updated_at,
        screenshot: pen.screenshot_urls.small
      }
    });

    return new Response(JSON.stringify(data), {
      headers: {
        'Content-Type': 'application/json'
      }
    })
  } catch (error) {
    return new Response(error.toString(), {
      status: 500,
    })
  }
}

I'm filtering by public pens and pens that aren't templates, sorted by last updated, and capping the list to 10. Then I map the data to a much smaller set of information as I only need part of what's returned in my front end.

Then all I needed to do was add it to my stuff page:

let $pens = document.querySelector('#pens');

let pens = await fetch('/.netlify/functions/get-codepens').then(r => r.json());

pens.forEach(p => {
	let pen = document.createElement('a');
	pen.className = 'penBox';
	pen.href = p.url;
	pen.target = '_blank';
	pen.rel = 'noopener noreferrer';

	let screenshot = document.createElement('img');
	screenshot.src = p.screenshot;
	screenshot.alt = '';
	screenshot.loading = 'lazy';

	let title = document.createElement('h3');
	title.textContent = p.title;

	pen.append(screenshot, title);
	$pens.append(pen);
});

Sweet. Of course, I think I'm the only person who visits either my stuff or now pages, but they make me happy!

A Not-So-Simple RSS App in TypeScript

2026-10-02T18:00:00+00:00

Ok, I lie, this demo is also pretty simple, but I wanted to break the pattern of the last few posts and at least pretend this example is a bit more complex. As I try to find excuses to write more TypeScript, I thought a great example of that would be a simple RSS aggregator. You hit the site, tell it the feeds you care about, and it renders a date sorted list of entries.

Because RSS typically can't be parsed in client-side JavaScript (don't know why? ask me below!) so I'd have to make use of a serverless function to proxy the calls (and at the same time, handle turning the XML into JSON).

Now, to be fair, I had built nearly the same thing back in February: Building an RSS Aggregator with Astro . This let me crib a bit of the work already done.

For this one, my stack was:

Vite for the build process
Alpine on the front end
TypeScript, as much as possible
Hosting on Netlify to make the serverless function easier to do
WebAwesome, which I've used in the previous ones, for the UI

You can test this yourself here: https://ts-rss-vite.netlify.app/. The full source is here: https://github.com/cfjedimaster/typescript-stuff/tree/main/rss-reader-1.

I figure yall have seen a few of these posts already, so let me focus on sharing the interesting stuff.

Run TypeScript Checking

I mentioned in my last post that when Vite would reload, it wasn't running the TypeScript checker. It only did this when a build was run. Enabling this checking while in dev mode took two steps.

First, simply add "strict": true, to tsconfig.json. Funny enough, in years past I can remember removing this when I was trying to get something working in a TypeScript app and I was too lazy to learn or figure it out.

Second, I had to add vite-plugin-checker to the app and modify vite.config.ts.

import { defineConfig } from 'vite';
import checker from 'vite-plugin-checker';

export default defineConfig({
  plugins: [checker({ typescript: true })],
});

This file doesn't exist by default so it was a net new file for the app. As soon as I did that, if I screwed something up on purpose (ahem, I only make mistakes on purpose), I saw errors in my terminal when Vite was running.

The Serverless Function

For the backend, I used the ntl CLI (this is Netlify's CLI tool) to scaffold a function, which helpfully includes a TypeScript option. For the most part, the code here is a simpler version of what I had done for the Astro site, specifically I didn't bother with BLOB caching. Anyway, here's that function:

import Parser from 'rss-parser';
import type { Context } from '@netlify/functions';

type FeedItem = {
  title: string;
  link: string;
  pubDate: string;
  content: string;
  feedTitle: string;
};

export default async (request: Request, context: Context) => {
  if (request.method !== 'POST') {
    return new Response('Method not allowed', {
      status: 405,
      headers: { Allow: 'POST' },
    })
  }

  try {
    const body: unknown = await request.json()
    const parser = new Parser();

    if (
      typeof body !== 'object' ||
      body === null ||
      !('feeds' in body) ||
      !Array.isArray(body.feeds)
    ) {
      return new Response('Request body must include a feeds array', {
        status: 400,
      })
    }
    console.log('Parsing feeds:', body.feeds);

    let reqs: Promise<any>[] = [];
    let items: FeedItem[] = [];

    for(const feed of body.feeds) {
      reqs.push(parser.parseURL(feed.url));
    }

    const results = await Promise.allSettled(reqs);
    for (const result of results) {
        if (result.status === 'fulfilled') {
            const feed = result.value;
            console.log(`Fetched feed: ${feed.title} with ${feed.items.length} items.`);
            let newItems:any[] = [];
            feed.items.forEach(item => {
                /*
                will use content as a grab all for different fields
                for example, netlify had summary, not content
                */
                let content = item.contentSnippet || item.summary || item.content || '';
                newItems.push({
                    title: item.title,
                    link: item.link,
                    content: content,
                    pubDate: item.pubDate,
                    feedTitle: feed.title
                });
            });

            items.push(...newItems);

        } else {
            console.error('Error fetching/parsing feed:', result.reason);
        }
    }

    // now sort items by pubDate descending
    items.sort((a, b) => new Date(b.pubDate) - new Date(a.pubDate));

    return new Response(JSON.stringify(items), {
        status: 200,
        headers: {
        "Content-Type": "application/json",
        },
    });

  } catch(e) {
    console.log(e);
    return new Response('Request body must be valid JSON', {
      status: 400,
    })
  }
}

This is all pretty simple but I liked having the ability to create a custom type for my results.

I did run into an error after I created the function - and it's one I've seen twice now. Something in what the Netlify CLI does breaks some dependencies and my app fails to run at all. I passed the error to Claude and what it said was:

The most likely cause is that adding the Netlify function pulled in an older 
typescript that's now being resolved instead of your project's version. This 
usually happens when a netlify/functions package has its own package.json, 
or when netlify-cli or the functions bundler is running an older tsc from a 
different node_modules.

Its suggested fix, npm i -D typescript@latest, was enough to correct it. I definitely won't forget this when it happens again.

What's Next?

This has been so fun, at least for me. I've got my next two ideas ready! (Well, in my head at least. ;)

A Simple Weather App in TypeScript

2026-09-26T18:00:00+00:00

Happy Sunday, my fellow nerds. If you've been keeping up with my posts (all 4 of you - thank you!) then you know I've been experimenting with TypeScript (and Vite) recently. This past week I decided to try building a real "app", and of course by app I mean something incredibly small, but a bit "real world"-ish to kind of get a feel for what the development process felt like.

I decided on a fairly simple weather application. The application would prompt you for a location. That location gets geocoded to longitude and latitude values. With those values, I'd grab a simple weather forecast. After you add one, you can add another, and delete as well. Finally, all the values are stored in local storage so that on reload you get the same values loaded immediately.

If you actually want to see this - you can head over to https://weather-app-ts-vite-alpine.netlify.app/. The complete source may be found here: https://github.com/cfjedimaster/typescript-stuff/tree/main/weather-demo. Now let me dig into what I discovered while building it.

The One Thing

Let me start off with what I think is the biggest thing that clicked with me. While building out the various parts and using (at least some) of the TypeScript features, I immediately ran into probably the biggest win - immediate feedback in my editor when I had screwed things up. And yea, I know that's something TypeScript provided since day one, but it's also a bit different to kind of see it in action while building the app. Especially since I had two or three times when I had to refactor how I was doing things. Having the types in place (specifically for my remote API calls) helped keep things in order across the different moving parts.

I also found myself being forced to think more about how those parts interacted. So for example, a wrapper to my geocoding service - I instinctively knew what I had wanted - but having it spelled out in code actually made me see possible issues - modify my approach - and so forth - all earlier than I would have in my usual development process.

Again - this wasn't necessarily a surprise to me. This all fell in line with what I knew about TypeScript and what I had expected. But never having built an app from scratch with TypeScript before it still felt pretty cool to actually see all this play out.

The Architecture

It feels a bit silly to talk about the architecture of such a small little app, but this is how I built out the parts.

Once again, I used Vite.
On top of that, I used Alpine.js. In case you missed it, my last blog post discussed how to do this.
The main page handles displaying the 'weather cards' along with a simple form to add new locations.
When a location is entered, I use the excellent Geocodio API to translate it into longitude and latitude.
With that information, I use the Pirate Weather API to get the forecast.

The UI

As mentioned above, this was a Vite and Alpine app, but I also decided to try adding a UI library in as well. I picked Web Awesome primarily for the Card element. I've used this library in the past (when it was called Shoelace) and I really like it, especially as it uses web components. They also make it easy to only import what you need.

In my main.ts, this came down to:

import '@awesome.me/webawesome/dist/styles/webawesome.css';
import '@awesome.me/webawesome/dist/components/card/card.js';
import '@awesome.me/webawesome/dist/components/input/input.js';
import '@awesome.me/webawesome/dist/components/button/button.js';

With this in place, it was a simple matter to use the components. As an example:

<div class="wa-flank:end wa-gap-xs">
<wa-input placeholder="New Location (America, Canada, Mexico, UK only)" x-model="newLocation"></wa-input>
<wa-button variant="brand" @click="addLocation(newLocation)">Add</wa-button>
</div>

Make note of the classes on the div tag there. That comes from Web Awesome's various utility classes and this was a place where I leaned on my AI tool to help.

Here's the entirety of the main HTML page which shows you both Web Awesome in play as well as my Alpine directives:

<!doctype html>
<html lang="en" class="wa-dark">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Weather Demo</title>
  </head>
  <body>
    <div x-data="app" class="container wa-stack">

      <header>
        <h1>Weather Demo</h1>
      </header>

      <template x-if="locations.length === 0"> 
        <p>No locations added yet. Add a location to get started.</p>
      </template>
      <div class="wa-grid wa-gap-1" style="--min-column-size: 30ch;">
      <template x-for="(location,index) in locations" :key="location.name">
        <wa-card class="card-basic" >
          <h3 slot="header" x-text="location.name"></h3>
          <wa-button appearance="plain" @click="removeLocation(index)" slot="header-actions">
            <wa-icon name="trash" variant="solid" label="Delete"></wa-icon>
          </wa-button>
          <template x-if="location.weather">
            <p x-html="`Temperature: ${location.weather.temperature}°F<br/>Condition: ${location.weather.summary}<br>Low: ${location.weather.low}°F<br/>High: ${location.weather.high}°F`"></p>
          </template>
          <template x-if="!location.weather">
            <p>Loading weather data...</p>
          </template>
        </wa-card>
      </template>
        </div>

      <div class="wa-flank:end wa-gap-xs">
      <wa-input placeholder="New Location (America, Canada, Mexico, UK only)" x-model="newLocation"></wa-input>
      <wa-button variant="brand" @click="addLocation(newLocation)">Add</wa-button>
      </div>

    </div>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

The Three "Services"

I'm using "services" in quotes there as it feels a bit overly dramatic to name it as such, but I broke out three parts into their own files - one for geocoding, one for the weather, and one for storage. Let's start with storage first.

This file wraps the calls to LocalStorage and in theory - I could easily switch out to IndexedDB in the future - but I'd have to mark the functions async of course:

import type { SavedLocation } from './types';

// This is where it's stored in localStorage. 
const KEY = 'weather-locations';

// Type guard: checks at runtime that an unknown value really is a SavedLocation.
// localStorage can contain anything (old versions of your app, manual edits),
// so we validate instead of trusting it.
// Ray, in case you forget, the value is means that if the function returns true, 
// it's ok for TS to consider the value as of type SavedLocation
function isSavedLocation(value: unknown): value is SavedLocation {
  if (typeof value !== 'object' || value === null) return false;
  const v = value as Record<string, unknown>;
  return (
    typeof v.name === 'string' &&
    typeof v.longitude === 'number' &&
    typeof v.latitude === 'number'
  );
}

export function getLocations(): SavedLocation[] {
  const locations = localStorage.getItem(KEY);
  if(!locations) return [];

  const parsed = JSON.parse(locations);
  return Array.isArray(parsed) ? parsed.filter(isSavedLocation) : [];
}

export function addLocation(location: SavedLocation): void {
  const locations = getLocations();
  locations.push(location);
  localStorage.setItem(KEY, JSON.stringify(locations));
}

export function removeLocation(index: number): void {
  const locations = getLocations();
  locations.splice(index, 1);
  localStorage.setItem(KEY, JSON.stringify(locations));
}

The first thing you see on top is importing a type that defines what a 'stored location' is in terms of my application. From that file, here is the definition:

export type SavedLocation = {
  name: string;
  longitude: number;
  latitude: number, 
  weather?: WeatherData;
};

This should mostly make sense - the name comes from the user, the longitude and latitude from the geocoding service.

The weather part actually comes after the app loads in the existing values from local storage and hits the weather API. There's a part of me that looks at that and thinks maybe I should have a type for the "stored" value and one for the "live" value. I also think I could possibly cache the weather so that on reload it's quicker, but weather data is the kind of thing that gets stale pretty quickly.

Here's that file:

import type { WeatherData } from './types';

const KEY = import.meta.env.VITE_PIRATE_KEY as string;

export async function getWeather(lat: number, lng: number): Promise<WeatherData> {
    const req = await fetch(`https://api.pirateweather.net/forecast/${KEY}/${lat},${lng}?units=us&exclude=minutely,hourly,alerts,flags`);
    const res = await req.json();

    return {
        summary: res.currently.summary,
        temperature: res.currently.temperature,
        low: res.daily.data[0].temperatureLow,
        high: res.daily.data[0].temperatureHigh
    };

}

And here's the type:

export type WeatherData = {
  summary: string;
  temperature: number;
  low: number;
  high: number;
}

Finally, here's the geocoding wrapper:

import type { GeoCodedLocation } from './types';

// Only the fields we use from Geocodio's "simple" format
type GeocodioSimpleResponse = {
  lat?: number;
  lng?: number;
};

const KEY = import.meta.env.VITE_GEOCODIO_KEY as string;

export async function geoCode(location: string): Promise<GeoCodedLocation> {
    const req = await fetch(`https://api.geocod.io/v1.7/geocode?q=${encodeURIComponent(location)}&format=simple&api_key=${KEY}`);
    const res = (await req.json()) as GeocodioSimpleResponse;

    if(!res || !res.lat || !res.lng) {
        throw new Error('No results');
    }

    return { lat: res.lat, lng: res.lng };
}

You'll notice I do the HTTP call slightly different here. I've got an inline type here that defines what is being used from Geocodio. I'll be honest and say I want to think about these two approaches and figure out when I should use each. I mean, when you look at GeoCodedLocation:

export type GeoCodedLocation = {
  lat: number;
  lng: number;
};

I honestly don't get the point of the inline type as well. I was having AI help me a bit, so it's on me to nail down if this makes sense in the context of the file. I'll be returning to that soon.

The Core App

Now let's put it together with my core file - which is mainly Alpine.js specific:

import Alpine from 'alpinejs';

import '@awesome.me/webawesome/dist/styles/webawesome.css';
import '@awesome.me/webawesome/dist/components/card/card.js';
import '@awesome.me/webawesome/dist/components/input/input.js';
import '@awesome.me/webawesome/dist/components/button/button.js';
import './style.css';

import type { SavedLocation } from './types';
import { getLocations, addLocation, removeLocation } from './storage';
import { getWeather } from './weather';
import { geoCode } from './geocode';

Alpine.data('app', () => ({
  locations: [] as SavedLocation[],
  newLocation: '',
  init() {
    this.locations = getLocations();
    if(this.locations.length > 0) {
      this.hydrateWeather();
    }
  },
  async addLocation(location: string) {
    if(!location) return;
    const geo = await geoCode(location);
    const newLoc: SavedLocation = { name: location, longitude: geo.lng, latitude: geo.lat };
    this.locations.push(newLoc);
    // just noticed my method is addLocation as is the imported one. works but - eww. 
    addLocation(newLoc);
    this.newLocation = '';
    // in theory it is wasteful to hydrate ALL of them, but it's a super quick call
    this.hydrateWeather();
  }, 
  removeLocation(index: number) {
    this.locations.splice(index, 1);
    // same issue with naming - advice?
    removeLocation(index);
  },
  async hydrateWeather() {
    for(const loc of this.locations) {
      const weather = await getWeather(loc.latitude, loc.longitude);
      loc.weather = weather;
    }
  }
}));

Alpine.start();

If you actually took the time to read all that, you can see I wrote a few questions to myself. By accident, I ended up having Alpine methods with the same name as methods in my services, and that really bugs me... but it also works... so... yeah. It's kinda clear that this.something is Alpine and something is being imported in, but I still don't care for that. How would you rename things? (And I'd assume the rename would be on the Alpine side.)

I also notice a few lines where I didn't define my type. A quick search shows that by adding strict:true to my tsconfig.json would fix that. I know in the past I've seen that in projects and it's annoyed the heck out of me, so I get why Vite's scaffold doesn't include it, but for my next project, I'm going to turn that on so I can be a bit more precise in my learning with TypeScript.

Your Turn!

Ok, I know blogging is dead (again) and no humans read these posts again, but if you are reading this, and know TypeScript well, I'd love any and all feedback! Give me a comment below and help me keep learning this.

Photo by Patrick Fore on Unsplash

A Simple Alpine.js Template with Vite and TypeScript

2026-09-22T18:00:00+00:00

This will be a quick one - but as I think more about TypeScript and how I'd like to learn (and play, and build silly demos), I naturally thought it may make sense to look at how I'd use Alpine.js with that stack. Alpine's been my go to library for web apps that reach the level of complexity where I'd like some help with DOM manipulation and such. I don't always use it, because (imho) the default stack should be as vanilla as possible (obviously I'm going a bit off ranch with these explorations into TypeScript and Vite) but Alpine is lightweight and simple and just a great little library in general. What follows isn't necessarily a "template" as it's got a bit of template code with it, but I thought it would be helpful to share. As always, let me know what you think!

Step One - the Scaffold

In my first post a few days ago, I mentioned that the Vite scaffold support lets you create a vanilla application with TypeScript. I used that for my code and removed as much of the demo code as I could. I do wish Vite's template was a bit more minimal.

Step Two - Adding Alpine

Usually I make use of the Alpine CDN in my demos, for this one, I instead installed it as a dependency. I also installed the Alpine types dependency. Here's my package.json:

{
  "name": "alpine-test-1",
  "private": true,
  "version": "0.0.0",
  "type": "module",
  "scripts": {
    "dev": "vite",
    "build": "tsc && vite build",
    "preview": "vite preview"
  },
  "devDependencies": {
    "@types/alpinejs": "^3.13.11",
    "typescript": "~6.0.2",
    "vite": "^8.3.0"
  },
  "dependencies": {
    "alpinejs": "^3.17.4"
  }
}

Step Three - the HTML

Ok, so this part is really simple. Alpine "ties" to your DOM usually via an x-data attribute. That means this is the bare minimum:

<div x-data="app">
</div>

But of course you'll have more Alpine directives and more HTML. Also, "app" is not required, but is the name I pretty much use all the time. For my template/demo, I output a couple of variables and included a few click directives just to test stuff out. Oh, I also added Simple.css to just to make it look prettier. That's absolutely not necessary. The Vite demo actually imports CSS in their main TypeScript file (you can see that on Stackblitz here) and I'm not sure how I feel about that. I know it minimizes the code, but it feels really weird to me. Anyway, here's my HTML:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <link rel="stylesheet" href="https://cdn.simplecss.org/simple.min.css">
    <title>alpine-test-1</title>
  </head>
  <body>
    <div x-data="app">
      <p>
      <span x-text="message"></span>
      </p>
      <p>
      <button @click="meow()">Meow (default)</button>
      <button @click="meow('Purr...')">Meow (custom)</button>
      </p>
      <ul>
        <template x-for="(cat, index) in cats" :key="index">
          <li x-text="cat.name"></li>
        </template>
      </ul>
    </div>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

Step Four - Enter the TypeScript

Ok, for the final bit - my TypeScript code:

import Alpine from 'alpinejs';

type Cat = {
  name: string;
  breed: string;
  gender: 'male' | 'female';
};

Alpine.data('app', () => ({
  message:'Hello from Alpine!',
  cats: [] as Cat[],
  init() {
    this.cats.push({ name: 'Whiskers', breed: 'Siamese', gender: 'male' });
    this.cats.push({ name: 'Fluffy', breed: 'Persian', gender: 'female' });
  },
  meow(message:string = 'Meow!') {
    alert(message);
  }
}));

Alpine.start();

Let me point out the important bits. Unlike my usual Alpine demos, I import Alpine here from the local install. I also need to fire Alpine.start() manually. But outside of that, it's pretty vanilla Alpine - define the app and include relevant variables and methods, which in this case is pretty small.

Now obviously I'm trying to learn TypeScript as well, but I kept it pretty short here. I've defined a type for Cat and when I worked with the data, my editor (Visual Studio Code) provided support as I'd expect - it knew the right parts of a cat and correctly flagged an error if I tried to include something that wasn't defined in the type.

As a reminder, this is all done in the editor - it wouldn't be a "real" error in production - but the idea here - and the benefit of TypeScript - is that I'd (hopefully!) catch it much earlier.

Outside of that, you can also see where I define cats as an array of Cat and specify that the message argument to meow is string.

Again - this is pretty minimal TypeScript usage, but I dig it, and I can really see how in some of my larger Alpine demos in the past, the additional safety/checking/etc would have been real helpful I think.

There Is No Step Five

If you want the code to try it yourself, you can copy it from here: https://github.com/cfjedimaster/typescript-stuff/tree/main/alpine-test-1. I know this was pretty short, but I'd still love any feedback or advice, so hit up the comments below!

Links For You (9/20/26)

2026-09-20T18:00:00+00:00

Happy "Football is Back" season to those of you who celebrate. I'm currently watching my Saints take on the Ravens (who are also a favorite of mine) and hoping for our first win. The last few weeks have been incredibly busy (I feel like I always say that, sorry) with a trip for work that then morphed into a short vacation with my wife and I which included my first Blizzcon (which is freaking cool as hell) and our first visit to Disneyland. (We've been to Disney World a few times.) I think we both agreed that Disney World is cooler, but the crowds and - most importantly - the weather - was much better in California.

RSS Lookup

First up for the links today is RSS Lookup, a simple web site that lets you paste in a URL and see if it has a RSS feed. Not every site does a good job of letting you know about their RSS options so this can make it easier. Most likely I think the bookmarklet will be more useful to folks.

If your curious, here's the meta tag used to signify a site's feed:

<link rel="alternate" type="application/rss+xml" 
title="Your Site Title - RSS Feed" href="https://example.com" />

Interfaces, a collection by Ron Domingue

Ron is someone I've known for a while, a local down here in Louisiana, who has done some incredibly stunning visual works. His Interfaces is a collection of various UI interfaces for different types of data. I'd be hard pressed to pick a favorite, but Landfall is a stunning visualization of hurricane tracks and their landfall.

Remember Imagemaps?

Imagemaps are one of those old web techs that used to be everywhere, and then disappeared. In case you don't remember, the idea was that one image on a web page, when clicked, could have multiple different destinations based on where you clicked. Typically this was defined in HTML with coordinates mapping to URLs. But you could also handle the location on the server side as well. In that form, the coordinates are included in the URL and your server side tech has to handle figuring out what goes where.

This post, "Today I Rescued 7,234 Old GIFs", by Dan Q explores how he attempted (and succeeded) in scraping a bunch of Gif icons for an old directory.

Not gonna lie - kinda miss the old web. :)

Just For Fun

Ok, usually I share cool music videos here, but today I want to share something different. My father-in-law shared this short with us and while it's marked as comedy, it's a pretty deep 30-ish minute short staring Jane Kaczmarek. It's definitely worth your time!

It's only a decade late, I'll learn TypeScript!

2026-09-18T18:00:00+00:00

I've been a bit worried lately. Of course, my friends will tell you that's my norm. But more specifically, I've been worried about my coding skills. As I use AI to generate more and more code, and it does that job well, I kinda miss actually writing code. I've also had a bit of writer's block in terms of topics to cover, and especially in the area of the web platform. A few days ago it occurred to me - I've never really dug into TypeScript. Sure, I've used it, many times, in the fourteen or so years it's been out, but many times I kinda guess at what I'm doing and it was never my default for projects. Partly that's due to my philosophy of avoiding a build step in my projects and just KISS in general.

But as I said - the inspiration hit me this past week and I thought I'd do some digging. Here's a few initial thoughts and experiments. Oh, and I still used AI a bit and I'll explain exactly how in the post below.

TypeScript via Vite

Working with TypeScript can be as simple as npm i -g typescript and then tsc somefile.ts. I decided to use Vite instead as it's focused on web projects and most of my development involves web projects. I assume most of my readers know of Vite, but if you somehow have managed to avoid hearing about it or using it yet, it is a lightning quick build tool for web projects. By "lightning quick" I mean that I still remember the first time I used it thinking it had failed to actually do anything - that's how quick it works.

I also appreciated the fact that Vite's CLI supports a vanilla-ts scaffold that is really lightweight. On the other hand, I'm not necessarily a fan of what it actually shows as it feels a bit like bad practice, specifically an index file with just one div:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" type="image/svg+xml" href="/favicon.svg" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Vite + TS</title>
  </head>
  <body>
    <div id="app"></div>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

And then injects a bunch of HTML in main.ts:

import './style.css'
import heroImg from './assets/hero.png'
import typescriptLogo from './assets/typescript.svg'
import viteLogo from './assets/vite.svg'
import { setupCounter } from './counter.ts'

document.querySelector<HTMLDivElement>('#app')!.innerHTML = `
<section id="center">
  <div class="hero">
    <img src="${heroImg}" class="base" width="170" height="179">
    <img src="${typescriptLogo}" class="framework" alt="TypeScript logo"/>
    <img src="${viteLogo}" class="vite" alt="Vite logo" />
  </div>
  <div>
    <h1>Get started</h1>
    <p>Edit <code>src/main.ts</code> and save to test <code>HMR</code></p>
  </div>
  <button id="counter" type="button" class="counter"></button>
</section>

<div class="ticks"></div>

<section id="next-steps">
  <div id="docs">
    <svg class="icon" role="presentation" aria-hidden="true"><use href="/icons.svg#documentation-icon"></use></svg>
    <h2>Documentation</h2>
    <p>Your questions, answered</p>
    <ul>
      <li>
        <a href="https://vite.dev/" target="_blank">
          <img class="logo" src="${viteLogo}" alt="" />
          Explore Vite
        </a>
      </li>
      <li>
        <a href="https://www.typescriptlang.org" target="_blank">
          <img class="button-icon" src="${typescriptLogo}" alt="">
          Learn more
        </a>
      </li>
    </ul>
  </div>
  <div id="social">
    <svg class="icon" role="presentation" aria-hidden="true"><use href="/icons.svg#social-icon"></use></svg>
    <h2>Connect with us</h2>
    <p>Join the Vite community</p>
    <ul>
      <li><a href="https://github.com/vitejs/vite" target="_blank"><svg class="button-icon" role="presentation" aria-hidden="true"><use href="/icons.svg#github-icon"></use></svg>GitHub</a></li>
      <li><a href="https://chat.vite.dev/" target="_blank"><svg class="button-icon" role="presentation" aria-hidden="true"><use href="/icons.svg#discord-icon"></use></svg>Discord</a></li>
      <li><a href="https://x.com/vite_js" target="_blank"><svg class="button-icon" role="presentation" aria-hidden="true"><use href="/icons.svg#x-icon"></use></svg>X.com</a></li>
      <li><a href="https://bsky.app/profile/vite.dev" target="_blank"><svg class="button-icon" role="presentation" aria-hidden="true"><use href="/icons.svg#bluesky-icon"></use></svg>Bluesky</a></li>
    </ul>
  </div>
</section>

<div class="ticks"></div>
<section id="spacer"></section>
`

setupCounter(document.querySelector<HTMLButtonElement>('#counter')!)

I'm probably being real nit picky here, but having 99% of the HTML for something in JavaScript versus HTML that gets enhanced feels off to me. But again - I'm being picky, and the actual code spit out is pretty minimal. (I could go on for ages about what's "appropriate" for scaffolded projects and such. Give me a soap box and I'll tell you more.)

So yeah, that's how I started. I pretty much nuked most of the code in main.ts and simplified even more.

I mentioned earlier I still used a bit of AI in my exploration, and one example was to help clarify things a bit. For example, my very high level basic understanding of TypeScript basically came down to type annotations like so:

let name:string = "Ray";

This line in the sample code confused me:

document.querySelector<HTMLDivElement>('#app')!.innerHTML = `

So I simply asked Claude to explain it:

The <HTMLDivElement> (generic type argument)

By default, querySelector returns Element | null. Element is a very generic type — 
TypeScript doesn't know whether it's a div, an input, an SVG circle, etc. That 
matters because different elements have different properties: Element doesn't 
have .value, for example, but HTMLInputElement does.

Writing querySelector<HTMLDivElement>('#app') tells TypeScript: "trust me, the 
thing this selector finds is a div." So the return type becomes 
HTMLDivElement | null instead of Element | null, and you get proper autocomplete 
and type checking for div-specific properties.

Like the !, this is a compile-time-only assertion — TypeScript doesn't verify 
it. If #app were actually a <span>, the code would still compile and run; you'd 
just have a lying type.

Fun fact: in this particular line the generic is technically unnecessary, since 
.innerHTML exists on Element anyway. It's there mostly out of habit/convention 
(this looks like the Vite starter template). It becomes genuinely useful when 
you need element-specific properties like .value, .src, or .checked.

Cool. And this is something I've really liked about AI in the past. I feel like my question, a particular syntax being used, wouldn't Google well and AI tools do a better job of getting to the right answer.

At this point, I felt ready to write something.

Actually, let's not build for the web...

So when I figured out a good simple thing to build, I realized I didn't actually need a web UI for it, at least not initially, so I did a quick pivot and looked up info on vitest, a "Vite-native" testing framework. I actually don't have a huge amount of experience with unit tests as so much of my work is educational, demo based, and such, that tests aren't really required. That being said, I've written them, I'm familiar with Jest (which vitest is compatible with), so it seemed like an easy win.

I did a quick npm i -D vitest and added this to my package.json scripts block: "test": "vitest"

This let me run npm run test in my terminal and get immediate feedback on what I was writing.

Roll the dice...

About five years ago, I thought it would be fun, and surely pretty simple, to build an RPG in Vue.js (here's the first entry: "Testing Vue.js Application Files That Aren't Components". I never finished that project, but I don't care - it was fun to work on.

As part of that project, I built a simple "dice" utility that supported typical D&D dice rolls of the form: xDy. This translates to roll a Y-sided dice X times. It can get fancy too, so 2d6+2 means roll a six sided die two times and then add two tp the final result. (You could imagine a scenario where a player is attempting to do something they are talented at, so the +2 represents a bonus to their chance to do the thing.)

The code for that looked like so:

export const dice = {

	roll(style) {
		let bonus=0, total=0;
		if(style.indexOf('+') > -1) {
			[style, bonus] = style.split('+');
		} 
		
		let [rolls, sided] = style.split('d');
		
		//console.log(rolls, sided);
		for(let i=0;i<rolls;i++) {
			total += getRandomIntInclusive(1, sided);
		}
		total += parseInt(bonus);
		return total;
	}
}

function getRandomIntInclusive(min, max) {
  min = Math.ceil(min);
  max = Math.floor(max);
  return Math.floor(Math.random() * (max - min + 1)) + min; //The maximum is inclusive and the minimum is inclusive 
}

I thought a good first test would be to attempt to rewrite this in a TypeScript file. I actually broke it out into two files, one for the roll action and a 'util' one for the random number selection.

I'll share the utility function first as it was the simplest change:

export function getRandomInt(min: number, max: number): number {
  min = Math.ceil(min)
  max = Math.floor(max)
  return Math.floor(Math.random() * (max - min + 1)) + min
}

This was really simple - just adding types to my arguments and result. I also removed inclusive from the name as I never see myself needing a non-inclusive random number selection.

The test for this was pretty simple too:

import { describe, it, expect } from 'vitest'
import { getRandomInt } from './utils'

describe('getRandomInt', () => {
  it('returns a number between min and max', () => {
    const min = 1;
    const max = 2;
    const randomInt = getRandomInt(min, max);
    expect(randomInt).toBeGreaterThanOrEqual(min);
    expect(randomInt).toBeLessThanOrEqual(max);
  })

  it('returns an integer', () => {
    const randomInt = getRandomInt(1, 10);
    expect(Number.isInteger(randomInt)).toBe(true);
  })
});

I discovered after writing this that you can actually screw with Math.random() which is cool af as the kids say, so I may return to this. But now let's turn to the dice stuff which got REALLY complicated, but in a fun way.

My first version went a bit like this:

import { getRandomInt } from './utils.ts';

export const dice = {

	/*
	xdy

	x rolls of a y sided dice

	xdy+n
	xdy

	x rolls of a y side dice + n
	*/
	roll(styleInput: string): number {
		let bonus:number=0, total:number=0;
        let bonusStr:string='';
        let style = '';

        if(styleInput.indexOf('+') > -1) {
			[style, bonusStr] = styleInput.split('+');
			bonus = Number(bonusStr);
		} else style = styleInput;
		
		const [rollsStr, sidedStr] = style.split('d');
		const rolls = Number(rollsStr);
		const sided = Number(sidedStr);

		//console.log(rolls, sided);
		for(let i=0;i<rolls;i++) {
			total += getRandomInt(1, sided);
		}

		total += Number(bonus);
		return total;
	}
}

And you'll notice it's a bit longer than the original version, and I don't mean more characters, I expected that, but some things took me a bit by surprise. Take this (original) line:

let [rolls, sided] = style.split('d');

My original code just coerced rolls into a number, which is bad, but I tried this and it didn't work:

let [rolls:number, sided: number] = style.split('d');

Which is obvious - the result of the string split function is strings. What didn't occur to me at the time was to chain to map:

let [rolls, sided] = s.split('d').map(Number);

Live and learn, right? I built some basic tests for that and was curious what else I could do. I turned to my AI agent (Claude in this case) and just asked what other 'dice format' options were available, and was pleasantly surprised to discover quite a few. In particular I thought these made sense:

Keep highest, lowest, using KH or KL. So for example, 3D6KH1 means roll a six sided die three times, keep the highest one.
Given a dice string input, what's the lowest value, and what's the highest value?

At this point, I decided to let AI help me write a bit of the code and handle updating the library to be a bit more flexible. The final result supports all of the above:

import { getRandomInt } from './utils.ts';

const VALID_ROLL_REGEX =
    /^(\d*)d(\d+)(?:(kh|kl|dh|dl)(\d+))?([+-]\d+)?$/i;

function validRoll(style: string): boolean {
    return VALID_ROLL_REGEX.test(style);
}

function parseRoll(styleInput: string) {
    if (!validRoll(styleInput)) {
        throw new Error(`Invalid dice roll style: ${styleInput}`);
    }

    const match = styleInput.match(VALID_ROLL_REGEX)!;

    return {
        rolls: match[1] ? Number(match[1]) : 1,
        sided: Number(match[2]),
        keepMode: match[3]?.toLowerCase(),
        keepCount: match[4] ? Number(match[4]) : 0,
        bonus: match[5] ? Number(match[5]) : 0,
    };
}

function applyKeepDrop(
    dice: number[],
    keepMode: string | undefined,
    keepCount: number,
): number[] {
    if (!keepMode || keepCount === 0) {
        return dice;
    }

    dice.sort((a, b) => a - b);

    switch (keepMode) {
        case 'kh':
            return dice.slice(-keepCount);
        case 'kl':
            return dice.slice(0, keepCount);
        case 'dh':
            return dice.slice(0, -keepCount);
        case 'dl':
            return dice.slice(keepCount);
        default:
            return dice;
    }
}

export function roll(styleInput: string): number {
    const { rolls, sided, keepMode, keepCount, bonus } =
        parseRoll(styleInput);

    const dice: number[] = [];

    for (let i = 0; i < rolls; i++) {
        dice.push(getRandomInt(1, sided));
    }

    const total = applyKeepDrop(dice, keepMode, keepCount)
        .reduce((sum, die) => sum + die, 0);

    return total + bonus;
}

export function rollWithAdvantage(styleInput: string): number {
    return Math.max(roll(styleInput), roll(styleInput));
}

export function rollWithDisadvantage(styleInput: string): number {
    return Math.min(roll(styleInput), roll(styleInput));
}

export function minRoll(styleInput: string): number {
    const { rolls, keepMode, keepCount, bonus } = parseRoll(styleInput);
    const dice = Array(rolls).fill(1);

    return applyKeepDrop(dice, keepMode, keepCount)
        .reduce((sum, die) => sum + die, 0) + bonus;
}

export function maxRoll(styleInput: string): number {
    const { rolls, sided, keepMode, keepCount, bonus } =
        parseRoll(styleInput);
    const dice = Array(rolls).fill(sided);

    return applyKeepDrop(dice, keepMode, keepCount)
        .reduce((sum, die) => sum + die, 0) + bonus;
}

I won't share the entire test file (don't worry, I'll link to the repo in a bit), but as I mentioned above, you can actually "hack" random and that's really freaking sweet. For example, here is a test for rolls where you drop the lowest value:

it('handles drop lowest', () => {
    const spy = vi.spyOn(Math, 'random')
        .mockReturnValueOnce(0.1)  // first roll → low
        .mockReturnValueOnce(0.9);  // second roll → high

    const result = roll('2d6dl1');
    expect(result).toBe(6);

    spy.mockRestore();
});

Looking at it just now I see the second mock isn't needed - I'll fix that (eventually, honest) - but you get the idea.

The bits, and nothing but the bits...

So this isn't a "real" project, but I loved getting my feet wet in TypeScript and - tbh - just writing some darn code. The repo is here: https://github.com/cfjedimaster/typescript-stuff/tree/main/vite-one

I've already got an idea for a next project, one that will actually have a web presence, so I'll share that when I get the time.

And this is where you come in. I'd be willing to bet 99% of you are writing TypeScript daily and have plenty of comments - so let me know. Just be gentle. Please.

Building a Document Q&A System with On-Device AI

2026-09-06T18:00:00+00:00

Every now and then I build a demo for a presentation and think to myself - this deserves its own blog post. I then promptly forget to actually do that. Even better, I completely forget to even show the demo in the presentation. A few weeks ago I made my first presentation at RenderATL and gave my talk on Chrome's on-device AI technology. I've been blogging about this particular set of APIs for a few years now and I've given talks on it at numerous conferences. While these APIs are still evolving, many of them (and the ones I'm using today in particular) are now fully GA for Chrome. For this demo, I put together a few things I've done before into one cohesive tool - a completely client-side application that lets you pick a file, get a summary, and then chat with it.

The Stack

The demo is built from a few different things:

First, I'm making use of the incredibly excellent officeParser library by Harsh Ankur. This library can take any Office document, or PDF, or ODT, or CSV, and so on, and creates a parsed version you can do nearly anything with. For me, the most important feature is the ability to convert the file into Markdown which can then be used with AI.
Next, it makes use of Chrome's Summarizer API which - you guessed it - provides summaries of textual input.
Finally, it makes use of Chrome's Prompt API to let you ask questions about the input.

The web app itself is a simple Vite app using vanilla JavaScript. I used my AI agent to set up the application and create the design and there was quite a bit of back and forth to get things locked down, but the end result is pretty cool I think.

The App

Ok, I'm obviously going to link to it, and the source, too, but I thought I'd share a few screenshots for people who may be on Safari, or maybe reading this on iOS where Chrome is locked down to the Safari engine.

On opening the app, you get a three panel UI. The left side is for selecting and previewing the document. The upper right is for the summary. The rest of the right column is for Q and A:

I selected my resume and after a few seconds, I get a summary. Now - I should clarify - the reason it works fast for me is that Chrome has already downloaded the roughly 4 gig model. That's absolutely not insignificant. But it's also a model shared by the browser for any web site making use of these APIs so it's not something a user has to download again and again.

Here's the summary that was displayed:

This is nearly perfect. For some reason it thinks I worked at Microsoft and as far as I know I only mention Microsoft once in the resume and it's in regard to work done at Webflow.

But that brings up a great first use of the Q and A - I specifically asked if Ray worked at Microsoft and I got the proper response:

"The provided document does not mention Ray Camden working at Microsoft."

I asked a followup question about PHP and I liked the response:

Honestly that's a pretty deep answer and kind of impressive I think.

Anyway, if you like this, and are using an up to date Chrome (on desktop or Android), you can check it out here: https://document-question-answer.netlify.app/. You can peruse the source up here: https://github.com/cfjedimaster/doc_qa

My Family Allowance - a Simple Allowance Tracking Site

2026-09-02T18:00:00+00:00

As you can probably tell, I've been on a bit of a builder kick the last few weeks. Today's "release" (it's been live for a few days already) is a tool to help fix a manual process we had in our family - tracking allowance for the kids.

Previously we made use of a Google Sheet. Each kid had a column. When a kid would ask for something, we'd look to see when we last added allowance, multiply the number of weeks by their rate, add it, and then add another row to reduce by the amount they were spending. A simple formula on the right hand side would give a running total so they could see what their current balance was.

I decided to take this manual process and turn it into a proper application.

Using Cursor, I created an application with the following features:

The parent signs up with their Google account.
They then have a simple admin to add, edit, and delete kids while setting their weekly allowance.
The parent can then add or remove funds when necessary.
Every Sunday, automatically, allowance is paid.
They are given a unique URL for their family and can set a basic password. A great idea for this would be the same password used for wifi in the house.
The "family" URL lets kids see their totals, and even click in to see a transaction history if they want to remember what they spent money on.

The stack is Astro, hosted on Netlify, with their Netlify DB as the storage system.

That's it! You can check it out here: https://www.myallowance.family/. If you want to check out the source, you can check out the repo: https://github.com/cfjedimaster/myfamilyallowance

Photo by Igal Ness on Unsplash