Which is a real head scratcher, because as a rule, JavaScript developers use JavaScript package managers, and JavaScript package managers, especially npm, provide good license metadata and auditability. You can have an automated tool, usually a plugin for your front-end bundler, compile a pretty good notice file for you, no many how many direct and transitive dependencies you have.
I think there's also a chicken-and-egg problem, in that it's not exactly clear how to make the notices file for front-end code available. Link from website footer? At the top of the client bundle? Comment at the top of the client bundle, with a URL for the notices files?
> Q16: Is "minified" JavaScript Source Code?
> No. Minified JavaScript, while not an "executable" in the software engineering sense of the word, is difficult for humans to read, edit, and modify. As such, it is not "the preferred form for modification" and so it is not Source Code as defined by the license. Therefore, minified JavaScript is the Executable form, and the responsibilities set out in the license for distribution of the Executable form should be met when you distribute minified MPL-licensed JavaScript.
> This means, among other things, that you do not need to, and probably should not preserve the MPL boilerplate (which begins "This Source Code Form...") when minifying JavaScript. However, you do need to comply with section 3.2(a) by informing the recipients of the minified source how they can obtain a copy of the source code. How exactly you do this will depend on how they can obtain that copy, but one way would be to include a comment with a link to the source code in either the page which uses the JavaScript or in the JavaScript file itself.
> Note that treating minified JavaScript as an executable increases distributor flexibility by allowing MPL-licensed code to be combined into a single file with non-MPL JavaScript source code without requiring the non-MPL code to be distributed under the terms of the MPL.
I think the tl;dr is that this is feasible but not common, and there's no single widely-used default way of doing it.
E.g. Many packages put their copyright/license info in special inline comments (using /! ... / tags), and every minifier I've used keeps such tags by default. But including these tags in your bundles can be undesirable - if a dependency has: /! Copyright foo@bar / without specifying the package name, then your bundle will appear to be entirely (c) that author.
OTOH the huge majority of projects do include a valid license identifier in a package.json tag (since npm complains if you don't). But I don't think there's any widely-used default way of generating a good licenses declaration from them.
If you are using some js library with the MIT license in your frontend then you are distributing a copy of the software. You have to include the notice somewhere on your website (typically next to the library)
However, the license doesn't have to appear on the website portion specifically highlighted for human viewing. It merely needs to exist, say, at the top of every javascript file.
Or a link to where the text form of the license is.
Just because it's inconvenient, and just because people are ignoring it, doesn't mean it's being done as it should be...
Of course javascript optimizers and the like might throw a wrench in the works these days, but that's a pretty recent and specific problem.
The JavaScript and npm ecosystem are extremely dependency-heavy. Even if you only take a few yourself, the number of sub-dependencies of even a simple application are often in the hundreds.
Why does "everyone" ignore the attribution of their dependencies and sub-dependencies? Laziness? Risk of getting sued too low? What happens if Oracle buys all the left-pads in the world?