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.
submitted by
/u/cloudinstone2 [link] [comments]