Zauważyłem, że za każdym razem, gdy używam Google's Closure Compiler Service, pozostawia ona kilka niepotrzebnych spacji w skompilowanym kodzie widocznym po prawej stronie. Odpowiadają one podziałom linii w hostowanej wersji skompilowanego kodu.Dlaczego Google Closure Compiler pozostawia kilka niepotrzebnych spacji lub linii?
Na przykład (zwróć uwagę na podziały wierszy, z których każdy wydaje się niepotrzebny):
http://troy.onespot.com/static/stack_overflow/closure_spaces.js
do tej pory, właśnie został usuwając je ręcznie, ale jestem ciekaw, dlaczego oni tam . Czy ograniczenie długości linii hostowanej wersji kodu jest bardziej czytelne? Czy kompilator może być wystarczająco inteligentny, aby go zostawić lub wstawić celowo, aby zmaksymalizować wysiłki kompresji GZIP?
Wiem, że mają one niewielki wpływ na rozmiar pliku, ale przy tak wielkim wysiłku przechodzącym na minimalizowanie wszystkich ostatnich bajtów w skrypcie źródłowym, jest to sprzeczne z intuicją, dlaczego tak się dzieje.
Nie mam dostępu do pliku [default.js] (http://closure-compiler.appspot.com/code/jsc39ddc01a5a74a754148a33d2d8f1444/default.js), link zwraca stronę z "Content-Length" z 0. Czy możesz wkleić (część) kodu w swoim pytaniu? –
Przepraszam za to - założyłem, że Google hostował skompilowany kod w nieskończoność, ale najwyraźniej tak nie jest. Zaktualizowałem link w powyższym pytaniu. – Bungle
Najbardziej szaloną rzeczą jest Google PageSpeed Insights narzeka na kilka bajtów (<1 KB) i kiedy pobieram zoptymalizowane pliki, js ma 180K długich linii, ale nie ma sposobu, aby polecić kompilatorowi zamknięcia (API lub aplikacji JAVA), aby złamać linie o dowolnej długości (np. 180K) –