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.

> 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) 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?

        --dkg

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel

Reply via email to