public digest · 5 picks
Local LLMs, a better ls, and the browser automation trifecha
Five picks this week that split cleanly into two camps: tools you run locally to make your machine better, and tools you use to make other software behave. Both camps share a theme — maturity has a cost, and every one of these projects makes you pay it somewhere, whether that's a bloated flag list, a Bazel build, or a postinstall script your package manager quietly blocks.
If you've been putting off self-hosting an LLM, or you're choosing between Cypress, Puppeteer, and Selenium for the third time this year, this batch should settle a few arguments.
// pick 1 of 5
This is the rebrand/evolution of text-generation-webui, a long-running Gradio-based desktop app and API server for running local LLMs (GGUF, EXL3, Transformers, TensorRT-LLM). It targets people who want a self-hosted ChatGPT-style UI with an OpenAI/Anthropic-compatible API, without sending data anywhere.
This is the project formerly known as text-generation-webui, and it's still the most complete answer to "I want a local ChatGPT with an API, no cloud." The multi-backend support is the real selling point — llama.cpp, ExLlamaV3, Transformers, TensorRT-LLM, all under one roof — which is more than most competing UIs bother to maintain. The portable builds with bundled CUDA/ROCm/Vulkan binaries genuinely fix the worst part of local LLM setup: driver hell.
What to know going in: the install matrix (conda vs portable vs docker) and the sheer number of CLI flags mean there's a real learning curve before you're comfortable. Extensions are a mixed bag — some are clearly unmaintained side projects bundled along for the ride. And the project's history of renaming itself means don't get too attached to your bookmarked docs URLs.
View on GitHub → Our full take →
// pick 2 of 5
eza is a Rust rewrite/continuation of exa, a drop-in ls replacement with git status, icons, themes, and tree views. It's for anyone who wants a nicer default file listing in their terminal without giving up ls muscle memory.
eza is what ls should have been by now. Git status baked into the long/tree view is the single feature that makes switching worth it, and the fact that it ships as a static binary with zero runtime deps means it's trivial to drop into any environment. It's also actually tested — trycmd snapshot tests catch output regressions, which is rare for a CLI tool this size.
This is a continuation of exa after its maintainer went quiet, so some of the design decisions and open issues are inherited rather than reconsidered from scratch. It's also not a drop-in ls replacement for scripts — the flag set diverges from POSIX ls, so anything parsing ls output needs adjusting before you alias it away. Cross-platform quirks (Windows permissions, macOS mounts) are handled with separate code paths, which is more to keep in sync but so far seems to work.
View on GitHub → Our full take →
// pick 3 of 5
Cypress is a browser-based end-to-end and component testing framework, used widely for testing web apps in JS/TS with a real-time test runner. It's aimed at frontend and QA engineers who want tests that run in an actual browser rather than jsdom, with time-travel debugging.
Cypress remains the most pleasant way to write browser tests if your stack is JS/TS-first. The time-travel debugger and automatic waiting model quietly eliminate a huge class of flaky-test hacks that Selenium-era suites are full of, and the monorepo shows real production maturity — separate packages for driver, server, reporter, and per-framework component testing adapters.
Heads-up before you commit: this is a large codebase to contribute to, building the binary locally is not a weekend project. No Safari support at all is a dealbreaker for some teams, and multi-tab/multi-origin scenarios still require workarounds. Component testing quality varies a lot by framework — React and Angular get first-class treatment, others less so.
View on GitHub → Our full take →
// pick 4 of 5
Puppeteer is Google's official Node.js library for controlling Chrome/Firefox via DevTools Protocol or WebDriver BiDi, used for headless browser automation, scraping, and testing. It's the de facto standard most other browser automation tools (and testing frameworks) build on top of.
Puppeteer is the base layer half the browser automation ecosystem is built on, and for good reason — the API is mature, request interception and coverage collection are genuinely useful, and BiDi support means it's no longer Chrome-only in spirit. Being maintained by the Chrome DevTools team means protocol changes get tracked fast.
The recurring pain point is the postinstall Chromium download getting silently blocked by npm/pnpm/yarn's script-blocking defaults — you will hit this, and the fix (running `puppeteer browsers install` manually) isn't obvious until you've read an issue thread about it. The API surface is also enormous, with overlapping abstractions (CDP, BiDi, puppeteer-core, puppeteer) that add real cognitive load. Firefox support via BiDi is still second-class, so verify per-feature before betting on it.
View on GitHub → Our full take →
// pick 5 of 5
Selenium is the reference implementation of WebDriver browser automation, spanning Java, Python, JavaScript, Ruby, C#, and Rust bindings plus the Grid for distributed test execution. It's for anyone building browser automation or end-to-end test infrastructure, whether directly or as a dependency of higher-level testing tools.
Selenium is still the reference point for browser automation, and the spec-driven approach (W3C WebDriver) means behavior is consistent across its Java, Python, JS, Ruby, C#, and Rust bindings — genuinely rare for a project this old and this large. Selenium Manager finally killed the old driver-version-matching headache, which used to be half the support burden.
What to know: the build system is heavy, Bazel plus per-language toolchains plus a Rake wrapper, and setup on Windows is non-trivial by their own admission. It's an old, sprawling codebase, so contributing past small fixes takes real ramp-up time. And flakiness in browser-driven tests is inherent to the problem space — Selenium can't fully engineer that away, and neither can anything downstream of it.
View on GitHub → Our full take →
That's the list. If you want these picks in your inbox instead of hunting for them, sign up for the weekly email below — no fluff, just the repos worth your time.
Get this in your inbox →