Overview of 986: Does Code Quality Matter Anymore?
Hosts Wes Bos and Scott Tolinski run a potluck Q&A episode covering a wide set of frontend and tooling topics: modern patterns for navs (dialog/popover vs JS toggles), whether code quality still matters in an AI-first world, Wes’s “second brain” Obsidian setup (with vector search via QMD), supporting older browsers and progressive enhancement, Effect (effect.ts) tradeoffs, picking a JS full‑stack stack vs Rails-style conventions, layout frameworks vs native CSS, accessibility feedback strategies, and some tools/product picks and plugs.
Key topics discussed
- Navigation patterns (dialog/popover vs classic JS toggles)
- New HTML dialog/popover + CSS features (starting-style / allow-discrete) can animate show/hide, but browser support lags.
- Practical approach today: still use JS to toggle classes for compatibility; migrate to dialog/popover when support is acceptable.
- Haptics on the web
- iOS exposes a vibration-like behavior via a hidden switch hack; Chrome/Android supports navigator.vibrate.
- Potential for abuse and platform limitations noted.
- Does code quality matter when AI writes code?
- Short answer: yes — organization, discoverability, and maintainability still matter.
- AI helps but can introduce drift, duplicated styles/values, and brittle code if the codebase isn’t well structured.
- Well‑organized projects enable better automation/AI assistance (LSPs and agents rely on discoverability).
- Wes’s “Second Brain” update (Obsidian + agents)
- Migrated ~10 years of Markdown into an Obsidian vault, used Obsidian CLI + local agent to log quick items.
- Added structured front-matter for things like clothing measurements and queries via a local agent.
- QMD (vector search) used to index sentence-level embeddings of markdown for better recall (semantic search vs exact text).
- Future wishlist: better image/screenshot OCR support and richer memory search.
- Supporting older browsers & progressive enhancement
- Progressive enhancement + feature queries, fallbacks, or polyfills for new CSS APIs recommended.
- Biggest pain point: long-lived iPads / old Safari versions.
- Use monitoring (Sentry) to detect real-world browser breakage and decide where to polyfill or wait.
- Effect / effect.ts
- Powerful for typed concurrency, error handling and composition, but steep learning curve and heavy buy-in.
- Probably more impactful in projects where these correctness guarantees pay off (or for AI-driven code generation).
- Choosing a JS full‑stack in a fragmented ecosystem
- Rails provides convention; JS has many choices (Next, Remix, Astro, Hono, TanStack, Redwood, etc.).
- Advice: prioritize stability, maintenance, popularity, docs, and whether a tool adheres to web standards (so switching later is easier).
- Tooling ecosystem and third‑party libs may drive frameworks (e.g., some libs only have React support).
- Layout systems: CSS Grid / Flexbox / container queries vs frameworks
- Native CSS + a small set of reusable utility/layout classes (e.g., stack, app-shell, container constraints) covers most needs.
- Little value to bringing in a large layout framework for most modern projects.
- Accessibility / broken sites you visit often
- Record a short screen capture reproducing the issue; send clear, actionable steps to devs (offer that they can discard it).
- Be prepared that some companies won’t act; AI-based tooling (e.g., modem.dev idea) might automate bug-to-PR workflows in the future.
Main takeaways
- Code quality still matters — perhaps even more — because:
- AI tooling benefits from well-structured code for discoverability and safe modification.
- Poor structure leads to drift/rot and makes long-term maintenance painful.
- Use modern APIs (dialog/popover, CSS features) but keep pragmatic fallbacks (JS toggling, feature queries or polyfills) until support is widespread.
- Small, composable CSS utilities + native layout primitives reduce the need for large grid frameworks.
- For personal knowledge management, Obsidian + CLI + local agents + QMD-style vector search is a practical “second brain.”
- When choosing frameworks/tools, balance novelty vs stability, docs, ecosystem support, and how much vendor lock-in you can tolerate.
- Monitor real users (Sentry) to prioritize polyfills/fixes and detect browser-specific regressions.
Notable quotes & insights
- “You can’t outsource the brain job to a machine.” — caution against offloading architectural thinking and organization to AI.
- AI is improving at refactoring into existing codebases when those codebases follow clear patterns — invest in structure.
- “Small collection of reusable layout classes + native CSS = 80/20 coverage for most sites.”
Actionable recommendations
- Navs: Implement dialog/popover where feasible, but ship with a JS class toggle fallback today for older browsers.
- Progressive enhancement: Use feature queries, polyfills when necessary, and test on real user browser stats before blocking features.
- Monitoring: Add Sentry (or equivalent) to collect errors and browser usage data to inform where compatibility work is needed.
- Obsidian second brain:
- Store facts/measurements as structured Markdown with front-matter.
- Use QMD/vector search or a local agent to make semantic retrieval fast (screenshots/OCR are next steps).
- Accessibility issues: screen-record + concise reproduction steps, send to product/dev with an offer to discard if not useful.
- Tool selection: choose based on stability, docs, and ecosystem rather than hype; prefer standards-based stacks to ease future migration.
- CSS/layout: build a tiny local toolkit (stack, container, app-shell) that you can copy/paste into projects instead of pulling a big framework.
Tools & resources mentioned
- Obsidian (vaults, daily notes, CLI)
- QMD (vectorizing/searching markdown)
- OpenAI/local agents / “OpenClaw” (Wes’s agent reference)
- dialog / popover (HTML elements) and CSS animation properties (starting-style, allow-discrete)
- Sentry (monitoring & root cause analysis) — sentry.io/syntax
- effect (effect.ts) — effect.website
- Frameworks referenced: Next.js, Remix, Astro, Hono, TanStack, Redwood, SvelteKit
- DB/ORM/auth choices referenced: Prisma, Drizzle, Auth.js (and successors)
- Graffiti UI (Wes/Scott’s lightweight layout utility system)
- Capture hardware: AverMedia Live Streamer 4K (capture card) — reliable alternative to small HDMI dongles
- Hardware pick: multi-USB power strip (practical family pick)
- modem.dev (startup mentioned as automating feedback → PR workflows)
- Remotion (used as a reason Scott had to touch React)
Sick picks & shameless plugs
- Wes: multi‑USB braided power strip (keeps kids’ devices charged, flush plugs hold better).
- Scott: AverMedia Live Streamer 4K capture card — reliable HDMI→USB-C capture.
- Shameless plug: Scott’s wife’s parenting podcast, Phases.fm (launched March 4th) — parenting conversations with a psychologist lens.
- Hosts: both use Obsidian; Wes is evangelizing his second-brain setup and Scott teased an episode on Sentry setups and Obsidian tips.
Episode verdict
A wide-ranging, practical conversation for frontend devs and makers. Strong emphasis on pragmatism: adopt modern standards where possible, but keep fallbacks, monitor real users, and keep code organized — AI is a powerful assistant but not a replacement for good architecture and maintainability.