Комментарии 51
Теперь заменим везде в теле функции this на self и посмотрим на результаты сжатия.
а на сколько t тяжелее s?
А вы пробовали сравнить два результата? Там все видно.
this нельзя сжимать. а вот self — можно
В Google Closure Compiler есть возможнось алиасить переменные this, window, document. Но от этого отказались по умолчанию потому как это уменьшает скорость выполнения ~10%. В особенности V8 не любит это.
Спроситите в maillist они вам более развернутый ответ дадут.
Спроситите в maillist они вам более развернутый ответ дадут.
Скажу сразу, что gzip нам не переплюнуть, но когда его нет под рукой, эта техника сжатия может оказаться весьма полезной.Прям страшный сон какой-то, нет под рукой gzip :)
gzip нам не переплюнуть, но когда его нет под рукойЭто как, простите?
GZip есть везде, другое дело что включать его иногда не хотят по каким-то причинам. Но в продакшен можно уже и включить.
Бывает всякое: требования заказчика, старые браузеры, спортивный интерес… :) Кроме того, я думаю, можно организовать код так, чтобы он эффективнее сжимался gzip'ом, и тогда оптимизированные скрипты будут выигрывать и в .gz.
Как-то не хватает итогов, на сколько с применением данных техник стали меньше исходники, сжатые Closure Compiler и YUI Compressor, по сравнению с оригинальными исходниками, сжатыми ими же?
НЛО прилетело и опубликовало эту надпись здесь
GWT?
НЛО прилетело и опубликовало эту надпись здесь
На самом деле я был не совсем прав.
Все-таки там генерируется джаваскрипт, который достаточно сильно сжат именно вербальными методами. Но мне затруднительно сказать, сколько он экономит трафика, потому что он еще и обфусцирован до полной невозможности восприятия.
А сам GWT — это возможность написать клиент-серверное веб-приложение на php или java без знания html, javascript и css
Все-таки там генерируется джаваскрипт, который достаточно сильно сжат именно вербальными методами. Но мне затруднительно сказать, сколько он экономит трафика, потому что он еще и обфусцирован до полной невозможности восприятия.
А сам GWT — это возможность написать клиент-серверное веб-приложение на php или java без знания html, javascript и css
А разве GWT существует не только под Java'у?
Родной он под джаву, но
code.google.com/p/gwtphp/
www.gwtphp.com/
Насколько они актуальны, я не знаю, потому что сам пишу на джаве.
code.google.com/p/gwtphp/
www.gwtphp.com/
Насколько они актуальны, я не знаю, потому что сам пишу на джаве.
Это тока сервеная часть. Клиентскую так и остается на java.
/Клиентская часть — это по сути всего навсего один js+5 html файликов. Не думаю, что большой проблемой является их распаковать из war архива и заставить отдаваться через апач/инжиникс.
GWT это штука которая компилит java в javascript. Как одну из фитчей он потдерживает комуникацию с сервером. gwtphp это простейшая реализация протокола которым пользуется gwt. Никаких компиляций клиентского кода єта либа не потдерживает.
А, то есть как бэкэнд нам все равно нужен сервер типа томката или глассфиша?
Для меня просто тема не особо актуальна, потому что у нас в продакшене все равно томкат используется.
Для меня просто тема не особо актуальна, потому что у нас в продакшене все равно томкат используется.
То что компилит GWT для клиентской части, это набор статических файлов. JS, CSS, HTML и картинки. Их можно хостить где угодно. Мы например .NET стек, и хостим их под IIS. А вообще собираемся на CDN.
А уж серверная часть может быть быть начем угодно, по умолчанию это java и соотвевенно требует апп сервер. Но вполне может быть чем угодно. У нас это .NET. Вот и gwtphp, это тока серверная часть. Маленький опциональный кусочек.
Тоесть вы все ранво продолжаете писать клиентскую часть на java. Компилить ее в статические файлы. А сервер уже PHP.
Это я к тому что не существует GWT не под java. Есть интеграции с разными серверными стеками.
А уж серверная часть может быть быть начем угодно, по умолчанию это java и соотвевенно требует апп сервер. Но вполне может быть чем угодно. У нас это .NET. Вот и gwtphp, это тока серверная часть. Маленький опциональный кусочек.
Тоесть вы все ранво продолжаете писать клиентскую часть на java. Компилить ее в статические файлы. А сервер уже PHP.
Это я к тому что не существует GWT не под java. Есть интеграции с разными серверными стеками.
А, теперь понял.
Да, мне как-то не пришло в голову, что именно джава компилится в джаваскрипт и так далее.
Прошу прощения за тупость.
Ну и в итоге имеем, что при желании GWT-приложение можно поднять на бесплатном хостинге с php+mysql. До вас мне эта мысль в голову не приходила, спасибо.
А нет ли аналогичных фреймворков для того же php? Чтобы мы написали на php, запустили, у нас создалось некоторое количкство файликов?
Да, мне как-то не пришло в голову, что именно джава компилится в джаваскрипт и так далее.
Прошу прощения за тупость.
Ну и в итоге имеем, что при желании GWT-приложение можно поднять на бесплатном хостинге с php+mysql. До вас мне эта мысль в голову не приходила, спасибо.
А нет ли аналогичных фреймворков для того же php? Чтобы мы написали на php, запустили, у нас создалось некоторое количкство файликов?
Тестовый плагин весит ровно 1 КБ, в сжатом виде 576 Байт, в gzip 391 КБ.
391 килобайт?:)
Тестовый плагин весит ровно 1 КБ, в сжатом виде 576 Байт, в gzip 391 КБ.Если там действительно килобайты, то Вы очень неплохо переплюнули gzip :)
По-моему, правильное решение в этом случае — это написать предложение в саппорт Google Compiler'a и прочих сжимальщиков.
Код всегда должен оставаться как можно более читабельным, с возможностью быстрого сжатия специализированными тулзами.
Код всегда должен оставаться как можно более читабельным, с возможностью быстрого сжатия специализированными тулзами.
Есть одна проблема. Дело в том, что обращение к методу через переменную более долгое, чем напрямую по имени.
Т.е.
Я раньше тоже использовал технику кэширования имен атрибутов и методов, но потом провел тесты и решил отказаться от этого в пользу производительности.
Т.е.
obj["method"](); // Дольше, чем:
obj.method();
Я раньше тоже использовал технику кэширования имен атрибутов и методов, но потом провел тесты и решил отказаться от этого в пользу производительности.
о, расскажите, пожалуйста, поподробнее? насколько дольше?
Разумеется, этот подход не для тех приложений, в которых критична скорость (впрочем, как и ООП с его наследованием и другие навороты). Но если в пределах 5 строк 12 раз встречаются конструкции типа
$(document), то уж обращение к свойству через переменную вы точно можете себе позволить.
в таком варианте — все равно. Производительность обычно на вызовах функций падает, а не на разыменовании
Packer тоже примерно также писали. Только вот инициализация такого сжатого скрипта — неблагодарное занятие.
Отличная статья, спасибо. Кстати, вы там случайно функцию копирайта выложили ;)
Можно было бы завернуть весь скрипт в строку, провести часточный анализ слов и заменять самые используемые слова в строке на неиспользуемые байты.
Распаковщик будет в 50 байт.
Распаковщик будет в 50 байт.
Подобное я уже где-то видел… А, в плагине Lightbox для RightJS: rightjs.org/builds/ui/right-lightbox.js
«var self = this», кстати, помогает, если ночью, когда «мозги не варят», переключаешься между Python и JS кодом и путаешься %)
Я для своего Санкалка на 10к использовал ту же методику. :) Всё-таки удалось в итоге добить размер до заветных 10240. Основной прирост при это обеспечил модуль Math и все его методы — Math -> m, m.cos -> mc, etc. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сам себе gzip: сжимаем скрипты на 20% лучше