What this prompt does
This prompt produces an honest, structured Vue 3 versus Angular [angular_version] decision for your team building [project_description]. It factors in your [team_profile], [current_skills], and [project_scale], then compares learning curve, developer experience, TypeScript depth, state management, architecture at scale, performance, enterprise readiness, ecosystem maturity, hiring pool, and a side-by-side implementation of [comparison_feature]. The result is a recommendation you can defend rather than a gut feeling.
It works because it grounds the comparison in your specifics rather than generic framework hype. By telling the AI your team is switching from React or has a tight deadline (via [constraints]), the recommendation weighs what actually bites at scale rather than what looks good in a benchmark. It ends in a decision matrix scoring each category 1 to 5 and is instructed to stay honest — both frameworks are excellent, with different strengths — so you get reasoning you can take to stakeholders, not a foregone conclusion dressed up as analysis.
When to use it
- Choosing a framework your team will live with for years and want a defensible rationale
- A team with
[current_skills](say, React) deciding which framework to adopt next - Evaluating fit for a specific
[project_scale]like 200+ components and 50+ routes - Weighing state management options (Pinia versus NgRx/Signal Store) for your needs
- Factoring hard
[constraints]such as a deadline or accessibility requirements into the call - Wanting a scored decision matrix to bring to stakeholders rather than opinions
Example output
You get a comparison report: a section per category (learning curve for your [current_skills], DX, TypeScript depth, state management, architecture at [project_scale], performance, enterprise readiness, ecosystem for [required_features], hiring pool), a side-by-side code comparison implementing [comparison_feature] in both frameworks, and a decision matrix scoring each category 1 to 5 with a weighted recommendation that accounts for your [constraints].
Pro tips
- Describe
[project_description]and[project_scale]concretely; the right choice differs for a 10-view app versus a 200-component platform - State
[current_skills]honestly — a React team faces a different learning curve than a greenfield one, and that shifts the score - List real
[constraints](deadline, accessibility, low-boilerplate preference) because they often decide the matrix more than raw capability - Name the
[required_features]you depend on so ecosystem maturity is judged against your needs, not in the abstract - Pick a
[comparison_feature]that represents your hardest real screen so the side-by-side code reflects actual effort, not a toy example - Factor the hiring pool in your region into the call, since the easiest framework to staff is sometimes worth more than a marginal technical edge
- Remember the matrix encodes your weighting; if a category matters more to you, adjust its weight rather than trusting a flat average
