Re: Web versions

Colby Russell wrote:
> [...]
> Consider this passage from The JavaScript Trap:
>
>     If the program is self-contained [...] you can copy it to a file on
>     your machine, modify it, and visit that file with a browser to run
>     it.  But that is an unusual case.
>
> In particular, consider the irony of it, in light of the way this
> discussion has gone.  In this discussion, it has been you all who would
> bear responsibility for this case remaining "unusual": by continually
> invoking the web app canard and responding to imagined caricatures of
> the arguments being sent your way, rather than the actual arguments
> themselves.

The original message that started this discussion was a request to port 
all GNU packages to WebAssembly targets.

As I understand, that is not currently technically feasible because 
WebAssembly does not offer the APIs that most GNU packages use.  I 
further suggest that making it feasible would be a bad idea because that 
would effectively remove the browser sandbox.

One of the rationales presented to me (off-list) for this was that a 
WebAssembly port of GNU could be run as a web app and therefore be 
"always up-to-date" and I answered that removing the option to continue 
using an old (possibly customized) version from the user, as that would 
do, is wrong.


In short:
    1.  Most GNU packages are written to POSIX API, possibly with GNU 
extensions.
    2.  Browsers do not offer POSIX API to JS/WebAssembly for very good 
reasons.
    3.  Web apps stored on "the cloud" are bad because they often do not 
respect the user's freedoms, as even if the software is under Free 
license terms, technical issues can make running a modified version 
difficult or impossible.

Therefore:
    Porting to "the Web" is simply not practical or appropriate for most 
GNU software.  This does not exclude the possibility of writing useful 
Free software for "the Web" but the GNU project is focused on the GNU 
operating system.

The GNU operating system is not supposed to depend on external network 
resources for routine operation.  I believe that "Who Does That Server 
Really Serve?" better applies to these issues than "The JavaScript Trap" 
does:  the former warns against relying on systems outside of the user's 
control, even if those systems are also running Free software, while the 
latter applies to a widespread means of "sneaking" non-free software 
into otherwise-Free environments under the user's proverbial nose.


-- Jacob