Зачем отделять CSS и JS поставщиков от пользовательских CSS и JS в рабочем процессе?

Я пытался определить причины, лежащие в основе того, что, похоже, стало стандартной практикой в интерфейсных рабочих процессах разделения JS и CSS поставщиков от пользовательских JS и CSS. Я не уверен, в чем преимущества по сравнению с недостатком дополнительного HTTP-запроса, казалось бы, чище просто иметь один файл CSS & JS, а не иметь поставщика.css, main.css и поставщик.js, главная.JS.

Может ли кто - нибудь пролить на это свет?
4 7
bower gruntjs yeoman frontend

4 ответа:

Код поставщика обычно изменяется реже, чем код вашего приложения. Таким образом, при обновлении приложения код поставщика может оставаться неизменным и кэшироваться в браузере пользователя.

В сценарии, где код поставщика поставляется в комплекте с кодом приложения, пользователь должен загружать весь код поставщика каждый раз при обновлении приложения.

Дополнительный HTTP-запрос от отдельного пакета поставщиков смягчается тем фактом, что пользователь будет загружать меньше кода на каждый пакет. обновление приложения.

8

Я могу назвать две причины.

  1. код поставщика хостинга отдельно от вашего кода (например, размещенные библиотеки Google )
  2. Разделение проблем: код поставщика может быть большим и обновляется независимо от вашего пользовательского кода. Сохранение кода в отдельном файле позволяет избежать необходимости помещать код поставщика в систему управления версиями, упрощает навигацию по коду, упрощает обновление до нового кода поставщика, поскольку вы точно знаете, что код поставщика не был щипанным.

Тем более, что вы пометили вопрос grunt, конечный пользователь может никогда не увидеть этого изменения, так как вы можете объединить стили/сценарии поставщика и пользователя во время сборки.

Однако, если код поставщика велик и изменяется нечасто, вы получаете преимущество кэширования, имея редко изменяющийся, большой файл поставщика, сопровождаемый небольшим, быстро изменяющимся файлом пользовательского кода. Для крупных сайтов, которые не используют CDN (надеюсь, не ваш), влияние может быть заметным.

3

В зависимости от ситуации это позволяет сделать ваши изменения ниже в каскаде, так что вы можете переопределить стили и поведение поставщиков, не разрушая их код. Это полезно, чтобы у вас всегда была рабочая версия(код поставщика), к которой вы можете вернуться. В ситуациях, подобных работе с Wordpress, разработка дочерней темы позволяет обновить родительскую тему, не разрушая ваши настройки.

1

Различные ответы уже касались этого, но я сделаю это очень конкретно:

  1. Код поставщика может изменяться чаще или реже, чем ваш код. Если код поставщика изменяется чаще, например, для исправления ошибок, вы бы хотите использовать более новые версии и иметь лучший общий веб-сайт. Если код поставщика изменяется реже, чем ваш код, вы можете пожелать чтобы изменить свой код без прикосновения к рабочим вещам.

  2. Код поставщика часто размещается на CDNs, например https://cdnjs.com/#q=ajax или https://developers.google.com/speed/libraries/ они быстрые погрузка. Они также не изменятся, поэтому пользователь может полагаться на кэшированные данные. файлы и, таким образом, ваш сайт будет загружаться быстрее.

  3. Как правило, лучше вносить итеративные изменения в код. Кроме того, проще управлять кодом, особенно с помощью системы управления версиями, когда это необходимо. все меняется. Нет необходимости менять местами большие файлы, когда их нет измененный. Держать вещи отдельно делает его проще сделать инкрементные изменения, особенно если эти две вещи имеют разные изменения скорости.

1