Bonjour à tous,
 
Je suis actuellement à la recherche d'un logiciel ou d'un petit site web proposant de compacter mon code source Javascript.
J'ai trouver une première solution : http://dean.edwards.name/packer/ mais ce site se plante quand il y à des commentaires dans le code.
Actuellement je suis en train de faire un beau scirpt qui fait tout ça à la main mais j'ai du boulot plus urgent dont si vous avez un logiciel ou un site qui fait le même travail que celui que j'ai donner en lien dans ce message et qui en plus vire les commentaires de tout poils : je vous serais très reconnaissant.    
 
Merci d'avance.

quel est l'interet ?

http://javascriptcompressor.com/ c'est parfait et très bien.

Dans le cas d'un gros script de warrior magique qui fait tout et qui est bien codé, c'est utile d'obfusquer le code et puis ca compresse le code et ca vire les commentaires dont 99% des gens qui visitent un site n'en ont rien à battre des commentaires dans le code.

Je prend mon exemple, en ce moment je code un système de validation de formulaire basé sur des mots clé. Le core du système est bien warrior et est codé à la warrior et j'ai pas forcément envie que quelqu'un d'autre récupère le code, le colle dans un site comme codes-sources.com et dise : Ouais les mecs c'est à moi.
Ensuite le code est hyper commenté, pour 5k de code, il y a 5ko de commentaires. Et les commentaires on s'en branle sur un site en prod.

ça réduit vraiment beaucoup la taille ?

un code de 20ko non commenté descent à 10ko
certains vont me dire que modgzip existe, ouais et j'ai testé, un JS compressé + mod gzip c'est moins lourd qu'un simple fichier JS modgzippé

 
ben tu fou une en tête GPL dans ton scriptdewarior.js
enfin au nivveau du poids ça vaux bien le coup

 
Merci beaucoup.
 

 
Rien à rajouter là dessus c'est exactement mon usage et mon point de vue.    

Je fait remonter ce topic car je fait face à un nouveau problème :
Il semblerait que dans les miliers de lignes de code JS que je cherche à compacter, un ou plusieurs petits malins se seraient amusés à ne pas mettre leur ';' en fin de ligne... Ce qui est certe possible en JS mais qui pose apparement de nombreux problèmes au compacteur fourni plus haut et aux autres que j'ai trouver ensuite...

Bref je me demandais si vous ne connaîtriez pas une sorte de parser de JS avec des options ou en tout cas me permettant de trouver facilement sur qu'elle ligne il manque un ';' et pouvoir corriger le problème rapidement.

Merci d'avance.  

bennan  
mais un code de 1000 lignes est vite checké à la main

 
Essaye ça : http://www.jslint.com/
 
Sinon c'est très bien de compresser les fichiers JS pour optimiser le temps de chargement de la page et économiser de la bande passante, mais personnellement je suis contre les algos qui brouillent (obfuscate) le code. Ca me rappelle les débuts d'Internet où des couillons essayaient de brouiller le code HTML de leur page "pour pas qu'on le vole", ou les scripts "anti-clic-droit" qui n'ont jamais fonctionnés. Le trio HTML-CSS-Javascript *est* ouvert par nature, et toute tentative de le brouiller relève de l'abbération (ou d'un grave problème d'égo : croyez-vous vraiment que votre super javascript est tellement mieux que les dizaines de bibliothèques/framework libres qui existent ?   ). Bref, jette un oeil à JSMin, ça fait surement des fichiers moins petits, mais au moins on ne perd pas en interopérabilité.

Perso ouais  
Mais je cherche pas à l'obfusquer, mais à compresser les parties inutiles pour quelqu'un qui cherche à faire des modifs.
 
En ce moment je suis en train de coder un script de validation de formulaire basé sur des mots clés
<input type="text" validation="required email">
 
Sachant que chaque mot clé est directement une clé d'un tableau de fonction
functionsArray["required"]
functionsArray["email"]
 
Il y a un core (coeur) de fonction à ce script (je dirait plutôt lib). Et ce coeur est gros et fait tout (gestion de messages et autres biduleries).
J'ai envie que lorsque je livrerai mon script aux maquettistes (HTMListes) de ma boite, ils auront le script en 2 parties
premiere partie compressée (obfusquée aussi, puisque la compression entraine une part d'obfuscation).
Et la seconde partie ouverte puisque ca serait les fonctions de mon array de fonction.
 
 
C'est un exemple hein
 

Gatsu35 -> 1000 lignes certe mais là c'est un script total de plus de 4500 lignes. Donc j'ai un peu autre chose à faire quoi.    
cgo2 -> Merci je vais tester ça de suite. Pour ce qui est de la non obfuscation de code : c'est un point de vue. Perso je cherche à ce que mon script soit le plus petit possible juste pour allèger le chargement de la première page.  

Un script de 4500 lignes, j'ai peur qu'il soit fucké ton truc là

Quand je dis un script, je parle de la concaténation de plusieurs fichiers javascript, ce qui inclue ceux des libs qu'on utilise en plus de ceux que nous avons développés.
 
Mais ca va je n'ai pas trop trop d'erreures sur le lien donné un peu plus haut. Je corrige ça et je regarde.  

Ah ouais en fait c'est un peu la mort... J'avais pas fait gaffe qu'à la fin il indiquait trouver trop d'erreures et arrêtait son parsing à 7%.  
 
Mais bon c'est un peu "nazi" comme parser... J'aimerais juste qu'il me "spot" les ';' manquant... Je sent que je vais devoir me taper des copier coller de petite taille à chaque coup. Fichtre.
 
En tout cas merci car ça me permet d'avancer.

Juste pour info :
100% des serveurs Web disposent d'une compression dynamique ZLIB ou assimilée
100% des navigateurs comprennent ce type de compression
100% des serveurs Web sont capable de mettre en cache les documents ainsi compressés lorsqu'ils sont statiques (donc aucune perte de temps à les compresser)
 
Pour rappel, la compression "Z" apporte entre 70% et 95% de compression sur un document texte.
 
Ensuite, quel est l'intérêt de compresser un script, si c'est pour le décompresser en JS ?
1/ La compression utilisée par le script va nécessiter d'envoyer un décrypteur non compressé, qui va bouffer certainement 90% du gain de la compression.
2/ JS c'est pas ce qu'on peut appeler ce qu'il y a de plus rapide. Donc au lieu de passer 1 seconde à charger le JS, le navigateur va passer 30 secondes à décompresser le JS.
 
Bref, /me dit qu'il ne voit pas l'intérêt.
 
 
A noter aussi que...
 
Modem 56k : 6 Ko/s Donc un script de 100 Ko met 17 secondes à charger. On peut estimer que les personnes utilisent ce genre de modem on habituées à poireauter 30 minutes par page qu'ils visitent, puisqu'ils se heurent à des menus en BMP qui font 12 Mo pour un cadre de 300 pixels par 100 pixels
 
ADSL 512 : 64 Ko/s Donc moins de deux seconde pour ce type de script.
 
ADSL 1Mo ou 2Mo (les plus répendus aujourd'hui) : 128 ou 256 Ko/s Donc ça prends entre une seconde et une demi-seconde pour charger le script
 
ADSL 20+ : 2048 Ko/s (euh... 5 centièmes de secondes... y'a pas un CPU qui sait décompresser en JS un fichier en si peut de temps)
 
Et quand je dis un script de 100 Ko, c'est qu'il est déjà compressé avec ZLIB, c'est à dire qu'il faisait entre 500 Ko et 1 Mo au départ !
 
Je ne vois donc pas trop l'intérêt, une fois que tu es passé sous la barre des 4 Ko, de compresser plus, puisqu'ensuite le fichier ne remplira pas une trame TCP/IP...
 
 
 
Ah, et enfin : si on compresse en JS avec des fonctionnalités avancées (huffman ou autre) on augmente l'aléa des caractères, et on diminue d'autant voir plus la performance de la compression ZLIB. Il suffit de prendre un fichier texte, le zipper, puis prendre le même, le rarer et zipper le résultat : le fichier deux fois compressé est plus gros que celui qui n'est compressé qu'une fois !

Merci à toi pour ce magnifique déballage de connaissances.
 
Malheureusement et comme tu le précise si bien : tu ne vois pas l'intérêt. Tu aurais donc du te dire avant de supposer une éventuelle inutilité ou incompétence en face de toi, que c'est peut-être pour des raisons que tu ignores mais tout de même utiles que certains font se genre d'effort.  
 
Bref je pense que la société pour laquelle je bosse et avec qui je suis d'accord sur le sujet, à trouver un intérêt plus que certain de réduire du mieux que l'on pouvait la taille du fichier JS pour ce site pro.

Je ne parle pas d'incompétences ou autre.
 
Plutôt que de te dire que je trouve ça inutile, je te dis pourquoi je trouve ça inutile.
 
Y'en a marre à la fin, à chaque fois qu'on argumente d'être pris pour quelqu'un qui déballe ça science. Franchement c'est lourd.
 
PS : Alors dis-nous pourquoi y'a besoin de compresser, on pourra peut-être apporter des réponses plus précises. Notamment parce que souvent, quand une personne se pointe avec un problème précis, qui nous semble stupide, c'est parcequ'en creusant un peu on s'apperçoit qu'elle butte sur un problème lié à un autre, qui trouve une solution toute autre.
 
=> Tu peux t'acharner sur le bouton de l'ascenceur de ton immeuble pendant 2 heures, il ne descendra que si avant tu remets le courant C'est con, mais ça arrive souvent, et c'est en rien une preuve d'incompétence ou autre : quand tu pars sur une fausse piste dès le départ, il est très difficile de trouver jusqu'où prendre du recul pour voir ce qui cloche.

Genre, tu dis que ton script fait 4000 lignes...
Ok.
 
Soit il y a un problème certain de développeur (quand on arrive à de telles tailles, on modularise et on fait plusieurs fichiers, ne serait-ce que parceque le risque de timeout ou d'erreur de chargement est bien trop grand avec le protocole HTML), soit (et j'en suis sûr) un manque de ta part dans la description du problème :
c'est quoi ces 4000 lignes ? 4000 lignes de code Javascript, ou 100 lignes de code et 3900 de données inclues dynamiquement dans le JS via un langage sur le serveur ?
 
Si c'est le second, alors la solution vient très certainement avec l'utilisation d'Ajax, qui te permettra de faire un chargement différé de ces informations, et ainsi permettre l'interactivité avec l'utilisateur pendant que les données chargent.
 
Ton problème est certainement tout autre. Mais détaille un peu.
Nous dire que t'as un JS de 4 Mo, ça nous amène forcément à nous demander le bien fondé de ta demande. Et surtout, nous empêche totalement d'y apporter une solution correcte.
 
Si maintenant vous voulez compresser pour rendre le code illisible, y'a des fonctions d'encryption, qui seront bien plus adaptées.
 
Bref, détaille ta demande, et on ne répondra peut-être pas à côté du sujet.
 
 
Si c'est juste pour nous dire "tel code de goret téléchargé sur le site de la cave de machin marche pas", ça sert à rien

Ben tu passes pour quelqu'un qui débale inutilement sa science pour la seule raison que tu dis : "je vois pas l'intérêt" qui sous entend selon le ton de ton message : "donc ça sert à rien".
 
Il faut juste savoir présenter ses propos. Je t'ai d'ailleurs précisé que ces infos étaient certes intéressantes mais mal exposées et surtout hors de propos.
Nous (la société pour laquelle je bosse) cherchons simplement à faire un seul fichier JS assez compact plutôt que d'inclure les uns après les autres, plus d'une dizaine de fichiers JS. Ce qui au final fait un code de (très exactement 3578 lignes). Au total on a gagner dans les 450ms au chargement de cette page (sans parler des nombreuses autres optims auquel j'ai participé) sur une connexion. Sachant qu'il y à environ 5000 connexions permanentes sur ce site c'est donc assez significatif comme gain.
Pour ce qui est de l'utilisation d'Ajax pour charger ce JS : je ne vois vraiment pas le rapport.    
 
De plus je vois pas comment je peux plus détailler mon problème que je ne l'ai déjà fait. Tu viens juste après la bataille quoi. J'ai un "simple" problème pour "compresser" mon JS, on m'a au total déjà fournis les outils dont j'avais besoin. J'ai remercier les gens qui m'ont fournis ces outils. Il n'y à rien à rajouter.  
 
Encore une fois : Il n'y à pas de mal à "déballer sa science" mais autant le faire dans un cadre ou c'est utile et demandé. Là tu as totalement déballé tes connaissances à côté du problème. Rien de grave donc mais je te le précise quand même.    
 
Bref il faut partir du principe que la personne qui pose une question à de bonnes raisons de le faire et que lorsqu'elle à trouvé la solution qui lui convenait : il ne sert à rien de vouloir résoudre le problème autrement.
 
Edit : Toutefois je te remercie de ta participation à ce sujet et d'avance à tes autres participations.  

Je parlais d'Ajax dans la mesure ou "souvent", un JS va contenir une partie script, et une partie de données.
 
Genre t'as un bloc de news, qui pour rendre l'affichage plus "sexy" est chargé en JS (par exemple pagination sans rechargement de la page).
=> Tu vas donc charger mettons 50 news, alors que tu n'en affiches que 10 à la fois (et donc, au moment du premier affichage, tu charge 40 news inutilement). Da ce cas, Ajax est d'une grande aide, puisqu'il permet de réduire considérablement la taille du JS chargé initialement.
 
Ensuite, tu parles de 5000 connexions "permanantes". Qu'entends-tu par là ? Les JS sont rechargés à chaque chargement de page, ou juste lors du chargement de la première page ? Je pose la question, parceque sur IIS par exemple, on peut indiquer au serveur d'imposer le rechargement de tous les objets, y compris les objets statiques (images, JS, CSS) au cas où par exemple on ait du JS généré dynamiquement, mais avec une extension en JS (donc détecté par le serveur comme statique).
Dans ce cas, il y a un certain nombre de manips à faire pour permettre la mise en cache de certains fichiers particuliers. Ca peut être une autre piste si vous avez actuellement ce problème (500 ms "de plus" sur la home page, c'est loin d'être dramatique je pense, par contre, 500 ms "de plus" sur l'ensemble des pages d'un site, effectivement c'est la mort).
 
Dans tous les cas, je te conseille très fortement de tester ce que donne ton script de décompression sur un PC assez ancien. Très franchement, si le problème n'est qu'un problème de temps (et non de bande passante), alors sur une machine rustique la décompression pourrait s'avérer pire que le chargement de plus d'informations.

MagicBuzz > Son probléme est/était le suivant : j'ai plusieurs milliers de lignes dont 20 à 50% sont des commentaires. Quel programme utiliser pour virer les commentaires.
J'espéres que tu devines quel intéret il peut y avoir à virer les commentaires d'un fichier javascript.
 
PS : Je sais, c'était pas dit comme ça, mais c'est comme ça que je l'ai compris.

Bah si c'est juste les commentaires à virer, une regexp de 30 caractères en perl et le tour est joué (et pas besoin de décompresser à la sortie )
(et ça s'appelle plus de la compression, mais tu nettoyage de code )

Non, pas du PERL ...  
Ha le perl, j'ai d'assez bon souvenir de ce langage. J'avais le site le plus dynamique de l'IUT grace à lui. En fait j'étais le premier à avoir utilisé autre chose que de l'html sur le serveur interne de l'IUT.

Ben nous avons fait face à plusieurs problèmes. Un de temps de loading de la première page et un autre d'utilisation CPU.
Le loading de la première page était du en partie à la taille des JS chargés (chose que j'ai maintenant règler ici), et d'autres qui eux ont étés effectivements annulés par des optimisations en Ajax que j'ai déjà effectué pour des chargement de datas à partir d'une bdd et évoluant en fonction de l'utilisation. De plus l'utilisation d'Ajax pour taper dans la base en cas d'effective nécessité est encore amoindrie par le fait que cet appel n'est fait qu'une fois pendant lequel le retour de la requète Ajax est stocké en local et donc les appels suivants chargeront le fichier local plutôt que de retaper dans la bdd à chaque fois.
 
En fait le gain de temps sur la première page est au total d'environ 3.5s (oui on a fait bcp bcp d'optimisations) mais c'est surtout pour plaire au client car une fois cette page chargée, tout le site allait super vite. Donc juste pour leur faire plaisir on a beaucoup optimiser le chargement de la première page. Par contre on à du faire un tout autre travail sur le problème de charge CPU du serveur. Mais c'est maintenant règlé.
 
Edit : c'est un peu simple de s'arrêter au fait de virer les commentaires. Mais oui je ne voulais pas de compression de malade. Virer les commentaires, les espaces inutiles, les retour à la ligne, renommage intelligent des variables, etc... Et hop. Oui j'aurais pu le faire moi même mais disons que j'ai un peu d'autres choses à foutre que de me prendre la tête à recréer quelque chose qui existe surement déjà.
 
Voilà.
 
Par contre ça me fait bien marrer le coup du PERL pour la première fois sur le serveur web de l'IUT. Ca fait peur d'imaginer ce que pondaient les autres en HTML.  

Les autres se contentaient quasiment tous de ce qui était explicitement demandé dans les exercices donné par les profs. Des trucs du genre : "afficher telle image avec deux zones cliquables : une circulaire et une autre rectangulaire" (avec les coordonées dans l'énoncé). Le pire, c'est qu'on s'attendaient tous à être noté sur l'ensemble des exercices. D'un autre côté, heureusement qu'on ne l'a pas été, je n'avais pas fait la moitié des trucs demandé vu que j'avais trouvé plus intéressant à faire.
 
EDIT : Correction gramaticale.

Super détérrage de topic
 
Je sais pas si vous connaissez mais depuis le temps il y a du nouveau avec Yuicompressor pour compresser du code javascript.
 
Il peut être utilisé avec CSS et Javascript et à en en voir les benchmarks c'est l'un des meilleurs (Merci Yahoo)
 
J'ai aussi trouvé un petit comparatif avec les autres outils de ce genre : http://www.julienlecomte.net/blog/2007/08/13/]Comparatif compression javascript css