835: How to Pick a JavaScript Framework

Episode Summary

Executive Summary: The episode breaks down how to evaluate a JavaScript framework before adopting it, using recent frameworks like OneStack as a catalyst. The hosts argue that framework choice should be driven by practical needs: shipping targets, rendering model, deployment platform, data layer, server functions, auth, TypeScript, CSS, images, ecosystem maturity, portability, and hiring. They also debate what truly counts as a “framework,” contrasting lighter meta-frameworks with more opinionated full-stack systems like Rails, Django, Adonis, and Redwood.

Main Topics: What counts as a framework vs. a library: The hosts debate whether a framework must include routing, auth, database/ORM, and broader application scaffolding, versus being a smaller tool that requires many add-ons. Shipping targets and rendering choices: Discussion centered on whether the app targets web, native, desktop, or webview; and how client-side, server-side, and static rendering should be mixed per route or product area. Deployment and adapter portability: They emphasize choosing frameworks that can deploy across runtimes and hosts through adapters, rather than locking into one platform or cloud provider. Data, APIs, and server functions: The episode covers existing APIs, REST/GraphQL/RPC choices, ORM/database support, and whether the framework supports server actions/functions and endpoint creation. Auth, email, TypeScript, images, and CSS support: A long checklist of practical features to verify before adoption, including auth, built-in email, typed routes, image pipelines, styling approaches, and component library compatibility. Ecosystem maturity, community, and hiring: The hosts note the importance of active maintainers, docs, community support, ecosystem libraries, stability, portability, and whether the framework helps or hurts hiring. Developer experience and opinions: They repeatedly return to the idea that great frameworks make strong choices for you, reducing glue code and making client/server interaction feel like simple function calls.

Key Arguments: A framework should do enough of the app stack to be useful out of the box; otherwise it is closer to a pre-framework or library. The right framework depends on what you are shipping: web, native, desktop, or a mix of product UI and marketing pages. Rendering should be chosen per use case; many products do not need SSR, while content-heavy sites may need SSR or static generation. Adapter-based deployment is preferable because it keeps code portable across hosts and runtimes. Modern frameworks are increasingly converging on route-level rendering choices and runtime-agnostic deployment. Existing API architectures should influence framework choice; teams with established backends often need less opinionation from the frontend framework. Server actions/RPC patterns improve DX because they let developers call server logic like functions while preserving type safety. Auth is often missing from frameworks because database/ORM support is missing or too tightly coupled to a single database. A good framework should support TypeScript deeply, including typed routes and typed params, not just permit TS syntax. Community activity, issue responsiveness, and ecosystem breadth matter because they predict whether bugs can be solved and the framework can survive long-term. Portability matters: choosing web standards and avoiding host-specific APIs makes future migration easier. Hiring remains a practical factor; React’s popularity is partly sustained by the number of developers who know it.

Data Points: Sentry JavaScript integrations: 28 - Wes said Sentry has 28 specific JavaScript integrations. General Sentry integrations guess: 50 - CJ guessed Sentry had 50 integrations before learning the JavaScript-specific count was 28. Sentry signup offer: 2 months free - Listeners are told to use coupon code "tasty treat" at century.io/syntax-signup. Coupon code: tasty treat - Required for the Sentry offer to receive the full two free months. Cloudflare Node compatibility: 98% - They cited Cloudflare’s use of unenv to reach roughly 98% Node compatibility. OneStack status: new framework - The episode is motivated by a recently released JavaScript framework called OneStack/One. GitHub Universe meetup date: October 28th - Syntax meetup announcement in San Francisco tied to GitHub Universe. Meetup time window: 5 to 7 p.m. - Scheduled time for the San Francisco Syntax meetup. Years of production longevity example: 10 years - Scott referenced Express code that still runs after about 10 years of upgrades. Upgrade experience example: 10–15 minutes - Scott described many Express upgrades as taking only 10–15 minutes.

Pivotal Quotes: "I don't believe a framework is a framework without auth and a database, or at least some sort of solution for that." — Wes: Wes defines a framework as something more complete than just routing or UI primitives. "I like the approach in general, I like the islands. I like that it is kind of like you're opting into client-side where you want it." — Scott: Scott explains why Astro appeals to him as a flexible, modern framework approach. "One of the beautiful things is this idea of being able to call the code with just a function call." — CJ: CJ praises server actions/RPC-style full-stack DX and type-safe client/server coupling.

Implications: Listeners should evaluate frameworks as product platforms, not just syntax choices. The episode suggests future-proof picks favor adapters, standards, typed data flows, and flexible rendering over host lock-in or hype.