Thanks! Let me know if you run into any issues or need additional codecs/formats.

I know this is a thing of taste, but have you considered a syntax closer to SolidJS's approach? Something that feels a bit more vanilla JavaScript, where signals are just tuples with getter/setter and you use JSX instead of template strings and components are just plain functions?

For comparison, here's how this example would look:

  import { render } from "solid-js/web";
  import { createSignal } from "solid-js";

  function Counter() {
    const [getCount, setCount] = createSignal(0);
    return <button onClick={() => setCount(getCount() + 1)}>{getCount()}</button>;
  }
  render(() => <Counter />, document.getElementById("app"));

For open implementations, look at ffmpeg.wasm - it's FFmpeg compiled to WebAssembly and supports a wide range of codecs. It's open source and actively maintained.

Some truly open/royalty-free codecs you could use - video: VP8, VP9, AV1. audio: Opus, Vorbis, FLAC.

That said, building a VLC in the browser gets complicated quickly because of licensing - even if the decoder implementation is open source, some codecs have patent licensing requirements depending on jurisdiction and use case. For example, H.264's basic patents have mostly expired, but I'd verify the specific profiles you need.

Without revealing too much, the business logic must remain client side for this use case, and it's a common problem across our industry.

I've explained the security reality to the business many times - any JavaScript sent to the client can be read, executed, proxied, or tampered with. That's just how browsers work.

The current directive is - make it as difficult to understand as reasonably possible. We're not trying to stop determined adversaries (that's impossible), but we can raise the bar high enough to deter script kiddies and casual attackers from easily abusing it.