Мне было интересно, зачем нам нужны несжатые файлы для разработки и минифицированные для производства? Я имею в виду, каковы преимущества использования несжатых файлов перед минифицированными?
Они дают вам более точные сообщения об ошибках или просто, если мы хотим что-то найти, мы можем просмотреть код несжатых файлов?
Возможно, некоторым из вас это покажется глупым вопросом, но у меня никогда не было привычки просматривать код хорошо известных больших библиотек, и, если я не ошибаюсь, очень немногие люди это делают.
Вы говорите о сжатии или минификации?
Да, они лучше выводят сообщения об ошибках и отладку. (Вы может используете исходные карты, чтобы получить эти преимущества в некоторой степени на минифицированном коде.) Их также немного быстрее изменить, потому что этап минификации требует времени. Если у вас нет других шагов сборки, вы можете полностью пропустить сборку.
@Ry, спасибо за ответ, он прояснил мой вопрос.
Основная причина этого - удобство использования. Когда js-файл минифицирован, и у вас возникла ошибка, и вы пытаетесь найти место, где он находится, что бы вы обнаружили? просто минифицированная строка вроде
(function(_){var window=this,document=this.document;var ba,ea,fa,ha,la,na,oa,pa,qa,sa,ra,ta,wa,xa,za,Aa,Da,Ea,Fa,Ga,Ia;ba=function(a){return function(){return _.aa[a].apply(this,arguments)}};ea=function(a){return ca(_.p.top,a)||ca(da(),a)};_.aa=[];fa = "function"==typeof Object.create?Object.create:function(a){var b=function(){};...
и так далее. Это читается для вас? Я так не думаю. Это вообще не читается.
Чтобы лучше понять код, его нужно распаковать. Это добавит дополнительные пробелы и отформатирует код более читабельным. так это будет выглядеть так:
(function(){
var b = j(),
c = k (b);
})();
Это позволяет вам переходить от одного фрагмента кода к другому и обнаруживать код или искать свою ошибку внутри.
Кроме того, для производства вам нужно не только минимизировать код, но и сжать его. Так что было бы неплохо использовать для этого библиотеку Uglify
.
Он удаляет ненужные пробелы, переименовывает переменные, объекты и функции для гораздо меньших имен, таких как a
или b12
. Это увеличивает скорость загрузки.
Надеюсь, это поможет тебе.
Может быть несколько причин, по которым можно предпочесть несжатые [неминифицированные] файлы во время разработки. Некоторые причины, о которых я могу думать:
Сократите время на просмотр изменений при кодировании, пропустив этап минификации. (Если вы используете минификацию как часть этапа сборки во время разработки, вам, возможно, придется ждать завершения минификации каждый раз, когда вы вносите изменение, чтобы увидеть его в браузере.)
Если используется менеджер кода, переменные могут быть переименованы и не будут интуитивно понятны в отношении того, что они на самом деле вызываются в базе кода.
Если вы используете веб-пакет или какой-либо подобный загрузчик модулей, он может включать дополнительный код для горячей перезагрузки модуля и внедрения зависимостей / отслеживания ошибок, если он не минифицирован (что вам не нужно в производстве).
Это позволяет сделать отладку более простой, удобочитаемой и интуитивно понятной.
Минификация и изменение кода выполняются В основном для того, чтобы сделать доставку этих активов более эффективной от сервера конечному пользователю (клиенту). Это гарантирует, что клиент может быстро загрузить сценарий, а также снижает затраты веб-сайта / компании на доставку этого сценария пользователю. Так что это можно считать лишним ненужным шагом при запуске кода во время разработки. (Активы уже доступны на месте, поэтому дополнительная стоимость полезной нагрузки незначительна)
TL; DR: минификация и изменение кода могут занять много времени (особенно когда мы создаем файлы карт и т. д.), Что может задерживать время между изменениями и время, когда эти изменения видны на локальном экземпляре. Это также может фактически затруднить разработку, усложняя / менее интуитивно понятную отладку.