5 ms·
I strenuously disagree that distributing the source for web apps is orthogonal to open source. That the web is by default open presents the social dynamics tha
by knowtheory 14y ago
I strenuously disagree that distributing the source for web apps is orthogonal to open source.
That the web is by default open presents the social dynamics that are quite different than in systems like java applets, which are by default closed.
Open source can exist regardless of whether the web is open or not, but you are kidding yourself if you think whether or not source is distributed with a web page doesn't effect the open source landscape.
- exDM69 14y agoToday, JavaScript is distributed in minified and/or obfuscated form. And the JavaScript code might have originally been generated by a compiler from a different source language. So calling the stuff your web browser downloads and executes the "source" is not really a valid argument. Instead, JavaScript is used as a program representation with small size and immediate execution in mind, and it really sucks in that role. Even if the code is distributed in source code form with white space, identifier names and comments intact (bandwidth isn't cheap, you know), licensing is still the factor that legally determines if it is free software or just open source by default.
- knowtheory 14y agoThe ability to figure out how a piece of code works is different than being able to take that code and reuse it elsewhere. View source is important both for the sake of debugging in the case of 3rd party javascript, and also for the sake of being able to teach others. Regardless of the minification issue, it's possible to use a code formatter to expand a minified file and at least identify where declarations are being made and what functional behavior is being specified. Minification makes viewing source inconvenient, but that's not equivalent with closed.
- moe 14y agoit's possible to use a code formatter to expand a minified file If you go to that length you can just as well use a decompiler, no difference.
- beagle3 14y agoHuge difference. Minified files, more often than not, have the original identifiers, original code structure (e.g. you know a for from a while ). With a decompiler, you lose all of that. Google closure is a compiler (and thus loses a lot of this data), but most minifiers are not semantically destructive.
- moe 14y agoMany other minifiers also munge the symbols (e.g. YUI compressor). And why should this process retain anything anyways? If you want your source-code available for download then... put up a download link.
- beagle3 14y ago> And why should this process retain anything anyways? Because javascript has some reflection, and also because of weird scoping rules (with, eval, etc.) you can never be sure where a symbol comes from unless you have access to the exact version of every other script on the page, e.g. jquery, etc) > If you want your source-code available for download then... put up a download link. I agree - but there is still a huge difference between deminified and decompiled source readbility - which is all I was saying.
- pka 14y agojs minifiers not only remove whitespace, they reorder execution paths, eliminate useless declarations, identify unreachable code [1]. Reformatting a minified js file is not going to produce a much better result than disassembling a distributed binary file would. [1] https://developers.google.com/closure https://developers.google.com/closure
- beagle3 14y agoGoogle's closure is a compiler, not a minifier (the distinction being: if it does semantic analysis it is a compiler; although I've never seen a minifier that does even real syntactic analysis -- they all do lexical)