Why My PC Fans Go Crazy While Watching YouTube
A few days ago, I was just sitting there, enjoying a 4K video on YouTube, when my PC fans suddenly kicked into high gear.
My thoughts, musings, and researches in coding, software, and life.
A few days ago, I was just sitting there, enjoying a 4K video on YouTube, when my PC fans suddenly kicked into high gear.
Teams often get stuck overusing visual regression testing in an attempt to keep UIs consistent.
Having the latest tech doesn't mean much if it doesn't actually help us work or, worse, just adds more mental overhead.
I often see teams hitting the same wall when writing E2E tests: should we go through the actual login process every single time, or just manipulate the data?
Implementing the Page Object Model (POM) for every single automated test scenario often feels like a chore, but not everything needs to be wrapped in a class.
TypeScript 6.0 is essentially a bridge release.
A while back, my team tried moving our tooling from ESLint and Prettier to Biome within a monorepo.
I’ve written a lot recently about configuring ESLint and Prettier, dealing with pre-commit hooks, and optimizing slow rules.
I’ve had those moments where everything runs perfectly on my machine, only to have things fall apart the second they hit production.
Keeping a testing suite fast within a pnpm monorepo is a real technical challenge.
I see it all the time in pull requests: debates over how a test should actually be written.
Deciding on a testing strategy usually runs into the same trap: the idea that more tests equals a safer app.
Building a design system or smart UI components requires precision when mapping relationships between props.
There’s a tendency in the TypeScript community to throw generics everywhere just to look "complete" or sophisticated.
When a component starts getting "fat," it’s usually not because the file size is huge, but because the list of props has turned into a grocery list.
Building components for a design system usually hits a wall the moment product requirements get weird.
Building flexible UI components usually leads to a fight between utility classes.
Variant explosion in primitive components is a real problem that can quickly wreck a design system.
Handling errors in a React app isn't just about keeping it from crashing; it’s about controlling the blast radius.
I often see apps that just feel...
I often find myself caught in the debate over the "best" way to handle inputs in React.
A lot of web projects look great on a massive monitor but fall apart the second you open them on a phone.
Picking a UI library isn't just about finding a nice logo or following whatever is trending on social media.
When organizing component structures, it’s easy to fall into the trap of the "lazy" approach: throwing everything into a single ui/ folder.
The real headache in modern app development usually isn't the libraries we pick, but the blurred boundaries between our data.
The same pattern keeps showing up in different React apps: forcing API data into Redux, shoving user profiles into Context, or manually building fetching logic with `useEffect`.
Choosing a tech stack often feels like a trap driven by social media trends, as if we’re forced to always pick the "most modern" tool.
Modern frameworks sell us on file-based routing with a very tempting pitch: just create a file, and your URL is ready to go.
Ever since React 19 dropped late last year, it feels like everyone has been talking about the same thing.
The biggest headache when implementing dark mode is the "white flash": that split second where the screen blasts bright white before finally switching to dark as the page loads.
Maintaining design consistency in a large project isn't really a CSS skill issue. It’s a management issue.
I see development teams stuck in endless migration cycles all the time.
I’ve always felt like HMR (Hot Module Replacement) is a bit of magic when you're in the zone.
Setting up Sentry for a Single Page Application (SPA) usually puts you in a dilemma: you either get useful data or you just collect junk.
There’s a common misconception that your .env file acts like a private vault inside a Single Page Application (SPA).
I see it all the time: teams eventually stop running the linter.
Picking tools for a new project often feels like being caught in the hype cycles of Twitter/X.
Choosing a website structure usually involves a trade-off: do you build a highly responsive app or keep the JavaScript weight low? It used to be a black-and-white choice.
For the longest time, I felt like building applications as standard SPAs with Vite was more than enough.
The debate over which framework is "best" for web apps usually boils down to a choice between using a massive, all-in-one meta-framework or going back to basic…
When starting a new project, the real question isn't "Should I use React or Vue?" It’s something much more critical: are we building a Single-Page App (SPA), a Multi-Page App (MPA), or some hybrid?
A while back, I wrote about the experience of moving from raw JavaScript to TypeScript.
Migrating a project from raw JavaScript to TypeScript is a common trap for overambitious teams.
Messy code on your main branch is a classic headache that usually happens when you only run linters in CI.
ESLint Flat Config is now the standard.
Managing a single project is draining enough; adding a monorepo to the mix can make it much worse.
Does every single project actually need the complexity of a strict typing system? Sometimes, I find myself tempted to just go back to raw JavaScript, using JSD…
Going full TypeScript for a small project or a simple script often feels like overkill.
Choosing between TypeScript or just blasting ahead with raw JavaScript usually comes down to how long the tool is actually going to live.
Managing multiple packages in a single repository (a monorepo) is a bit like managing an ecosystem.
I often find myself caught up in debates about repository structure.
A while back, I ran into a bit of a headache while working on a project.
I often find myself building little tools to help with my daily tasks: things like banner generators, image compressors, or file format converters.
Image assets, especially SVGs, are often an afterthought when building websites with dark mode support.
After a long stint on Windows, I’ve finally decided to make Linux my daily driver again.
Writing technical articles with plain text often feels limiting when I want to drop in interactive elements.
I finally decided to build my own personal site.
Displaying code as plain black-and-white text is a massive mistake when writing tutorials.
Large image assets are a massive drag on website performance.
This year, I decided to make a big change in how I work with my computer: I’m moving from Windows to Linux.