Is Gutenberg fragmentation impacting your wordpress plugin architecture? (Block-only vs. Legacy theme compatibility)

​Post Body:

​Specifically, I’m constantly torn between two paths: building exclusively for the Block Editor vs. maintaining backward compatibility with classic themes.

​Here is why this choice creates such a massive headache:

​The Block Approach: Building features as Gutenberg blocks offers intuitive inline previews, live interactivity, and a seamless visual editing experience. It keeps the codebase clean, modern, and light. A pure block version of a plugin might easily stay around 1MB.

​The Compatibility Trait: To make that same plugin work smoothly on non-block/classic themes, you have to ship a mountain of legacy overhead—extra database storage logic, classic settings UIs (like Option Pages or Meta Boxes), complex fallback conditional checks, and duplicate frontend rendering routines. That lean 1MB plugin suddenly bloats into 10MB just to support both worlds.

​This constant tug-of-war between modern UX and legacy support feels like a developer's nightmare. You either sacrifice codebase simplicity or lock out a significant portion of users who still rely on classic themes and page builders.

​For those of you actively building and selling plugins:

​Which path do you lean toward? Are you moving to Block-only, or are you prioritizing maximum backward compatibility?

​How do you handle the technical debt and code bloat if you choose to support both?

​Would love to hear how other developers in the community are tackling this tradeoff.