Если упакованный Javascript экономит 20 КБ от размера загрузки, но требует снижения производительности для распаковки, то есть ли какие-то преимущества, помимо запутывания кода?
Я сделал эту вики-страницу сообщества, потому что она может быть открыта для обсуждения.



![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)


Короткий ответ: да, потому что время распаковки клиентской машины быстрее, чем передача, а также Интернет перегружен как есть, поэтому любой вклад в улучшение ситуации приветствуется анонимами, также помните, что большинство клиентов будут кэшировать этот материал, и чем больше размер файл, тем больше шансов, что он сам или другие вещи будут вытеснены из кеша клиентов, особенно на мобильных устройствах
Согласен, сжатие лучше, но сжатие минифицированного источника вдвое лучше. Ну, не совсем 200%, но суть вы поняли.
О да, я согласен, что минификация может иметь смысл. Просто спрашивающий говорит о «временной остановке браузера» для распаковки сценария, предполагая, что происходит что-то иное, кроме сжатия на уровне HTTP. Это не должно останавливать браузер.
Да, для пользователя не должно быть заметной остановки, все это должно быть спрятано глубоко в глубине души, но не знать, какой браузер он использует :)
Может стоит отредактировать вопрос! И чтобы уточнить, я использую Firefox 3 в OS X
Упакованный код javascript обычно не требует больше времени для выполнения по сравнению с обычным кодом. Большинство упаковщиков кода сокращают переменные, имена функций и используют множество уловок, чтобы уменьшить размер исходного кода. Полученный исходный код полностью исполняемый! Вы можете убедиться в этом, взглянув на это во время выполнения с помощью firebug. Вы увидите выполнение сжатого кода в его свернутом виде.
упакованный js делает добавляет несколько миллисекунд выполнения (minified - нет), это можно измерить с помощью Firebug
Как вы используете Firebug для определения времени выполнения Javascript? Думаю, это новый вопрос!
Спрашивается, почему упаковка экономит 20кБ? Вам следует подумать о том, чтобы уменьшить размер вашего «обычного» javascript. Значительно ли улучшилась читаемость вашего кода за счет помещения пробелов вокруг операторов или использования очень длинных имен переменных и функций? Самая вопиющая трата пропускной способности, которую я видел на любом веб-контенте, скрипте, странице или CSS, - это отступы с пробелами. Если вам необходимо сделать отступ, используйте табуляцию или одиночные пробелы. Нет ничего более расточительного, чем сто строк подряд с 20+ пробелами в начале.
Оптимизируйте свой код для использования людьми. Однажды кому-то будет поручено поддерживать его, а вы не хотите, чтобы в ваших руках была месть. Упаковщики позволяют использовать лучшее из обоих миров. Согласованы по пробелам и табуляциям.
Длинные последовательности пробелов очень эффективно обрабатываются сжатием gzip на уровне сервера. И если вы не архивируете свой JS-код, вы платите гораздо большую цену, чем вы бы сэкономили, изменив свой стиль отступа.
Вот почему у вас есть 3 файла: 1) исходный файл, который вы редактируете, 2) уменьшенная версия на сервере, 3) сжатая минифицированная версия на сервере. И вы настраиваете свой сервер для отправки сжатой версии, если клиент может ее обработать, или минифицированной версии. (продолжение)
Таким образом, вы получите хорошее сжатие только за счет проверки, существует ли файл, но без дополнительных циклов процессора для сжатия файла. А поскольку он предварительно сжат, вы можете получить наилучшее сжатие.
Ребята из Yahoo's YSlow рекомендуют использовать как минификатор, так и сжатие gzip.
Минификатор удалит пробелы, укорачивает имена переменных и т. д. Таким образом, вы можете кодировать с правильным отступом и именами переменных, чтобы другие разработчики могли понять ваш код.
Сжатие gzip, вероятно, даже более ценно.
Предположительно, упакованный JavaScript (немного) более эффективен для отправки сервером, в то время как расходы на распаковку берут на себя клиент.
Если пользовательский интерфейс в обоих случаях эквивалентен, я бы выбрал упакованный JS.
Каждый раз, когда вы можете передать некоторую работу клиенту, не вызывая негативных эмоций у пользователей, сделайте это и воспользуйтесь преимуществами распределенных вычислений.
Браузеры и HTTP-серверы по-прежнему не поддерживают gzip, сжатие и дефляцию кодирования содержимого? Если стоит заархивировать javascript, то, безусловно, стоит заархивировать все, и это проблема уровня HTTP, а не уровня сценария.