Re: [Pkg-javascript-devel] documentation about distributing minified versions of files
On 05/08/2013 07:29 AM, Jérémy Lal wrote: 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). Why not? I don't see what problems it causes for that scenario. 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. this sounds like we would be encouraging a maintenance nightmare. what if the user adds a new script or a new symlink manually to the same directory, and then re-runs the makefile hook to bring the external dependencies up to date or to switch from minified to non-minified? for people who deploy their code from (signed) tags in a VCS, do they have to have a new tag at each deployment that re-runs this hook to adjust the links, thereby diverging from their VCS checkout? But if the user has to install libjs-jquery or libjs-jquery-minified each time, it is a painful process. why is this painful? During development, you install libjs-jquery alongside whatever other development tools, libraries, frameworks your user project depends on. your user project links to the /usr/share/javascript/jquery directory, whose contents are provided by libjs-jquery. In deployment, the sysadmins install libjs-jquery-minified on the live server instead. this installs minified files in /usr/share/javascript/jquery . the user project does not change at all. Regards, --dkg 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
Re: [Pkg-javascript-devel] documentation about distributing minified versions of files
On 09/05/2013 21:09, Daniel Kahn Gillmor wrote: On 05/09/2013 02:11 PM, David Prévot wrote: Hi, Le 09/05/2013 13:40, Daniel Kahn Gillmor a écrit : why is this painful? During development, you install libjs-jquery alongside whatever other development tools, libraries, frameworks your user project depends on. your user project links to the /usr/share/javascript/jquery directory, whose contents are provided by libjs-jquery. I fail to understand the benefit of the split (as in “what real life problem is this supposed to solve?”). It makes it possible, at a system level, to switch any particular piece of javascript into (or out of) debug mode without needing to make any changes to the rest of your webapp stack. looked at another way, it makes it possible to deploy the same code with minified javascript even though you develop with debuggable non-minified js. Is this useful? it seems like it might be to me, but i could be convinced otherwise. If the server hosts several webapps, it locks webapps in production or development mode *all at once*, and there should be a way to not do it all at once. Jérémy. 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
Re: [Pkg-javascript-devel] documentation about distributing minified versions of files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, Le 09/05/2013 15:09, Daniel Kahn Gillmor a écrit : On 05/09/2013 02:11 PM, David Prévot wrote: Please note that some projects (including ownCloud, packaged on Debian) allow the web administrator to switch (temporarily) in debug mode, where, among other things, the non-minified JavaScript are used instead of the usual minified ones. […] interesting, thanks for this data point. does this switch work by taking advantage of the min.js suffix, or via some other mechanism? Via the .min.js suffix if I remember correctly (or other specific suffixes, since not all minified JavaScript in ownCloud use the .min.js suffix). does it work for all js (including libraries), or just for the owncloud-native js segments? All JavaScript if I remember correctly (especially since upstream embedded convenient copies of external libraries, usually replaced by symlinks in the Debian package). That reminds me we may have to add back the non-minified (symlinks to) JavaScript inside the ownCloud package (for this debug feature), so I’m going to check it again pretty soon and will be back here with more accurate data if I notice I didn’t remember correctly. […] Should we expect each framework to implement it separately? Please note that, in the ownCloud case, the non-minified JavaScript is not the only feature of the debug mode, of course (and thus can’t be addressed in a JavaScript-only generic way, and maybe not even in a generic way at all). Regards David -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRi/x/AAoJELgqIXr9/gnykOoP/j44V8XlJPUTF7E0xGtLrns9 xoJnTxxJinHEt7f2s+j1kQAMdjq3vZ5aqdRJWBPotM86TXIZ0p4Am2XHGrWnYTTg 9FyALNvWUH1hgCiUv9pr7iC8T1alz8BIG7uMoJc+avgfmLp8XsuzChCLvXTNTVhX ObyGhFoBLHgj/qVLZbNaCqvKskxQxUdSVa49fevfw7mDP8FhKdLesZIvxEOZmVSv z+ruSW5ft2REQruWb63loT4o8bnCBOGo7vpxE2VUF23C+elnJfxYVtAzAA8P73Mx WBZhd93mS1I6OXltYTrGq2D2fmyQp3oAJ5nsxlNHq2OCLMRBjyJFzpZxIR81yNKz Fv6M4cNVH23t7nm4Y52nu89+TKYCPMq4DzSwc/peJNkZxGCwFXeX7b1nZB38CCwJ +Dg1bmo7wJ+n2ffReco29c2sTeIzWaQhtOA/5nsPRO46fginGlPN9NUWPbVJAXIY EJIW8lQRnhExDJ6ytUwAXQWZEtYujDrdjMyecTaJkzixCSl1nofq5IYkxjs3psYP JSwMApSl952mRRS9y1a9DPbdNo+LR0YNII3wEFY4g1Mcurlr87tgox+jBlOU56ZQ C/EzvWypCc+T5a4kuXjBjIZP1zYzymM/r9qQkV6MRJE3aKlDCtpMZ0IBrcKTY0bp 7G2O4SoHONbZiCDkJbOz =6d3B -END PGP 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
Re: [Pkg-javascript-devel] documentation about distributing minified versions of files
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 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
Re: [Pkg-javascript-devel] documentation about distributing minified versions of files
Quoting Jérémy Lal (2013-05-06 15:18:15) First please note that i am not talking here about minified versions of javascript files that are shipped in upstream tarballs [0]. Please comment about what could be part of our javascript policy [1]. It might help future javascript maintainers. A package that distribute minified files for convenience * must distribute the unminified files * should name the minified files like foo.min.js * should not minify all files blindly (i'm thinking of jquery.ui.datepicker-xx.js) * if no minifier was available at build time, the minified files must symlink to the unminified ones (instead of being removed or empty). * a node-foo package should not distribute minified files. Some of these could even become lintian tags. All of above sounds sensible to me. Thanks for summarizing. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private ___ Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
