Proposal: Migrate Away from Polymer Frontend

[Ben0p]

🚀 Proposal: Migrate Away from Polymer Frontend

1️⃣ Context & Motivation

• The current frontend uses Polymer, which is now deprecated and in maintenance-only mode.
• Continuing to use Polymer risks technical debt, compatibility issues, and performance limitations.
• Migrating gives us a chance to adopt a modern framework with better tooling, performance, and maintainability.

---

2️⃣ Framework Options

🧱 A. Lit (Web Components)

Pros:

• Official successor to Polymer.
• Lightweight, fast, uses modern JS features (async rendering, decorators, etc.).
• Allows incremental migration from Polymer to Lit.
• Excellent compatibility with other frameworks (Angular, React, Vue).

Cons:

• Requires some learning for new lifecycle and tooling.

---

🏗️ B. Angular

Pros:

• Fully-featured and battle-tested framework.
• Great tooling (CLI), TypeScript-first, strong Google support.
• Enterprise-ready with scalable architecture.
• I (op) have extensive experience with Angular, but will still go with the consensus.

Cons:

• Heavier than Lit and not designed for web-component-first development.
• Not optimal for reusable components across environments.

---

⚛️ C. React / Next.js

Pros:

• Massive ecosystem and mature tooling.
• Next.js adds SSR/SSG, routing, and performance enhancements.

Cons:

• JSX and virtual DOM make interop with web components harder.
• React appears to be slowing in popularity growth.
• Less ideal if we want to preserve web components.

---

🔍 D. Other Options

• Vue / Svelte: Simpler DX and lightweight runtime, great for small-to-medium apps.
• Stencil / FAST / LWC: Web component-oriented, but with smaller communities.
• Could be overkill or unfamiliar to contributors.

---

3️⃣ Evaluation Criteria

Criteria	Lit	Angular	React / Next.js	Vue / Svelte	Stencil / FAST
Incremental migration	✅ Excellent	⚠️ Partial	⚠️ Wrappers needed	⚠️ Wrappers	⚠️ Wrappers
Native web-component support	✅ Yes	⚠️ Custom schema	⚠️ Wrapper-only	⚠️ Limited	✅ Yes
Developer experience	✅ Lightweight	⚠️ Steep	⚠️ Mixed (JSX, boilerplate)	✅ Simple	⚠️ New / niche
Performance / Bundle size	✅ Small	⚠️ Larger	⚠️ Moderate	✅ Small	✅ Small
Ecosystem / Support	✅ Growing	✅ Mature	✅ Massive	✅ Growing	⚠️ Niche
My familiarity	👍 Some	👍 High	⚠️ Moderate	⚠️ Low	⚠️ Low

---

4️⃣ Suggested Approach

1. Build a Prototype

   • Convert one real-world Polymer component (e.g. mist-picker) to Lit.
   • Evaluate bundle size, build workflow, and developer experience.

2. Host a Discussion

   • Share this proposal and prototype outcomes with the team.
   • Collect input, discuss trade-offs, finalize decision.

3. Migration Plan

   • If Lit is selected, use a hybrid migration (Polymer 3 + Lit).
   • Define priorities: auth, dashboard, forms, etc.

---

5️⃣ Recommendation

• Primary Recommendation: Adopt Lit for component migration.
  • Best incremental path from Polymer.
  • Good long-term strategy for reusable, interoperable components.
• Keep Angular as a shell host if needed, or go full-Lit if aiming for standalone web components.
• React/Next.js/Vue/Svelte are still on the table, but come with higher migration and interop costs.

---

🧩 Next Steps

• Prototype a component in Lit.
• Open team discussion and review.
• Draft a phased migration roadmap.

[Ben0p]

I am personally familiar with Angular, and the Nebular UI library. However, migrating to an entirely different framework would require a complete re-write of the UI. Lit could be more of a gradual migration, except the complexity of the app has probably outgrown web components and probably needs a more scalable framework like Angular.

I am not a fan of the inline template string blocks with web components, the IDE linting doesn't work, it just sees it as a string. The HTML / CSS could probably be split out in to another file or there may be a way to configure the IDE to recognise the template string blocks. Could also be a skill issue.

There are a lot of pros and cons. Medium-term, Lit makes sense, long-term, Angular makes more sense.

It is also possible I have no idea what I'm talking about and there is some other solution.

Whatever the decision, we probably won't tackle that until way in the future like version 6.0.0 or something. It is more important to get it functional for now.