Как отказаться от jQuery в современном фронтенде опыт команды GitHub


Оглавление (нажмите, чтобы открыть):

Для чего нужен GitHub Frontend-разработчику?

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

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

  1. Любая задача вызывает у вас ступор, потому что ничего не понятно (наш мозг очень ленивое создание и не любит все новое и непонятное, потому что нужно тратить драгоценную энергию).
  2. На таск, который более опытный разработчик тратит 2-3 часа, у новичка уходит 2-3 дня.
  3. Вы отвлекаете от работы старших коллег вопросами, время которых стоит дороже, чем ваше.
  4. Новички постоянно что-то ломают, а потом долго ищут способ, как починить, потому что не знают.

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

Используйте GitHub, чтобы наработать опыт

Когда вы решаете учебные задачи или собственные домашние проекты, вы пишете код. Во-первых, все свои учебные проекты на гитхаб в удаленном репозитории хранить удобнее, чем у себя на компьютере. Особенно сборки с node_modules, которые отжирают немерено памяти на диске за счет веса вышеупомянутой папки. Несколько проектов и ваш компьютер может забиться. А удаленный репозиторий доступен вам всегда для скачивания на любое устройство, где есть интернет. Поэтому использовать git — хорошая практика даже для программиста-одиночки. Каждый коммит в аккаунте фиксируется и в профиле можно посмотреть, насколько продуктиктивен тот или иной разработчик, когда он начал работать, чем интересуется и чему учился.

Во-вторых, чтобы получить опыт, можно поучаствовать в разработке open source библиотек. Попросите владельца репозитория накидать вам несложных для новичка тасков. За участие в open source проекте вам никто не заплатит, но когда вы попытаетесь сделать коммит в репозиторий библиотеки через pull-request, владелец репозитория либо его принимает, либо его отклоняет. И если отклоняет, то чаще всего дает обратную связь, почему ваш код плохой. Главное не стесняться спросить — разработчики, как правило, люди открытые и с удовольствием объясняют, что в вашем коде не так.

Используйте GitHub, чтобы найти работу

Рекрутеры IT-компаний, как правило, просматривают аккаунты разработчиков. Главное не полениться и помочь вас найти, аккуратно оформив аккаунт, репозитории и коммиты. Из своего опыта где-то за последние полгода мне поступало около 10 писем на мой почтовый ящик с приглашением на собеседование. И когда я задавала рекрутеру вопрос: «Откуда Вы меня нашли?», мне честно отвечали: «Я просматриваю аккаунты на гитхабе» (на тот момент у меня уже было более 400 коммитов за год и больше 20 репозиториев). Конечно приятно, когда работа уже начинает искать вас.

GitHub для общения с себе подобными

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

Ну вот такой небольшой мотивационный обзор. Удачи и до новых встреч в следующих статьях!

Нужен ли вам jQuery? По полочкам. Сниппеты You Don’t Need jQuery / VSC, Sublime Text

Всем привет, друзья! Сообщество веб-разработчиков в последнее время разрывает дикий баттхёрт относительно того, стоит ли использовать jQuery в своей работе. Одни топят за то, что нужно использовать эту библиотеку во всех проектах без исключения, другие не могут понять, что вообще происходит и продолжают делать то, что делали раньше. Третьи, чтобы не отрываться от коллектива, осваивают последний ECMAScript, всячески открещиваются от jQuery и бомбят при любом упоминании этой библиотеки. Сегодня мы разберёмся в вопросе более подробно, без крайностей и максимализма.

Полезные ресурсы урока:

  • Сниппеты YDNjQ на Github
  • Урок по редактору Visual Studio Code
  • Урок по редактору Sublime Text
  • Урок по созданию сниппетов для Sublime Text

В конце выпуска мы познакомимся с коллекцией сниппетов You Don’t Need jQuery, которую я подготовил для редакторов Visual Studio Code и Sublime Text. Эта коллекция послужит отличным помощником, если вы вдруг проснулись и поняли, что жизнь слишком проста и нужно писать код исключительно на ванильном JS. Кроме того, в грядущем большом курсе Джедай вёрстки 8, в качестве академического примера, мы будем верстать без использования jQuery, на чистом JS и представленная коллекция будет очень кстати.

jQuery – это самая популярная в мире JS библиотека, позволяющая значительно упростить процесс взаимодействия с элементами DOM, а также предоставляющая удобный API для работы с событиями и AJAX.

Здесь я не буду защищать ни одну из сторон, так как это бессмысленно. Это не конкуренция и сокращение «vs» (versus) ставить между jQuery и нативным JS просто некорректно. Когда надо, я использую jQuery, когда не надо, не использую. jQuery — это инструмент, созданный для того, чтобы максимально сократить время разработки. Здесь я даже не говорю о краткости записи, ведь нативный JS не стоит на месте, стандарты ES развиваются и нативный код становится короче. Дело не в этом.

Главное преимущество jQuery – это тысячи готовых плагинов и расширений, которые можно подключить к проекту и настроить всего за несколько минут. Второе важнейшее преимущество — это проверенная, оттестированная, железобетонная кроссбраузерность и поддержка всего, что может отображать веб-страницы с поддержкой JavaScript.

Но, давайте по-порядку рассмотрим все аргументы «за» и «против» использования jQuery, а затем перейдём к примерам проектов, в которых целесообразно использовать эту библиотеку.

Аргументы в пользу jQuery

  1. Кроссбраузерность. jQuery учитывает особенности работы со всеми возможными браузерами (с поддержкой JS, конечно-же), имеет все необходимые фолбеки и запасные варианты реализации. Ваш код будет работать везде. В противовес, НЕ использование jQuery потребует от вас больше временных затрат и усилий для написания и тестирования вашего кода.
  2. Вариативность. Функции jQuery включают огромное количество вариантов и возможностей использования, что делает их максимально универсальными и лаконичными. Использование ванильного JS предполагает написание намного большего количества кода, условий и проверок для реализации аналогичного функционала, даже если речь идёт о какой-то специфической задаче, где не требуется особая универсальность.
  3. Расширения. Тысячи готовых плагинов, расширений, примеров, сниппетов готовы к использованию. Вам не придётся писать свой велосипед для решения типовой задачи. Можно сказать, что это самое важное преимущество jQuery. Писать плагины для jQuery также легко, как писать любой другой код с использованием этой библиотеки. Именно поэтому jQuery так нравится многим веб-разработчикам. Сейчас можно найти абсолютно любой плагин, который поможет быстро решить любую задачу в условиях коммерческого проекта. А в заказной разработке, если вы фрилансер или студия, время — деньги.
  4. Сообщество. Огромное количество уроков, примеров кода, решений на сайтах QA. Можно очень быстро найти решение любой задачи, моментально найти ответ на любой вопрос и продолжить работу.
  5. Краткость записи. Нативный JS, не смотря на своё развитие, пока что не может предложить такие-же возможности краткой записи. jQuery – это простой, лаконичный код, понятный даже начинающим и довольно простой в изучении.
  6. CMS. Практически все популярные CMS, такие, как OpenCart, Joomla, WordPress, используют библиотеку jQuery. Это огромный плюс, ведь возможности этой библиотеки как во фронтенде, так и в бэкенде любой CMS, как правило, реализованы по максимуму и вопроса — подключать jQuery для десяти кастомных строк кода или нет, не стоит. Пользуйтесь в своё удовольствие.

Аргументы против jQuery

  1. Библиотека jQuery загружается в проект как дополнительный ресурс. Можно много спорить относительно того, стоит ли загружать файл, весом 100кб к проекту, чтобы написать всего 5 строчек кода, в то время, когда каждая из картинок на странице весит гораздо больше, а их там, на минуточку, могут быть сотни. Также, следует учитывать и все подключённые плагины, сниппеты и другие ресурсы, использующие jQuery, чтобы понять целесообразность подключения библиотеки.

Зачастую это главный и единственный аргумент против использования jQuery и предмет спора в сообществе. jQuery хоть и крайне маленький ресурс, однако его нерациональное использование может серьёзно пошатнуть психику кодера-перфекциониста.

Само по себе понятие «библиотека» в программировании довольно простое для понимания. В процессе работы с каким-либо языком программирования, разработчики сталкивались с определёнными задачами, однотипными проблемами, решения которых в результате были объединены в библиотеки для удобного повторного использования. Отсюда и возникают все плюсы и минусы использования библиотек. Плюс — проверенный код на любой случай жизни, минус — много того, что не используется здесь и сейчас также подтягивается в проект.

Можно услышать и некоторые другие аргументы против использования jQuery, вроде того, что эта библиотека замедляет работу браузера и работает медленнее нативного кода. Это весьма сомнительные заявления, не подкреплённые никакими фактами, экспериментальными выводами и результатами тестов. Как показывает практика, никакого негативного влияния на скорость работы браузера библиотека не оказывает, а код работает также быстро, как и нативный, ведь он, по-сути и является нативным — все функции jQuery не имеют какой-то космически-сложной структуры, которая хоть как-то влияла бы на скорость исполнения.

Использовать или не использовать jQuery?

В первую очередь, не стоит отказываться от jQuery в заказной или тиражной разработке сайтов. Эти области достаточно хорошо стандартизированы и автоматизированы. Можно получить потрясающий результат, используя популярные фреймворки, вроде Bootstrap и библиотеки, вроде jQuery, совместно с крутыми известными плагинами. Если вы видите в дизайне элементы, блоки или секции, которые проще и быстрее реализовать с использованием jQuery и плагинов, вперёд!

Вообще, jQuery можно использовать практически в любых проектах, если вы уверены, что будет задействована достаточная часть библиотеки и не используется какой-либо JS-фреймворк. Конечно, никто не запретит подключить библиотеку к проекту и написать пресловутые 5 строк кода. Осудить вас может, пожалуй, только вышеупомянутый кодер-перфекционист, если случайно заглянет в ваши исходники. Ему лучше на глаза не попадаться, чтобы не случился очередной приступ паранойи и неконтролируемого гнева. А если серьёзно, то в таких случаях библиотеку можно и не использовать, а посмотреть вариант решения задачи в сниппетах для редакторов кода, которые я подготовил к данному выпуску (см. Полезные ресурсы урока).

Кроме того, не стоит использовать jQuery, если вы планируете делать уникальный сложный проект, который будет бесконечно развиваться. Зачастую, над такими проектами работает большая команда и функционал фронтенда выходит далеко за пределы возможностей библиотеки jQuery.

В настоящее время огромное количество контентных проектов, крупных СМИ, коммерческих сайтов и многих известных ресурсов используют jQuery, так как функционал этой библиотеки достаточен и значительная его часть реализована. Это и есть основные критерии грамотного использования любого ресурса.

Коллекция сниппетов для Visual Studio Code и Sublime Text.

Для того, чтобы облегчить написание нативного JS, если до этого вы использовали только jQuery, я подготовил коллекцию сниппетов для редакторов Visual Studio Code и Sublime Text, основанную на популярных примерах You Don’t Need jQuery (см. Полезные ресурсы урока). Сниппеты устанавливаются и работают с редакторами кода штатным образом. В коде каждого сниппета есть закомментированный пример, написанный с использованием jQuery и его альтернатива в нативном исполнении:

Установка в Sublime Text

Для установки сниппетов в редактор Sublime Text достаточно скачать архив с GitHub и распаковать папку «YDNjQ — Sublime Text Snippets» в директорию «ПОЛЬЗОВАТЕЛЬ\AppData\Roaming\Sublime Text 3\Packages\User», которую можно открыть из редактора: Меню «Preferences > Browse Packages. », затем перейти в папку User:

Установка в Visual Studio Code

Процесс установки сниппетов в кодовый редактор Visual Studio Code не на много сложнее. Скачиваем тот-же самый архив с GitHub и выгружаем содержимое папки «YDNjQ — Visual Studio Code Snippets» в папку «ПОЛЬЗОВАТЕЛЬ\AppData\Roaming\Code\User\snippets». Обратите внимание, что необходимо выгрузить именно содержимое папки «YDNjQ — Visual Studio Code Snippets», то-есть весь список файлов:

После установки сниппеты доступны по ключевым словам jQuery-функций. Например, «hide», «fade», «load» и т. д. Для использования в Sublime Text достаточно набрать нужное сокращение и нажать Tab, или нажав Ctrl+Shift+P, ввести ключевое слово и выбрать нужный сниппет с префиксом YDNjQ. В редакторе Visual Studio Code достаточно нажать F1 > Insert Snippet, ввести ключ сниппета и выбрать нужный.

И в заключение. Хотите использовать jQuery или какую-либо другую библиотеку в вашем проекте — используйте на здоровье. Грамотно и рационально.

Премиум уроки от WebDesign Master

Создание контентного сайта на Jekyll от А до Я

Создание современного интернет-магазина от А до Я

Я — фрилансер! — Руководство успешного фрилансера

Frontend разработчик

На разработку инновационого WEB сервиса требуется разработчик со знанием AngularJS или любого популярного фреймворка.

Задача: сверстать и разработать frontend часть проекта. Дизайна нет, , будет прототип в Axure, поэтому от вас желательно умение создать что-то красивое и приятное для глаза.

Требования к кандидату:

Готовность к длительной работе над проектом ( если у вас нет возможности на протяжении 3-х и более месяцев работать с нами, не тратьте время)
Знание основных структур данных, алгоритмов и паттернов проектирования;
Уверенное знание и опыт разработки на популярных фреймворках Angular либо React.
Опыт работы с нативным JavaScript, понимание событийной модели, тонкости, прототипы, наследование, контексты, замыкания JS, this и т.д (вы должны знать как работает язык, понимать объектную модель JS, а слово «замыкание» не должно ассоциироваться с электрическим током)
Владение jQuery, использование jQ-плагинов, написание своих
Хорошее знание HTML5/CSS3, SASS/SCSS/LESS, опыт использования любого пост/препроцессора
Понимание принципов работы клиент-серверной архитектуры и функционирования сети Интернет и протокола HTTP, умение использовать AJAX, REST API
Опыт работы с библиотеками шаблонизации на стороне клиента.
Понимание модульного подхода к разработке (AMD и RequireJS)
Слежение за актуальными тенденциями клиентских технологий (HTML5, CSS3, ECMA-262, . )
Usability для вас не пустой звук.
Опыт работы с системами контроля версий, предпочтительно Git.
Опыт работы frontend разработчиком от 1 года, желательно больше
Желателен опыт работы frontend-разработчиком в серьезных проектах;
Умение писать автоматические тесты для веб-интерфейсов и не пугаться (как минимум) покрытия JS кода тестами ( unit, TDD, BDD)
Умение комментировать и документировать код
Опыт работы с системами контроля версий, желательно GIT
Ответственность и пунктуальность
Умение работать в команде.
Желательно иметь пример работ на указанных технологиях.

Опыт программирования, понимание ООП, MVC, MVVM в JavaScript и т.п.
Опыт работы с PHP(Yii/Yii2), либо другими back-end фрэймворками
Комфортен с gulp/grunt, bower и прочими упрощающими жизнь инструментами
Знакомство с системами управления проектами
Умение писать хорошую техническую документацию
Если есть опыт работы в крупных проектах – замечательно
Есть наличие портфолио – еще лучше.
Наличие GitHub аккаунта с примерами кода
Профиль на Habrahabr, LinkedIn, и т.п

Работать будем по Scrum. При положительном опыте сотрудничества возможна дальнейшая работа по поддержке проекта и работа над последующими его версиями с возможностью трудоустройства.

Указывать в заявках:

1) Опыт работы c JavaScript и указанными фреймворками
2) Портфолио (если есть), отзывы (если есть, на других биржах тоже). Особенно интересуют проекты с использованием Angular и ReactJs, сложные проекты
3) Стоимость ваших услуг за день или месяц работы
4) Другие языки и технологии, которыми вы владеете (если нет в профиле)

Frontender Magazine

На днях я подготовила README для одного проекта, который, надеюсь, будет интересен и поучителен для других разработчиков. Так вот, когда я его писала, я поняла, что несколько лет назад испугалась бы до смерти, если бы наткнулась на нечто подобное, со всякими упоминаниями о Node и его пакетном менеджере, системах Homebrew и Git, всевозможных тестах, тестовых и финальных сборках.

Когда-то основная часть рабочего процесса фронтенд-разработчика состояла в редактировании файлов, их локальном тестировании (в меру возможностей) и пересылке на сервер через FTP. Мы измеряли свою крутость умением подчинить своей воле IE6 или добиться пиксельного соответствия в различных браузерах. Многим членам нашего сообщества — и мне тоже — не хватало опыта традиционного программирования. HTML, CSS и JavaScript — обычно в виде jQuery — осваивались самостоятельно.

За последние несколько лет кое-что изменилось. Возможно, причиной этому стало то, что люди начали воспринимать фронтенд-разработку серьезно; может быть, то, что разработчики браузеров в большинстве своем наконец-то навели порядок в своих творениях; а, может, просто фронтенд-разработчики, опять же, включая меня, в конце концов постигли суть процесса разработки ПО.


Что бы там ни было, думаю, мы стали свидетелями смещения акцента с ценности различных мелочей на ценность инструментов. Теперь, чтобы быть успешным фронтенд-разработчиком, нужно обладать набором базовых навыков, а те разработчики, которые не соответствуют этим требованиям, скоро начнут всё сильнее чувствовать насколько сильно они отстали, по мере того как источники информации начинают подразумевать наличие некоторых знаний как само собой разумеющееся.

Вот некоторые вещи, с которыми хотелось бы, чтобы все были знакомы и некоторые источники, которые можно использовать, чтобы подтянуть свои навыки. (Спасибо Полу Айришу (Paul Irish), Майку Тейлору (Mike Taylor), Ангусу Кролу (Angus Croll) и Владу Филипову (Vlad Filippov) за их вклад.)

JavaScript

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

Мастер Йода рекомендует:  MySQL против PostgreSQL

Это значит, что вы прочитали «JavaScript: Сильные стороны», желательно больше одного раза. Что вы понимаете принцип работы структур данных вроде объектов и массивов; функции, в том числе как и почему их нужно вызывать и применять; умеете работать с наследованием через прототипы; и можете справиться с асинхронностью.

Если ваши навыки работы с простым JavaScript оставляют желать лучшего, вот некоторые ресурсы, которые вас выручат:

  • «Красноречивый JavaScript»: Замечательная книга (также доступна печатная версия), посвящённая основам JavaScript
  • Тестовая оценка владения JS: подборка тестов с ошибками на различные темы по JavaScript; сможете ли вы переписать код тестов так, чтобы он заработал?
  • 10 вещей, которым я научился из исходного кода jQuery — старенькая, но мощная вещь от Пола Айриша, демонстрирующая чему можно научиться, читая чужой код.

Система управления версиями файлов Git (и профиль на GitHub)

Если вас нет на GitHub, в общем и целом вы не можете участвовать в жизни крупного сообщества с открытым исходным кодом, которое выросло вокруг технологий фронтенд разработки. Клонирование репозитория с целью испробовать его возможности должно стать для вас привычным делом и вы должны понимать как использовать ветки в совместных проектах.

Хотите повысить свои навыки работы с Git?

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

Те дни, когда управление зависимостями сводилось к добавлению дополнительного скрипта или тега стилей на страницу, давно прошли. Даже если у вас не было возможности внедрить замечательные инструменты вроде RequireJS в процесс разработки на работе, вам стоит найти время изучить их в своем личном проекте или проекте вроде Backbone Boilerplate, так как преимущества, которые они в себе несут, трудно переоценить. RequireJS, в частности, делает возможной разработку с использованием небольших модульных файлов JS и CSS, а затем конкатенирует и минифицирует их с помощью своего инструмента оптимизации для дальнейшего использования.

Скептически настроены относительно разработки на основе модулей? Это не причина ничего не делать. По крайней мере, вам должны быть знакомы инструменты вроде UglifyJS или Closure Compiler, которые грамотно сжимают ваш код, а затем конкатенируют эти сжатые файлы перед выдачей результата.

Если вы пишете на чистом CSS — то есть не используете препроцессор вроде Sass или Stylus – RequireJS также поможет организовать ваши CSS файлы по модульному принципу. Используйте операторы @import в основном файле, чтобы загрузить зависимости для разработки и затем запустите средство оптимизации RequireJS для основного файла чтобы создать готовый для использования файл.

Инструменты разработчика, встроенные в браузер

За последние несколько лет инструменты для разработчиков, встроенные в браузеры, ощутимо усовершенствовались и теперь они могут существенно улучшить ваш опыт разработки, если вы научитесь ими правильно пользоваться. (Подсказка: если вы все еще отлаживаете код, используя alert , вы зря убиваете время.)

Вам наверняка стоит выбрать один браузер, чьи инструменты разработчика вы будете использовать на постоянной основе — на данный момент я склоняюсь к инструментам разработчика в Google Chrome — но не отказывайтесь полностью от инструментов в других браузерах, так как в них время от времени на основе откликов разработчиков добавляются новые полезные возможности. В Dragonfly от Opera, в частности, были добавлены некоторые возможности, выделяющие её инструменты разработчика на фоне других, например: (экспериментальный) CSS- профилировщик, настраиваемые горячие клавиши, удалённая отладка без необходимости USB-подключения, а также возможность сохранять и использовать пользовательские цветовые палитры.

Если вы не очень хорошо разбираетесь в браузерных инструментах разработчика, презентация «Чиним код jQuery» послужит отличным (и не слишком сфокусированным на jQuery) обзором отладки, который включает в себя описание процесса пошаговой отладки — того, что изменит вашу жизнь, если вы с этой презентацией ещё не знакомы.

Командная строка

Если говорить о командной строке, её уверенное использование уже является обязательным — вы непозволительно много упускаете, если не готовы тут же зайти в окно терминала и погрузиться в работу. Я не говорю, что вам следует делать всё через терминал — можете продолжать пользоваться графическим интерфейсом Git, хотя думаю, в конце концов, вам же будет лучше, если вы от него откажетесь — однако, несомненно, окно терминала должно быть постоянно открыто для проекта, над которым вы работаете. Есть несколько задач, которые вы должны выполнять через командную строку не задумываясь:

  • ssh для подключения к другой машине или серверу
  • scp для копирования файлов на другую машину или сервер
  • ack или grep для поиска файлов в проекте по строке или шаблону
  • find для обнаружения файлов, чьи названия совпадают с данным шаблоном
  • git для выполнения хотя бы базовых действий вроде add , commit , status и pull
  • brew для использования Homebrew для установки пакетов
  • npm для установки пакетов Node
  • gem для установки пакетов Ruby

Если какими-то командами вы пользуетесь особенно часто, отредактируйте свой .bashrc , .profile или .zshrc (или что у вас там) и создайте для них альтернативные имена чтобы не набирать команды руками каждый раз. Также можно добавить альтернативные имена в файл

/.gitconfig . Файлы с точками от Джанни Чиаппетта (Gianni Chiappetta) могут послужить отличным источником вдохновения.

Примечание: Если вы пользуетесь Windows, я не знаю, как вам помочь, разве что могу посоветовать Cygwin. Возможно, я не права, но принимать участие в жизни сообщества фронтенд-разработчиков с открытым кодом на машине с Windows существенно сложнее. Если посмотреть на вещи оптимистически, ноутбуки MacBook Air не очень дорогие, мощные и на удивление портативные, кроме того существуют Ubuntu или Unix.

Шаблонизация на стороне клиента

Не так давно для серверов было обычным делом отвечать на запрос XHR фрагментом HTML-кода, однако за последние 12-18 месяцев сообщество фронтенд разработчиков прозрело и начало требовать данных от сервера в чистом виде. Преобразование таких данных в HTML, который затем можно добавить в дерево документа, может оказаться трудоёмким и неудобным процессом, если иметь дело непосредственно с кодом. Вот когда в дело вступают библиотеки шаблонизации на стороне клиента: они позволяют использовать шаблоны, которые после добавления данных превращаются в строку HTML. Вам нужна помощь в подборе инструмента для шаблонизации? Схема для выбора шаблона от Герен Минс (Garann Means) поможет вам найти подходящий.

CSS-препроцессоры

На днях Пол Айриш отметил, что мы стали свидетелями того, что фронтенд- разработчики пишут код, сильно отличающийся от того, который в результате оказывается в готовой сборке и ярким примером тому является код, написанный с помощью CSS-препроцессоров. Всё еще есть крикливая компания, которая считает, что только чистый CSS имеет право на жизнь, но они начинают менять мнение. Эти инструменты дают нам возможности, которые, по мнению некоторых, уже должны были быть добавлены в CSS — переменные, математические выражения, логику, миксины, а также они могут помочь справиться с префиксами свойств.

Тестирование

Одна из радостей написания модульного, свободно сопряжённого кода состоит в том, что такой код намного легче тестировать, а с инструментами вроде Grunt, подготовка проекта со встроенными тестами вообще стала проще простого. В Grunt интегрирован QUnit, однако существует много фреймворков для тестирования, из которых вы можете выбрать те, что вам по душе — моими любимыми на данный момент являются Jasmine и Mocha — в зависимости от стиля, который вы предпочитаете, и остальных составляющих вашей подборки.

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

  • Короткий скринкаст, записанный мной о тестировании jQuery-кода с помощью Jasmine.
  • Пример модульного тестирования на плагине jQuery BBQ.

Автоматизация процессов (rake/make/grunt/и т.д.)

Возможность с помощью Grunt настроить проект со встроенной поддержкой модульного тестирования — это один из примеров автоматизации процессов. Реальность фронтенд-разработки такова, что нам приходится выполнять множество повторяющихся действий, но, как однажды сказал мне друг: хороший разработчик — ленивый разработчик. Советую придерживаться золотого правила: если вы выполняете какое-либо действие больше трёх раз, пора его автоматизировать.

Уже довольно давно нам в этом помогают инструменты вроде make , кроме него существуют также rake , grunt и другие. Если вы хотите автоматизировать выполнение заданий связанных с файловыми системами, исключительно полезно будет изучить язык, отличный от JavaScript, так как асинхронная природа Node может стать неподъемным грузом, если вы умеете только управлять файлами. Существует также множество других инструментов автоматизации, созданных под конкретные задачи: инструменты для развёртывания, генерирования сборки, проверки качества кода, и др.

Качество кода

Если вам когда-либо приходилось ощущать негативные последствия от пропущенной точки с запятой или лишней запятой, вы знаете сколько времени можно потерять из-за мелких ошибок в коде. Поэтому вы пропускаете свой код через инструмент вроде JSHint, верно? Он поддаётся настройке и может быть интегрирован в ваш редактор или процесс сборки несколькими способами.

Хорошее руководство

К сожалению, руководства по фронтенд-разработке не существует, однако ресурс MDN вполне подходит на эту роль. Хорошие фронтенд разработчики знают, что в каждый поисковый запрос нужно добавлять префикс mdn — например, mdn массивы javascript — чтобы избежать коммерческой чумы, которой является ресурс w3schools.

Конец

Как всегда, просто почитав обо всех этих инструментах, вы не научитесь ими пользоваться на уровне эксперта или хотя бы любителя, единственный верный способ научиться что-то делать — начать пробовать это делать. Удачи вам.

Статья переведена благодаря спонсорской поддержке компании «Одноклассники».

The GitHub Blog

September 6, 2020

Removing jQuery from GitHub.com frontend

We have recently completed a milestone where we were able to drop jQuery as a dependency of the frontend code for GitHub.com. This marks the end of a gradual, years-long transition of increasingly decoupling from jQuery until we were able to completely remove the library. In this post, we will explain a bit of history of how we started depending on jQuery in the first place, how we realized when it was no longer needed, and point out that—instead of replacing it with another library or framework—we were able to achieve everything that we needed using standard browser APIs.

Why jQuery made sense early on

GitHub.com pulled in jQuery 1.2.1 as a dependency in late 2007. For a bit of context, that was a year before Google released the first version of their Chrome browser. There was no standard way to query DOM elements by a CSS selector, no standard way to animate visual styles of an element, and the XMLHttpRequest interface pioneered by Internet Explorer was, like many other APIs, inconsistent between browsers.

jQuery made it simple to manipulate the DOM, define animations, and make “AJAX” requests— basically, it enabled web developers to create more modern, dynamic experiences that stood out from the rest. Most importantly of all, the JavaScript features built in one browser with jQuery would generally work in other browsers, too. In those early days of GitHub when most of its features were still getting fleshed out, this allowed the small development team to prototype rapidly and get new features out the door without having to adjust code specifically for each web browser.

The simple interface of jQuery also served as a blueprint to craft extension libraries that would later serve as building blocks for the rest of GitHub.com frontend: pjax and facebox.

We will always be thankful to John Resig and the jQuery contributors for creating and maintaining such a useful and, for the time, essential library.

Web standards in the later years

Over the years, GitHub grew into a company with hundreds of engineers and a dedicated team gradually formed to take responsibility for the size and quality of JavaScript code that we serve to web browsers. One of the things that we’re constantly on the lookout for is technical debt, and sometimes technical debt grows around dependenices that once provided value, but whose value dropped over time.

When it came to jQuery, we compared it against the rapid evolution of supported web standard in modern browsers and realized:

  • The $(selector) pattern can easily be replaced with querySelectorAll() ;
  • CSS classname switching can now be achieved using Element.classList;
  • CSS now supports defining visual animations in stylesheets rather than in JavaScript;
  • $.ajax requests can be performed using the Fetch Standard;
  • The addEventListener() interface is stable enough for cross-platform use;
  • We could easily encapsulate the event delegation pattern with a lightweight library;
  • Some syntactic sugar that jQuery provides has become reduntant with the evolution of JavaScript language.

Furthermore, the chaining syntax didn’t satisfy how we wanted to write code going forward. For example:

This syntax is simple to write, but to our standards, doesn’t communicate intent really well. Did the author expect one or more js-widget elements on this page? Also, if we update our page markup and accidentally leave out the js-widget classname, will an exception in the browser inform us that something went wrong? By default, jQuery silently skips the whole expresion when nothing matched the initial selector; but to us, such behavior was a bug rather than a feature.

Finally, we wanted to start annotating types with Flow to perform static type checking at build time, and we concluded that the chaining syntax doesn’t lend itself well to static analysis, since almost every result of a jQuery method call is of the same type. We chose Flow over alternatives because, at the time, features such as @flow weak mode allowed us to progressively and efficiently start applying types to a codebase which was largely untyped.

All in all, decoupling from jQuery would mean that we could rely on web standards more, have MDN web docs be de-facto default documentation for our frontend developers, maintain more resilient code in the future, and eventually drop a 30 kB dependency from our packaged bundles, speeding up page load times and JavaScript execution times.

Incremental decoupling

Even with an end goal in sight, we knew that it wouldn’t be feasible to just allocate all resources we had to rewriting everything from jQuery to vanilla JS. If anything, such a rushed endeavor would likely lead to many regressions in site functionality that we would later have to weed out. Instead, we:

  • Set up metrics that tracked ratio of jQuery calls used per overall line of code and monitored that graph over time to make sure that it’s either staying constant or going down, not up.
  • We discouraged importing jQuery in any new code. To facilitate that using automation, we created eslint-plugin-jquery which would fail CI checks if anyone tried to use jQuery features, for example $.ajax .
  • There were now plenty of violations of eslint rules in old code, all of which we’ve annotated with specific eslint-disable rules in code comments. To the reader of that code, those comments would serve as a clear signal that this code doesn’t represent our current coding practices.
  • We created a pull request bot that would leave a review comment on a pull request pinging our team whenever somebody tried to add a new eslint-disable rule. This way we would get involved in code review early and suggest alternatives.
  • A lot of old code had explicit coupling to external interfaces of pjax and facebox jQuery plugins, so we’ve kept their interfaces relatively the same while we’ve internally replaced their implementation with vanilla JS. Having static type checking helped us have greater confidence around those refactorings.
  • Plenty of old code interfaced with rails-behaviors, our adapter for the Ruby on Rails approach to “unobtrusive” JS, in a way that they would attach an AJAX lifecycle handler to certain forms:

Instead of having to rewrite all of those call sites at once to the new approach, we’ve opted to trigger fake ajax* lifecycle events and keep these forms submitting their contents asynchronously as before; only this time fetch() was used internally.

  • We maintained a custom build of jQuery and whenever we’ve identified that we’re not using a certain module of jQuery anymore, we would remove it from the custom build and ship a slimmer version. For instance, after we have removed the final usage of jQuery-specific CSS pseudo-selectors such as :visible or :checkbox , we were able to remove the Sizzle module; and when the last $.ajax call was replaced with fetch() , we were able to remove the AJAX module. This served a dual purpose: speeding up JavaScript execution times while at the same time ensuring that no new code is created that would try using the removed functionality.
  • We kept dropping support for old Internet Explorer versions as soon as it would be feasible to, as informed by our site analytics. Whenever use of a certain IE version dropped below a certain threshold, we would stop serving JavaScript to it and focus on testing against and supporting more modern browsers. Dropping support for IE 8–9 early on allowed us to adopt many native browser features that would otherwise be hard to polyfill.
  • As part of our refined approach to building frontend features on GitHub.com, we focused on getting away with regular HTML foundation as much as we could, and only adding JavaScript behaviors as progressive enhancement. As a result, even those web forms and other UI elements that were enhanced using JS would usually also work with JavaScript disabled in the browser. In some cases, we were able to delete certain legacy behaviors altogether instead of having to rewrite them in vanilla JS.
  • With these and similar efforts combined over the years, we were able gradually reduce our dependence on jQuery until there was not a single line of code referencing it anymore.

    Custom Elements


    One technology that has been making waves in the recent years is Custom Elements: a component library native to the browser, which means that there are no additional bytes of a framework for the user to download, parse and compile.

    We had created a few Custom Elements based on the v0 specification since 2014. However, as standards were still in flux back then, we did not invest as much. It was not until 2020 when the Web Components v1 spec was released and implemented in both Chrome and Safari that we began to adopt Custom Elements on a wider scale.

    During the jQuery migration, we looked for patterns that would be suitable for extraction as custom elements. For example, we converted our facebox usage for displaying modal dialogs to the element.

    Our general philosophy of striving for progressive enhancement extends to custom elements as well. This means that we keep as much of the content in markup as possible and only add behaviors on top of that. For example, shows the raw timestamp by default and gets upgraded to translate the time to the local timezone, while , when nested in the element, is interactive even without JavaScript, but gets upgraded with accessibility enhancements.

    Here is an example of how a custom element could be implemented:

    One aspect of Web Components that we’re looking forward to adopting is Shadow DOM. The powerful nature of Shadow DOM has the potential to unlock a lot of possibilities for the web, but that also makes it harder to polyfill. Because polyfilling it today incurs a performance penalty even for code that manipulates parts of the DOM unrelated to web components, it is unfeasible for us to start using it in production.

    Как отказаться от jQuery в современном фронтенде: опыт команды GitHub

    Нет. Не весело. И не легко. Но важен подход, от которого будет зависеть степень сложности.

    Цель — Senior Frontend Developer.

    Работа (настоящее время): Junior Frontend Developer (контракт на 3 месяца).

    Я не витал в облаках, когда решил стать веб-разработчиком. Я понимал, что там, где большие деньги — большая ответственность. Какой дурак будет платить хорошие деньги за простую и легкую работу? Но понимать — это одно, а вот испытать всё это на своей шкуре — это другое.

    Я продолжаю работать над старым проектом и еще как минимум месяц буду им заниматься. Много ли я сделал за последний месяц? Нет, не много. Много ли я понял — думаю да. Есть чем поделиться.

    Программирование — сложная сфера, даже не побоюсь сказать, что очень сложная. Но к любому делу нужен правильный подход. Так уж вышло, что я стал именно тем человеком, которого слишком рано подвели к большому и сложному проекту(на мой необъективный взгляд). Это выглядит вот как: 3 месяца я учился работать технически сложноустроенной лопатой с кучей характеристик и кнопок. Еще не успел до конца не разобраться как следует с этой штукой, как меня подвели к землеройному комплексу из разных крутых и современных технических средств, и сказали — ты тут рулишь всей этой темой. И твоя задача разобраться как оно всё работает, как все устройства взаимосвязаны друг с другом и рыть туннель через вон ту скалу. Дерзай.

    И это не весело. Абсолютно.

    За последний месяц меня много раз настигало разочарование в себе. Куча мыслей, которые накручивались одна за другой после очередного поражения. А может быть я вообще не создан для этого дела? Наверное я не смогу с этим справиться, наверное это не мое. Вон ребята на ютубе так просто всё делают, у них всё получается, я делаю также — у меня нихера не получается. ОМГ?

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

    После этого я возвращаюсь к основам и начинаю изучать основы «Азбуки».

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

    Из этого кстати и вытекает нобходимость поиска такой работы, где тебя будут вводить в курс дела постепенно, шаг за шагом усложняя и доверяя тебе всё сложнее и сложнее задачи. Особенно это касается таких же вайтишников как и я. Если работодателю нужен уже готовый специалист, и он не готов тебя водить некоторое время за руку, то лучше не иди туда. Получишь гору неудач и в итоге можешь вообще перегореть и бросить всё это дело.

    Наверное, я не открыл истину, эти вещи простые и понятные всем, но иногда они забываются.

    Что касается моей продуктивности, то как следствие вышестоящего текста, она была маленькая по самому проекту, но неплохая с точки зрения осваивания основ программирования:

    1. Познакомился с регулярными выражениями. Сначала начал читать крутую книгу Джеффри Фридл «Регулярные выражения», а потом нашел раздел вот здесь. Этого мне хватило за глаза.

    2. На 70% прошел курс Дмитрия Лаврика по Vue JS. Очень крутой, рекомендую.

    3. Разобрался на базовом уровне с Vuex. Пользуюсь кстати Vue CLI. Кто писал мне про него — да, спасибо, это спасение 🙂

    4. Углубил основы JS по всем известному учебнику.

    5. Прошел несколько уроков по старому курсу JS. Всё никак не могу его закончить.

    6. Прошел курс по алгоритмам и структурам данных. Правда объясняется на языке Паскаль. Но тем не менее, интересно.

    7. Английский. Продолжаю проходить курс Elementary. Английский подтянул очень хорошо. Если раньше у меня был уровень Elementary, то теперь у меня уже твердый Elementary.

    8. Начал писать тексты на английском языке. Раз в 2-3 дня сажусь за текстовый документ, открываю рандомайзер слов на английском. Попадается слово(как правило несколько слов) — вокруг них начинаю строить предложения на английском, объяснять их на английском, импровизировать. Задача написать связный текст на 1 страницу вордовского документа, 13 кегль.

    По методу Пимпслера прошел 30 уроков и завязал с ним. Скучный он для меня.

    По рабочему проекту:

    1. Сверстал и внедрил фоторедактор на Vue, за основу взял вот этот готовый компонент. Не все функции еще работают, так как нужен бэк, которого нет, но фронт частично готов.

    2. Научился немного работать с VK Api. Пока слабовато, но кое что удалось написать.

    3. С Api Instagram так и не разобрался, темный лес для меня.

    Такие у меня дела. Как у вас? Есть успехи у того, кто тоже недавно начал похожий путь? Поделитесь — будет очень интересно почитать!

    Через месяц я заканчиваю работу над этим проектом и буду искать пристанище в продуктовой(желательно, но необязательно) компании в г. Санкт-Петербург.

    Если есть вакансии в ваших компаниях(обращаюсь к программистам, тим лидам и проджектам) — буду благодарен за наводку.

    Начну ходить на собеседования уже через неделю.

    Всем успехов, не унывайте и держите хвост трубой!

    А я пойду дальше копаться в своем проекте 🙂

    От новичка в JS до трудоустройства за полгода. День 46

    Всем привет! Извините, отчетов не было достаточно долго. Был крайне тяжелый месяц.

    1. Практически закончил с основами из JS Learn. Скоро буду начинать ES6.
    2. Калькулятор так же практически закончен. Осталось допилить работу с плавающей точкой и еще несколько мелочей.
    3. Судя по тестам, уровень английского уже Intermediate (B1), за пол года изучения:)
    4. Окончательно перешел на Ubuntu 18.04. Очень доволен!
    5. Начал помогать изучать английский другу. Крайне интересный опыт..

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

    По итогам месяца пришел к выводу, что в сравнении с временами когда я работал обычный 8 часовой рабочий день времени стало ещё меньше, нагрузка примерно такая же (но интересно).

    Всем большое спасибо за, то что помогали все это время советами и критикой. Постараюсь больше так на долго не пропадать.

    HomeCredit Bank или как провести три часа жизни впустую

    Доброго времени суток, друзья.
    Учусь на IT специальности, одного очень необычного ВУЗа Воронежа. Предметная область настолько широка, что рано или поздно приходится выбирать более узкое направление и прогрессировать в чем то одном. Мой выбор пал на веб-разработку, а в частности, для начала, решил освоить все прелести, тонкости, заковырочки FrontEnd’а
    Тут, как и во многом в этой жизни главное — начать, ну а дальше все зависит от твоего умения сидеть на причинном месте как можно дольше, изучая и впитывая информацию. Начал я с поиска ресурсов и всевозможных учебных программ, что в итоге привело меня на вебинар от Skillbox.
    Там я вдохновился и замотивировался по самые гланды. Решив, что нужно как то систематизировать обучение, оставил заявку на покупку курса за авторством этих ребят, как говорится: «. и тут Остапа понесло». Со мной связались, ответили на мои вопросы и предложили рассрочку у их банк-партнёра HomeCredit.
    —Отлично! Подумал я, оформят, одобрят, да ещё и договор на дом курьером привезут, сиди на диване, предвкушай первые уроки, казалось бы. Но не тут то было. Нет, все конечно одобрили и оформили прямо по телефону, но
    —«курьеров в вашем городе нет», проворковал мне милый женский голос,
    —«езжай ка ты, друг в другой конец города в отделение банка, где сидит ЕДИНСТВЕННЫЙ, кто сможет тебе помочь»
    , эдакий бог рассрочки. Ну ок, подумал я, выбрал день и поехал. На автобусе. 10 километров. 47 остановок. (Москвичи, спрячте свои помидоры, я просто не люблю Воронежские автобусы) Прелесть, сами понимаете. Приехал на место и нашел нужный адрес — огрооомный хозяйственный/мебельный/продуктовый/чеготамтольконет ангар. Хотя стоп, насчёт чеготамтольконет я погорячился. Ведь, как вы уже догадались, нет там ЕГО — нужного, мать его, мне отделения банка. Оперативно-разыскные мероприятия ака звонок на горячую линию дали следующие плоды:
    1. Бывает, что базы данных сбоят, в связи с чем милые дамы из колцентра посылают тебя туда, где хоум кредитом и не пахнет.
    2. Колцентр-дамы очень плохие актрисы.
    3. И да-да, пошёл я нахер.
    Заявку по итогу аннулировали, компенсировать никто никому ничего не будет, а на разбирательства просто нет времени, да и желания. Спасибо за терпение, не думаю, что кто то до сих пор дочитал, а кто дочитал — мораль истории такова:
    В Воронеж требуются курьеры HomeCredit.

    Frontend по-новому: новая подборка лучших опенсорсных либ

    Содержание статьи

    ExpandJS

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

    Вернемся к ExpandJS. Это большой проект, который содержит в себе более 80 подобных элементов и свыше 350 JavaScript-функций для работы с ними. Плюс ко всему все они оформлены в стиле популярного Material Design, хотя также существуют как абстрактные объекты.

    Пример разметки в соответствии с типом устройства:

    Пример разметки страницы с выпадающим сайдбаром:

    Electron

    В прошлых выпусках мы писали про NativeScript и React Native для разработки аппов для мобильных операционных систем средствами на веб-технологиях. Сегодня речь пойдет об Electron, который позволяет писать кросс-платформенные десктопные приложения также с помощью HTML, CSS и JavaScript. Electron, ранее известный как Atom Shell, разработан командой GitHub. Проект автоматически обновляется, сообщает об ошибках, обеспечивает набор инструментов для дебаггинга и профилирования, предоставляет доступ к нативным меню операционных систем и центру уведомлений. В его основе лежит io.js и движок Chromium. Помимо того, что на нем написан гитхабовский редактор Atom, проект активно используется такими компаниями, как Docker, Slack, Facebook, Microsoft. Кстати, о последней: для Electron есть и Windows-инсталлер.

    Globalize

    Функциональная библиотека, предназначенная для интернационализации и локализации проектов для Node.js и браузеров. Globalize удобным способом позволяет форматировать и парсить дату, валюты и непосредственно сам контент. Все данные предоставляются в формате Unicode CLDR JSON, а код содержится отдельно от i18n.

    Ramjet

    Потрясающий скрипт, который производит плавную трансформацию элементов из одного состояния в другое. Причем это не только для SVG, но еще изображения и DOM-узлы со всеми дочерними элементами. Ramjet содержит коллекцию easing-функций и максимально прост в использовании:

    Vault

    Секьюрное хранилище твоих данных, написанное на Go. Vault защищает и хранит токены, пароли, сертификаты, API и другие секреты и управляет всем этим. Проект предоставляет унифицированный API для доступа к серверной части: HSMs, AWS IAM, SQL и другие. Хочу обратить твое внимание на то, что, помимо подробнейшей документации, разработчики создали краткий интерактивный курс, обучающий работе с Vault.

    Clusterize.js

    Продолжение доступно только участникам

    Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

    Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

    Как организовать сотрудничество на GitHub

    Если вы еще не в курсе, GitHub это очень эффективный способ организации совместной работы над проектами.

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

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

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

    Начните с малого

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


    Не бойтесь начать с малого : вместо того, чтобы пытаться исправить большие ошибки ( баги ) или переписать целый модуль, попробуйте найти недостатки в документации или ошибки кроссплатформенности, или даже простые синтаксические и грамматические ошибки ( пример на GitHub от пользователя mzgol).

    Выполнение таких задач это отличный способ сделать первые шаги в качестве того, кто приложил руку к развитию какого-либо проекта, и при этом не брать на себя непосильные задачи. Зарегистрируйтесь на ресурсе CodeTriage , чтобы автоматически получать GitHub Issues в свой почтовый ящик.

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

    Изучите экосистему проекта

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

    Например, GitHub стандартизовал файл CONTRIBUTING.md (ознакомьтесь для примера с этим документом ). Подобные инструкции поддерживаются людьми, которые обслуживают базы кодов.

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

    Теперь, когда вы являетесь частью экосистемы проекта, как же вам все-таки внести изменения?

    Использование Pull-Request для внесения изменений

    Рабочая среда для внесения изменений в код, сначала может показаться сложной .

    Первое, что следует уяснить, это важность следования стандартам и соглашениям, принятым в проекте, над которым вы работаете (что уже обсуждалось выше). Стандартная рабочая среда на GitHub достаточно проста и позволяет:

    • Ответвлять выбранный репозиторий в ваш аккаунт;
    • Копировать репозиторий на локальную машину;
    • Выбирать ветку ( topic branch ) и вносить в неё изменения;
    • Переносить изменения из других веток в свою;
    • Использовать различные инструменты GitHub, чтобы создавать pull request’ы через обсуждения;
    • Применять полученные изменения;
    • Pull request сливается с проектом (как правило с основной веткой – master branch ), а topic branch удаляется из репозитария.

    Внутри рабочей среды, вы можете увидеть множество отличий между разными проектами. Например, различия в соглашениях о названии тем. Некоторые проекты могут использовать соглашения типа bug_345 , где 345 это идентификатор (ID #) GitHub issue .

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

    Шаг 1: Ответвление (Forking)

    Ответвление репозитария на GitHub.com

    Шаг 2: Клонирование

    Клонировать репозитарий можно, используя URL-адрес, показанный на сайдбаре справа:

    Шаг 3: Добавление Upstream Remote

    Внесите изменения в клонированную директорию и тогда вы сможете добавить upstream remote , то есть указать удаленный репозиторий, с которым будет происходить слияние локальных правок:

    Теперь вы сможете вносить изменения локально и синхронизировать их с удаленным репозиторием:

    Шаг 4: Выбор ветки (Topic Branch)

    Перед внесением изменений, выберите ветку:

    Шаг 5: Создание правок

    Теперь, вы можете внести изменения и создать коммит, который будет отслеживать только эти изменения:

    Шаг 6: Внесение правок

    Далее, необходимо внести изменения, сделанные в ветке вашего проекта:

    Шаг 7: Создание Pull Request’а

    Наконец, вы можете создать pull request . Для этого, перейдите в вашу ветку репозитария. Там вы увидите надпись « Недавно измененные вами ветки » ( your recently pushed branches ), и если это так, можно выбрать « Сравнить и сделать Pull Request » ( Compare and Pull Request ).

    В противном случае, вы можете выбрать вашу ветку из выпадающего списка и нажать « Pull Request » или « Compare » в верхней правой части секции репозитария.

    Создание pull request через кнопку « Compare and Pull Request ».

    Создание pull request посредством выпадающего списка веток

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

    Если у кого-то имеются вопросы, они могут задать их в комментариях, а также попросить вас очистить и послать ваш pull request заново, или удалить его.

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

    Как написал работник Github Зак Холман ( Zach Holman ) в документе « How GitHub Uses GitHub to Build GitHub », pull request это обсуждение. Именно в таком ключе они и должны восприниматься; вместо ожидания мгновенного принятия вашей правки, следует ждать её обсуждения.

    GitHub Issues + Pull Requests = Дзен управления проектом

    На GitHub имеется инструмент GitHub Issues, который предоставляет надежный способ создания хорошо документированных, интерактивных, автоматизированных обсуждений багов и функций любого проекта. Issues по умолчанию включен, но его можно отключить.

    У Issues много отличных встроенных возможностей, но одна из наиболее важных, это интеграция с pull request’ами . Пользователь может сослаться на issue в своем коммите, просто добавив туда его цифровой ID.

    Этот коммит автоматически пометит issue №3 как закрытый, когда соответствующий pull request будет принят. Данный способ автоматизации делает GitHub прекрасным инструментом для управления процессом разработки.

    Поиск других способов взаимодействия

    Зачастую, большие open-source проекты имеют преимущество при совместной работе над ними нескольких людей.

    Не заблуждайтесь думая, что единственным способом внести вклад в проект является использование pull request’ов .

    Например, такой проект, как Ruby on Rails , был известен своим сообществом; оно отвечало на вопросы на форумах и IRC-чатах, чтобы помочь повысить осведомленность об этом фреймворке, а также помочь направить его развитие путем обсуждения идей и найденных ошибок.

    Такие способы взаимодействия обычно представлены форумами и чатами. Но не только: это могут быть почтовые рассылки, аудио- и видеоконференции, которые могут помочь определить направление развития проекта и создать живое, продуктивное сообщество вокруг проекта. Без такого сообщества, pull request’ы не эффективны.

    Все зависит от отношения

    Запомните, что проекты с открытым кодом возглавляются людьми, для которых преумножение и распространение знаний является самым важным. Участие в таких проектах будет более эффективным, если вы будете иметь правильное отношение, смысл которого заключен в следующем вопросе: « Чем я могу помочь? », который отличается от отношения « Помогу, чем смогу ».

    Люди в мире открытого исходного кода, хотят работать с теми, кто движим желанием помочь другим.

    Заключение

    Если вы заинтересовались разработкой open-source проектов, то это прекрасно! Если вы решились принять участие в одном из них, то не забудьте о правильном отношении и принципе « начни с малого ». Это приблизит вас к моменту, когда вы увидите свое имя в только что присоединенном к проекту pull request’е .

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

    Потенциал GitHub и мир open-source продолжают свой рост каждый день; начните сотрудничать с другими разработчиками и станьте частью этого мира!

    Данная публикация представляет собой перевод статьи « How to Collaborate On GitHub » , подготовленной дружной командой проекта Интернет-технологии.ру

    Клиентская оптимизация: 10+ способов ускорить фронтенд

    В наше время фронтенд-разработчику недостаточно уметь верстать и писать javascript-код. Проекты растут, увеличивается их объем и сложность. Важной частью становится умение оптимизировать работу сайта, делать его быстрее и легче.

    В этой статье я расскажу про 10+ способов оптимизировать веб-приложение с точки зрения фронтенд-разработчика. Также предложу Вам инструменты, которые помогут делать это веселее и приятнее.

    Если говорить в общем, то вся оптимизация фронтенда сводится к двум типам задач. Первая — это ускорение передачи данных по сети. Состоит из двух подпунктов: уменьшение количества запросов к серверу и уменьшение объема передаваемых данных. И второе — ускорение работы приложения в браузере. А теперь подробнее.

    1. Склеивайте js-скрипты и css-стили

    Делайте как можно меньше запросов к серверу. js и css-код прекрасно подходят для этой задачи. Забудьте о приемах десятилетней давности, когда на сайте лежало два десятка js-файлов, и на каждой странице подгружались 5-6 из них. В идеале у Вас должен быть один js-файл и 1 css-файл. И этого достаточно.

    Сейчас экономия пары десятков килобайт не стоит того, чтобы сделать один запрос вместо 20-ти. Грузите весь код одним разом, только позаботьтесь, чтобы на разных страницах выполнялись отдельные участки javacsript-ов. К тому же помните о кэше: один раз скачав файл, пользователь сохранит его в кэш браузера, и уже на следующих страницах Вашего сайта статика мгновенно загрузится из кэша, а не с удаленного сервера.

    2. Сжимайте javascript, стили и html-код

    Несмотря на то, что мы сделали всего один запрос на сервер, не стоит забывать, что объем данных тоже имеет значение. Минифицирование кода позволяет уменьшить объем данных до 40-50%, что никогда не будет лишним. Особенно это актуально для мобильных устройств.

    Для минификации есть масса онлайн-сервисов, например, minifycode.com. Но гораздо удобнее использовать инструменты сборки фронтенда, например, grunt, gulp или webpack. На тему сборки с помощью gulp на webdevkin-е есть одна статья из целой серии, посвященной сборке фронтенда в веб-приложениях.

    3. Оптимизируйте изображения

    Часто нам не нужны 10-мегапиксельные фото на сайте. Мало того, что им можно уменьшить разрешение, так еще и дополнительно сжать картинки с минимальной потерей качества. Как правило, для веба супер-качества и не нужно. Также конвертируйте картинки из png в jpg, если Вам не нужна прозрачность.

    Помочь в этом могут как графические редакторы вроде фотошопа (в них даже есть специальная опция «сжать для веба»), так и те же инструменты сборки, например плагины gulp-imagemin и imagemin-pngquant.

    4. Делайте спрайты изображений

    Иконки, фоны для кнопок, галочки и стрелочки — вся эта мелкая шелуха занимает мало места, но требует много запросов к серверу. Чтобы не отдавать каждую иконочку по отдельности, склеивайте их в спрайты и грузите опять-таки одним разом.

    Вариантов сделать спрайты масса:

    • — руками (фууу)
    • — в онлайн-инструментах вроде instantsprite.com (нормально)
    • — инструментами сборки (вообще круто)

    Впрочем, я умею только первыми двумя, до третьего способа не дает добраться лень 🙂

    5. Применяйте lazy load — ленивую загрузку изображений

    Термин lazy load относится и к скриптам, и к стилям, но чаще всего с ним упоминают изображения. Мода на огромные лэндинги на десяток экранов и с мегабайтами картинок не проходит. Грузить эти тонны данных проблема, какой бы быстрый интернет у нас ни был.

    Идея lazy load заключается в том, чтобы загружать ресурсы только тогда, когда они нам реально понадобятся. В случае к картинками грузятся только те изображения, которые видны в данный момент. То есть если пользователь прокрутил только первые пару экранов лэндинга, тонна картинок, спрятанная «ниже» по сайту, не загрузится. Тем самым наш сервер разгрузится от лишних назойливых запросов, и что важнее, экономится трафик и нервы посетителя сайта.


    Хотя кажется, что реализация ленивой загрузки сложна, на самом деле есть море плагинов, которые сделают всю работу за Вас. Например, плагин lazy load для jquery требует всего лишь подключить библиотеку, заменить в теге img атрибут src на data-original и запустить плагин одной строчкой кода. Усилий минимум — эффект значительный. Рекомендую.

    6. Не ленитесь делать превью изображений

    Капитанский совет, но просто удивительно, сколько людей пренебрегают этим простым правилам. Смотришь на красивую галерею на сайте с ajax-подгрузкой картинок и думаешь «какие молодцы». А потом замечаешь, что превьюшки на слайдере — это те же здоровенные картинки, только уменьшенные css-ом. И думаешь «ну и на хрена это все?»

    Задачу по созданию превьюшек не назовешь фронтовой. Если это приходится делать Вам самим, то могу только посочувствовать. Обычно это делается или средствами специально приставленных людей, которые выполняют эту неблагодарную работу врукопашную или с помощью инструментов пакетной обработки изображений. Или, если Вам не чуждо человеколюбие, на стороне бекенда. Ресайз картинок выполняется как правило плагинами cms/фреймворков при загрузке изображений на сервер или при первом обращении к нужной картинке. В любом случае Вы, как фронтендщик, должны понимать, что именно Ваша забота — обеспечить максимально быструю загрузку клиентской части сайта. И проконтролировать нужных людей тоже.

    7. Отдавайте статику с разных доменов/поддоменов

    Если у вас небольшой проект, блог или сайт с котятами, не заморачивайтесь — никакого профита не почувствуете. Но если Вы, почем знать, разрабатываете второй ВКонтакт, то массу статики, да тех же фото, стоит разносить по разным поддоменам или, по-царски, доменам. Дело в том, что браузеры имеют ограничения по количеству потоков на загрузку ресурсов с одного (под)домена. Поэтому если у Вас есть громадная масса контента, то лучше позаботиться о ее раскидывании.

    8. Подключайте js-код или файлы в конце страницы

    А именно перед закрывающим тегом body. В первую очередь браузер должен загрузить контент, а только потом js. Конечно, если у Вас Single Page Application, то профита от этого совета не будет. Но не расстраивайтесь, если Вы занимаетесь SPA, то у Вас и так все хорошо 🙂

    9. Подключайте стили динамически (но осторожно)

    Совет из разряда «на свой страх и риск». Попробуйте подгрузить стили уже после отрисовки голого html. Ускорение загрузки страницы будет, возможно, мизерное. А вот Ваш html может быть настолько страшен, что без стилей пользователям хватит четверти секунды, чтобы сбежать с сайта. В общем, пробуйте и решайте, нужно ли Вам это.

    10. Избавляйтесь от лишних dom-элементов

    Операции с dom — это одна из самых тяжелых частей работы браузера. Не делайте таблицы там, где достаточно двух плавающих div-ов. Не лепите лишние span-ы для красоты. Не делайте обертки для оберток контейнеров, если конечно, этого не требует javascript-логика.

    В общем, делайте проще и стремитесь к минимализму.

    11. Используйте нативный javascript вместо jquery

    Не будем делать вид, что нам позарез нужен jquery для манипуляции dom. Просто мы к нему привыкли. Гораздо удобнее написать $(‘#myDiv’), чем document.getElementById(‘myDiv’). Но времена поддержки седьмых IE прошли, и если для Вас действительно критична оптимизация, переходите на нативный js — выигрыш по скорости работы с dom будет в десятки и сотни раз.

    12. Не бойтесь навешивать id элементам dom для быстрого доступа к ним из javascript-кода

    Верстайте только на классах, а айдишники оставьте для js. Это максимально быстрый способ получить доступ к нужному элементу. К тому же Вы скоро перестанете путаться в приоритетах применения стилей и всегда будете знать: если на этот элемент навешан id, значит javascript от него что-то хочет. А если навешан класс, то что-то хочет css.

    13. Используйте css-анимации вместо javascript

    Иногда очень прикольно запилить хитрую анимацию на js, но нужно всегда помнить, что это большая нагрузка на браузер. Не говоря уже о лишнем js-коде. CSS3 давно в почете и можно не стесняться пользоваться transitions и keyframes.

    Конечно, стоит брать во внимание поддержку этих свойств нужными браузерами. Часто анимации носят декоративный, дополнительный характер. Если в браузере пользователя css-transitions не поддерживаются, то он просто увидит статичную картинку. Но если реализация анимации крайне необходима, то стоит дублировать ее javascript-ом.

    14. Избегайте тяжелых операций с dom при скроллинге/прокрутке страницы и разберитесь с throttle и debounce

    Наши любимые клиенты очень любят смотреть, как при изменении размеров окна на экране происходит волшебство: меняются местами блоки, а из-за края монитора выпрыгивают зайчики. К сожалению, восторженные директора и менеджеры при этом не слышат, как начинает завывать старенький кулер на процессоре и не видят, как скачет расход памяти в браузере. А ведь далеко не у всех посетителей сайта на руках macBook с core i7 и 8 Гб памяти.

    Конечно, некоторую долю преобразований можно сделать, не вмешиваясь в dom, исключительно стилями и media query. Но часто приходится подключать и тяжелую артиллерию в виде старого доброго js. И чтобы при этом у Вас не взвыл браузер и посетитель сайта, разберитесь с такой темой: Как и зачем использовать throttle и debounce

    15. Изучайте ajax-запросы и анализируйте передачу данных с сервера

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

    Обсуждайте с коллегами-бэкендщиками обмен данных между клиентом и сервером. Обговаривайте формат данных и api. Стройте REST-сервис вместе. В конце концов, именно Вы знаете, какие данные нужны на клиенте.

    Если Вам нужна общая информация, например, о покупателе интернет-магазина, выбросьте из запроса лишние данные о всех его заказах с наименованиями, ценами и скидками. Вынесите это в отдельный запрос. Чем проще и легковеснее будут ваши запросы, тем легче с ними работать и меньше нагрузка на сервер.

    Откажитесь от XML — как ни странно, он еще довольно часто используется.

    Если проект это позволяет, переносите логику с сервера на клиент. Получайте с сервера сырые данные и обрабатывайте их как Вам нужно на клиенте — это будет максимально быстро. underscore.js и lodash.js помогут в этом деле и очень разнообразят Вам жизнь. Работать с данными интереснее, чем с кнопочками и инпутами.

    Не бойтесь сами разбираться с серверной частью проекта. Если у вас mongodb, то тем более флаг Вам в руки — работа с ней это чистый javascript. Возможно, Вы еще сможете предложить лучшие решения по организации коллекций и выборке данных. В любом случае, вряд ли Вас кто осудит, если это произойдет не с первого раза.

    16. Найдите и изучите подходящие инструменты

    Изучите один или несколько инструментов сборки проектов.
    Бродите по закоулкам developer tools Вашего браузера — там невероятно много интересного 🙂
    PageSpeed Insights от Google даст Вам пищу для размышлений и рекомендации к действию.

    17. Останавливайтесь вовремя

    Оптимизация скорости это как рефакторинг кода — процесс бесконечный. Всегда найдется, что улучшить еще чуть-чуть. А потом еще. Ну и вот последнее и тогда-то точно все будет зашибись.

    Мой совет — останавливайтесь вовремя. Достаточно хорошо и быстро лучше, чем идеально, но долго. Экономия еще нескольких Кб не стоит четырех часов Вашего времени или еще хуже, нервов Ваших коллег и клиентов.

    Золотую середину найти сложно, и у каждого она своя. Но нужно как минимум о ней помнить и стараться достичь.

    На этом все. С интересом почитаю в комментариях Ваш опыт по оптимизации фронтенда и другим философским вопросам. Велкам!

    Современные инструменты для Front End разработки

    Разработчики веб-страниц Front End’a несут ответственность за то, чтобы страница точь-в-точь повторяла макет дизайнера и одинаково отображалась во всех браузерах. В течение долгого времени это становилось легче с появлением более продвинутых браузеров и большего количества средств разработки.

    В то время как все знают о HTML и CSS, меньше людей знает о Sass и Haml. Развитие фронтенда продолжает продвигаться с каждым годом. Одно из основных заданий разработчика – всегда быть в курсе последних нововведений.

    Если вы чувствовали себя немного неуверенными в своих навыках фронтенда или просто хотите узнать о более новых методах, эту небольшую статью советую прочитать именно вам. Я предлагаю вам несколько популярных инструментов и ресурсов, которые каждый разработчик Front End’a должен использовать или по крайней мере знать об их существовании.

    CSS препроцессоры

    Возможно, самый известные препроцессоры CSS: SASS, также немного похож на него LESS. Благодаря этим двум библиотекам вы можете создать более динамический код.

    Термин “SASS” можно применять как к технологии, так и к синтаксису. Файлы SASS могут также быть файлами SCSS, между ними нет особых различий, местами SCSS просто более напоминает привычный CSS. LESS – та же самая вещь только с различным синтаксисом.

    SASS и LESS не языки по сути, но небольше расширения для CSS. Код SASS/LESS компилируется в обычный CSS.

    Самое большое различие между SASS и LESS, кроме синтаксиса, то, как они работают. SASS компилируется с помощью Руби, в то время как LESS – использует JavaScript (или Node.js).

    Обратите внимание на то, что предварительная обработка CSS действительно требует небольшого знания команд Terminal/CLI. Вам не обязательно быть экспертом, но у вас должны быть хотя бы базовые знания работы в командной строке. Например, самый быстрый способ собрать файлы SASS состоит в том, чтобы использовать что-то вроде этого в терминале:

    sass input.scss output.css

    Но как только вы получаете некоторую практику, это становится для вас вторым способом написания CSS.

    Вот некоторые ресурсы для того, чтобы узнать больше о препроцессорах для CSS:

    GIT (Распределенная система управления версиями)

    Контроль для управлением проектом и версиями необходим для больших веб-проектов. Такое сообщество как GitHub сделало “GIT” обычной частью технологий.

    Но как это работает, и почему вы должны его использовать?

    GIT – система управления версиями, которая позволяет разработчикам писать код, не переписывая предыдущую работу. Это возможно посредством перехода, где различные части проекта могут быть сохранены как архив. С GIT’ом возможно разветвить ваш текущий проект, попытаться добавить новую опцию и сохранить, если она вам понравилась, или удалить ту ветвь, которая не работает.

    Установка GIT’a очень снисходительно относится ко всем операционным системам. Легкое достаточно подробное обучение, в процессе которого вы узнает, как все передается, ветвится и контролируется.

    Но с вводным гидом и большим количеством практики GIT будет медленно становиться частью вашего технологического процесса Front End’a.

    Одно из самых больших препятствий, которое может произойти – это использование GIT через командную строку. Это – предпочтительный метод большинства программистов, которые уже используют CLI ежедневно. Однако, если вы так и не смогли научиться использовать его, то вам на помощь приходит приложение от GitHub’a и который на данный момент является бесплатным.

    Мой совет если вы все таки решили начать изучать GIT’a состоит в том, чтобы вы учили его не в спешке, а поэтапно. Легко быть обескураженным, если контроль версий – абсолютно незнакомое понятие. Поэтому учитесь в своем собственном темпе и не сдавайтесь!

    Вот некоторые превосходные веб-сайты для изучения основных возможностей GIT’a:

    JavaScript библиотеки

    Развитие Front End’a, несомненно, переместилось к полной поддержке JavaScript. От динамических элементов страницы до мультипликации JavaScript – одного из основных инструментов каждого веб-проекта.

    Но недавно казалось, что все больше разработчиков выбирает библиотеки JavaScript, которые довольно таки упрощают процесс написания кода. Это отлично потому, что библиотеки порой содержат в себе упрощенные понятия, которые могут облегчить взаимодействие с такими методами как AJAX. Отрицательная сторона этого явления – с таким количеством различных библиотек трудно будет понять, с чего начать.

    Хорошее правило состоит в том, чтобы изучить только то, в чем вы нуждаетесь и когда вам это нужно. Если вы тот, кто просто любит писать код для забавы, лучше освоить только несколько библиотек. jQuery – возможно, лучший выбор, чтобы начать, так как это – одна из лучших пяти библиотек JavaScript, которыми чаще всего пользуются.

    Но также следует рассмотреть более современные инструменты, такие как Backbone.js или Angular.js. Они оба являются общедоступными библиотеками, которые были написаны для структурирования основных JS веб-приложений. Они невероятно сильны, но могут служить небольшим дополнением на простом блоге WordPress.

    Разработчики, ищущие проблему, могли бы считать изучение одного из инструментов предварительной обработкой языков, таких как CoffeeScript, TypeScript или LiveScript. Все три языка собирают в JavaScript, но предлагают небольшие отличия оригинальному синтаксису.

    Настоящая сила JavaScript только сейчас обнаруживается. С таким инструментом как Node.js появляется возможность установить его на сервер. Нельзя не напомнить о том, что сырой JavaScript может быть выполнен в консоли браузера, дающей еще больше возможностей Front End разработчикам.

    Являетесь ли вы полным новичком или закаленным разработчиком, есть всегда то, чему возможно научиться с JavaScript, если вы увлечены веб-разработкой. Следующие ресурсы могут оказаться исключительно полезны:

    HTML препроцессоры

    Популярность препроцессоров CSS, также дала возможность появлению препроцессоров для HTML Front End’a. Это работает точно так же, как SASS/LESS, где вы написав код, и скомпилировав, получили ли бы обычный HTML-код.

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

    Haml и Jade – эти два наиболее популярных препроцессора с совсем разными стилями синтаксиса. Slim – третий вариант. Все три – в открытом доступе и все время улучшаются, благодаря общественной поддержке.

    Haml и Slim работают на Ruby, Haml является альтернативой ERB шаблонов. Сейчас Haml – большой инструмент для разработчиков Rails. Для Front End’еров может быть столь же полезным, вне зависимости от того, пишете ли вы код на Back End’е или нет.

    Jade – шаблонный двигатель, который работает на Node.js. Лучше использовать его для приложенний Node или также можно использоваться в качестве автономного решения для разработчиков Front End’a, которым нравится синтаксис Jade.

    Нет никакого запрета или неправильного выбора, так как они оба довольно таки похожи. Общее согласие среди любителей Ruby состоит в том, чтобы придерживаться разработки на Haml. Но много разработчиков Front End’a склоняются к Jade’у, потому что Node.js стал горячей тенденцией в веб-разработке.

    Правда, немного разработчиков находят обязательной предварительную обработку HTML. Вы можете предпочесть писать статический HTML, но некоторые разработчики предпочитают Haml/Slim/Jade. Поэтому, если вы можете, по крайней мере, понять синтаксис, это даст вам большое преимущество.

    Советую вам изучить эти подробные обучающие ресурсы, чтобы копнуть поглубже:

    JS менеджер задач

    Автоматизированные менеджеры задач – новейшие инструменты Front End’a. Понятие часто запутывающее сначала, но менеджеры задач могут существенно улучшить ваш технологический процесс и дать огромный потенциал.

    Два крупных менеджера задач – Gulp и Grunt. Вы заметите, что они оба работают на JavaScript, но также им требуется терминал. Так каким же образом все работает?

    Gulp и Grunt устанавливаются через Node Package Manager (NPM) в командной строке. Сами библиотеки могут управляться командами JS от отдельных файлов, gulpfile.js и gruntfile.js соответственно.

    Эти файлы могут быть очень маленькими или очень большими в зависимости от того, сколько задач вы хотите автоматизировать. Посмотрите на этот стандартный Gulpfile.js, чтобы увидеть, как это все может выглядеть.

    Если вы никогда не делали ничего подобного до этого времени, вы вероятно несколько смущены. Не волнуйтесь насчет синтаксиса на данный момент, вместо этого вы можете сосредоточиться на понятиях и особенностях, предоставляемых этими .js файлами.

    Вы можете добавить код JS, который автоматизирует некоторые задачи, такие как обработка файлов SASS, Haml, даже языки JS, один из которых CoffeeScript. Вы заметите, что каждая из тех связей указывает на пакет NPM, предварительно написанный для Gulp’a. Это означает, что вы не должны писать, то же, что и ваши собственные автокомпиляторы SASS, потому что это уже все написано!

    Обучение использованию менеджера задач требует поэтапной работы. Понятия могут казаться незнакомыми и, подобно изучению SASS’a, есть сложности в понимании для новичков. Однако, как только вы разберетесь в основах и увидите, как это затрагивает вашу разработку в целом, вы даже не подумаете вернуться к старым способам.

    Чтобы начать, просто выберите Gulp или Grunt и заставьте себя практиковаться.

    Вот некоторые способы начать:

    В заключение

    Все эти инструменты довольно новые или очень выросли за прошедшие несколько лет. Мир развития Front End’a предлагает столько впечатляющих инструментов для упрощения написания кода, и я надеюсь, что эта статья даст вам отправную точку.

    Мастер Йода рекомендует:  12 простых советов тем, кто самостоятельно учит математику
    Добавить комментарий