JavaScript развивается так быстро, что зачастую неясно, делаешь ли ты что-то «не так». В данной статье собраны 8 капитанских правил, на которые стоит обратить внимание при написании JavaScript’а в 2015 году.
1. JS должен быть в .JS-файлах
«Да ладно, это всего лишь несколько строк...» Но нет, весь JS-код должен быть в .JS-файлах. Встроенный JavaScript-код загружается каждый раз при открытии страницы. В противоположность этому, отдельные .JS-файлы кешируются, что ускоряет загрузку страниц. Кроме этого, соблюдение данного правила, поможет вам придерживаться остальных.
2. JS должен быть в конце HTML-файла
Если вы разместите <script> внутри <head>, то скрипт заблокирует рендеринг страницы. Браузер должен обрабатывать скрипты в <head> до того, как отобразит тело страницы. Таким образом, размещение <script> в конце страницы (перед </body>) позволяет заметно ускорить загрузку страницы. Это помогает улучшить восприятие производительности, давая пользователям увидеть страницу до загрузки скриптов.
Кроме того, переносить скрипты в конец файла требует сервис Google mobile frendly при проверке удобства просмотра сайта на мобильных устройствах. Несоблюдение этих рекомендаций может снизить видимость сайта в поисковиках.
3. JS должен быть минимизирован
Минимизация уменьшает размеры файлов, что опять же ускоряет загрузку страниц. Помните, что производительность – это важно. И конечно, чтобы минимизировать JS-код, его необходимо разместить в отдельном файле, т.е. мы возвращаемся к важности первого пункта.
Когда-то, минимизация доставляла много хлопот. Сегодня есть десятки способов автоматизировать это.
4. JS должен проверяться в реальном времени
JavaScript, будучи языком с динамической и слабой типизацией, особенно подвержен ошибкам разработчиков. Есть множество инструментов, которые помогают находить такие ошибки, проверять на соответствие стайл-гайдам и позволяют разработчикам обнаружить проблемы с их JavaScript-кодом до его выполнения. Сравнение инструментов для JavaScript-линтинг.
5. JS должен быть покрыт тестами
Важность тестирования программисты осознали много лет назад. Но эта важность, в значительной степени, игнорируется в отношении JavaScript-кода. Сегодня, типичные приложения на JavaScript обрабатывают все больше логики и регулярно «тестировать» код вручную не представляется возможным.
Можно сконцентрироваться на интеграционном тестировании через такие инструменты как Selenium. С другой стороны, можно сосредоточиться на автоматизированном модульном тестировании с помощью таких инструментов как Jasmine или Mocha. В любом случае, ваш JS-код должен быть покрыт тестами.
6. JS должен иметь автоматизированную сборку
Выше было сказано о важности минимизация, проверки и тестировании кода. С помощью процесса автоматической сборки, которая наблюдает за файлами можно пользоваться всеми этими благами без проблем.
Прежде всего обратите внимание на Grunt, Gulp, Bower.
7. JS должен быть написан на ES6?
Последняя версия JavaScript, более известная как ES6 была официально выпущена в июне 2015 года. Браузеры все еще не поддерживают большую часть новых особенностей.
Однако вы можете наслаждаться огромным списком новых функций уже сегодня, с помощью Babel. Если же вы не хотите смириться с некоторыми причудами производительности Babel, то CoffeeScript — лучший выбор на сегодняшний день.
8. Используйте фреймворки или библиотеки
Сегодня с помощью JS приходится решать новый класс задач: создание сложных приложений. Как правило это одностраничные решения, требующие шаблонизации, связывания данных, модульной структуры и т.п. На рынке существует множество решений для этих целей: Ember, Angular (Google), React (Facebook).
Не пытайтесь начинать с нуля, стойте на плечах гигантов.
Тренды JavaScript на 2015 год.
12 Rules for Professional JavaScript in 2015.
1. JS должен быть в .JS-файлах
«Да ладно, это всего лишь несколько строк...» Но нет, весь JS-код должен быть в .JS-файлах. Встроенный JavaScript-код загружается каждый раз при открытии страницы. В противоположность этому, отдельные .JS-файлы кешируются, что ускоряет загрузку страниц. Кроме этого, соблюдение данного правила, поможет вам придерживаться остальных.
2. JS должен быть в конце HTML-файла
Если вы разместите <script> внутри <head>, то скрипт заблокирует рендеринг страницы. Браузер должен обрабатывать скрипты в <head> до того, как отобразит тело страницы. Таким образом, размещение <script> в конце страницы (перед </body>) позволяет заметно ускорить загрузку страницы. Это помогает улучшить восприятие производительности, давая пользователям увидеть страницу до загрузки скриптов.
Кроме того, переносить скрипты в конец файла требует сервис Google mobile frendly при проверке удобства просмотра сайта на мобильных устройствах. Несоблюдение этих рекомендаций может снизить видимость сайта в поисковиках.
3. JS должен быть минимизирован
Минимизация уменьшает размеры файлов, что опять же ускоряет загрузку страниц. Помните, что производительность – это важно. И конечно, чтобы минимизировать JS-код, его необходимо разместить в отдельном файле, т.е. мы возвращаемся к важности первого пункта.
Когда-то, минимизация доставляла много хлопот. Сегодня есть десятки способов автоматизировать это.
4. JS должен проверяться в реальном времени
JavaScript, будучи языком с динамической и слабой типизацией, особенно подвержен ошибкам разработчиков. Есть множество инструментов, которые помогают находить такие ошибки, проверять на соответствие стайл-гайдам и позволяют разработчикам обнаружить проблемы с их JavaScript-кодом до его выполнения. Сравнение инструментов для JavaScript-линтинг.
5. JS должен быть покрыт тестами
Важность тестирования программисты осознали много лет назад. Но эта важность, в значительной степени, игнорируется в отношении JavaScript-кода. Сегодня, типичные приложения на JavaScript обрабатывают все больше логики и регулярно «тестировать» код вручную не представляется возможным.
Можно сконцентрироваться на интеграционном тестировании через такие инструменты как Selenium. С другой стороны, можно сосредоточиться на автоматизированном модульном тестировании с помощью таких инструментов как Jasmine или Mocha. В любом случае, ваш JS-код должен быть покрыт тестами.
6. JS должен иметь автоматизированную сборку
Выше было сказано о важности минимизация, проверки и тестировании кода. С помощью процесса автоматической сборки, которая наблюдает за файлами можно пользоваться всеми этими благами без проблем.
Прежде всего обратите внимание на Grunt, Gulp, Bower.
7. JS должен быть написан на ES6?
Последняя версия JavaScript, более известная как ES6 была официально выпущена в июне 2015 года. Браузеры все еще не поддерживают большую часть новых особенностей.
Однако вы можете наслаждаться огромным списком новых функций уже сегодня, с помощью Babel. Если же вы не хотите смириться с некоторыми причудами производительности Babel, то CoffeeScript — лучший выбор на сегодняшний день.
8. Используйте фреймворки или библиотеки
Сегодня с помощью JS приходится решать новый класс задач: создание сложных приложений. Как правило это одностраничные решения, требующие шаблонизации, связывания данных, модульной структуры и т.п. На рынке существует множество решений для этих целей: Ember, Angular (Google), React (Facebook).
Не пытайтесь начинать с нуля, стойте на плечах гигантов.
Ссылки по теме
Тренды JavaScript на 2015 год.
12 Rules for Professional JavaScript in 2015.
vintage
1. JS должен быть в .JS-файлах
Тем не менее точку входа удобно иметь в html файле.
3. JS должен быть минимизирован
Не должен. А вот зиповать при передаче желательно.
4. JS должен проверяться в реальном времени. JavaScript, будучи языком с динамической и слабой типизацией, особенно подвержен ошибкам
Ну так и используйте статическую типизацию — TS
6. JS должен иметь автоматизированную сборку
Это касается всего проекта, а не только JS.
7. JS должен быть написан на ES6? Если же вы не хотите смириться с некоторыми причудами производительности Babel, то CoffeeScript — лучший выбор на сегодняшний день.
Использовать препроцессоры без веской на то причины — изобретать себе проблемы на ровном месте.
8. Используйте фреймворки или библиотеки. Не пытайтесь начинать с нуля, стойте на плечах гигантов.
А если я изобрету что-то лучше, то я плохой, негодный программист?