Maybe I'm atypical because I work with Javascript a lot, but I don't think it's that hard to read minified JS. Modern browsers have a lot of tools to help with that -- you can set breakpoints on DOM manipulations, you can autoformat the code so it's not just a jumble of text -- you can even pause execution and add custom code to functions that can do additional logging or subvert existing behavior.

And because the industry is at least somewhat focused on minimizing bundle size, it's pretty uncommon outside of captchas for me to see obfuscated code -- most of the time, you'll only be dealing with minification.

I don't know how WASM is going to affect this -- I suspect it'll be more problematic. But I manipulate minified JS all the time. It's a very 'inspectable' language, for lack of a better term.

Mobile gui's without javascript would be horrendous. On top of that, that's the platform you're minifying for.

I don't minify javascript to hide what's running, I minify it because a 3KB file is a lot less to download than a 12KB file.

So what? You design an entirely new language that: A) Can't be minified (How?) B) Has to be open source C) Can't be obfuscated (virtually impossible to prevent)

I'm sorry, but the stance is kinda dumb.

But if the firmware isn't modifiable by anybody (including the manufacturer) because the capability to update it was never built in the first place, then no capabilities are being withheld from the users of that product.

Distribution rights are a lot clearer with firmware on the device and a driver in code.

With firmware on the card, the interface between the kernel and the card is likely to be more well defined and thus easier to replace either side.