5 ms·

I'm interested this for JS. Most codecs are either patent-heavy or hugely complex (requiring hundreds of kilobytes of WebAssembly), and a lot of the native APIs

I'm interested this for JS. Most codecs are either patent-heavy or hugely complex (requiring hundreds of kilobytes of WebAssembly), and a lot of the native APIs builtin to browsers have a tendency to shift every few years. It would be nice to have a pure JS alternative to WAV that provides some file reduction.

jefftk 4y ago
> the native APIs builtin to browsers have a tendency to shift every few years The web platform is incredibly backwards compatible; I'm having trouble thinking of any cases where they've dropped a format (which doesn't mean there aren't any!) On the other hand, while the browsers generally ship with many codecs [1] the APIs for interacting with them are pretty terrible. [1] https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Audio_codecs https://developer.mozilla.org/en-US/docs/Web/Media/Formats/A...
- Turing_Machine 4y ago
  > I'm having trouble thinking of any cases where they've dropped a format Flash?
  - jefftk 4y ago
    Flash was a plugin, not a "native API built into browsers".
    - Turing_Machine 4y ago
      A distinction with no difference. Flash used to run on every standard browser. Now it doesn't exist.
      - jefftk 4y ago
        It's an important difference if you're trying to predict how browsers will behave in the future. They're generally very conservative about removing platform features that people depend on, but this doesn't cover plugins.
- mattdesl 4y ago
  WebAudio has had a couple: e.g. user gesture requirement which has broken many websites, and even things as simple as using AudioContext to decode a WAV file to a buffer. Another one is script processor nodes. Beyond API shifts, there are constant regressions and incompatibilities across browser implementations, especially in rich media APIs like image, audio, and video.

5 ms·

I'm interested this for JS. Most codecs are either patent-heavy or hugely complex (requiring hundreds of kilobytes of WebAssembly), and a lot of the native APIs

by mattdesl 4y ago

jefftk 4y ago
> the native APIs builtin to browsers have a tendency to shift every few years The web platform is incredibly backwards compatible; I'm having trouble thinking of any cases where they've dropped a format (which doesn't mean there aren't any!) On the other hand, while the browsers generally ship with many codecs [1] the APIs for interacting with them are pretty terrible. [1] https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Audio_codecs https://developer.mozilla.org/en-US/docs/Web/Media/Formats/A...
- Turing_Machine 4y ago
  > I'm having trouble thinking of any cases where they've dropped a format Flash?
  - jefftk 4y ago
    Flash was a plugin, not a "native API built into browsers".
    - Turing_Machine 4y ago
      A distinction with no difference. Flash used to run on every standard browser. Now it doesn't exist.
      - jefftk 4y ago
        It's an important difference if you're trying to predict how browsers will behave in the future. They're generally very conservative about removing platform features that people depend on, but this doesn't cover plugins.
- mattdesl 4y ago
  WebAudio has had a couple: e.g. user gesture requirement which has broken many websites, and even things as simple as using AudioContext to decode a WAV file to a buffer. Another one is script processor nodes. Beyond API shifts, there are constant regressions and incompatibilities across browser implementations, especially in rich media APIs like image, audio, and video.