Gergő Takács

What do I use AI for?

Gergő Takács — Thu, 14 Nov 2024 24:00:00 GMT

For better or worse generative AI is a part of our lives now. As a tool it can be entertaining but useless, very handy, or even downright scary. People's opinion on it is just as varied. Doomers think the current generation of AI is the harbinger of a more powerful AGI that will bring the end of civilization. On the other end of the spectrum there are people who think it's the best thing since sliced bread. For companies it is a money printing machine. Everyone is trying to replicate OpenAI's success. This is how you end up with AI in your mouse software.

I'm – and I assume most people are – somewhere in the middle. I find most of the criticism against generative AI to be genuinely concerning, I don't think we should be pouring as much money into it as we are now. However I don't see it as the destroyer of worlds, neither do I think it will drastically change how I work. It's just another tool in my toolbox.

The bad

Generative AI in its current form is far from being ethical or environmentally friendly. As is often the case with technological advancements, regulators are playing catch-up. It is used by malicious actors to spread misinformation, it is being trained on content it was told to ignore, it requires a shit-ton of electricity to train and run... I could go on for paragraphs. Does this mean I completely avoid using these tools? No, just as I still use a car and travel by plane, even though I'm aware of their impact on our planet. However I try to be considerate – even conservative – in my usage of AI.

The good

Now to answer the question in the title, I will go over some use cases where I've found AI (more specifically LLMs) to be genuinely helpful.

One such area is search. Traditional search engines can be pretty good at knowing what you are looking for, even if you are not searching for the right words. However if you are looking for something that you can't easily express in a couple of keywords, finding the exact thing you need can seem impossible. A piece of relevant context, if it does not appear in the page you are looking for, can completely derail your keyword search, but can be just what ChatGPT needs to point you in the right direction.

Considering how shitty Google search results have become, I can't wait for more AI based search engines to emerge^[1].

As a non-english speaker I also reach for an LLM when I'm struggling to make a sentence sound professional. This is an area where I really want to avoid overusing it. I only use it as a last resort, and only for rephrasing no more than a single sentence. It should improve my vocabulary, not make me lazy^[2].

It is also really good at reading documentation, so you don't have to RTFM. I work a lot with a datagrid library called AG Grid. It has a crazy number of configuration options, so sometimes it can be a pain to figure out which ones I need to “make it work like Excel”. Often the easiest way is to just describe to ChatGPT what I need and let it figure it out for me. For a popular library like AG Grid it works pretty well. Some companies even provide an LLM-backed chat interface right in their documentation. This lets them train the model on their docs to provide even better answers^[3].

When it comes to writing code, I don't rely on AI tools too much. My typing speed is not what prevents me from shipping features faster, so tools like GitHub Copilot – although impressive – don't provide too much value to me. The times when I reach for ChatGPT are when I'm working on repetitive, but hard to automate tasks, typically refactoring.

As these tools mature I can see myself incorporating them into my workflow in more ways. More and more tools are popping up where AI is not just an optional feature but the whole premise. Tools like Vercel's v0 or StackBlitz's bolt.new are already empowering people to quickly prototype their ideas even if they lack the technical expertise to develop something from scratch. I'm certain our IDE of the future will look a lot like these tools. As to what this means for the quality of our software? Well...

Since I've started writing this article OpenAI has released ChatGPT Search, which – as a non-premium user – I have not had a chance to try yet. ↩︎
I don't use it for blog posts though. On this site you will only find 100% handcrafted, artisan, freerange sentences. ↩︎
https://houston.astro.build/ ↩︎

What can YOU do for a more accessible web?

Gergő Takács — Fri, 26 Sep 2025 18:22:55 GMT

In most of the teams I've worked in, accessibility was an afterthought. Early in my career it was my own ignorance, later I was actively discouraged by managers from spending time on it. I care about the work I do, and I feel like it is - at least partly - my responsibility to make sure the products I work on are accessible to everyone. I've found a few ways how I, a single developer, can spread awareness and start meaningful change in the teams I work in.

Step zero

First things first, educate yourself on the topic. If you have opened this article, you probably already have this box ticked. If you feel like doing a brush-up on the topic, I've listed some great resources at the end of the article.

Convincing stakeholders

Depending on what kind of product you are working on, getting management on board can be either easy or impossible. If your team is developing internal tools, your manager will be quick to point out, that they personally know all the users, and they all have 20/20 vision, three perfectly healthy hands, and ears like a bat. I'd still argue that these tools should be accessible, but you will have a hard time convincing your boss.

You will have better chances at success if you are working on something public. Corporations only speak the language of money, so you should try to make your case by letting your manager know how much money the company could lose by neglecting accessibility.

They lose customers

Nearly a quarter of people aged 16 years or over in the EU had a disability in 2024.^[1] If people cannot use your company's product, they will go to a competitor.

Creating accessible websites can also indirectly boost SEO. Writing well-structured, semantic HTML helps both users of assistive technologies and web crawlers access a site's contents.

They can face fines

If your company operates in the EU, its products might be legally required to meet a certain level of WCAG compliance.^[2] Businesses failing to comply can face serious fines.

Accessibility overlays

As a quick aside I want to mention accessibility overlays. Companies like AccessiBe or AudiEye advertise their products as a quick and easy solution to make a website accessible, and avoid fines. Just add a single third-party script and *poof*, your site is accessible. However, the truth is that these tools not only fail to fulfill this promise, in some cases they can even make it harder for disabled users to use your site.^[3] Their pitch does sound good, so I don't blame businesses for falling for it. It is your job to let your boss know what they risk by taking this shortcut. Overlay Fact Sheet is a great resource to help you convince them.

Fostering an accessibility culture

Having everyone on board is a good start, but not enough. In my experience, most companies don't have a dedicated accessibility team, so it is up to you - the developer - to make sure your team's work is accessible.

Automate as much as you can. Most testing frameworks and linters have accessibility add-ons. Use them! Make them part of your CI process!

Manual testing is also important, so make sure it is not forgotten. Even a single checklist item in your issue or PR template can go a long way. As an example here is what my team uses:

[] I have reviewed the accessibility impact of my changes and tested new UI features following our accessibility evaluation guide, or confirmed that no UI changes were made.

Good intentions are not enough if you don't know what you are doing. Compile a list of resources and tools to help your team properly test their work. I've listed some of my recommendations at the end of this article.

Do you have some downtime between tickets? Load up a page and conduct an audit. Let your manager know the results, so they can plan how you are going to tackle the issues.

Can AI help?

You cannot write an article in 2025 without mentioning AI. I've found some use cases where generative AI shines, however accessibility is not one of them. The reason for this is that LLM's are trained on the web, and let's be honest, the web is in large, inaccessible.^[4] Surely, they can be used to generate alt text, newer models are great at describing images. Well, not so much... Yes, good alt text should describe what's on a particular image. But it should also capture context and nuance. For example, take the following alt text I've generated using ChatGPT. Try to imagine what the original image would look like.

“An older man with a white beard and a light-colored shirt is smiling and giving a thumbs up, sitting indoors in a bright room.”

Now, take a look at the image. If you are unfamiliar with this person, he is known by the name Hide the Pain Harold. He got popular because of his facial expression that seems to hide some discomfort behind a forced smile. In the LLM's description this nuance is completely lost.

Conclusion

Even though recent legislation brings more attention to the topic, without proper education and advocates, accessibility will not be solved. Are my tips groundbreaking? Definitely not. With a little attention and some proactivity, even a single dev can do a lot for a more accessible internet.

Showcasing my demos

Gergő Takács — Sun, 24 Mar 2024 18:47:27 GMT

I have a repository for my demos and experiments that I wanted to showcase on my website. I wanted to keep these separate from and agnostic of my site code. For this I needed a set of constraints that each demo follows, that are flexible enough to allow me to build them any way I want.

First rule: each demo should be a static website

This is a static site, built with 11ty and hosted on a CDN. I wanted my demos to be a directory that I can just copy as-is to my 11ty build output. The demos repository is an npm workspaces project with a build script in the root project, that just calls the build script of each subproject. The build step of each subproject can be anything, as long as the result is a directory in the root project's build folder with at least an index.html in it.

Since all these projects are and will be web-related, this rule was easy to follow.

The repository is added as a git submodule to my main site repo and built separately before the 11ty build.

Second rule: each demo should be able to describe itself

I needed some metadata about each demo to be able to display them in a collection. For this I chose the Open Graph protocol. Open Graph tags are easy to parse and 11ty agnostic so they fit the bill perfectly. For scraping the metadata from the html content of each demo, I chose the open-graph-scraper-lite npm package.

Bringing it all together

Now all I needed was to make each demo reachable as a page on my site and to have them available as an 11ty collection, so I can render them into a list.

For the prior all I needed was a simple passthrough copy to copy the demos folder to the build output.

eleventyConfig.addPassthroughCopy({ 'demos/build': '/demos' });

To create a collection I needed to read all directories in the demos folder, scrape the Open Graph tags and add each item to the demos collection.

const ogs = require('open-graph-scraper-lite');

eleventyConfig.addCollection('demos', async function () {
    // read all directories
    const demoDirs = (await fs.readdir('demos/build', { withFileTypes: true }))
      .filter(dirent => dirent.isDirectory())
      .map(({ name }) => name);

    return Promise.all(demoDirs.map(async (name) => {
      // get html content
      const contents = await fs.readFile(
        path.join('demos/build', name, 'index.html')
      );
      // scrape OG tags
      const { 
        result: { ogTitle, ogDescription, articleTag }
      } = await ogs({ html: contents.toString() });

      return {
        title: ogTitle,
        description: ogDescription,
        name,
        url: `/demos/${name}`,
        tags: articleTag.split(';')
      };
    }));
  });

The last step was to create a page for showcasing the demos. Behold the shed.

How I shaved off megabytes from our React applications' bundle size

Gergő Takács — Fri, 06 Dec 2024 24:00:00 GMT

Single page application frameworks get a lot of (well deserved) flak for producing enormous JavaScript bundles. Although some of this bloat cannot be avoided, it is worth taking a closer look at your setup, because a misconfigured toolchain can add KBs or even MBs to your app's final size.

In this post I explain how I shaved off almost half the size of some of our applications by changing how our internal NPM libraries are built.

Initial setup

For the purpose of showing the issue I've created a stripped-down version of our app. It is a monorepo setup of a Vite based React application and a component library, both written in TypeScript. The library package uses an open-source general purpose component library called BlueprintJS.

The example app renders a single BlueprintJS button imported from the component library.

// app/src/App.tsx
import { MyButton } from 'lib';

function App() {
  return (
    <MyButton />
  );
}

export default App;

// lib/index.tsx
import { Button } from '@blueprintjs/core';
import { IconNames } from '@blueprintjs/icons';

export function MyButton() {
  return (
    <Button
      rightIcon={IconNames.COG}
    />
  );
}

Simple enough, right? The app bundle shouldn't be more than a few kilobytes. Let's do a prod build!

HOLY CANNOLI! How did THAT happen?! That bundle is so fat, it has its own ZIP code. Let's take a look inside the bundle and see what we can find out. We can use vite-bundle-visualizer for that.

See the image in full

Looks like the entire BlueprintJS library has been included into our bundle. To understand how this happened we need to take a closer look at our component library and learn a bit about how bundlers work.

Before we got ES modules, JavaScript had several non-standard module systems. Historically npm packages used a module system called CommonJS, since that was the default for NodeJS. By design CommonJS is dynamic, which makes it hard to statically analyze. The problem with this is that bundlers analyze your modules so that in the final bundle only the code that you actually use is included. This process is called tree-shaking. Nowadays most npm packages are provided as both ES and CommonJS modules as well. This is true for BlueprintJS as well. So how come we ended up with Godzilla in our build folder?

Before being imported into our app, the component library is run through the TypeScript compiler. Let's take a look at the compiler's output.

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.MyButton = MyButton;
const jsx_runtime_1 = require("react/jsx-runtime");
const core_1 = require("@blueprintjs/core");
const icons_1 = require("@blueprintjs/icons");
function MyButton() {
    return ((0, jsx_runtime_1.jsx)(core_1.Button, { rightIcon: icons_1.IconNames.COG }));
}

Those require() calls are a clear sign that this code is using CommonJS. So even if our app uses ES modules, we will end up with the CommonJS variant of BlueprintJS because of how our component library is built.

Let's fix this!

The fix

Thankfully we don't have to do much to tell the TypeScript compiler what module system to use.

// tsconfig.json
{
...
-  "module": "commonjs",
+  "module": "esnext",
+  "moduleResolution": "bundler",
...
}

First we set module to esnext to tell TypeScript that the compiled code should use ES modules. When using this option we are also required to set the moduleResolution option to tell TypeScript how it should resolve imports. If your code will be bundled – like in our case – the recommended value to use is bundler.

As I mentioned above, it is possible for a library to provide both ES and CommonJS modules, but I will not be getting into that in this article. If you would like to learn more about creating npm packages, I suggest you take a look at this wonderful article by Matt Pocock.

Results

Now that our tsconfig is updated, let's do another build and see how our output changes.

import { jsx as _jsx } from "react/jsx-runtime";
import { Button } from "@blueprintjs/core";
import { IconNames } from "@blueprintjs/icons";
export function MyButton() {
    return (_jsx(Button, { rightIcon: IconNames.COG }));
}

This time the compiled code is almost identical to our original source code, it is no longer using CommonJS. Only the jsx parts have been transpiled.

Let's see how this change affects our application bundle.

This looks much better. Our bundle is now split into three much smaller JavaScript files. The code-splitting occured because the ES module variant of BlueprintJS utilizes dynamic imports, which if encountered by Vite will cause a split.

Takeaways

Although this article focuses on a specific issue and its solution, my main takeaways are more general. First of all the bundle should not be treated as a black box, you can and should take a look inside to spot potential issues. And most importantly, you should familiarize yourself with the tools you use in order to make the best possible version of your app.

You can find the source code of the example here: https://github.com/spiroka/bundle-size-demo.

Color theory essentials for CSS

Gergő Takács — Fri, 19 Jan 2024 24:00:00 GMT

I was having a rough time recently trying to understand how the new CSS color functions work and why they are better than what we had before. I've been using colors in CSS for a decade, but besides knowing what the three letters in RGB stood for, I knew nothing about color theory.

This article assumes that you have at least heard about the new CSS color features. Its goal is to clear up the most common terms in the topic, it is not meant to be a deep dive by any means – it is probably not even entirely accurate – but thinking about them this way helped me make sense of all the new color features.

Color space

A color space is a range of colors, like the range of colors visible to the human eye. Historically in CSS we could only define colors in the sRGB space, which is roughly one third of the visible color spectrum.^[1] Modern displays are capable of showing way more colors than that. We will call the colors that fall into this wider range, high definition colors.

The CSS Color Level 4 spec introduced several new color spaces that we can utilize with the new functions. These are already supported in most browsers^[2], so you can start making your websites more colorful.

Color model

A color model is a mathematical model for expressing colors. Think of them as functions, that take some parameters and return a color. For example in CSS the rgb() and hsl() color functions are based on models with the same names.

Although technically incorrect, it is common to refer to models as color spaces^[3], which confused the hell out of me initially. The reason for this is that in practice, models are accompanied by a mapping function which maps the values of the model to a color in a color space. This means that a particular combination of model and mapping function will identify a color space.

Choosing what model to use is not just about preference. Let's say I want the background color of a button to be slightly lighter when it is hovered. If the original color is defined as a hex value, I would probably reach for a color picker to get the lighter version. With the introduction of hsl() into CSS, manipulating color got a lot simpler. It makes more sense what changing each value will do to the color. With hsl(), getting the lighter color is just a matter of increasing the value of the third (lightness) parameter, I don't even have to leave my editor.

The Color Level 4 spec introduced a bunch of new color functions, that – besides giving us a broader range of colors to choose from – have further improved the way we work with colors.

Gamut

A gamut – just like a color space – is a range of colors. The difference is that gamut refers to the colors that a device (eg. a monitor or printer) can display or reproduce within a color space.

With the new color spaces in CSS we can take advantage of wide gamut displays. While browsers are smart enough to approximate high definition colors on devices that don't support them, providing a fallback ourselves can yield better results. Just like with other device characteristics, we will use a media query to check if the user's display supports a specific gamut.

p {
  background-color: red; /* fallback color */
  
  /* check if the user's browser supports oklch() */
  @supports (background-color: oklch(0 0 0)) {
    /* check if the display supports the p3 gamut */
    @media (color-gamut: p3) {
      background-color: oklch(45% 0.3 264);
    }
  }
}

To know what gamut to test for, given a certain color, you can use a color picker that provides this information (eg. oklch.com) or use the stylelint-gamut Stylelint plugin.

Summary

My goal with this post was to summarize the things that have helped me understand the CSS Color Level 4 spec. Having a basic understanding of these three terms should be enough to be able to comfortably use the new color functions.

If you wish to learn more about the new CSS features, I've listed some great articles below.