Tag: frontend
How to implement an accessible accordion
A short guide on implementing an accessible accordion component, JS optional.
Why frontend developers should learn more than just React
What can we learn from studying other frameworks, and what are we missing out on if we don't?
"Every Layout" Mixins
Every Layout is a collection of composable CSS layout patterns. Here's how I've extracted them into a reusable pattern library I can use in any project.
Why I spent years trying to make CSS states predictable
Why predictable CSS state resolution matters, and how Tasty approaches it with state maps and non-overlapping selectors.
The Vertical Codebase
Let's take a look at why the common, horizontal code structure is not ideal, where it breaks down, and what we can do about it.
Dana Lawson - Netlify
Netlify CTO Dana Lawson discusses her journey from the US Army to leading engineering teams and Netlify's evolution into AI-powered developer tools.
The Tailwind Labs Story: How AI Disrupted a Successful Business Model
On January 6, 2026, Adam Wathan, creator of Tailwind CSS, made a difficult announcement that sent shockwaves through the web development community: Tailwind Labs laid off 75% of its engineering team—three out of four engineers—despite the framework being more popular than ever. The layoffs occurred because of a brutal 80% revenue collapse, driven primarily by the way artificial intelligence has fundamentally altered how developers learn, build, and consume development tools. This situation represents a watershed moment in understanding how AI impacts not just the broader tech industry, but specifically the economics of open-source software businesses and their commercial derivatives.
Jeppe Reinhold - Storybook Modernization
Jeppe Reinhold from Chromatic reveals Storybook's transformation into a fast, modern development environment with Vite integration and AI-powered component discovery.
Gabriel Nordeborn - Rescript
Gabriel Nordeborn from the Rescript team showcases the OCaml-based language's superpowers including pattern matching and seamless React integration for frontend development.
Curated List: Web Platform, CSS, Accessibility
James Garbutt - E18e
James Garbutt explains e18e, the community initiative focused on improving JavaScript package performance across the entire npm ecosystem.
Simen Svale - sanity.io
Simen Svale from Sanity.io explains how their developer-focused CMS is evolving into a content operating system with real-time collaboration features.
Ryan Carniato - SolidJS, Marko.js, and the Future of Frontend Development
Ryan Carniato explores SolidJS's reactive approach that works opposite to React, plus his insights on Marko.js and the future of frontend frameworks.
Anselm Eickhoff - Jazz Tools
Anselm Eickhoff presents Jazz Tools, reimagining client-server boundaries for local-first apps with collaborative data structures.
Nathan Walker, Eduardo Speroni - NativeScript
Nathan Walker and Eduardo Speroni dive into NativeScript's ability to bridge JavaScript with native platform APIs for cross-platform mobile development.
React Conf 2024. React v19 RC
The first day of React.js Conf just concluded. This much-anticipated conference took place almost 3 years after the previous one. The React updates were just as eagerly awaited. The conference began with these updates and this article will be dedicated to them. And yes, as you saw from the preview — version 19 has moved into the release candidate status. The full release is promised within two weeks.
Adam Wathan - Tailwind CSS v4, The Evolution and Technical Journey
Adam Wathan reveals Tailwind CSS v4's technical journey with Rust and Lightning CSS, plus how Tailwind Labs monetizes and handles criticism.
March 2024 projects update
I’ve been still pretty busy with various Bluesky- and social-related projects recently, so here’s a small update on what I’ve been working on since my November post, if you’re interested: Skythread – quote & hashtag search I was missing one useful feature that’s still not available on Bluesky: being able to see the number of quote posts a post has received and looking up the list of those quote posts. The Bluesky AppView doesn’t currently collect and expose this info, so it’s not a simple matter of calling the API. But since everything’s open, anyone can build a service that does this, they just need to collect the data themselves. Since I’m already recording all recent posts in a database for the purposes of feeds and other tools, I figured I could just add an indexed quote_id column and set it to reference the source post on all incoming posts that are quotes, and later look up the quotes using that field. Skythread, my thread reading tool, seemed like a good place to add a UI for this. When you look up a thread there, it now makes a call to a private endpoint on my server which returns the number of quotes of the root post, and if there are any, it shows an appropriate link below the post. The link leads you to another page that lists the quotes in a reverse-chronological order, like this (it doesn’t currently do pagination though). You can open that page directly by appending the bsky.app URL of a post after the quotes= parameter here: https://blue.mackuba.eu/skythread/?quotes=. In the same way, I also indexed posts including hashtags, since hashtags were being written into post records since the autumn, but it wasn’t possible to search for them in the app. However, this has now been added to the Bluesky app and search service, so you don’t need to use Skythread for that. I hope that the quote search also won’t be needed for much longer :) Handles directory One very cool feature of Bluesky is that you can verify the authenticity of your account by yourself, by proving that you own the domain name that you’ve used as your handle. So for official accounts like The New York Times, The Washington Post, or Alexandria Ocasio-Cortez, it’s enough if they just set their handle to their main website domain (or a subdomain of house.gov in AOC’s case) to prove they’re legit – they don’t need to apply anywhere to get a blue or gold tick on their profile. I was thinking one day that it would be nice to see how many e.g. .gov handles there are and notice easily when new ones show up. So I grabbed a list of all custom handes from the plc.directory and started recording new and updated ones from the firehose. In the end, I decided to build a whole catalog of all custom handles, grouped by TLD, and show which TLDs are the most popular. At first I only included the “traditional” main TLDs and country domains, but a lot of people liked it and I got a lot of requests to also include domains like .art, .blue, .xyz and so on, so in the next update I’ve add…
Caching in next.js. Gift or Curse
The App Router significantly expands the functionality of next.js — partial pre-rendering, templates, parallel and interceptable routes, server components, and much more. However, despite all these improvements, not everyone has decided to switch to the App Router. And there are reasons for that.
Robert Balicki - Isograph, Relay, and the Future of Data Fetching in React
Robert Balicki introduces Isograph as a potential future of React data fetching, comparing it to his experience building Relay at Meta.
Matteo Collina - Node.js, Fastify, Platformatic
Matteo Collina explores his prolific Node.js contributions, the ESM/CJS transition, plus his work building Fastify and Platformatic for modern development.
Braden Sidoti - Clerk
Braden Sidoti, CTO of Clerk, breaks down authentication complexity, session management challenges, and how Clerk evolved beyond just auth.
2023: Year of social media coding
I had different plans for this year… then, Elon Musk happened. Elon took over Twitter in October last year, which set many different processes in motion. A lot of people I liked and followed started leaving the platform. Mastodon and the broader Fediverse, which has been slowly growing for many years but never got anything close to being mainstream, suddenly blew up with activity. A lot of those people I was following ended up there. Then, Twitter started getting progressively worse under the new management. Elon’s antics, the whole blue checks / verification clusterfuck, killing off third party apps and effectively shutting down the API, locking the site behind a login wall, finally renaming the app and changing the logo – each step made some of the users lose interest in the platform, making it gradually less interesting and harder to use. Changes, so many changes… and things changing meant that I had to change my workflows, change some plans, build a whole bunch of new tools, change plans a few times again, and so on. My GitHub looks like this right now, which is way above the average of previous years: As usual, I ended up writing way more Ruby and JavaScript than Swift, which goes a bit against my general career plans – but I’ve built so much stuff this year and I had a ton of fun doing it. So in this blog post, I wanted to share some of the things I’ve been working on lately. The Dead Bird Site 🦤 I had a bunch of private tools written for the Twitter API. For example, I had a script that downloaded all tweets from my timeline and some lists to a local database. I was also running various statistics on tweets, e.g. which people contribute how much to the timeline and list feeds, and automatically extracted links from tweets from some selected lists. And then Elon shut off access to the API (unless you can afford $100 per month for a “hobbyist” plan), which meant I had to try to find other ways to get that data. I quickly got the idea that I could somehow intercept the JSON responses that the Twitter webapp (I refuse to call it the new name, sue me) is loading from the JavaScript code. The JSON responses are very complicated with a lot of extra content, but they do contain everything I need. The problem is how to get them; I wanted to get data from my personal timelines, so I couldn’t do anonymous requests, and I didn’t want to make authenticated requests for my account from some hacked-together scripts, for fear of triggering some bot detection tripwire that would lock my account. So the approach I settled on was to passively collect the requests in the browser, using Safari’s Web Inspector, and export them to a HAR file that can be parsed and processed like the data from the public API. (It would be even better to have a browser extension that intercepts XHR calls on twitter.com automatically, but as far I can tell, there is no way for request monitoring extensions to look at the content of responses, unless you inject scripts to …
Aiden Bai - Million.js
Aiden Bai explains how Million.js makes React render faster and discusses growing up alongside his open source community.
Tuomas Artman - Linear
Tuomas Artman from Linear breaks down the engineering behind their lightning-fast sync engine that powers the beloved modern issue tracking tool.
Steven Fabre - Liveblocks
Steven Fabre, CEO of Liveblocks, shares how his collaboration platform is transforming developer experience by making real-time features effortless to implement.
Implementing dark mode with NextJS and TailwindCSS
Learn how to implement a flexible dark mode toggle in NextJS with TailwindCSS. Includes light, dark, and system mode options with localStorage persistence.
Next.js Layout RFC: Changing Everything to Make the Web Faster
In May of this year, Next.js unexpectedly published an RFC (request for comments) on its blog. It primarily discusses a new abstraction - layouts - as well as a host of related changes aimed at speeding up development, improving DX, and standardizing through the creation of new conventions. This working proposal definitely deserves attention, both because of its complexity for the framework and because it literally describes what it will look like in the future.
Hard problems in the browser
Frontend roles encompass a vast range of skills. Some of them have been solved by cloud infrastructure providers, and the rest take years of experience.
Introduction to Penpot - an open-source design tool
Discover Penpot, a free and open-source design tool that provides solid features for developers and designers. Cross-platform alternative to proprietary design software.
Front-end web development
Frontend web development is hectic, fast-paced, and a lot more driven by thought leaders than any of us want to admit.
Yang Zhang - Plasmic
Yang Zhang, co-founder of Plasmic, shows how their platform bridges designers and developers through code imports and drag-and-drop editing.
Theming. Part 2. New Browser APIs. Theming with SSR. Choosing Between SPA, SSR, and SSG.
According to data collected by Android Authority (2,514 respondents) and an analysis by Thomas Steiner, over 80% of users use a dark theme. Of course, it’s hard to call this sample entirely representative, since the surveys were conducted on technical forums, but overall, we can say that a good half of the internet uses a dark theme.
Alex Johansson - tRPC, Zart
Alex Johansson explains how tRPC enables end-to-end typesafe APIs without code generation, plus his work on the Zart project.
Primeiros passos com Flutter
Pedro Duarte - Modulz, Radix, Stitches
Pedro Duarte shares how his developer experience work at Modulz powers the open source Radix and Stitches libraries used by countless developers.
Thematization: History, Causes, and Implementation
A dark theme for nighttime use isn’t the only reason for adding theming to a website. Another important goal is service accessibility. Worldwide, there are 285 million people with total or partial vision loss; in Russia, there are 218,000, and up to 2.2 billion with various visual impairments
TypeScript on Corona Charts
Back in spring I built a website that lets you browse charts of coronavirus cases for each country separately, or to compare any chosen countries or regions together on one chart. I spent about a month of time working on it, but I mostly stopped around early May, since I ran out of feature ideas and the pandemic situation was getting better (at least in Europe). The traffic that was huge at the beginning (over 10k visits daily at first) gradually fell to something around 1-1.5k over a few months, and I was only checking the page myself now and then. So it seemed like it wouldn’t be needed for much longer… “Oh, my sweet summer child”, I kinda want to tell the June me 😬 So now that autumn is here and winter is coming, I suddenly found new motivation to work on the charts site again. But instead of adding a bunch of new features right away, I figured that maybe some refactoring would make sense first. I initially built this page as a sort of hackathon-style prototype (“let’s see if I can build this in a day”), but it grew much more complex since then, to reach around 2k lines of plain JavaScript - all in one file and on one level. I started thinking about how I can make this easier to manage, and somehow I got the idea to try TypeScript. Why add static typing? I used to believe that static typing was just unnecessary complication. My first programming experiments back in school were in Pascal and very bad C++. At the university, pretty much everything was either plain C or Java (or C#, depending on which group you picked). It was only near the end of the studies that I suddenly discovered Python and later Ruby, and it was like a breath of fresh air. I also read Paul Graham’s book “Hackers and Painters”, which made a big impression on me, steered me away from big corpos towards the startup world (for which I’m forever grateful), and also showed me how much better dynamically typed languages (specifically Lisp) were than statically typed ones. I spent the next few years writing mostly Ruby and some JavaScript for the frontend, and I loved it. I still love Ruby and to this day I use it for all my scripting and server-side code. However, at some point I also started building Mac and iOS apps, first in ObjC, and then in Swift. ObjC just felt like so much unnecessary boilerplate, and it really was. Then Swift came and simplified everything, but it exchanged the boilerplate for a very strict type system, much stricter than anything I’ve seen before. It was annoying to have to explain the compiler which property can be nil and when and what to do with it, or what to do if this JSON array does not contain what I think it does. But after using Swift for a few years, I really appreciate the feeling of safety it gives you. You have to put in more work up front, but once you do, and once it compiles, you can be sure that whole categories of possible errors have already been eliminated before you even run the app. You have to do fewer build - run - find …
Coronavirus charts
I’ve been tracking the growth of the new coronavirus ever since it first appeared in China in the last week of January, and even more since it spread to Europe around mid February. Initially I’ve been looking mostly at the popular ArcGIS dashboard made by Johns Hopkins University that everyone is probably familiar with. However, I really wanted to see some charts showing how the numbers grow in each country separately, since just seeing “8000 in Italy” doesn’t tell me much if I don’t remember how much it was yesterday. At that point it wasn’t possible to see that kind of information on the dashboard, and I couldn’t find any other source that showed that in an accessible way. But then I saw a mention in the footer on the dashboard that the authors have shared all their data (including past numbers) in a GitHub repository in the form of CSV files. So of course I decided to do what always comes to my mind when I have a problem to solve… build a new project :) And that’s how the Coronavirus charts site was born. I managed to build and deploy an initial working version in one afternoon and evening - it’s amazing how fast you can build things with the right tools. I used Ruby for the server part - I wrote an import script that downloads the CSV files from GitHub every few hours (though in practice they only change daily) and processes them into a JSON file. There’s a whole bunch of things that need to be done on the data: extract the columns that list the numbers, calculate totals (global count, whole Europe, adding up Australian or Canadian provinces which are listed separately), some naming tweaks, etc. And Ruby is absolutely *perfect* for tasks like that - get this file, parse it, slice it into arrays, filter them this way, map them through that block, gsub some strings with a regexp, and so on - nothing else I know comes close. It feels almost like being Dr. Strange. The UI part is a small amount of plain static HTML, some vanilla CSS and JS, and the Chart.js library for rendering the charts. I’ve worked with Chart.js before and it’s super easy to get started and get a nice chart once you have the arrays of numbers loaded from the JSON. Everything else is completely plain JS, no jQuery, no NPM, no React, no nothing. I like to avoid dependencies, and it’s so nice how much more you can achieve with standard JS now than what I remember from my professional web development days, when IE 8 was still a thing. Things like arrow functions, fetch, querySelectorAll, classList, ES5 Array extensions and so on make coding in plain JS much easier than it used to be when jQuery or at least Underscore.js was a requirement. Since the first version the code grew quite a lot - I’m adding some improvements almost every other day. You can now switch between linear and logarithmic scales, “daily increase” and “% increase” views, and there’s a pretty complex “Compare Countries” screen that lets you compare up to 20 countries or regions, with a few more options li…
CORS, CodePen & Me
My adventures solving the CORS issue.