Developing spectrum SPAs on milo

[npeltier]

Hey,

still on plans pages, and not entirely coupled to https://github.com/orgs/adobecom/discussions/754, we'd need stateful behaviours for our plans pages.
Options looked at so far:

• full reuse with amendments of existing blocks (tabs, cards, ...),
• leverage of spectrum css and specifics web component,
• preact application,
• react spectrum

each ones have their pros & cons i won't depict here to let others thoughts & ideas be spit freely :)

[auniverseaway]

The general rule I have is, "If it walks like and SPA and talks like an SPA, it's an SPA and you should use SPA frameworks."

I think you have two competing priorities to consider with plans:

1. Performance - Duh
2. Developer quality of life - state management, maintainability, and code re-use.

I have never seen these two ideals get along when trying to achieve 100LH.

The code you likely want to re-use (Spectrum in all flavors - React, Web Component, CSS-only) is not performant. At all. You won't get 100LH using Spectrum in a real-world scenario. I've done my own POCs on Spectrum:

1. Cost of adding a simple React Spectrum button. - With only a single button, you are introducing 40MS (minimum of TBT)
2. Cost of only using Spectrum CSS. Wildly fluctuating TBT.

If someone else wants to take a crack at using Spectrum again, that's totally fine for me, but if it's not a stable 100 in real-world scenarios, it doesn't ship. It's been ~9 months since I did my CSS-only explorations, so maybe performance is better?

My high-level knowledge of plans says it's not enough of an SPA to warrant using a framework. Especially since you probably want to use Milo's tabs block. I think the only exception would be the business mini-cart (for lack of a better term). I think there's some state in there that you would have to juggle, but I would probably try to write a mini-state management tool (or use Preact's signals independently).

Whenever I have competing priorities, I always fall back on the hierarchy of importance doc.