Re: webaudio

Hi,

Thanks. I am glad to hear that Firefox is persuing what
seems like a reasonable approach to me. I agree that it would
be a good idea to change the phrasing to something else since
"deprecated" (in other contexts) is often used as a last warning
before removal of an API.

Best regards,
Jürgen




On 2023-01-26 15:54, Paul Adenot wrote:
> 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
>>

Received on Friday, 27 January 2023 09:03:30 UTC