标签：#frontend

While building a Computer-Based Testing (CBT) platform, I ran into an unexpected problem. Creating mathematics and chemistry questions wasn't nearly as straightforward as I expected. Although there are many excellent editors and open-source libraries available, I couldn't find one that brought everything together in a way that was simple, lightweight, and designed specifically for CBT systems. Instead of building everything from scratch, I took a different approach. I combined several powerful open-source technologies into a single editor that focuses on one job—making it easy to create mathematics and chemistry content for online examinations. The result is CBT Editor, a free and open-source equation editor built for developers, schools, and educational platforms. It supports common mathematical expressions, chemistry notation, scientific symbols, fractions, superscripts, subscripts, and more, while remaining easy to integrate into existing projects. This project isn't meant to replace the fantastic libraries that already exist. In fact, it depends on them. The goal is to provide a clean, unified experience so developers don't have to spend hours combining multiple tools just to support technical examination questions. If you're building a CBT platform, an online examination system, or any educational application that requires mathematics and chemistry editing, I'd love for you to give CBT Editor a try and share your feedback. 🔗 Live Demo: https://holygist.github.io/cbt-editor/ Open-source software grows through collaboration. If you find the project useful, feel free to contribute, report issues, suggest improvements, or simply share it with other developers.

There's a project on every developer's machine that has Sass installed for one reason: &:hover {} . Not @mixin . Not @each . Just the nesting. The variables long since became --custom-properties . The only thing still justifying node_modules/sass is the ability to write child selectors inside parent rules. CSS added that natively in 2023. It shipped in Chrome 112, Firefox 117, and Safari 16.5 — every major browser released in the last two years. The compiler is not earning its spot anymore. What you've been writing in Sass The classic pattern — component styles scoped to a block, with states and modifiers nested inside: .card { padding : 1 .5rem ; border-radius : 0 .5rem ; background : var ( -- surface ); & :hover { background : var ( -- surface-hover ); } & __title { font-size : 1 .125rem ; font-weight : 600 ; } & --featured { border : 2px solid var ( -- accent ); } } The output is flat, specificity-controlled CSS. The source is organized by component. That's the trade Sass nesting has always offered — and native CSS now offers the same deal. The same thing in native CSS .card { padding : 1.5rem ; border-radius : 0.5rem ; background : var ( --surface ); &:hover { background : var ( --surface-hover ); } & .card__title { font-size : 1.125rem ; font-weight : 600 ; } & .card--featured { border : 2px solid var ( --accent ); } } Two differences are worth noticing. First: pseudo-classes work exactly as in Sass — &:hover resolves to .card:hover with no extra syntax. Second: descendant selectors require an explicit & followed by a space. & .card__title becomes .card .card__title . This is where native nesting differs from BEM's __ / -- convention: in native CSS, & is a selector reference , not a string concatenation operator. If you're using BEM naming heavily, &__foo becomes & .block__foo . The compiled output is identical; the source is slightly more explicit about what's happening. Media queries nested inside their rules This is the feature that earns native nesting a pe

AI is becoming a powerful part of modern software development. But I've realized that getting high-quality code isn't just about writing better prompts—it's about giving AI the right guidance. That's where Modern Web Guidance caught my attention. Instead of generating code that simply works, it encourages AI to produce HTML, CSS, and JavaScript that follow modern web standards. The result is code that is: More accessible Easier to maintain Better performing Closer to production-ready quality As a Front-End Engineer, I think this is an important shift. Rather than treating AI as a code generator, we can treat it as a development partner that follows the same engineering standards we do. This means fewer outdated patterns, better semantic HTML, improved accessibility, and cleaner architecture from the beginning. I'm planning to integrate Modern Web Guidance into my daily workflow for: Building accessible UI components Writing semantic HTML Creating maintainable CSS Improving JavaScript quality Reducing unnecessary refactoring after AI-generated code I'm curious to see how much it improves both code quality and development speed in real-world projects. If you've already tried Modern Web Guidance, I'd love to hear: What has been your experience? Has it improved the quality of AI-generated code? Any tips or best practices you've discovered? The future of AI-assisted development isn't just about generating more code—it's about generating better code. Happy coding! 🚀 Learn more: https://developer.chrome.com/docs/modern-web-guidance

Hello fellow React developers! In this article we will be breaking down what React component instance is and scenarios where React component instance is at play. What is a React Component ? Before we can understand and really appreciate what a React component instance is, we first need to understand what a component itself is. Basically, components are the fundamental building blocks of any React application. They are independent, reusable pieces of code that allow you to split your application into distinct, manageable bits of logic and UI. From our knowledge of JavaScript, you can think of components in a way as what a function is. Just as we create and use functions to avoid repeating code and separate logic, components are used to divide our application into reusable visual chunks. However, they work in isolation and return HTML (via JSX) to describe what appears on the UI. Let take a look at a simple Greetings component used in a demo; Instead of writing the HTML layout for a greeting over and over again, we define it once as a component and reuse it multiple times in our application by passing different props (arguments). React Component Instances: What are they ? Now that we understand what a React component is, let's move on to React component instances. In programming, an instance is a concrete object created from a specific template (such as a JavaScript class or a Constructor function). In React, a component instance is the actual implementation of a component in a React application. It is a long-lived object that holds contextual information about a particular component. Every time a component is rendered in our application, React creates a new instance of that component. To help you visualize this, let’s take a look at a simple Counter component; // A Counter Component import React , { useState } from ' react ' ; export default function Counter () { const [ count , setCount ] = useState ( 0 ); return < button onClick = {() => setCount ( count + 1 )} > C

React is a library, Next.js is a framework — here's what that actually means for your project, and how to choose based on SEO, scale, and team.

There's a pattern I see a lot in Angular codebases that adopted Signals early: a developer discovers rxResource , loves that it handles loading and error state automatically, and then immediately reaches for tap() to write a signal inside the stream. private readonly resource = rxResource ({ params : () => this . paramsSignal (), stream : ({ params }) => this . api . fetch ( params ). pipe ( tap ( data => this . sideSignal . set ( data . meta )) // 💥 ) }); This looks harmless. It runs in development without complaint in zone-based Angular. Then you enable zoneless — or Angular tightens its reactive graph enforcement — and you get NG0600: Writing to signals is not allowed in a reactive context . The rxResource stream runs inside Angular's reactive scheduler. Signal writes there aren't just discouraged — they're illegal by design. The scheduler assumes computed signals and reactive contexts are read-only during evaluation. A write mid-computation breaks the glitch-free guarantee Angular's signal graph is built on. The fix I landed on: make the stream return everything it needs to return, as a single typed value. interface ResourceValue { readonly sections : Section []; readonly meta : Meta ; } private readonly resource = rxResource < ResourceValue , Params > ({ stream : ({ params }) => this . api . fetch ( params ). pipe ( map ( data => ({ sections : transform ( data ), meta : data . meta })) ) }); No tap . No side signal. Everything the rest of the store needs lives in resource.value() and can be read via computed . The lesson isn't "don't use tap". The lesson is that rxResource has a contract: it is a read primitive . Its stream is for fetching and transforming. If you're writing signals inside it, you're treating it as a command bus — and that's a different tool. Originally published on ysndmr.com .

The first question I ask when reviewing a frontend architecture is: where does the state live relative to where it is used? In most codebases I have reviewed, the answer is "in a global store, regardless of scope." This is the wrong default. The rule State should live as close to its consumers as possible. If only one component needs it, it is component state. If a subtree needs it, it is a context or service scoped to that subtree. Global state is for truly global concerns: authentication, locale, theme.

Most async code in frontend apps has a hidden bug: it doesn't stop when it should. A user navigates away mid-request. A component unmounts. A newer search query supersedes the previous one. The old network call keeps running, eventually resolves, and tries to update state that no longer exists. In React, that's the infamous warning: "Can't perform a React state update on an unmounted component." In vanilla JS, it silently delivers stale data. AbortController is the browser's built-in solution. It's been in every major browser since 2018 — old enough that there's no excuse not to use it. But most tutorials skip it, most codebases use it inconsistently, and most devs reach for it only after they've debugged a flicker one too many times. Here's the pattern, end to end. The race condition you already have function SearchResults ({ query }: { query : string }) { const [ results , setResults ] = useState < Result [] > ([]); useEffect (() => { fetch ( `/api/search?q= ${ query } ` ) . then ( r => r . json ()) . then ( data => setResults ( data )); // runs even if query changed }, [ query ]); return < ul > { results . map ( r => < li key = { r . id } > { r . name } </ li >) } </ ul >; } When the user types "re" and then "rea" before the first request finishes, two fetches are in flight simultaneously. The request for "re" might complete after the request for "rea" — and when it does, setResults silently overwrites the correct result with the stale one. The component shows the wrong data. No error, no warning, no clue. This is a race condition, not a hypothetical. It happens on slow networks, during fast typing, on underpowered devices, and in staging environments right before a demo. AbortController: the three-line fix An AbortController is a pair: a controller object and a signal. You pass the signal into any abort-aware API; you call abort() to cancel it. useEffect (() => { const controller = new AbortController (); fetch ( `/api/search?q= ${ query } ` , { signal : control

In my previous articles, I’ve consistently emphasized a core architectural principle: once the render layer no longer dictates the entire data flow, the boundaries between State, Derived State, and Effects become critical. When we fall into the habit of stuffing every UI-affecting variable into generic "state," the system quickly loses its semantic structure. In modern frontend applications, this architectural gap becomes most glaring when dealing with asynchronous work. Async data is never merely "a value that will appear in the future." It carries complex semantics regarding its source, temporal validity, cancellation, error recovery, and invalidation. If these semantics aren't modeled explicitly, they inevitably get pushed down into the UI framework’s lifecycle—indirectly patched together through component mounts, effect dependencies, and callback guards. This brings us to the core question of this article: What does a system lose when the correctness of async work is forced to depend on the UI lifecycle? We are all incredibly familiar with this pattern: const data = await fetchSomething () setState ( data ) Or, using a standard UI framework hook: useEffect (() => { let cancelled = false fetchSomething (). then ( result => { if ( ! cancelled ) { setData ( result ) } }) return () => { cancelled = true } }, []) There is nothing inherently wrong with this code for simple use cases. It’s intuitive and perfectly aligns with how Promises are designed to work: trigger the operation, wait for the resolution, and write the result back into state. However, this mental model has a subtle downside. It encourages us to think of async work as simply calling setState after a Promise resolves. That may hold up for simple screens, but as an application grows, the model starts to expose structural problems. Promise Only Describes Completion, Not Ownership A Promise solves a very specific problem: A piece of work will complete in the future, and it will either succeed or fail. It c

In the first article of this series, we saw how a custom build-time compiler can transform a legacy Angular.js template into raw, optimized JavaScript. To recap, starting from this template: <!-- simple.html --> <p> Hello {{ name }}! </p> Our Go compiler generates the following JavaScript module: // simple.js export function template () { const p_0 = document . createElement ( " p " ); const text_1 = document . createTextNode ( "" ); p_0 . append ( text_1 ); return { mount ( container ) { container . append ( p_0 ); }, update ( change ) { if ( " name " in change ) { text_1 . data = " Hello " + change . name + " ! " ; } } } } This is incredibly clean. By running template() , we get an object with mount and update methods. Using mount is fully intuitive: we pass a reference to a DOM element, and it injects our empty paragraph ( p_0 ) into it: import { template } from ' ./simple.js ' ; const { mount , update } = template (); const container = document . getElementById ( ' view-container ' ); mount ( container ); // The DOM now contains: <p></p> (waiting for data) However, the paragraph remains empty until we call update with a change object like this: let changes = { name : " Mario " , }; update ( changes ); // The DOM surgically updates to: <p>Hello Mario!</p> But who is responsible for tracking changes in our application state, building this changes object, and calling update ? The answer lies in marrying the legacy Angular.js $scope with the modern JavaScript Proxy API . The Legacy State Pattern In a traditional Angular.js application, developers mutate the state directly inside a controller by assigning properties to the $scope object: // simple-controller.js export function SimpleController ( $scope ) { $scope . name = " Mario " ; } To bridge the gap between this legacy controller and our new build-time template, we need a way to automatically capture the assignment $scope.name = "Mario" and translate it into a structured update: let changes = { name : " Mario " }

Last month our visual-diff monitor flagged 47 changes on a client's homepage in one run. Forty-six of them were a rotating testimonial carousel that happened to land on a different slide each time the page was captured. One was real. If you've built or used any screenshot-based monitoring, you already know this problem. Two screenshots of the exact same, unchanged page rarely match pixel-for-pixel. Carousels rotate. Cookie banners fade in on a timer. Lazy-loaded images pop in a beat late. Ads shift half a pixel. Fonts render with slightly different anti-aliasing depending on what else the browser was doing. Diff two raw captures and you get a wall of "changes," and within a week nobody on the team opens the alert anymore. Why the obvious fixes don't work The first instinct is usually to loosen the pixel-diff threshold. That just trades false positives for false negatives - now a genuinely moved button or a broken layout has to clear the same bar as carousel noise, so you miss the thing you built the tool to catch in the first place. The second instinct is manual exclusion zones: tell the tool to ignore the carousel <div> , the ad slot, the cookie banner. This works until the page changes - a redesign moves the carousel, a new banner ships with a different selector, and you're back to noisy alerts plus a pile of dead config nobody remembers writing. The third "fix" is tolerating the noise, which is what most teams actually do in practice, and it's a big part of why visual regression tooling has a reputation for being more trouble than it's worth. Make the page prove it's stable before you trust anything about it The fix that actually moved the needle for us wasn't a smarter diff algorithm. It was refusing to treat a single screenshot as ground truth at all. Before any comparison happens, the page goes through a stabilization pass: known cookie/consent overlays get removed (we track a couple hundred variants at this point — cookie banner vendors are not standardized),

When you fire a fetch() and the component that triggered it unmounts, the request keeps going. The server still processes it. When the response arrives, it calls back into whatever JavaScript it finds — a stale closure, a dead state setter, a global store that has already moved on. React's "Can't perform a state update on an unmounted component" warning is the polite version of this. The silent version is worse: results from an old query overwriting the current UI. These aren't mysterious race conditions. They're the predictable result of starting async work and never telling it to stop. The race condition hiding in every search box The search input is the clearest example. The user types "reac", your debounce fires a request. Before it lands, they finish typing "react" and you fire another. Two requests, in flight at the same time, and no guarantee about which one finishes first. If the "reac" request happens to be slower — network jitter, a cache miss, a heavier result set — it will land after "react" and overwrite the correct results with the wrong ones. The bug reproduces maybe one time in twenty on a local dev server, and consistently in production on a slow connection. The fix isn't smarter debouncing. It's cancelling the previous request when a new one starts. AbortController in plain terms AbortController is a browser-native API for cancelling async work. You create a controller, pass its signal to fetch() , and call controller.abort() to cancel. If the response hasn't arrived yet, the fetch promise rejects with an AbortError . const controller = new AbortController (); fetch ( ' /api/search?q=react ' , { signal : controller . signal }) . then ( res => res . json ()) . then ( data => setResults ( data )) . catch ( err => { if ( err . name === ' AbortError ' ) return ; // expected — not a real error setError ( err ); }); // Somewhere else, when we no longer need this request: controller . abort (); Two things to internalize: signal is how the controller knows

Bootstrap 5 and Tailwind CSS are the two most popular CSS frameworks in 2026. If you're starting a new project and trying to decide between them, this guide gives you an honest comparison based on real-world usage — not just feature lists. The Core Difference Bootstrap 5 gives you pre-built components. Tailwind CSS gives you utility classes to build your own. That's the fundamental difference and it drives every other comparison. With Bootstrap you get a navbar, modal, card, and dropdown out of the box. With Tailwind you build those yourself using utility classes like flex , px-4 , bg-blue . Neither is wrong. They solve different problems for different teams. When Bootstrap 5 Makes More Sense You Need to Ship Fast Bootstrap's pre-built components mean you spend less time on UI and more time on business logic. For admin dashboards, CRM panels, and internal tools — where UI consistency matters more than pixel-perfect custom design — Bootstrap is the faster choice. Your Team Knows HTML and CSS Bootstrap has a shallow learning curve. Any developer who knows basic HTML and CSS can pick up Bootstrap in a day. Tailwind requires understanding its utility-first philosophy and memorizing class names. You're Building an Admin Dashboard Admin dashboards need data tables, modals, dropdowns, sidebars, and form components — all of which Bootstrap provides out of the box. Building these from scratch with Tailwind takes significantly more time. You Want Predictable Output Bootstrap's components look consistent across browsers and screen sizes without extra configuration. Tailwind output depends heavily on how well your team implements it. When Tailwind CSS Makes More Sense You're Building a Custom Marketing Site If your design is highly custom — unique layouts, non-standard components, pixel-perfect design system — Tailwind gives you more flexibility without fighting Bootstrap's default styles. You Have a Design System Already If your team has a defined design system with specific t

OpenNG Foundation and spartan/ui 1.0 are the headline topics this week: a new home for libraries like Spectator and Elf, and spartan/ui, a stable shadcn-inspired component library for Angular. Also in brief: Storybook's Angular modernization through AnalogJS, the end of ng-conf, and AI Dev Craft in Las Vegas. OpenNG Foundation Maintaining open-source libraries is hard work. Developers often do it in their spare time, committing to years of maintenance, adding new features, and responding to user requests. Last episode, we reported that the ngneat organization was taken down for unknown reasons. While we still don't know why it happened, a new home has emerged for its popular libraries like Spectator and Elf: the OpenNG Foundation. Gerome Grignon, known for CanIUseAngular and as the organizer of Ng-Baguette, announced the foundation, which is already hosting these libraries. Alongside Gerome, the current OpenNG team also includes Dominic Bachmann, organizer of Angular Lucerne and author of the angular-typed-router library. OpenNG Foundation · GitHub OpenNG Foundation has 8 repositories available. Follow their code on GitHub. github.com spartan/ui 1.0 spartan/ui has officially released its 1.0 version. It provides an "accessible, production-ready library of more than 55 components" with fully customizable styling. After debuting in August 2023 with 30 primitives, it now reaches stable in 2026 with a modern architecture built around signals, standalone components, zoneless change detection, and SSR. Originally initiated by Robin Götz, a full team quickly formed around the project. spartan/ui can be seen as the Angular equivalent to shadcn/ui, famous for its customizability. While similar open-source alternatives exist, spartan/ui was the pioneer and has a proven track record of active maintenance over the years. Announcing spartan/ui 1.0 Robin Goetz Robin Goetz Robin Goetz Follow for Playful Programming Angular Jun 24 Announcing spartan/ui 1.0 # angular # webdev 8 reac

Book: Decoupled PHP — Clean and Hexagonal Architecture for Applications That Outlive the Framework Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools Me: xgabriel.com | GitHub You have two copies of the same rules. One lives in a StoreUserRequest on the server. The other lives in a Zod schema, or a Yup object, or a pile of required attributes, on the front end. They started identical. Then someone bumped the password minimum from 8 to 12 on the backend and forgot the client. Now the form says the password is fine, the user clicks submit, and a 422 bounces back with an error the UI never predicted. That drift is the whole reason live client-side validation is annoying to maintain. You are keeping two rulesets in sync by hand, and the sync breaks quietly. Laravel Precognition removes the second copy. The front end asks the server "would this pass?" before the user submits, and the server answers using the exact same validation rules the real request will run. What a precognitive request actually is A precognitive request is a normal HTTP request to your real endpoint, tagged with a Precognition: true header. Laravel sees the header, runs the route's middleware and validation, and then stops before your controller does any real work. It never writes a row. It never sends an email. It runs the rules and returns the verdict. Success comes back as 204 No Content with a Precognition-Success: true header. Failure comes back as a normal 422 with the same JSON error bag your form submit would produce. Same rules, same messages, same field names. There is no second schema to drift. The lifecycle is worth holding in your head: Front end sends the form state to the real URL with Precognition: true . Middleware runs. FormRequest validation runs. Laravel short-circuits: your controller body never executes. Response is

Prologue A while ago, I decided to develop a fully accessible main navigation component in React and write a series of articles documenting the steps it took to create a non-trivial accessible component. This article completes the process of creating a main navigation component that is universally accessible, both perceptually and operatively; can operate in a controlled or uncontrolled state; and is operable when displayed in a horizontal, desktop arrangement as well as in a vertical, mobile scenario. Note : This article is one of a series demonstrating building a React navigational component from scratch while considering accessibility through the process. The articles are accompanied by a GitHub repository with releases tied to one or more articles; each builds on the previous one until a fully implemented navigation component is complete. Each release and its associated tag contain fully runnable code for the article. The code discussed in this article is available in the release. and may be downloaded at release 1.0.0 . Links in the article will take you to the proper file in the tagged GitHub Repository. Because the code for this release is scattered across components, line numbers are added to make it easier to locate in the linked GitHub file. Line numbers are also provided for those who would like to follow along with a downloaded copy. While code examples are written in JavaScript for brevity, all actual code is written in Typescript and targets React 19.x, all while using vanilla CSS. Examples use Next.js v16.x, which is not required to run the navigation component. You can view the requirements for Vertical Alignment along with previous requirements. Content Links Introduction Acceptance Criteria Data Setup Keeping SubLists Open Allowing Scroll when Focus Shifts Down Arrow Key Implementation Up Arrow Key Implementation Conclusion Introduction Up until now, all keyboard handling has been implemented with the default horizontal layout in mind. When display

If you're starting a web project, you're probably starting with a CSS reset, and for most of us, that means reaching for a trusted community solution - dropping it in and moving on. If you're building a design system, though, that habit may be working against you. The existing solutions The community reset ecosystem is genuinely good. Each tool approaches the browser compatibility problem from a slightly different angle. Some examples include: Eric Meyer's Reset is a classic: it zeros out margins, padding, and font sizes across every element, giving you a completely blank slate. It's minimal and predictable, which made it influential. Normalize.css smooths over inconsistencies while preserving the ones that are actually useful. sanitize.css and modern-normalize continue that evolution - incorporating contemporary best practices like box-sizing: border-box , improved form element handling, and accessibility-aware defaults. The problem isn't that any of these are bad. The problem is that they're all deliberately, necessarily generic. They can't know anything about your typeface, your color palette, your spacing scale, or how your interactive elements should behave. That's by design - they're tools for everyone, which means they're perfectly tailored for no one. The problem If you're building a design system, generic is exactly what you don't want your reset to be. The moment you drop in one of these resets and start building, you find yourself doing a second round of work. You apply your typeface to body . You reset margins on headings. You make form elements inherit fonts. You define focus styles. You're re-resetting - applying your design language on top of a layer that just cleared out the browser's defaults and replaced them with... more defaults you'll override. Worse, that duplication doesn't stay in one place. Every component you build either re-declares these foundational styles or silently assumes they're already set upstream. You end up with either redundanc

An accessibility audit is not only a compliance activity. For engineering teams, it is also a quality review of how real users interact with the product. If you are preparing for a WCAG 2.2 AA audit, the biggest mistake is waiting for the auditor to tell you what information is missing. You can make the process much smoother by preparing the right workflows, accounts, test data, and remediation owners upfront. Scope the product by user flow Do not start with only a list of URLs. URLs matter, but accessibility bugs often appear inside stateful interactions: Form validation Custom dropdowns Modal dialogs Keyboard focus management Error recovery Dynamic tables Authenticated dashboards Document downloads Instead of asking, "Which pages should we test?" ask: What tasks must users be able to complete? That usually gives you a better audit scope. Prepare accounts and stable data If a workflow requires authentication, roles, or sample records, prepare them before the audit starts. Useful prep includes: Admin, standard user, and limited-role accounts Stable sample records Forms with prefilled data where needed Test payment or transaction flows if applicable Known feature flags Environment notes This avoids spending audit time debugging access problems. Confirm the standards WCAG 2.2 AA may be the target, but the report may also need to reference WCAG 2.1 AA, Section 508, EN 301 549, GIGW, or IS 17802. Engineering teams should know this early because it affects reporting language and remediation priority. Make evidence developer-friendly A useful issue should be reproducible. Good audit findings usually include: Affected URL or screen Component or selector Steps to reproduce User impact WCAG success criterion Expected behavior Screenshot or notes This helps teams move from report to ticket without guessing. Plan remediation ownership Accessibility issues do not always map cleanly to one discipline. Examples: Missing form label: engineering Confusing error copy: content and pr

We've all been here. A new form shows up, you install React Hook Form, add Zod or Yup, and in ten minutes you have something that "works." The problem doesn't surface that day. It surfaces three months later, when the same VIN you validate in the create car form also has to be validated in edit , in import from Excel , and it turns out the rule —"17 characters, the last 5 numeric"— is written three times, each one slightly different, and none of them lives in a place you can point to and say "here is what a valid VIN is." A typical form with a library looks roughly like this: const schema = z . object ({ vin : z . string (). length ( 17 , " The VIN must be 17 characters " ), miles : z . number (). min ( 0 , " Miles cannot be negative " ), // ...and 8 more fields }); const { register , handleSubmit , watch , formState : { errors }, } = useForm ({ resolver : zodResolver ( schema ), }); It works. But if you stop to look at it, you're paying three costs that almost never get named: 1. Clean code dissolves. The business rule ends up scattered across the schema , the resolver , the register calls, the Controller s, and the JSX. The knowledge — what makes a car valid — has no home. It's wired into the UI. And what's wired into the UI doesn't get reused: it gets copied. 2. Performance and coupling are paid silently. These libraries live on subscriptions: watch , re-renders on every keystroke, internal state to keep in sync. For a contact form, who cares. For a screen with 15 fields, sub-forms, and cross-field validation, your component is tied to the library's lifecycle —not yours— and you start fighting it instead of using it. 3. Developer convenience is a trap. It's wonderfully convenient at first . But that same rule: how do you test it without mounting a component? How do you move it to the backend? How do you translate it into two languages without polluting the schema? Everything the library gave you for free, it charges you for the day you need to step outside its mo

I spent last month migrating 23 client sites from JPEG/PNG to WebP and AVIF. Here's what I wish someone told me before I started. AVIF vs WebP: the real numbers AVIF is about 30% smaller than WebP at the same quality level. But Safari support is still patchy — if your traffic is 40%+ iOS, you need <picture> tags with WebP fallback. No way around it. The biggest win wasn't the format The single biggest reduction came from capping max image width at 1200px and setting quality to 80. One site went from 9.4MB to 318KB per page — a 97% reduction — just from those two settings plus lazy loading. The format switch was the cherry on top, not the cake. Tools I used daily SmartImgKit — quick batch conversions in the browser. No uploads, no signup, drag and drop. Handles the 80% case where you don't need a CLI pipeline. Supports JPG, PNG, WebP, AVIF, GIF, BMP, TIFF. ImageMagick — server-side batch jobs for when you need automation. Squoosh — one-off fine-tuning with visual comparison. Sharp (Node.js) — build pipeline integration. The HEIC surprise Every iPhone user's photos are HEIC. Most web tools crash on them. You need a converter that handles them before the pipeline — SmartImgKit's HEIC converter works locally in-browser, no uploads. The 80/20 rule Format + max width + lazy loading = 80% of the gain. Everything else is diminishing returns. Don't over-engineer it.