Skip to main content
JL

James Long

2episodes
2podcasts

We have 2 summarized appearances for James Long so far. Browse all podcasts to discover more episodes.

Featured On 2 Podcasts

All Appearances

2 episodes

AI Summary

→ WHAT IT COVERS James Long, creator of Prettier, joins Josh Goldberg on Software Engineering Daily to discuss how the opinionated JavaScript formatter emerged from code-style debates at Mozilla, why deterministic formatting removes team friction, the technical complexity of building formatters, and the financial realities of sustaining popular open source tooling. → KEY INSIGHTS - **Opinionated formatting over configurable rules:** ESLint's 100+ formatting rules still left room for team disagreement and couldn't handle dynamic JavaScript patterns like inline callback arguments. Prettier eliminates debate by accepting only one meaningful parameter — print width — and producing identical output regardless of how the original code was written, removing style decisions entirely from code review. - **Prettier ignore as the escape valve:** When teams resist adopting Prettier due to intentional formatting choices — such as aligned equals signs in enums — the practical response is to use `// prettier-ignore` comments above those specific blocks. Long estimates only 0.1% of a typical codebase genuinely warrants manual formatting exceptions, making blanket resistance to automation statistically unjustified. - **Never run Prettier through ESLint:** Using the ESLint-Prettier plugin routes formatting through ESLint's rule engine, which reruns fixers up to 10 times when fixes conflict, turning a sub-second formatting operation into a multi-second delay per save. Running Prettier directly as a separate process avoids this overhead entirely and keeps the two tools' responsibilities cleanly separated. - **Unified AST toolchains solve the real performance problem:** Tools like Biome and OXC format are faster not solely because they use Rust, but because they parse JavaScript once and pass a single AST through formatting, linting, and analysis sequentially. The traditional stack parses and regenerates code at each tool boundary, multiplying overhead — a structural inefficiency that a Rust rewrite alone would not fix. - **Open source financial sustainability gap:** Prettier has raised approximately $243,000 total across nine-plus years on OpenCollective, with no full-time maintainers and no backing company. Long frames this as the standard open source trajectory: initial creative energy drives adoption, but long-term maintenance requires compensation structures that donation models rarely provide at sufficient scale for tools used by millions of developers daily. → NOTABLE MOMENT Long revealed that the productivity benefit Prettier became most known for — writing messy code and reformatting it instantly with one keystroke — was never the original design goal. He built it to eliminate PR review arguments, and the authoring speed improvement emerged as an entirely unplanned side effect after release. 💼 SPONSORS [{"name": "Unblocked", "url": "https://getunblocked.com/sedaily"}, {"name": "GuardSquare", "url": "https://www.guardsquare.com"}] 🏷️ JavaScript Tooling, Code Formatting, Open Source Sustainability, AST Parsing, Developer Experience

AI Summary

→ WHAT IT COVERS James Long explains building Actual, a local-first budgeting app using CRDTs for offline-first sync without central database, leveraging SQLite, Electron, and distributed systems concepts from backend architecture applied to client applications. → KEY INSIGHTS - **CRDT Architecture:** Conflict-free replicated data types enable true offline apps by duplicating data twice—normalized SQLite tables for queries and a messages table with hybrid logical clocks that replay in consistent order across all devices without conflicts. - **Merkle Tree Syncing:** Sync protocol uses Merkle trees to hash message chunks hierarchically, comparing single root hashes between clients to identify divergence points, then walking down tree branches to find exact messages needing sync without transferring entire databases. - **Eventual Consistency Trade-offs:** Apps must handle temporarily inconsistent data by normalizing database structure maximally, never deleting records (only tombstone flags), and querying only fully-consistent data at read time to prevent foreign key references to nonexistent records during sync. - **Security Considerations:** Electron apps allow JavaScript modification by unpacking and repacking, creating phishing risks for sensitive data like banking credentials. Service workers in browsers provide better security guarantees through sandboxing, making web-based local-first apps potentially more secure. - **Service Worker Backend:** Web implementation would run entire backend logic in service worker with IndexedDB for messages and WebAssembly-compiled SQLite in memory, enabling multiple browser tabs to sync instantly through single background process while maintaining offline functionality. → NOTABLE MOMENT James reveals his concern about launching bank credential syncing in Electron, explaining how attackers could modify the app's JavaScript to harvest passwords. He plans redirecting users to browsers for credential entry where URL bars provide verifiable security guarantees that desktop apps cannot offer. 💼 SPONSORS [{"name": "Cloudinary", "url": "https://cloudinary.com"}, {"name": "DigitalOcean", "url": "https://do.co/fullstack"}] 🏷️ CRDTs, Offline-First Architecture, Distributed Systems, Local-First Software, Electron Security

Never miss James Long's insights

Subscribe to get AI-powered summaries of James Long's podcast appearances delivered to your inbox weekly.

Start Free Today

No credit card required • Free tier available