But what happens when platform / browser vendors remove and/or deprecate a feature or API?
Picture this: You and your fellow developers spend many weeks developing a new feature. At its core, you’re using some newly exposed browser API. Although not all of the versions of the browser you support are going to have this feature, you find a polyfill that adds the feature and you feel pretty confident that it’ll work for the browsers that don’t natively implement the feature. The project is a giant success. Your customers are happy, your boss is happy, and your company is positively impacted.
A year later you hear that the browser vendors met with the W3C and decided to change the spec, or worse decide to deprecate/remove it. You break down into a cold sweat and ask yourself, “How did I not see this coming?”
Although I have never ran into this problem personally or while working at Ontraport, it’s a scary thought.
While no one can see the future, one should be weary of the fact that everything will continue to get bigger, better, faster. As developers we prematurely write polyfill(s) for browsers that don’t natively support the features that we want to use. Which is actually pretty cool!
But at the same time, we could end up finding ourselves in a situation similar to taking a loan from a loan shark. Most of time the browser vendors implement the feature, but every once a while you ending up playing back double.
The sad fact is that the browser is not a static environment; it holds front-end developers captive.
Taking a step back
A couple questions that we can ask ourselves to help prevent a situation like this:
- How much am I willing to gamble?
- Picking one version ahead of the widely-supported version is alright (think javascript transpilers) is akin to betting your car. Two versions ahead is like betting your whole house.
- What is the cost in development time, testing, and team eduction of learning this new API?
- Its there an older/standardized way of doing things that works just fine that we are ignoring because it isn’t new or shiny?
- If the feature or API can be polyfilled, what dependencies does the polyfill require? In the worst case scenario, if the core browser API is removed, will the polyfills still work?
So the question is how fast should we move? I think it’s a question that should be discussed a few times a year with the team and the decision makers. Opinions change, projects come and go, and the ever-changing tools and features make it harder to have an answer that fits all projects.
I think the important thing is to re-evaluate the amount of risk for each project. For some projects, it’s okay to bet the house; others may be different. So keep on trucking on, sometimes slow and steady, same old, same old is just fine.
