Lots of exciting new features have been landing in CSS recently, and it can be tough trying to figure out if they’re safe to use or not. We might know that a feature is available for 92% of users, but is that sufficient? Where do we draw the line? In this blog post, I’ll share the framework I use for deciding whether or not to use a modern CSS feature.

While we were busy trying to figure out which front-end library to bet on next, JavaScript itself has been going through an evolution of its own. New TC39 proposals are making waves in the community, while others are already on the verge of being implemented in browsers everywhere. And TypeScript's popularity is making the prospect of native type support at some point in the future an actual possibility. One thing's for certain – while the JavaScript of 2024 still feels familiar, there's no guarantee that we'll be able to say the same about the language we write five years from now. Until then, you can help chart our path by taking this year's State of JavaScript survey!

The library uses two native HTML range inputs. This means that all of the native interactions and accessibility features are preserved. Native inputs allow us not to reinvent the wheel. There is about fifty lines of JavaScript to synchronize the inputs, along with some CSS to ensure everything looks polished.

Comparing Core Web Vitals across several websites isn’t without problems. How do we compare three separate metrics, with equal weighting but different units, across multiple sites in a fair and meaningful way? That’s going to be an issue.

Frameworkism is now the dominant creed of today's frontend discourse, and it's bullshit. We owe it to ourselves and to our users to reject dogma and embrace engineering as a discipline that strives to serve users first and foremost.