Very often we get feature requests about something we could add to Sparkle. Sometimes they even go as far as suggesting the exact CSS feature to use, or ready-made component to grab and integrate.
This is generally called the “why don’t you just” suggestion, that underestimates what a full solution to a technical problem looks like. There are also considerations about consequences, support and strategy, but they’re less interesting than the technical challenge.
Let’s take for example the video component in Sparkle. You add it in the canvas and tweak a few options, and you’re good to go. The whole point of Sparkle is that it’s that fast, you don’t need to know what complexity a checkbox hides.
So the video component has 3 main video types (youtube, vimeo, mp4), each can be embedded in the page in 3 different ways (direct embed, click+play, click+lightbox), with 2 different player “themes” (the plyr.io based on-video controls or native browser controls). That alone means 3x3x2=18 variations, that have a few similarities but a lot of different underlying code.
Adding one feature to the video component means ensuring it works with every one of the 18 combinations, and potentially changing their behavior where it breaks.
Not only that, virtually every combination of Sparkle features and options is legitimate. If you think they don’t interact with each other, you’d be surprised. Animated text wrapped around a rotated video in a stick-to-top header? You got it.
But that’s all cool, we think about it a lot and work on solving it once and for all, so it creates an abstraction layer, a platform you can build on without needing to know all the underlying fiddly details.
Please keep the feedback coming, always welcome. But please trust us on finding the most appropriate route to the solution.
