5 аргументов не использовать inline CSS и JavaScript код

Если вы попали на мой блог, значит, вас интересует веб-программирование. Основой веб-программирования, понятное дело, является HTML, но никакой современный сайт уже не обходится без CSS и JS. В интернете можно встретить много разговоров о стандартах в web-программировании, в каком стиле лучше писать код. Ну а толку с них, - скажете вы, - если есть W3C, который занимается стандартизацией и там всё можно почитать. Конечно, можно, но там тонны информации, которую сложно переварить и надо затратить много времени на её изучение.

В этой статье я хотел бы изложить несколько рекомендаций как не следует писать код, и почему не следует делать напрямую вставки из стилей и скрипта по всей HTML странице.

Итак, что же такое inline JavaScript и CSS, - это когда внутри html страницы идут вперемешку скрипты и описания стилей через строчку с html разметкой. Под JavaScript-ом вперемешку я понимаю не вызовы функций по событиям on_click, а непосредственно объявление этих самых вызываемых функций или объявление переменных между тегами <> < /script>, разбросанное по всей странице. Какая разница? – спросит большинство. А разница всё-таки есть, и я приведу вам 5 аргументов не использовать inline CSS и JavaScript код.

Аргумент 1: Кэширование и большинство оптимизаций не работают.
Большинство браузеров для убыстрения работы и уменьшения перегоняемого трафика используют в своей работе кэширование страниц. HTML страницы никогда не кэшируются. Что же касается графических изображений, внешних каскадных таблиц стилей (CSS) и файлов JS скриптов – то браузер пользователя наоборот, старается сохранить файлы в кэше при первом визите и при последующих запросах этих файлов не загружать их заново. Таким образом, объёмы загружаемой информации резко уменьшаются, перегружается только HTML-код страницы, а всё остальное подгружается из локального кэша браузера.

Аргумент 2: Непонятность кода и сложность нейтрализации ошибок
Допустим, у вас по большой HTML странице разбросаны JavaScript вставки. При наступлении какого-то события с неявно указанным обработчиком вам будет сложно выудить необходимый участок кода и нейтрализовать программные ошибки. А если страница компонуется из нескольких вставок, то обработчик и вовсе не будет отрабатывать, по той простой причине, что этот участок кода был случайно не включён.

Аргумент 3: HTML код становится тяжелее.
На выходе ваш HTML код получится значительно тяжелее и больше по объёму. HTML страница пронизанная JS и CSS вставками будет весить в килобайтах гораздо больше, чем аналогичная страница «чистая» по своей структуре.

Аргумент 4: Сложность модификации.
Лучше код взаимодействия вынести в одно централизованное место, чем просматривать весь текст в поисках однотипных участков кода для изменения, разбросанных по всем страницам сайта. Не каждый программист выдержит поддержку такого кода, разбросанного по всему сайту.

Аргумент 5: Невозможность повторного использования кода.
Если вы реализовали отличный по функционалу элемент интерфейса, то вы наверняка захотите его повторно использовать в остальных своих проектах. Но он намертво «вшит» по всем страницам сайта, и вам придется потратить уйму времени на его выуживание и прикручивание к другому сайту. При реализации, разнесенной по отдельным внешним файлам, всё, на что бы вам пришлось потратить время – это сделать подгрузку этих файлов, и вставить в необходимые места вызовы методов.

Надеюсь, мои 5 аргументов не использовать inline CSS и JavaScript код вас хоть немного убедили, и вы возьмёте их на заметку. Успешного кода, программист, и держи реализацию CSS и JavaScript в отдельных внешних файлах.