Re: webaudio

Hi,

Thanks for writing to the list and expressing your concerns, and sorry for
the delay in answering, I read the email when you sent it, but then forgot
to answer.

Features that are standardized are generally never removed from the Web
Platform. When they are, it takes years, and/or the usage threshold is
generally extremely low (a fraction of a percent of page load, maybe other
browser vendors have numbers here). The ScriptProcessorNode is certainly
way above this treshold and isn't going to be removed, because it would
break so many web pages, and it's clearly not worth it.

Maybe other browser vendors can comment on their own removal policy, but
I'm pretty sure the bar is extremely high for a feature to be removed
regardless of the vendor. Here's a list of things that are considered to be
removed, or have been removed, for us (Firefox):
https://groups.google.com/g/mozilla.dev.platform/search?q=%22Intent%20to%20unship%22.
You can read the rational and some context each time. Most of the time,
it's a feature that's never been standardized.

These days (in contrast to a number of years ago, where it was common to
ship prefixed / non-standard APIs that developers eventually depended on),
developers can expect very high backward compatibility (barring any browser
vendor bugs, that can happen).

As alluded above, some non-standard APIs are routinely removed from
browsers. One (very related) example that comes to mind is the non-standard
Mozilla Audio Data API (that allowed developers to do audio sample
manipulation in JavaScript as well).

The feature was made available in late August, 2010. We (Mozilla) shipped
the Web Audio API (including ScriptProcessorNode, that replaced the Audio
Data API) in late October 2013, added a message that we were deprecating in
April 2013 and we removed the non standard API about a year later in July
2014. But this was a feature that was never standardized and was rather
niche, hence the rather short timeline. There was ample communication prior
to the removal, and the usage numbers were really low.

In this sense, "deprecated" doesn't mean (to us) that it is going to be
removed, it means that (as you note), no new features will be added, and
there is an alternative that's much better in every aspect. As you said,
it's not recommended for new developments, but it's maintained in a working
state, I've been personnaly fixing Firefox's implementation a couple time
in 2022.

I understand that it's easy to associate the deprecation of a feature with
its removal, but it isn't the case here, so it's essentially a
communication issue on our part. We always had automated tests (both per
browser engine, and also shared between browser engines) to ensure it's not
broken, and we've not communicated about any removal from the standard or
in implementations.

I think that changing the phrasing makes sense, "not recommended" or
"legacy" indeeds conveys a meaning that's probably more in line with its
status.

Please let us know if you have any idea about how to call this, but "not
recommended" with a non-normative note explaining some context might well
be the right thing to do.

In any case, I hope this clears up any uncertainty.

Best,
Paul.

On Tue, Dec 6, 2022 at 8:40 AM <info@wothke.ch> wrote:

> 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
>