[{"data":1,"prerenderedAt":14},["ShallowReactive",2],{"post-when-to-reach-for-typescript-vue":3},{"_path":4,"title":5,"description":6,"date":7,"tags":8,"readingTime":12,"body":13},"\u002Fblog\u002Fwhen-to-reach-for-typescript-vue\u002F","When to Reach for TypeScript on a Vue App","A pragmatic take on where TypeScript pays off in Vue—and where plain JS is still fine.","2025-11-30",[9,10,11],"typescript","vue","frontend",1,"# When to Reach for TypeScript on a Vue App\n\nTypeScript is valuable, but it is not free. On Vue projects I add it where the types catch real mistakes—and stay lighter where they mostly add noise.\n\n## Strong wins\n\n- **Shared data shapes** — API responses, blog post metadata, app config\n- **Composables used in many places** — a typed return value documents the contract\n- **Refactors across files** — renaming a prop or field with confidence\n\n```typescript\ninterface BlogPost {\n  _path: string;\n  title: string;\n  description: string;\n  date: string;\n  tags: string[];\n}\n```\n\n## Softer calls\n\nTiny one-off components, quick prototypes, and throwaway experiments often stay clearer in plain JavaScript. Forcing types on every local `ref` can slow you down without preventing bugs.\n\n## Meet in the middle\n\nJSDoc or gradual typing works well: type the boundaries (fetch results, composable APIs) and leave simple presentational pieces looser until they stabilize.\n\n## Wrap-up\n\nUse TypeScript where shared contracts matter. Skip the ceremony where the code is local, short-lived, and easy to reason about by eye.",1784110285920]