In this episode, GitHub engineer Joel Hawksley breaks down the evolution of GitHub’s UI architecture—from Rails views to ViewComponent to React—and the tradeoffs behind each step. ViewComponent emerged as a practical, backwards-compatible way to eliminate duplicated UI logic in GitHub’s massive Rails monolith, ultimately supporting thousands of components and becoming a key driver of consistency and accessibility. Joel explains how hard UI correctness is compared to backend systems, how keyboard-only tests surfaced real accessibility regressions, and why ViewComponent v4 streamlines the project as it enters a stable, long-term support phase. He also discusses why GitHub increasingly leans on React for complex, app-like behavior: developer enthusiasm, design-system tooling, CSS encapsulation, and the need to manage frontend–backend sync at scale. The conversation closes with reflections on the realities of open-source maintenance and the importance of stability as ViewComponent’s future.Links:Joel Hawksley’s WebsiteViewComponent WebsiteViewComponent GitHub RepoPrimer ViewComponentsPrimer ViewComponents RepoPhlex WebsitePhlex GitHub RepoHerb GitHub RepoReActionView GitHub RepoWCAG Accessibility StandardsRails Strict Locals DocumentationDead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.
--------
53:46
--------
53:46
Ground Zero-Cost Bindings (with Josh Vlk)
In this Dead Code episode, Jared and ReScript contributor Josh Vlk explain why ReScript is a strongly typed, sound language for web development that compiles to JavaScript, offers first-class React support, and favors a “one right way” approach (built-in formatter, no linters) over TypeScript’s configurable sprawl. They trace its evolution from Reason/BuckleScript to today’s standalone ReScript, with v12 shedding legacy OCaml baggage, adding a rewritten Rust compiler for major speed, native monorepo support, zero-cost JS bindings, and automated upgrade fixes. The pair highlight how variant types and exhaustive pattern matching naturally model complex business logic and make refactors safe and fast, often resulting in less code and fewer bugs. Adoption can be incremental—drop a rescript.json, compile alongside TS/JS, and start with a small component or state reducer. Jared closes by urging developers to try it, noting ReScript’s consistency may also make it especially friendly for AI-assisted coding.Links:ReScriptTypeScriptReasonMLBuckleScriptOCamlRust“ReScript Has Come a Long Way — Maybe It’s Time to Switch from TypeScript” by Josh Vlk“Domain Driven Design Made Functional” by Scott Wlaschin (F# / functional programming concepts)ReScript ForumsReScript DocsReScript Packages on npm – Community bindings and librariesJosh Vlk on BlueskyJosh’s website Dead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.
--------
1:10:14
--------
1:10:14
Brut-al Death (with David Bryant Copeland)
In this episode, Dave Copeland discusses Brut, his Ruby web framework built atop Sinatra that prioritizes “simple over easy” design principles. Brut replaces traditional MVC with pages, forms, and handlers, uses Flex for HTML generation, Sequel for database access, and lightweight tools like BrutCSS and BrutJS for styling and interactivity, emphasizing direct alignment with web standards. It eliminates free-form parameter hashes by injecting structured objects, mirrors HTML for form validations, and defaults to a strict, Postgres-only setup with non-nullable fields, required foreign keys, and built-in observability through OpenTelemetry and a strict Content Security Policy. Dave and Jared also discuss modern browser-based CSRF protections, the philosophy behind Brut’s defaults, and how Dave aims to refine it toward a 1.0 release with real-world apps and clear migration paths for Rails developers, positioning Brut as a lightweight, standards-aligned alternative within the Ruby ecosystem.Links:BrutSinatraHanamiSequelTachyonsTailwind CSSOpenTelemetryPostgreSQLMDN Web DocsElektron DigitaktAbleton LiveActiveRecordCoffeeScriptContent Security Policy (CSP)Rich Hickey – “Simple Made Easy” talkBurg.rbDead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.
--------
49:12
--------
49:12
God Class Funeral (with Adam Tornhill)
Jared talks with Adam Tornhill, founder of CodeScene, about the psychology of programming and how understanding human cognitive limits leads to better software. Adam explains that since working memory can only juggle a few items at once, developers must rely on chunking and good abstractions to manage complexity. His Code Health metric, based on detecting “ugliness” like long functions and low cohesion, shows that healthy code enables teams to deliver features up to ten times faster with far fewer defects. They discuss how God classes become coordination bottlenecks, how behavioral code analysis reveals hotspots where improvement matters most, and why learning different programming paradigms sharpens thinking. Adam emphasizes that writing readable, well-named, modular code benefits both humans and AI tools—because clarity, consistency, and thoughtful naming make code easier to understand, maintain, and extend.Links:CodeSceneYour Code as a Crime SceneWorking MemoryGod Class / God ObjectDomain-Specific Languages (DSLs)Dead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.
--------
35:01
--------
35:01
Deserial Killer (with Matt Schwager)
Jared sits down with Trail of Bits security engineer Matt Schwager to discuss the persistent security risks of Ruby’s Marshal library. Matt explains that while Marshal (and Python’s Pickle) makes serialization simple and fast for tasks like caching, its “serialize anything” design has led to over a decade of recurring vulnerabilities. Despite repeated patches, new bugs and exploitation gadgets keep surfacing, often hidden in defaults or legacy code, as seen in Rails caching and RubyGems.org. Matt argues that this reflects a fundamental trade-off between ergonomics and security, suggesting alternatives like JSON are safer, though less convenient. He highlights mitigation strategies such as documentation, static analysis, and fuzzing with his tool Ruzzy, while also pointing to broader Ruby risks like eval misuse, SSRF, and supply chain issues. Jared reflects on the cultural tension in Ruby between ease of use and security, wondering if safer defaults could help developers avoid these common pitfalls.Links:Trail of Bits BlogRuby Marshal documentationPython Pickle documentationJSONYAMLTOMLMessagePackRails Caching GuideRubyGems.orgRubyGems source on GitHubRuzzy on GitHubAFL on GitHubSemgrep RegistryBlack Hat USA 2017 TalkDead Code Podcast Links:MastodonXJared’s Links:MastodonXtwitch.tv/jardonamronJared’s Newsletter & WebsiteEpisode Transcript Hosted on Acast. See acast.com/privacy for more information.
The software industry has a short memory. It warps good ideas, quickly obfuscating their context and intent. Dead Code seeks to extract the good ideas from the chaos of modern software development. Hosted on Acast. See acast.com/privacy for more information.