Potluck - Gatsby vs Next × Is Google Home spying on you? × Flat File CMS × CSS Frameworks × Hosting Client Sites × More!

Episode Summary

Executive Summary: A potluck episode covering practical web-dev advice and listener questions. Wes and Scott discuss when Gatsby fits vs Next.js, the meaningless difference between “developer” and “engineer,” handling designers and CSS systems, the risks of overriding prototypes, why clients should own hosting accounts, privacy concerns around smart speakers, CMS choices, use of data attributes, CSS-in-JS vs Sass, when to use component libraries, Git client preferences, and a favorite fitness app plus a media recommendation.

Main Topics: Gatsby vs Next.js for dynamic content: They explain why Gatsby is a poor fit for sites with paywalled, user-specific, or frequently changing content, while Next.js better supports server-side rendering, authentication, and dynamic user state. Developer vs engineer: The hosts argue the distinction is mostly a job-title and legal-regulation issue, not a meaningful technical separation, and caution against overemphasizing titles. Design workflow and collaboration: They emphasize that design/dev friction is best solved through early, ongoing communication and shared system thinking rather than blaming designers or developers. Prototype overriding and safe JavaScript patterns: They discuss whether assigning Array.prototype to NodeList.prototype is acceptable, concluding built-in prototypes generally should not be overwritten, though this specific case seems low-risk in a library context. Client hosting ownership and recurring billing: They strongly recommend clients own hosting accounts and billing directly to avoid long-term support liability and being tied to problems outside the developer’s control. Privacy and smart-home devices: They debate always-listening devices like Google Home and smartphones, weighing convenience against surveillance concerns and noting a cautious trend toward privacy-focused products. CSS architecture and tooling choices: They compare Sass, CSS-in-JS, data attributes, and component libraries, generally advocating for choosing tools that improve maintainability and developer ergonomics rather than following trends.

Key Arguments: Gatsby is best for largely static sites; it struggles with real-time user state, paywalls, and dynamic app behavior, which Next.js handles better through server-side rendering and cookies. The difference between a software developer and software engineer is mostly semantic; titles vary by region, company, and legal rules, so it should not dominate discussion. Design problems are usually team-process problems: better communication, shared design systems, and early involvement of developers reduce inconsistencies more effectively than blame. Overwriting built-in prototypes is generally bad practice because it can surprise other code; however, some controlled library patterns like NodeList.prototype = Array.prototype may be acceptable when no behavior is lost. Clients should sign up for their own hosting/services so they own billing and credentials; otherwise, the developer becomes responsible for unrelated outages and long-term support. Smart speakers and phones are always listening in some sense, but the practical privacy tradeoff is personal; convenience is real, yet skepticism and new OS privacy prompts are encouraged. CSS-in-JS, Sass, classes, and data attributes are all valid; the right choice is the one that supports a maintainable system and fits the team’s workflow. Component libraries like Bootstrap or Material are useful when speed matters, especially for side projects or admin UIs, but can be painful when heavily customized in production apps. Using a GUI Git client or VS Code’s Git tools can help with merges and history, but terminal workflows remain fast for those with strong muscle memory. A one-time-purchase fitness app can be preferable to subscriptions when the app doesn’t need heavy server infrastructure. Sick picks and plugs are part of the show’s format, reflecting their preference for useful, enjoyable recommendations alongside technical topics.

Data Points: Course platform status: Currently based on Meteor, with a rewrite in Next.js in progress - Scott describes the backend/frontend transition for Level Up Tutorials Gatsby content timing: Static content is built at build time; user-specific content cannot be real-time - Reason Gatsby is not ideal for paywalled or logged-in experiences Mirror repair cost: A couple hundred bucks - Wes estimates his DIY car mirror repair cost versus a shop repair Broken mirror part cost: $3,000 - Wes says the full car mirror assembly is extremely expensive Fridge part cost: $100 - Wes considered buying a replacement valve for a fridge water dispenser Client hosting suggestion: Clients should set up and pay for their own hosting accounts - Advice to avoid recurring billing on the developer’s card Netlify sponsor CTA: netlify.com/syntax - Sponsor segment promoting Netlify hosting and deployment FreshBooks trial: 30-day unrestricted free trial - Sponsor segment promoting FreshBooks accounting FreshBooks promo code: syntax - Listeners are told to enter syntax.tax in the “how did you hear about us?” field Heavy Set price: $9 or $10 one-time purchase - Wes recommends the fitness app as a better value than subscriptions Heavy Set backup integration: Apple Health integration - One reason the app fit Wes’s iOS/fitness workflow Fitness app subscription norm: $10 a month - Wes criticizes many competing fitness apps for recurring pricing Baroness Von Sketch seasons: 5 seasons - Wes recommends the Canadian sketch comedy show

Pivotal Quotes: "We've said it before: Gatsby for websites, Next for apps." — Scott: Summary of their heuristic for choosing frameworks based on static vs dynamic needs "Please, please, please send them on in at syntax.fm." — Wes: Closing call for more potluck questions from listeners "Don't burn out." — Wes: Explaining why the show includes off-topic personal segments like fitness, health, and float tanks

Implications: For teams building modern web apps, architecture should follow content dynamics and ownership boundaries: use static tools where they fit, protect clients from billing/support entanglements, and prioritize collaboration and maintainable systems over trends or titles.