I think this topic needs further consideration.
While it is true that improvements on DEFLATE have been made in the decades since its introduction, it is also true that these algorithms are slower than DEFLATE, often by a great deal, for comparatively marginal gains. As the simpler algorithm among a handful of efficient compression fundamentals discovered, it will be with us for a long time to come.
Comparative efficiency arguments are superfluous, however, in the face of the breadth of DEFLATE usage by clients. PNG will not be superseded in our lifetimes, certainly. All the W3C member orgs make exensive use of DEFLATE in a variety of capacities in their software, from browsers to operating systems. While asm.js implementations of DEFLATE do exist, the fact remains that they are not native and when dealing with compression speed matters. It’s just another reason to rely on insecure plugin technology instead of scripting for routine tasks. asm.js DEFLATE are also inefficient, in that the deflation scripts must be included in every webpage that uses them. Is this not the purpose of the browser as a scripting runtime, to prevent the needless duplication of code?
Client-side DEFLATE is worth having. It will reduce server loads by allowing compression/decompression of the client side. In the age of fast phones, DEFLATE isn’t the CPU hog it used to be. It will mean compression becoming a tool of the casual developer. Today, those who try to implement compression in their web apps face criticism for not using native code solutions. This not only discourages the use of compression on the client side, but discourages the development of web apps generally.