We expose a "browser version" of the js-sdk, which is a browserified version of the entire js-sdk. It's not very well documented, but it is mentioned at https://github.com/matrix-org/matrix-js-sdk#in-a-browser.

I think we should reconsider whether we want to continue to support this artifact, for several reasons:

• Most urgently: without further action, the browserify artifact is going to lose support for E2E encryption once the transition to Element R (Adopt the E2EE cryptography module from matrix-rust-sdk: "Element R" element-hq/element-web#21972) is done and we drop support for the legacy libolm based encryption.
• It's barely tested, so is easy to break without our noticing and hard to fix when it does. (In particular, it's not what we use in-house: instead we use webpack to package element-web via typescript modules, which isn't a documented usage at all.)
• Wasm dependencies for the js-sdk - such as the rust e2e library - have to be base64-encoded into javascript (increasing their size) and loaded with custom loaders: browserify doesn't have good support for Wasm, whereas webpack, node (with --experimental-wasm-modules), and jest (from v29.3) all support it natively. (There is wasmify, but I failed to get it to work and it gave a strong impression of being essentially unused.)
• Frankly, browserify is outdated. Its last release was 2.5 years ago and nobody really uses it any more. More modern tools like webpack and rollup which consume libraries like the JS-SDK as ESM modules are much more flexible and powerful.

Some background on the current E2EE support: the browserify bundle doesn't include libolm; instead, if you want to use E2EE, you need a separate <script> tag to load the libolm library (from the artifacts available in gitlab; libolm exposes both a two-file version using wasm and a single-file asm.js version). That means that the matrix-js-sdk doesn't have a hard dependency on libolm, with the consequences:

• Every application that wants to use E2EE - including those using webpack - ends up with custom code to load libolm (see element-web for example)
• Every application that wants to use E2EE - including those using webpack - has a whole load of (barely tested) logic to handle the case that E2EE is not available, and fall back gracefully if not.

I am keen to avoid these scenarios in the transition to Element R.

On the other hand, including all the E2EE code in the browserify bundle would bloat it significantly (see #3182).

For now, I have preserved the status quo by stubbing out the rust code altogether (#3187), but the upshot of that is - as I said earlier - if we do nothing, the browserify artifact is going to lose support for E2E encryption once we drop libolm.

One potential solution is to expose two browserify bundles - one with E2EE enabled, and one without. (Or, potentially, a main one and an auxilliary one). However, that would require a bit of work to create, document, and test, and it still leaves us with artifacts that are hard to test and - as above - I don't really think that browserify is the future.