When Blockbase was a Young Theme many aspects of the Block Themes that are well handled now were not. There were things in the Block Themes roadmap that we expected to be taken care of down the road, but we wanted to add that functionality to themes being designed today. Most of the things in “ponyfill” are configured using “custom” settings or other global parameters and target styles that (at the time) weren’t handled by CORE. It gave us a mechanism to control those aspects in child themes.
Ultimately those things in ponyfill can/should be removed to leverage the native solution instead which could allow the ponyfill to go away. It’s not longer very relevant to newer themes and using Blockbase as a parent theme is discouraged.
The code is considered a “ponyfill” because it’s something that ADDS FUNCTIONALITY in it’s “own way” rather than backfilling the ability to do things in older environments (which is what a “polyfill” does).
Thanks for the explanation @pbking
What are the downsides of using Blockbase as a parent theme?
I would say that, at this point in Block Theme evolution, that using ANY theme as a parent theme is rather unnecessary. The aspects of a theme that are well suited as coming from a parent are actually very portable (theme.json settings) and I wouldn’t recommend that structure except for edge cases.
Blockbase specifically has a lot of historical “shims” and “polyfills” that helped us get configurable themes created quickly a few years ago when Block Themes were just starting out but those shims and polyfills aren’t necessary anymore and actually make it MORE difficult to customize now that much of that is available to be done in theme.json settings (and Blockbase is sometimes overriding that in CSS).
Better to start with a theme that has a lot of the styling already in place as a starting point. (We use Block Canvas for that purpose very often which actually looks a fair bit like Blockbase but without the baggage.
Thanks for the informative tips!
