[Pkg-javascript-devel] documentation about distributing minified versions of files

[Jérémy Lal]

On 07/05/2013 14:49, Daniel Kahn Gillmor wrote:
> On 05/06/2013 02:21 PM, Jérémy Lal wrote:
>> Daniel you ask me to explain some things i thought was common practice.
>> Below i try to give explanations ; please help me fix, refine, or reject
>> them.
> 
> thanks, i think it's useful to establish documentation of "common
> practice", along with the rationales for it, so we can evaluate whether
> the practice actually supports the rationales.
> 
>> An essential difference between C and Javascript is that C is compiled,
>> and Javascript is interpreted.
>> Before minifying was so easy, nobody minified Javascript files, and
>> it is perfectly fine to use unminified Javascript files in production.
> 
> sure, i understand the nature of the toolchains; but clearly it's not
> 100% "perfectly fine" to use unminified js in production, or we wouldn't
> have tools that generate minified js :)  That is, minifying js provides
> certain performance gains that users can't expect from non-minified js.
> 
>> The obvious advantage of keeping unminified files by default is keeping
>> this advantage of being able to debug a Javascript program right away,
>> since all modern web browsers ship full-featured debuggers.
> 
> i like the idea of being able to debug a webapp using the browser's
> debugger; however, i'm not sure how we expect a webapp maintainer to
> switch between the minified and non-minified versions of the javascript.
>>>> * should name the minified files like "foo.min.js"
> 
> it sounds to me like this proposal asks the webapp maintainer/developer
> to change all their code to explicitly source $foo.min.js when it is in
> production, and then change it back to sourcing $foo.js when they are
> debugging.
> 
> Is this a realistic workflow to expect of web developers?  It seems more
> plausible to me that webdevs will write the code to use $foo.js (for
> easier debugging) and never use the minified versions.
> Given that it will be system administrators and not webdevs who want it
> to use the minified versions, maybe another approach would be to have
> two different packages that conflict with each other.  for example:
> 
>  libjs-jquery
>  libjs-jquery-minified (Provides: libjs-jquery)
> 
> then the source code for webapps could remain static, and the sysadmin
> could switch between minified and verbose forms via apt/dpkg. 
> I'm happy to hear suggestions for other approaches, i'm just trying to
> think more widely if we're in the process of establishing best-practices.

There are two different needs :

1) packaged webapp that depends on libjs-* package

2) user project that depends on libjs-* package.


For 1) your suggestion would work, but it wouldn't for 2).

Something that would work for 2) is user Makefile that helps
setup symlinks or copies of the packaged files. Symlinks if the user
wants to be able to upgrade the files along with packages upgrades,
copies if he doesn't. In both cases it's up to a user script to
install minified/unminified version, possibly renaming the files and so
on.
But if the user has to install libjs-jquery or libjs-jquery-minified
each time, it is a painful process.
That's why i suggested to ship both versions of the file (minified/unminified)
with different, canonical, names; be them in separate packages or not.

>> For the "keep it easily debuggable" reason. It brings absolutely no
>> real advantage to have minified versions for nodejs modules.
> 
> Just to be clear, is this because node loads the interpreted code once,
> does so at minimal expense, and then operates from it in memory as it
> handles each subsequent request?  (sorry, i don't know the node process
> architecture very well)

yes it does :
http://nodejs.org/docs/latest/api/modules.html#modules_caching

> Or is it because node is loading the files from
> disk instead of over the network and we just assume that there is
> minimal cost for loading from disk as compared to loading over the network?

Also true. Modules are not loaded from network.


Jérémy.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20130508/f651ff77/attachment-0001.pgp>