Najlepszy kompresor JavaScript [zamknięty]

171

Jaki jest najlepszy dostępny kompresor JavaScript? Szukam narzędzia, które:

  • jest łatwy w użyciu
  • ma wysoki współczynnik kompresji
  • Osiągaj wiarygodne wyniki końcowe (nie psuje kodu)
javascript compression Ron Harlev
źródło
14
Czy ktoś zna sytuację w 2011 roku?
Dan
4
Jest teraz 2012 i myślę, że UglifyJS i Closure są zwycięzcami, używam UglifyJS i zwykle bije spodnie od wszystkiego innego.
mkoistinen
Używam htmlcompressor.com/compressor.html w mojej wielostronicowej aplikacji jQuery Mobile. Pobiera plik HTML z tagami <script> i kompresuje HTML, JavaScript i CSS. Działa jak marzenie.
Anders
Jest rok 2017 - co jest teraz najnowsze?
Abhinav Singi
Jest rok 2020. Przy domyślnej „bezpiecznej” konfiguracji UglifyJS nieznacznie wygrywa, ponieważ jest bardziej „bezpieczny”. W przypadku zaawansowanych zastosowań mocy Closure Compiler oddaje tyłek UglifyJS sobie. Closure Compiler z ADVANCDED_OPTIMIZATIONS może wykonywać różnego rodzaju sztuczki, które pomagają zoptymalizować przepływ pracy i kod w tym samym czasie. Zobacz stackoverflow.com/a/50355530/5601591 , aby zapoznać się z przykładami niesamowitości Closure Compiler (ZRZECZENIE SIĘ: nie mogłem znaleźć odpowiedniego wpisu na blogu w innym miejscu, więc musiałem skierować cię do wpisu, który napisałem).
Jack Giffin

Odpowiedzi:

149

Niedawno wypuściłem UglifyJS , kompresor JavaScript, który jest napisany w JavaScript (działa na platformie NodeJS Node.js , ale można go łatwo zmodyfikować, aby działał na dowolnym silniku JavaScript, ponieważ nie potrzebuje żadnych elementów Node.jswewnętrznych). Jest dużo szybszy niż zarówno YUI Compressor, jak i Google Closure , kompresuje lepiej niż YUI we wszystkich skryptach, na których go testowałem, i jest bezpieczniejszy niż Closure (wie, jak radzić sobie z „eval” lub „with”).

Oprócz usuwania białych znaków UglifyJS wykonuje również następujące czynności:

  • zmienia lokalne nazwy zmiennych (zwykle na pojedyncze znaki)
  • łączy kolejne deklaracje var
  • unika wstawiania niepotrzebnych nawiasów, nawiasów i średników
  • optymalizuje IF (usuwa „else”, gdy wykryje, że nie jest potrzebny, przekształca IF w operatory &&, || lub? /: jeśli to możliwe itd.).
  • przekształca foo["bar"]się foo.bartam, gdzie to możliwe
  • w miarę możliwości usuwa cudzysłowy z kluczy w literałach obiektów
  • rozwiązuje proste wyrażenia, gdy prowadzi to do mniejszego kodu (1 + 3 * 4 ==> 13)

PS: Och, to też może „upiększać”. ;-)

mishoo
źródło
17
Używamy uglify w aplikacji klasy korporacyjnej. Robi dobrą robotę.
gyorgyabraham
Czy możesz porównać do jsmin w węźle?
Gringo Suave,
ostatnio Uglify zrezygnowało z wywołań API
Gadelkareem
@mishoo Hej, uwielbiam twój Uglify JS2. Moja sieć obecnie nie działa dobrze ... Chciałbym jej używać w systemie Windows. Jakieś rozwiązanie? : o)
Hydroper
@mishoo Pokazuję link git, ale nie mam pomysłu, jak go używać
Sachin Sarola
124

Wrócenie do tego pytania kilka lat później, UglifyJS , wydaje się obecnie najlepszą opcją.

Jak podano poniżej, działa na platformie NodeJS, ale można go łatwo zmodyfikować, aby działał na dowolnym silniku JavaScript.

--- Stara odpowiedź poniżej ---

Google wypuścił Closure Compiler, który wydaje się generować najmniejsze pliki, jak dotąd tutaj i tutaj

Wcześniej różne opcje były następujące

Zasadniczo Packer radzi sobie lepiej przy początkowej kompresji, ale jeśli zamierzasz spakować pliki przed wysłaniem ich (co powinieneś zrobić), YUI Compressor uzyska najmniejszy ostateczny rozmiar.

Testy zostały wykonane na kodzie jQuery btw.

  • Oryginalna biblioteka jQuery 62885 bajtów, 19758 bajtów po gzip
  • jQuery zminifikowany przy użyciu 36 391 bajtów JSMin, 11541 bajtów po gzip
  • jQuery zminimalizowany za pomocą programu Packer 21,557 bajtów, 11 119 bajtów po gzip
  • jQuery zminimalizowany za pomocą kompresora YUI 31822 bajtów, 10818 bajtów po gzip

@ daniel james wspomina w komentarzu kompresorrater, który pokazuje Packerowi na czele tabeli w najlepszej kompresji, więc myślę, że ymmv

Poklepać
źródło
Packer ma opcję wyłączania kodowania base62 - a dla jQuery kompresuje mniej niż yui po gzipie. Dzieje się tak, ponieważ jquery używa „eval” i „with”, co uniemożliwia „bezpiecznym” wykonywanie określonych kompresji, ale paker je ignoruje. Ogólnie nie jest bezpieczny, ale jQuery jest testowany pod kątem programu Packer.
Daniel James,
Jeśli mi nie wierzysz , spróbuj także kompresorrater.thruhere.net .
Daniel James,
9
Nie zapomnij o minusie pakera - czasie dekompresji.
Nosredna
1
uważaj, zamknięcie google może czasami być najgorszym kompresorem (wyjście nawet większe niż oryginalne) - \uxxxxdomyślnie konwertuje znaki inne niż ASCII w łańcuchach na literały .. użyj np. --charset UTF-8(jeśli jesteś pewien, że jakoś o tym poinformujesz przeglądarkę)
mykhal
Dane wyjściowe ClosureCompiler nie działają dla mnie. jscompress.com działa
codenamezero
43

YUI Compressor to droga do zrobienia. Ma świetny współczynnik kompresji, jest dobrze przetestowany i jest używany w wielu najpopularniejszych witrynach, a także osobiście polecany przeze mnie.

Używałem go w moich projektach bez ani jednego błędu JavaScript lub czkawki. I ma ładną dokumentację.

Nigdy nie korzystałem z jego możliwości kompresji CSS, ale one też istnieją. Kompresja CSS działa równie dobrze.

Uwaga: Chociaż / packer / Dean Edwardsa osiąga lepszy współczynnik kompresji niż YUI Compressor, napotkałem kilka błędów JavaScript podczas korzystania z niego.

kamens
źródło
5
Packer wygląda dobrze pod względem rozmiaru pliku, ale okazuje się, że czas spędzony na rozpakowywaniu zwykle przeważa nad zyskiem czasu związanym z przesłaniem mniejszego pliku przez rury. Większość rzeczywistych testów porównawczych przeglądarek, które widziałem, jest wolniejsza niż surowe nieskompresowane pliki obsługiwane przez gzip pod względem czasu wykonania w przeglądarce.
pułkownik Sponsz
Oto jeden punkt odniesienia: ericmmartin.com/comparison-of-javascript-compression-methods
Colonel Sponsz
Oto wersja online kompresora na wypadek, gdybyś nie chciał mieć do czynienia z uruchomieniem Java: refresh-sf.com/yui
Bryan Legend
Skrypty skompresowane przy użyciu programu pakującego nie muszą być rozpakowywane, chyba że zaznaczysz opcję kodowania Base62 (czego nie powinieneś robić, ponieważ jest to gzip dla laika - jestem pewien, że większość nowoczesnych serwerów obsługuje gzip). Nie ma sensu gzipowanie pliku zakodowanego w base62, ponieważ nie ma już nadmiarowości do wykorzystania. Najnowsza wersja pakera (wersja ostateczna) nie wprowadza błędów, nie ma narzutów związanych z rozpakowywaniem (o ile nie kodujesz base62) i nadal osiąga największą kompresję. Jest też teraz wersja pakera z linii poleceń. Wystarczy zainstalować go przy KMP w następujący sposób: npm install packer. (= D
Aadit M Shah
8

Używam ShrinkSafe z projektu Dojo - jest to wyjątkowe, ponieważ faktycznie używa interpretera JavaScript ( Rhino ) do wyszukiwania symboli w kodzie i zrozumienia ich zakresu itp., Co pomaga zapewnić, że kod będzie działał, gdy wyjdzie z drugiej strony, w przeciwieństwie do wielu narzędzi do kompresji, które używają wyrażeń regularnych do tego samego (co nie jest tak niezawodne).

Właściwie mam zadanie MSBuild w projekcie wdrażania sieci Web w moim obecnym rozwiązaniu Visual Studio, które uruchamia skrypt, który z kolei uruchamia wszystkie pliki JS rozwiązania przez ShrinkSafe przed wdrożeniem i działa całkiem dobrze.

EDYCJA: Nawiasem mówiąc, „najlepszy” jest przedmiotem dyskusji, ponieważ kryteria „najlepszego” będą się różnić w zależności od potrzeb projektu. Osobiście uważam, że ShrinkSafe to dobra równowaga; dla niektórych osób, które uważają, że najmniejszy rozmiar == najlepszy, będzie niewystarczający.

EDYCJA: Warto zauważyć, że kompresor YUI również używa Rhino.

Jason Bunting
źródło
5

Wypróbuj JSMin , masz C #, Javę, C i inne porty, a także łatwo dostępne.

chakrit
źródło
Czy port C # został przeniesiony / usunięty?
Greg B
4

Jeśli używasz programu Packer, po prostu wybierz opcję „zmniejsz zmienne” i spakuj wynikowy kod za pomocą programu gzip. Opcja base62 jest używana tylko wtedy, gdy twój serwer nie może wysyłać plików spakowanych gzipem. Packer z 'shrink vars' osiąga lepszą kompresję YUI, ale może wprowadzić błędy, jeśli pominiesz gdzieś średnik.

base62 jest w zasadzie gzipem dla biednych ludzi, dlatego zgzowanie kodu base62-ed daje większe pliki niż gzipowanie kodu shrink-var-ed.

jcoglan
źródło
1

Oto skrypt kompresora YUI ( Byuic ), który znajduje wszystkie js i css w ścieżce i kompresuje / (opcjonalnie) zaciemnia je. Miło zintegrować się z procesem kompilacji.

jimg
źródło
1

KJScompress

http://opensource.seznam.cz/KJScompress/index.html

Kjscompress / csskompress to zestaw dwóch aplikacji (kjscompress a csscompress) do usuwania nieistotnych białych znaków i komentarzy z plików zawierających JavaScript i CSS. Obie są aplikacjami wiersza poleceń dla systemu operacyjnego GNU / Linux.

MicTech
źródło