Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 28

Посмотрел цифры, интерпретировал так: все минификаторы показывают примерно одинаковый результат; степень сжатия не является существенным критерием при выборе минификатора.
Всего голосов 21: ↑21 и ↓0+21
По опыту использования и тонкой настройки Google Closure Compiler могу сказать, что на сегодняшний день равных ему нет.
Всего голосов 1: ↑1 и ↓0+1
Очень странные графики в килобайтах. Может лучше проценты?..
Всего голосов 2: ↑1 и ↓10
Передал графики на отображение процентов.
Всего голосов 1: ↑0 и ↓1-1
Спасибо! Так стало действительно понятнее :-)
Комментарий пока не оценивали0
a. Взялись за Closure — так уж бы и code.google.com/p/closure-stylesheets/ посмотрели для CSS.
б. Closure c advanced компиляцией дает выигрыш в размере в ~20%. Минус (ли?) — (псевдо)строгая, (псевдо)статическая типизация комментариями.
Всего голосов 1: ↑1 и ↓0+1
Спасибо за информацию о Closure Stylesheets. Обязательно посмотрю его. Но, как я понял, что это не чистый минимизатор, а препроцессор со средствами минимизации.

В данном обзоре я сравнивал только минимизаторы, для которых есть модули в моем продукте (Bundle Transformer).
Комментарий пока не оценивали0
Closure Stylesheets is a system that supports a number Google extensions to the standard CSS language. With these extensions, you can define and use variables, functions, conditionals, and mixins in your stylesheet, making your stylesheets more readable and maintainable. An included tool can compile the stylesheet down into standard CSS and supports minification, linting, directionality (right-to-left flipping), and class renaming.
developers.google.com/closure/

Google PageSpeed (модуль/сервис) использует именно его для автоматической оптимизации. Нужно сравнение с Яндексом.
Некорректно сравнивать только оптимизаторы, которые вы сами поддерживаете :)
Всего голосов 1: ↑1 и ↓0+1
В данном обзоре я уже не буду проводить такое сравнение.

Но вы подали хорошую идею по дальнейшему развитию модуля BundleTransformer.Closure.
Комментарий пока не оценивали0
Его стоит использовать перед каком нить csso, но выигрышь будет при использовании например их методологии closure library,

Closure Stylesheets жмет названия классов например до однобуквенный используя css таблицы соотвествия… актуально в одностраничных приложениях
Комментарий пока не оценивали0
Closure Stylesheets в качестве CSS-минимизатора показался мне очень сырым.
Комментарий пока не оценивали0
он им и не является, я собственно и написал что он позволяет… надо просто правильно готовить тогда и будет максимальный выхлоп
Комментарий пока не оценивали0
Понятно, что Closure Stylesheets – это препроцессор, но, тем не менее, разработчиками заявлена поддержка минимизации обычных CSS-файлов. Речь идет о том, что он пока еще не готов для массового использования в качестве CSS-минимизатора (в данном случае, он не может распарсить bootstrap.css даже с включенной опцией --allow-unrecognized-functions).
Комментарий пока не оценивали0
ну там очень слабая минимизация в том виде в котором вы ее представляете. например может несколько файлов вместе объединить (правда очень медленный процесс), может убрать переносы и пробелы и прочий мусор. И как я уже говорил его лучше использовать для других целей. тогда можно получить максимальный эффект
Комментарий пока не оценивали0
Не подскажите где можно взять последнюю версию closure-stylesheets.jar?

А то я вижу только версии 2011 года.
Всего голосов 2: ↑1 и ↓10
Вместо того, чтобы минусовать лучше бы дали ссылку или сказали: «Собирай из исходников :-)».
Комментарий пока не оценивали0
CC в ADVANCED MODE очень капризный и нужно совершенно точно знать, что он делает.

Не забываем, что в этом режиме, вот такой код будет минифицирован неправильно и не заработает (тут «потеряется» свойство props):
// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// ==/ClosureCompiler==

function test() {
  var obj = {
     "props": { test: 123 }
  };

  return obj;
}

console.log(obj.props.test)


Попробуйте сами. И это только один из нюансов. Так что нужно быть ПОЛНОСТЬЮ уверенным в качестве своего кода, чтобы пропускать его через GCC в ADVANCED MODE
Всего голосов 1: ↑1 и ↓0+1
Консоль при попытке выполнить говорит:

> ReferenceError: obj is not defined

Возможно, имелось ввиду это?

// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// ==/ClosureCompiler==
function test() {
var obj = {
props: { test: 123 }
};
return obj;
}
console.log(test().props.test)

Что прекрасно сжимается в следующее:

console.log(123);
Всего голосов 1: ↑1 и ↓0+1
Кажется я скопировал не тот пример.
Вот:
// ==ClosureCompiler==
// @compilation_level ADVANCED_OPTIMIZATIONS
// ==/ClosureCompiler==

function test() {
  var obj = {
    "props": { test: 123 }
  };

  window.AA = obj;

  return obj;
}

console.log(test().props.test)
console.log(window.AA)

Минифицируется как
console.log(function(){var b={props:{test:123}};return window.a=b}().b.test);console.log(window.a);

Свойство «props» потерялось.
Комментарий пока не оценивали0
Собственно, документация именно про этот случай говорит: Solution: Be Consistent in Your Property Names
developers.google.com/closure/compiler/docs/api-tutorial3#propnames

В целом (для случайного читателя в первую очередь), рекомендую ознакомиться с
developers.google.com/closure/compiler/docs/api-tutorial3#dangers
И исходить из того, что сторонние библиотеки наверерняка про это даже и не думали. Так что если closure, то и его библиотеки, со всеми вытекающими.

Кстати, каким образом приведенный пример кореллирует с исходной посылкой про «качество кода», я не разобрался. Но не суть.

С исходной посылкой я в целом согласен — Closure Compiler с advanced режимом использовать без developers.google.com/closure/compiler/docs/js-for-compiler по меньшей мере неразумно.
Он делает много чего, удаляет код, раскрывает функции, вставляет значения констант, передвигает код в выводе — много на что выдаются предупреждения, но — из опыта — кто ж их читает?

Но справедливости ради отмечу, что приведенный пример минифицируется корректно и работает, если заменить «props» на props.

Также ломается если:

obj[«props»] = { abc: 42 };

Но в этом случае работает:

obj.props = { abc: 42 };

Еще, разумеется будет ломаться в более хитрых случаях, например, если имя свойство задавать через переменную, или вывод функции, или прототипы, или (миллион случаев сюда).
Комментарий пока не оценивали0
Так сложилось, что предпочитаю нативные (гомогенные) решения.
Под PHP — это github.com/meenie/javascript-packer + leafo.net/scssphp/
Под Python — это github.com/Kronuz/pyScss + django-compressor (rjsmin)
Два процента разницы в размере файла ТАКОЙ УЖ роли не играют
С Closure-компилером в свое время не срослось, поскольку он требовал уж очень четкого соблюдения стандартов, чего в любом проекте добиться крайне сложно (каждая вторая 3rd-party либа или legacy code приводит к аду)
Комментарий пока не оценивали0
  1. javascript-packer — это порт Packer
  2. scssphp и pyScss — это порты Sass
  3. Django Compressor — это по сути адаптеры для CSS Tidy, YUI compressor, Closure Compiler и JSmin

Все эти семейства алгоритмов присутствуют в списке вариантов ответов. Я ожидал увидеть в комментариях названия других семейств алгоритмов (например, комментарий по поводу Closure Stylesheets был в самую точку).
Комментарий пока не оценивали0
Но не обошлось и без ложки дегтя:… CSSO оставляет лишь первый такой комментарий, а остальные удаляет.
Оставлять остальные комментарии не имеет смысла потому, что при реструктуризации блоков нередко теряется то, что комментарий комментировал. В итоге получаем что-то вроде «это страшный IE-хак!» над блоком, из которого хаки уехали выше.
Всего голосов 1: ↑1 и ↓0+1
Сергей, спасибо за разъяснение.

Просто я оценивал CSSO с точки зрения опыта работы с другими CSS-минимизаторами, в которых не реализована структурная минимизация. К сожалению, пока CSSO не с чем сравнить, т.к. WebGrease Semantic CSS Minifier по-прежнему содержит ошибки.
Комментарий пока не оценивали0
В своем проекте виджета чата для сжатия/обфускации JS активно использую Closure Compiler в ADVANCED MODE.
Равных ему нет, особенно это становится заметно в проектах с большим количеством отдельных модулей.
Например, ему не составляет труда сгенерировать для каждой страницы сайта свой маленький js файл, который использует лишь небольшие куски кода из тысяч больших js модулей/классов. Совет — используйте Plovr, он значительно упростит разработку.

Выше писали, что сторонние библиотеки не дают нормально работать компилятору в ADVANCED MODE. По-началу меня это тоже напрягало, но решилось использованием огромной библиотеки Closure library которая написана специально для Closure Compiler.
Возможностей у нее куда больше чем у jQuery. Кроме того, в код вашего скрипта после компиляции попадут только реально используемые методы из этот библиотеки, а не вся библиотека разом (как при подключении jQuery), что значительно скажется на общем размере.
Всего голосов 2: ↑2 и ↓0+2
В целом да, грузить только нужный js на определенной странице, а не тащить весь jQuery на каждую, кажется очень даже разумным. Но вероятность того, что jQuery закэширован (Google/Yandex CDN) очень велика, а отдельных js файлов мала. При этом если учитывать, что почти весь js/css кэшируется при первом заходе на сайт, то я бы выбрал вариант с jQuery.
Комментарий пока не оценивали0
Для этого Closure Compiler умеет автоматически выделять и компилировать общий модуль, который используется на всех страницах сайта. И отдельные модули для каждой страницы. Таким образом на каждой странице подключается 2 скрипт тэга.
Надеяться на то, что у пользователя закэширован jQuery до захода на ваш сайт считаю не стоит, так как сайты ныне тяжелые и из кэша браузера достаточно быстро вытесняются необходимые вам файлы.
Комментарий пока не оценивали0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время
Изменить настройки темы

Истории

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr