The difference is that the front-end code runs on 'your' computer, the back-end code runs on 'their' computer. You typically don't care what point of sale software a store you are doing business with is running on their cash registers or the myriad of software run on the systems of the various manufacturers of the products it sells.[1] However, when you go to their web site(s) and it uses a bunch of minified, obfuscated code that runs on your computer... you should care about that.

The idea behind 'free' software was that you should have access to/control of the software running on your devices, not everyone else's. It was originally a pragmatic solution to a problem, not an abstract ideology that it's morphed into for some.

[1] It's up to the business in question to care about the software running on their computers.

Javascript in the browser is practically compiled binary software at this point. You can't realistically inspect or edit 99% of what you're running since it's fully minified and obfuscated. And that's even more the case with WASM.

I'm going to push back on this, at least a bit.

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.

Documentation, comments, code layout and file structure are all critical components to any software project. Minimization removes all of that (right?) and I wouldn't consider it to be in "source form" in the spirit the phrase intends.

I wouldn't say that I prefer reading minified code over well-formatted code. Certainly minified code isn't ideal or equivalent to getting access to original source form. What I'm specifically pushing back against is the idea that if code is minified, it might as well be running on a server -- that "you can't realistically inspect or edit 99% of what you're running".

I suspect that's hyperbole; browser inspection tools are really good, and I regularly inspect and edit minified code. Even outside of the browser, I've patched and fixed bugs in minified 3rd-party dependencies where I didn't have access to the source code. It takes a little while to untangle the code, but it's not hard -- just time consuming.

I don't want to dismiss people who struggle with that, but I also don't think I'm that special or amazing of a coder. If I can do something, odds are pretty good that other experienced programmers can too.

The fact that i can read quite a few Assembly dialects at the binary level doesn't mean that binary is suddenly equivalent to inspectable source.

Of course not, that's not something I would ever claim.

But, given a choice between serverside code that you absolutely can't inspect no matter what, and a binary blob that you can read with a bit of extra work, wouldn't you prefer the binary blob?

Where serverside logic is concerned, it doesn't even matter if the underlying code is Open Source. I still can't inspect the instance and tell if it's running the correct code, or what its parameters are.

Yeah, but what on earth is the alternative?

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.

You can serve minified JS, but you should also provide the source code. Doesn't need to be loaded directly, it can be a link on the website.

https://en.wikipedia.org/wiki/GNU_LibreJS

I don't think that there is anything necessarily wrong with it. I was just pushing back on the idea that just because Javascript is distributed in source form, that it isn't effectively the same thing as a compiled binary to the end user.

> I've always been a bit confused by this take, because the most likely alternative to having proprietary code in the front-end is to have proprietary code in the back-end.

He'd push for AGPL for that. Also Stallman doesn't like SaaS: https://www.gnu.org/philosophy/who-does-that-server-really-s...

That's something of a recurring issue with the philosophy. They also think that moving proprietary firmware into read-only memory is an acceptable solution, but I don't really understand why from a consequentialist point of view.

The issue is that usually the manufacturer builds in capabilities to update the firmware, and then reserves for themselves the ability to modify and update that firmware, while intentionally denying that ability to the users. This puts the manufacturer in a position of power over people who use the product.

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.

I don't know that I have a strong opinion on firmware, but I think there's a few points.

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.