webaudio

Hi

Somebody here 
https://github.com/GoogleChrome/developer.chrome.com/issues/3355 
suggested that I should share my concerns regarding the deprecation of 
the legacy ScriptProcessorNode API here with you.

I am therefore copy/pasting the relevant part of the above discussion 
below:


Obviously the ScriptProcessorNode has been working "good enough" for all 
these years (for many usecases) and and it still is up to this day! I am 
aware of one instance of a "severe security related ScriptProcessorNode 
flaw" that was successfully fixed (I think it was in 2021) - which 
proves that it is perfectly feasible to still update/maintain that API 
without leaving any critical issues in the infrastructure.

I am sure that the ScriptProcessorNode API has known limitations and 
that it may be unfeasible/undesirable to invest extra efforts to fix 
those - and I am perfectly fine with that. Call it a dead end - nobody 
expects that additional features should ever be added to that legacy 
API.

It is clear that even basic maintenance of any legacy API takes time 
(e.g. see above mentioned security fix). But from what I see the 
codebase of the ScriptProcessorNode related infrastructure is very tiny 
as compared to the extisting application codebases that have grown over 
the years. Migration of all that existing application code to a new API 
takes many orders of magnitude more effort than the effort it takes to 
regularly maintain the legacy ScriptProcessorNode API. (And I am glad 
that until now the developers of the infrastructure are making that 
investment and have kept support for that legacy API.)

I think it should be kept that way and removal of this legacy API would 
send a very worrying message, i.e. how little the time of application 
developers is valued as compared to the time of the core WebAudio engine 
developers. Like the WebAudio engine developers I (as an application 
developer) also prefer to write new stuff rather than spend my time 
maintaing my old stuff. I totally get it.. nobody likes to "waste" his 
time with maintenance.

But continued support for the legacy API is the best way to make sure 
that overall the least amount possible of ppls time is wasted. That's 
the important leverage you have in the infrastructure and you should not 
let that go to waste!

(I find it quite worrying to have the threat of "ScriptProcessorNode 
removal" hanging over my head and it makes me wonder if I should just 
abandon the "browser stuff" and better direct my application development 
efforts to a different more stable environment (unfortunately it seems 
to be a recurring pattern that browsers choose to "improve" using non 
backward compatible approches). It already has the effect that I find 
myself NOT implementing new user feature requests due to my fear that 
Chome/Firefox might be soon pulling that rug from under my feet and that 
my additional time investment would then also go to waste. I just cannot 
afford to rewrite my existing code base every few years - and I strongly 
resent having to do so just to let the infrastructure perform some minor 
API cleanup.)


I hope my feedback helps to keep those at bay that might be advocating 
for an actual removal of this legacy feature. I'd appreciate if the 
legacy ScriptProcessorNode API would be put into a "not recommended" 
state (removing the threat of random removal), returning planning 
security to those many application developers that still maintain large 
codebases that rely on that legacy feature.

Best regards,
Jürgen Wothke

Received on Tuesday, 6 December 2022 07:40:01 UTC