Frontend Focus: jQuery 4.0, Astro Joins Cloudflare, Docfind, and the Death of Pixel Perfect
Published on 21.01.2026
jQuery 4.0.0 — Happy 20th Birthday
TLDR: Twenty years after John Resig introduced jQuery at BarCamp NYC, version 4.0 arrives with IE<11 support removed, source migrated to ES modules, Trusted Types and CSP support, and a slimmer build that removes Deferreds and Callbacks.
jQuery 4.0 is the first major release in almost 10 years, and it brings breaking changes the team has wanted to make for years. The removal of deprecated APIs combined with dropping old IE code resulted in a size reduction of over 3KB gzipped.
Key changes include: IE 10 and older support dropped (IE 11 removal planned for jQuery 5.0), source migrated from AMD to ES modules making jQuery compatible with modern build tools, Trusted Types support for CSP compliance, and focus event order now follows the W3C spec (blur → focusout → focus → focusin).
The slim build got even smaller at around 19.5KB gzipped by removing Deferreds and Callbacks — native Promises can replace most usage in all supported browsers except IE11.
Removed APIs include jQuery.isArray, jQuery.parseJSON, jQuery.trim, and others that now have native equivalents. The migration guide and jQuery Migrate plugin are available to assist with upgrades.
Key takeaways:
- First major jQuery release in nearly a decade
- ES modules source enables modern build tool compatibility
- Deprecated APIs removed — use native equivalents like Array.isArray(), JSON.parse(), Date.now()
- Slim build now ~19.5KB gzipped without Deferreds/Callbacks
Link: jQuery 4.0.0
Astro is Joining Cloudflare
TLDR: The Astro Technology Company, creators of the Astro web framework, has been acquired by Cloudflare. Astro remains open source and MIT-licensed, with the entire team continuing to work on the framework. Astro 6 Beta is now available.
Astro powers content-driven websites for brands like Porsche, IKEA, OpenAI, and platforms like Webflow Cloud and Wix Vibe. Cloudflare uses Astro for their developer docs, website, landing pages, and blog. The acquisition brings the teams together to make Astro "the best framework for content-driven websites for many years to come."
The key to Astro's success has been focus: content-driven, server-first, fast by default, easy to use, and developer-focused. The Islands Architecture enables mostly static HTML with selective client-side interactivity using any framework — React, Vue, Svelte, Solid, or others on the same page.
Astro 6 brings a redesigned development server powered by the Vite Environments API. The headline feature: when you run astro dev with Cloudflare, your code runs in workerd (Cloudflare's open-source Workers runtime), with access to Durable Objects, KV, R2, and more — not simulations, the real APIs.
Live Content Collections are now stable, enabling real-time data updates without rebuilds. Content Security Policy support is also stable, handling hashes of scripts and styles automatically.
Key takeaways:
- Astro remains open source, MIT-licensed with public roadmap
- All Astro team members join Cloudflare, continuing Astro development
- Astro 6 dev server runs your code in the actual production runtime
- Islands Architecture enables mixing frameworks with static HTML
- Deploy anywhere — Cloudflare ownership doesn't change portability
Tradeoffs:
- Cloudflare ownership provides resources but raises vendor concentration concerns
- Real runtime dev server catches more bugs but requires runtime-specific setup
Link: Astro is joining Cloudflare
Building Docfind: Fast Client-Side Search with Rust and WebAssembly
TLDR: VS Code's documentation now features instant search powered by docfind — a client-side search engine built in Rust that compiles to WebAssembly. For ~3MB of markdown across 3,700 documents, the index is 2.7MB compressed with ~0.4ms search times.
João Moreno shares the journey of building docfind, from discovering a decade-old blog post about Finite State Transducers to patching WebAssembly binaries. The existing solutions (Algolia, TypeSense, Lunr.js, Stork Search) didn't hit the sweet spot: fast, client-side, compact, and easy to operate.
The technical foundation combines three algorithms: FST (Finite State Transducers) for compact keyword-to-document mapping, RAKE (Rapid Automatic Keyword Extraction) for extracting meaningful phrases from documents, and FSST (Fast Static Symbol Table) for string compression. Keywords are extracted and indexed, with the search supporting Levenshtein automaton for typo tolerance and prefix matching.
The clever trick: instead of shipping the index as a separate file, docfind embeds it directly into the WebAssembly module. The CLI parses a pre-compiled WASM template, finds placeholder globals with a marker value (0xdead_beef), patches them with the actual index location, and outputs a valid WebAssembly module containing both search code and data.
The author credits GitHub Copilot as essential to finishing the project — handling Rust's learning curve, WASM binary format details, and scaffolding work while allowing focus on the logic. For the VS Code website: 5.9MB index uncompressed, 2.7MB with Brotli, ~0.4ms search speed.
Key takeaways:
- FST provides memory-efficient string indexing with fast fuzzy/regex matching
- RAKE extracts keywords ranked by importance from documents
- FSST compression optimized for short strings keeps index small
- Index embedded in WASM module = single HTTP resource for search
- GitHub Copilot enabled tackling unfamiliar Rust/WASM domain
Tradeoffs:
- Client-side search eliminates server costs but requires initial WASM download
- Embedding index in WASM simplifies deployment but requires rebuild for content changes
Link: Building docfind: Fast Client-Side Search with Rust and WebAssembly
Rethinking "Pixel Perfect" Web Design
TLDR: In 2026, the term "pixel perfect" has become misleading, vague, and counterproductive. The web was never meant to be a static gallery — it's time to focus on design intent over static values.
Amit Sheen argues that clinging to pixel perfection is actively harmful. The term lacks technical specificity — when someone asks for "pixel perfect" implementation, are they asking about colors, spacing, typography, borders, alignment, shadows, or interactions? The answer "everything" reveals the problem: it's expressing a feeling, not giving a directive.
The multi-surface reality makes fixed pixel implementation a technical impossibility. We build for infinite viewports, resolutions, aspect ratios — from foldable phones to spatial interfaces. Content is dynamic: localization changes text length, currency symbols, date formats. A design "pixel-perfect" for English collapses in German or CJK languages.
The accessibility argument is compelling: if a layout breaks when users increase font size or force high-contrast mode, it isn't perfect — it's broken. Pixel-perfect prioritizes visual aesthetics over functional accessibility.
The practical advice: shift from static values to design intent. Instead of margin: 24px, ask why the margin exists. Use design tokens (--spacing-large instead of 32px) to sync logic between design and code. Embrace fluidity as a feature using clamp(), Container Queries, and relative units.
Replace "pixel perfect" with: "Visually consistent with the design system," "Matches spacing and hierarchy," "Preserves proportions and alignment logic," "Acceptable variance across platforms."
Key takeaways:
- "Pixel perfect" masks lack of clear requirements with a feeling
- Multi-surface reality makes fixed pixel implementation impossible
- Accessibility requires flexibility — rigid layouts break for many users
- Design intent (the "why") should drive implementation, not static mockups
- Design tokens bridge design and code by syncing logic, not values
Link: Rethinking "Pixel Perfect" Web Design
Using 100vw is Now Scrollbar-Aware in Chrome 145
TLDR: Chrome 145 fixes a longstanding CSS annoyance: 100vw now automatically subtracts the scrollbar width when overflow-y: scroll or scrollbar-gutter: stable is set on the html element.
The problem: viewport units don't account for classic scrollbars. Setting something to 100vw makes it viewport-width, but when a vertical scrollbar is present, the element becomes too wide and causes horizontal overflow — that "pointless" horizontal scrollbar everyone hates.
Why not just subtract the scrollbar size automatically? Cycles. If a page has a box sized 100vw × calc(100vh + 1px), subtracting scrollbar size creates an infinite loop: page overflows → scrollbar appears → size adjusts → no overflow → scrollbar disappears → repeat.
The solution: only subtract scrollbar size when scrollbars are unconditionally present. Firefox briefly had this behavior but removed it for interoperability. The CSS Working Group resolved in 2023 to implement this when overflow: scroll is set on the root element or when scrollbar-gutter: stable is used.
Recommendation: add scrollbar-gutter: stable to your CSS reset. It reserves space for the scrollbar without drawing one when not needed, and now triggers the scrollbar-aware viewport unit calculation.
Key takeaways:
- Chrome 145+ subtracts scrollbar width from
100vwunder specific conditions - Requires
overflow-y: scrollorscrollbar-gutter: stableon html element - Prefer
scrollbar-gutter: stable— reserves space without always drawing scrollbar - Currently Chromium-only, no CSS-only feature detection available
Link: Using 100vw is now scrollbar-aware
Better Defaults for Popovers with CSS Anchor Positioning
TLDR: A simple CSS reset rule positions popovers near their controlling button using implicit anchor positioning — something you probably want as default behavior instead of center-of-viewport placement.
Manuel Matuzovic shares a rule for UA+ reset that uses CSS anchor positioning to make popovers behave more intuitively. By default, popovers appear centered in the viewport like dialogs. In most cases, you want them aligned with their triggering button.
The fix is simple for browsers supporting anchor positioning (Chrome and Firefox at time of writing):
@supports(position-area: end) {
[popover] {
margin: 0;
position-area: end span-end;
position-try-fallbacks: flip-block, flip-inline, flip-block flip-inline;
}
}
Popovers already have an implicit anchor, so you just need to override the margin and set the position. The position-try-fallbacks property tells the popover to flip along the inline or block axis if it would overflow the viewport.
Key takeaways:
- Popovers have implicit anchors — no need to explicitly define anchor relationships
- Simple CSS reset positions popovers near their buttons by default
position-try-fallbackshandles viewport overflow with automatic flipping- Wrapped in
@supportsfor Safari compatibility
Link: Better defaults for popovers
ASCII Characters Are Not Pixels: A Deep Dive into ASCII Rendering
TLDR: Most ASCII renderers treat characters like pixels, ignoring their shape. By using a 6-dimensional "shape vector" to capture how characters occupy their grid cells, you can achieve dramatically sharper edges and better visual quality.
Alex Harri built an ASCII renderer that produces remarkably crisp results compared to typical implementations. The key insight: ASCII characters have shape that standard pixel-based approaches ignore. The character "T" is top-heavy, "L" is bottom-heavy, and these differences can be quantified and matched against image regions.
The approach: define 6 sampling circles within each grid cell, calculate overlap values for each ASCII character with these circles to create a "shape vector," then find the character whose shape vector best matches the sampling vector from the actual image region.
For enhanced contrast at boundaries, two techniques are applied. "Global contrast enhancement" normalizes each sampling vector and applies an exponent to crunch darker values while retaining lighter ones. "Directional contrast enhancement" uses external sampling circles reaching into neighboring cells to detect boundaries and sharpen edges.
The implementation required significant optimization. Brute-force nearest-neighbor lookups are replaced with k-d trees for faster character matching. Sampling collection moved to GPU shaders to handle thousands of cells at 60 FPS on mobile. Results are cached using quantized vector components packed into a single number as the cache key.
Key takeaways:
- Standard ASCII rendering treats characters as pixels, ignoring shape
- 6D shape vectors capture character density across grid cell regions
- Contrast enhancement sharpens boundaries without affecting uniform gradients
- k-d trees and GPU acceleration make real-time rendering feasible
- Shape-based matching produces dramatically higher effective resolution
Link: ASCII characters are not pixels: a deep dive into ASCII rendering
Some Thoughts on the Open Web
TLDR: The Open Web is under pressure from AI disruption that changed incentive structures for content publishers. Finding the right balance requires understanding why people publish openly and creating conditions where they want to continue.
Mark Nottingham reflects on the Open Web after hosting discussions at IETF and W3C Technical Plenary. The Open Web is an amazing public good — farmers in developing countries access crop guidelines, students worldwide access resources unimaginable decades ago. It's worth fighting for.
But people have different motivations for publishing openly: contributing to global commons, building reputation, selling ads, enticing subscriptions, or some blend. Discussions need to consider all motivations distinctly. There are also many degrees of "open" — from fully unrestricted to requiring login after three articles. These "small" barriers add up.
AI represents a massive disruption. Content creators feel exploited — they made content available to help people, and it's benefiting large corporations. Publishers see platforms taking more value: first AMP's forced intermediation, now AI reducing traffic to nothing in exchange for nothing. So people are blocking bots, adding paywalls, pulling content.
The tension is between content producer interests and content user interests. Either extreme — pixel-perfect control over usage or all information free for any purpose — would be bad. The challenge is finding a stable, sustainable balance that takes AI shocks into account.
The path forward: focus on creating and strengthening incentives to publish openly, understanding varied motivations. If environmental factors change incentives, address underlying concerns. We have to create an Internet where people want to publish content openly.
Key takeaways:
- The Open Web is a public good reducing costs and friction for information access
- Publishers have varied motivations — contributing to commons, building reputation, revenue
- AI disrupted incentive structures — content used for training, competing with sources
- Blocking bots is now widespread, evidence of demand on publisher side
- Focus on incentives that make publishers want to be open, not coercion
Link: Some Thoughts on the Open Web
The 2025 Web Almanac
TLDR: HTTP Archive's annual state of the web report is out, covering 16 chapters across 16.2 million websites. Variable fonts are supported but underexplored — 40% of sites use them, but mostly as multi-weight files rather than dynamic typography.
The 2025 Web Almanac combines HTTP Archive data with web community expertise. Key statistics: 72% of websites self-host fonts in some capacity, 40% use variable fonts, and 65% of font requests are served as WOFF2. The Fonts chapter highlights that variable fonts have high technical integration but early creative exploration — designers use them as convenient multi-weight files, not yet as fully dynamic typographic resources.
The report processes 244TB of data across 16.2 million websites, with 72 contributors volunteering countless hours. Chapters span page content, user experience, publishing, and distribution.
Key takeaways:
- 16.2 million websites tested, 244TB of data processed
- Variable fonts at 40% adoption but creative exploration still early
- 72% of sites self-host fonts
- 72 contributors across 16 chapters
Link: The 2025 Web Almanac
This article was compiled from the Frontend Focus newsletter. The opinions and summaries presented are interpretations of the original sources — always read the linked articles for complete context.