Myth busting mythbusted

Today CSS tricks features an article on JavaScript animations vs. CSS animations entitled Myth Busting: CSS Animations vs. JavaScript guest-written by Jack Doyle, one of the people behind the Greensock animation platform. Not surprisingly, Jack debunks the blanket statement that CSS animations are always better for performance and functionality than JavaScript animations.

Jack is doing a great job arguing his point that CSS animations are not always better than JavaScript animations. The issue is that all this does is debunking a blanket statement that was flawed from the very beginning and distilled down to a sound bite. An argument like “CSS animations are better than JavaScript animations for performance” is not a technical argument. It is damage control. You need to know a lot to make a JavaScript animation perform well, and you can do a lot of damage. If you use a CSS animation the only source of error is the browser. Thus, you prevent a lot of people writing even more badly optimised code for the web.

A blueprint for “considered harmful” articles

These kind of articles are lots of research but easy to write: you take a “common practice truth” and you debunk it by collecting counter arguments. Extra points go to having lots of performance benchmarks or demos that can not be done with the technology you debunk.

Personally, I have no problem when libraries, frameworks or software solutions are getting debunked but I have a real problem when solutions built into browsers and defined in standards are being painted as inadequate for the sake of a yet another library or – in a lot of cases of articles of this kind – your own product.

This is not helping us having a professional platform. If there are issues with performance or functionality of a standard, we should get them fixed on browser and spec level. Yes, this takes longer and we can not be the hero to the rescue that built the quick library that fixes all these problems. But we also fix it for everyone and not just for the moment as inevitably following one of these articles will be another one a few months later showing that the solution of the first one has issues.

And thus, the cycle restarts. We discuss things, we create performance tests, we find proof in a certain environment and we give once again the message that everything on the web is broken and needs people to fix it with JavaScript.

An endless source of dispute

Here are a few truths about web development:

• It will never be perfect – the idea of the web is to release code into the unknown. All you can do is make sure you don’t deliberately make it harder for people by expecting a certain technology or hardware to be available.
• You can always find a problem that is not possible with standard techniques – you can then use JavaScript and the DOM to solve that problem. Then you have the problem of people using your JavaScript solution and be ready to fix it for all the new platforms, browsers, environments and connection speeds to come. That’s what web development is about. That’s what browsers need to do.
• “Technique $X is the best to use” is a fleeting statement – table layouts were the only way to create a multi column layout and got replaced by CSS. CSS layout with positioning and floats is a make-do solution, too. Flexbox is the up and coming solution to the problem of layout on the web. It is not ready across all browsers and not backwards compatible if you want all browsers to create the same layout. See where this is going?
• There is no “one” solution for any web development problem – this is the beauty of the web. It is the “bring your own solution” platform. If you want to make it better for everybody, use standards and let the browsers worry about the performance issues and do report them to the browser makers. Everything else is patchwork and will be debunked as “not working as expected” over time
• In 90% of the cases mythbusting articles solve one problem – the argument is not that a technology is flawed, the argument is that it is not good enough to solve problem $x. Which is OK, there will always be things that can not be done. The real question is “do you need to solve problem $x and what dependencies, issues and problems does the solution bring along with it”?
• Everything on the web is best achieved with a mixture of technologies – CSS animations are great for certain jobs, but will not be good enough for others. You can achieve almost everything with JavaScript but that doesn’t mean you have to or should. Flash was used for a lot of things, some it was damn good for, others awful. There is no way – ever – that one technology can 100% replace another. Our use cases change and we should strive to use the technologies that gives us the best result for the least effort whilst allowing browsers to optimise for us. It is not about what we can do, it is about what makes sense to do.

All of this would not be an issue if people looked at the source of the article, the date of it and see it as a problem solution in a certain environment and time frame. What we do though is keep quoting them out of context and as gospel. Until someone else will take that argument without context and writes a mythbusting article about it.