3 ms·

Intent to Deprecate and Remove offscreenBuffering (2014)

21 points by tentacleuno 5y ago

Jyaif 5y ago
7 years later, `window.offscreenBuffering` is still there.
deleted 5y ago
[deleted]
tuankiet65 5y ago
(2014)
anaisbetts 5y ago
Honestly, imho there is no reason to do this, the cost-benefit analysis is all downsides and zero upsides. Removing this will absolutely break websites, and you gain nothing as a result, except "technical correctness". Not a single user will benefit from that change.
- rightbyte 5y ago
  I feel some devs want low effort easy tasks to do, to give the impression of getting things done for KPI hunting. Otherwise why put in more work into removing something than its presense will ever generate. Like when Python removed support for Windows 7 for no good reason at all but it being past LTS. But there was a submit ...
- DannyBee 5y ago
  I don't think it's that simple. There is always a fine line between complexity and compatibility. The things that are barely used/almost unused are the things that often end up the least tested or looked at. Depending on how complex they are, and what they do, this is a recipe for bugs/security issues. When you have thousands of these things, not removing them over time is a great way to end up with a huge mess. On the other side, as you say, removing any of them rarely benefits users directly (except in some individually minuscule way like binary size). What seems to happen here strikes me as a reasonable balance - people try to trade off the complexity of the feature vs its use, and wait for it to become unused enough that it might be worth removing. As you can see, here they decided it wasn't worth it, and it's still there today.
  - bastawhiz 5y ago
    Exactly. How many bytes in the much-discussed electron bundle size is the result of lots of little things to support one-offs going back decades? How do you document and maintain all of these things, which were pulled from WebKit, which were pulled from KHTML, which have no real documentation or obvious purpose?
iam-TJ 5y ago
There's one aspect of these deprecations of functionality in widely-used tools and agents that is often overlooked. The very premise of the deprecation and removal is that any code-base that uses that functionality is being constantly maintained and can be updated. That is a major misunderstanding that in the 'web' development world has become the norm due to 'DevOps', Continuous Integration, Continuous Testing. There are many codebases out there that achieved their objectives, are finished, and are effectively unmaintained since they work as designed. When the functionality they use is removed they fail and the end-user loses out. This is always going to be a major problem for historians, historical web-site and code archives that have active code (not just passive HTML/CSS). The problem we have is that with deprecations and removals of functionality that was previously recommended and/or 'best practice' our ability to maintain digital history is being chipped away. Historically, we've already lost the ability to easily use Adobe Flash (good from a security perspective but not so much from a historical perspective) and Java applets (still many 'enterprise' devices rely on them) and all those web-sites that relied on Internet Explorer specific features. For each codebase we now have to figure out which specific tooling and versions are required and try to re-acquire them. Not excessively difficult for open-source tooling but challenging for closed-source and proprietary tooling. Another related issue building up is the switch to 64-bit and the subsequent bit-rot of 32-bit support. It feels like the horizon to failure of a completed "web" codebase is less than 10 years.
- deleted 5y ago
  [deleted]
- waste_monk 5y ago
  On the other hand, maintaining obsolete code is very expensive (both in terms of time required to develop new features without breaking existing code, and also the architectural difficulties when you cannot refactor or clean things up), and you cannot simply tie developers to a chair and compel them to maintain projects in a fixed state forever. I would think that a prepackaged, heavily sandboxed VM with the appropriate configuration and software could be provided alongside the artefact of interest, much like using DosBox to play old games. This would be inconvenient, but in cases such as Flash it should not be possible to run the vulnerable software without being forced to acknowledge the inherent security risks (especially if the container interacts with the internet).

21 points by tentacleuno 5y ago

Jyaif 5y ago

7 years later, `window.offscreenBuffering` is still there.

deleted 5y ago

[deleted]

tuankiet65 5y ago

(2014)

anaisbetts 5y ago

Honestly, imho there is no reason to do this, the cost-benefit analysis is all downsides and zero upsides. Removing this will absolutely break websites, and you gain nothing as a result, except "technical correctness". Not a single user will benefit from that change.

rightbyte 5y ago
I feel some devs want low effort easy tasks to do, to give the impression of getting things done for KPI hunting. Otherwise why put in more work into removing something than its presense will ever generate. Like when Python removed support for Windows 7 for no good reason at all but it being past LTS. But there was a submit ...
DannyBee 5y ago
I don't think it's that simple. There is always a fine line between complexity and compatibility. The things that are barely used/almost unused are the things that often end up the least tested or looked at. Depending on how complex they are, and what they do, this is a recipe for bugs/security issues. When you have thousands of these things, not removing them over time is a great way to end up with a huge mess. On the other side, as you say, removing any of them rarely benefits users directly (except in some individually minuscule way like binary size). What seems to happen here strikes me as a reasonable balance - people try to trade off the complexity of the feature vs its use, and wait for it to become unused enough that it might be worth removing. As you can see, here they decided it wasn't worth it, and it's still there today.
- bastawhiz 5y ago
  Exactly. How many bytes in the much-discussed electron bundle size is the result of lots of little things to support one-offs going back decades? How do you document and maintain all of these things, which were pulled from WebKit, which were pulled from KHTML, which have no real documentation or obvious purpose?

iam-TJ 5y ago

There's one aspect of these deprecations of functionality in widely-used tools and agents that is often overlooked. The very premise of the deprecation and removal is that any code-base that uses that functionality is being constantly maintained and can be updated. That is a major misunderstanding that in the 'web' development world has become the norm due to 'DevOps', Continuous Integration, Continuous Testing. There are many codebases out there that achieved their objectives, are finished, and are effectively unmaintained since they work as designed. When the functionality they use is removed they fail and the end-user loses out. This is always going to be a major problem for historians, historical web-site and code archives that have active code (not just passive HTML/CSS). The problem we have is that with deprecations and removals of functionality that was previously recommended and/or 'best practice' our ability to maintain digital history is being chipped away. Historically, we've already lost the ability to easily use Adobe Flash (good from a security perspective but not so much from a historical perspective) and Java applets (still many 'enterprise' devices rely on them) and all those web-sites that relied on Internet Explorer specific features. For each codebase we now have to figure out which specific tooling and versions are required and try to re-acquire them. Not excessively difficult for open-source tooling but challenging for closed-source and proprietary tooling. Another related issue building up is the switch to 64-bit and the subsequent bit-rot of 32-bit support. It feels like the horizon to failure of a completed "web" codebase is less than 10 years.

deleted 5y ago
[deleted]
waste_monk 5y ago
On the other hand, maintaining obsolete code is very expensive (both in terms of time required to develop new features without breaking existing code, and also the architectural difficulties when you cannot refactor or clean things up), and you cannot simply tie developers to a chair and compel them to maintain projects in a fixed state forever. I would think that a prepackaged, heavily sandboxed VM with the appropriate configuration and software could be provided alongside the artefact of interest, much like using DosBox to play old games. This would be inconvenient, but in cases such as Flash it should not be possible to run the vulnerable software without being forced to acknowledge the inherent security risks (especially if the container interacts with the internet).