Front-end разработка в мире интернета вещей


Содержание материала:

10 навыков, которые нужно освоить, чтобы получить работу front-end разработчика

Если вы хотите сменить свою специальность, чтобы получить новую, более высокооплачиваемую работу, сфера IT и front end подходят для этого как нельзя лучше.

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

Сейчас я хочу сосредоточиться на front-end разработке. Если говорить обобщенно, front-end разработчики пишут сайты, используя HTML , CSS и JavaScript . Они же реализуют готовый дизайн на сайте.

Быстрый обзор текущих вакансий для front-end разработчиков показывает, что существует четкий набор навыков, которые указывают работодатели. Например, списки требований первых трех вакансий для front-end разработчиков, которые я нашел на Glassdoor.com , во многом идентичны: знания HTML , CSS и Javascript , контроль версий, фреймворки.

Это термины, с которыми вы познакомитесь, когда начнете изучать front-end разработку. Ниже приводится список 10 основных навыков, необходимых каждому front-end разработчику.

1. HTML / CSS

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

CSS ( каскадные таблицы стилей ) — это язык, используемый для представления документа, созданного с помощью HTML . CSS используется для определения макета страницы, цветов, шрифтов и других стилей!

2. JavaScript / jQuery

Еще одним основным инструментом в арсенале начинающего front end разработчика должен стать JavaScript ( JS ). Если HTML — это язык разметки, а CSS — язык стилей, то JS — это язык программирования. Если HTML и CSS определяют представление страницы, JS определяет ее функционал.

Для простых сайтов или веб-страниц достаточно будет HTML/CSS . Но для интерактивных функций ( аудио и видео, игры, прокрутка, анимация страниц ) понадобится JS .

Одна интересная вещь, которую следует знать о JS — это наличие библиотек, таких как jQuery . Библиотеки — это коллекции плагинов и расширений, которые позволяют проще и быстрее использовать JS на сайте.

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

3. CSS и JavaScript-фреймворки

CSS и JavaScript-фреймворки представляют собой наборы файлов CSS или JS , которые выполняют огромный объем работы, предоставляя базовый функционал. Например, формы регистрации на сайте или в блоге. Вместо того чтобы начинать с чистого документа, вы начинаете с файла, в котором уже есть общий JS-код .

Front end разработка и что это сложно свидетельствует тот факт, что у фреймворков есть свои сильные и слабые стороны. Например, некоторые JS-фреймворки отлично подходят для создания сложных пользовательских интерфейсов, а другие — для отображения содержимого сайта.

Чтобы еще больше все упростить, можно использовать фреймворки совместно. Обычно используется пара Bootstrap с другим JavaScript-фреймворком , таким как AngularJS . Содержимое обрабатывает Angular , а внешний вид — Bootstrap ( с некоторым изменениями в CSS ).

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

4. Препроцессинг CSS

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

Используя препроцессоры CSS , такие как Sass , LESS или Stylus , можно писать код на языке препроцессора, доверяя ему делать то, что может занять много времени при использовании CSS . Затем препроцессор преобразует код в CSS , чтобы он работал на сайте.

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

5. Контроль версий / Git

После написания кода HTML , CSS и программирования на JS front end web developer должен будет произвести ревизию проделанной работы. Если что-то пошло не так, последнее, что вам захочется, это начинать все с начала. Контроль версий — это процесс отслеживания и контроля изменений в исходном коде.

Программное обеспечение для управления версиями, такое как Open Source Stalwart Git — это инструмент для отслеживания изменений, чтобы иметь возможность вернуться к предыдущей версии и выяснить, что пошло не так.

6. Адаптивный дизайн

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

Адаптивный дизайн является неотъемлемой частью фреймворков CSS , таких как упомянутый выше Bootstrap .

7. Тестирование / отладка

Чтобы заставить все работать надлежащим образом, нужно тестировать код на наличие ошибок. Поэтому навыки тестирования и отладки являются обязательными для front-end разработчиков.

Существует несколько различных методов тестирования. Функциональное тестирование проверяет конкретный функционал сайта ( например, форму или базу данных ).

Единичное тестирование — это еще один метод. Он проверяет фрагменты кода, которые отвечают всего за одну вещь на сайте, на предмет их корректной работы.

Тестирование — важная часть процесса разработки front end на Java . Но это еще одна область, для которой существуют различные фреймворки, которые помогут вам. Такие программы, как Mocha и Jasmine , предназначены для ускорения и упрощения процесса тестирования.

8. Инструменты браузера для разработчиков

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

Встроенные в современные браузеры инструменты для разработчиков обычно состоят из инспектора и консоли JavaScript . Инспектор позволяет увидеть, как выглядит HTML-код на странице, какой CSS связан с конкретным элементом на странице. А также позволяет редактировать HTML и CSS , просматривать произошедшие изменения в режиме реального времени.

Консоль JS позволяет просматривать ошибки, возникающие при попытке браузера выполнить JS-код .

9. Инструменты для построения и автоматизации / производительности

Производительность сайта зависит от количества времени, которое требуется для его загрузки. Если при front end программировании возникли проблемы со временем выполнения, необходимо предпринять шаги для их решения. Например, оптимизация изображений ( масштабирование и сжатие изображений для максимальной производительности ), минимизация CSS и JavaScript ( удаление ненужных символов из кода без изменения функционала ).

Выполнение задач, которые приводят к повышению производительности, также может отнимать много времени. Но здесь на помощь приходят инструменты для построения и автоматизации. Такие программы, как Grunt и gulp , могут использоваться для автоматизации оптимизации изображений, минимизации CSS и JS и других задач.

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

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

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

Даже если большая часть работы front end web developer выполняет через графический интерфейс, он может получить серьезное преимущество в глазах потенциального работодателя, если будет владеть навыком работы с командной строкой.

Не останавливайтесь в совершенствовании своих профессиональных навыков!

Данная публикация представляет собой перевод статьи « 10 Skills You Need to Land Your First Front End Developer Job » , подготовленной дружной командой проекта Интернет-технологии.ру

Front-end разработка в мире интернета вещей

Одна из мыслей, которая поселилась в моей голове: должен ли frontend-разработчик быть в курсе всего? В общем смысле, frontend-разработчик может использоваться и на других рабочих местах. Вся команда разработчиков заканчивает разговор на frontend-разработчике. В этом смысл моей идеи. Frontend-разработчики создают те вещи, с которыми будут взаимодействовать люди. Все этапы разработки проходят вместе с frontend-разработчиком. Возможно, именно поэтому это такая забавная работа! Поскольку frontend-разработчик занимает центральное место в цепочке разработки, и при этом мы имеем дело с большим количеством разных специалистов, мы должны понимать их работу и иногда подсказывать, что и как сделать лучше.

От переводчика

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

Frontend-разработчик должен разбираться в дизайне

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

К прочтению:

Frontend-разработчик должен разбираться в работе серверной части (backend)

Даже если вы и не backend-разработчик, то вы явно осознаёте всю важность серверной части. Вы понимаете, с чем взаимодействует backend, что передается на сервер, а что нет. Вы знаете об обязанностях backend-разработчика. Вы понимаете, какой язык используется на сервере, и при этом должны уметь объяснить, что должен дать вам backend и что нужно от серверной части frontend-а.

К прочтению:

Frontend-разработчик должен разбираться в работе сетей

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

К прочтению:

Frontend-разработчик должен разбираться в производительности

Если вы не сосредоточены на производительности, то знаете, что производительность имеет важное место в успехе вашего проекта. Frontend-разработчики знают об этом нелегком мире. Нужные навыки помогут вам одержать быструю победу в долгой борьбе. Необходимо понимать насколько быстрым должен быть backend, а также, что оставшиеся 80% времени это загрузка сайта, т.е. это frontend.

К прочтению:

Frontend-разработчик должен разбираться в контент-стратегии

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

К прочтению:

Frontend-разработчик должен разбираться в базах данных

Контент хранится в базе данных. База данных должна корректно работать с контентом. А frontend-разработчик должен уметь работать с тем, что приходит ему из этой самой базы данных. Frontend-разработчику при работе с ответом базы данных нужно уметь комбинировать контент с шаблонами на сайте.

К прочтению:

Frontend-разработчик должен разбираться в тестировании

Существует большое количество видов тестирования. Интеграционное тестирование. Регрессионное тестирование. Пользовательское тестирование!

К прочтению:

Frontend-разработчик должен разбираться в системах сборки

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

К прочтению:

Frontend-разработчик должен разбираться в методологиях разработки

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

К прочтению:

Frontend-разработчик должен разбираться в настройке веб-серверов

Без них не было бы веб-сайтов.

К прочтению:

Frontend-разработчик должен разбираться в юзабилити

Если frontend-разработчик не очень хорошо разбирается в юзабилити, в любом случае он должен понимать насколько это важно. Необходимо уметь тестировать и налаживать юзабилити. Frontend-разработчик должен знать, с кем поговорить на эту тему.

К прочтению:

Frontend-разработчик должен разбираться в мобильном дизайне

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

К прочтению:

Заключение

Это всего лишь часть того, что должен знать frontend-разработчик. Чем больше, тем лучше. Все это, конечно, познается в работе. HTML, CSS, JavaScript, адаптивный дизайн, библиотеки и фреймворки — этот список может долго не заканчиваться.

Front-end разработка, с чего начать?

Доброе утро / день / вечер / ночь. Всем привет!

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

И так. Решил я попробовать себя я в сфере Front-End разработки, но с чего начать изучение, я не имею понятия, ибо конкретного плана где либо в интернете не найти. Там могут только дать с 1 места 200 направлений в разные русла и ты сидишь и не знаешь с чего начать.

Знания HTML и CSS у меня относительно хорошие. Без проблем могу сделать качественный лендинг, сверстать какой-нибудь PSD, все это хорошо. Но это Front-end’ ом не назвать.

Поэтому мне нужен ваш совет, в какой последовательности и что нужно изучать?

  • Вопрос задан более трёх лет назад
  • 27841 просмотр

Для начала изучите инструменты.

Препроцессоры: LESS/Sass/Stylus. Знать нужно не на уровне «ух ты, селекторы можно вкладывать», а на уровне «мне надо сделать классы вида class1..class10 с увеличивающимся размером шрифта и уменьшающейся прозрачностью, я знаю, что это можно сделать без копипасты и знаю, как» — хотя бы один из них. Последнее время очень популярен PostCSS, надо ознакомиться с его возможностями тоже.

Шаблонизаторы: Jade, Twig, Jinja. Аналогично предыдущему пункту.

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

Дальше — JS. Немножко изучите синтаксис и садитесь за таск-раннеры: Grunt, Gulp, Webpack. Надо уметь создать себе workflow: склейка/сжатие стилей, оптимизация картинок и генерация спрайтов, сборка статического HTML из шаблонов, склейка скриптов, все это с livereload’ом.

Дальше опять за JS: в jQuery надо ориентироваться хотя бы на уровне «знаю, что именно искать на api.jqiery.com». Дальше — высокоуровневые фреймворки, Angular/React. Потом — юнит-тесты, паттерны, компилируемые в JS языки.

Вот Вы сами пишете «зачем я задаю такого рода вопрос, ибо на него ведь есть куча ответов» и всё равно задаете такой вопрос. Ответ абсолютно одинаковый для всех! Вы решили попробовать себя в сфере frontend. Frontend — это клиентская часть. Базовые знания здесь — это HTML, CSS, JavaScript. Дальше учите то, что Вам нравится. А чтобы понять, что Вам понравится, Вы должны что-то попробовать. И пока Вы будете учить тот же JavaScript, Вы откроете для себя ещё огромную кучу всего нового, например мне в своё время захотелось разобраться в WebGL, но для этого нужно разобраться в JavaScript сперва. Поэтому я повторюсь — ответ ОДИНАКОВЫЙ ДЛЯ ВСЕХ И НЕ ВАЖНО У КОГО КАКОЙ ОПЫТ! HTML, CSS, JavaScript, а дальше, что душе угодно. Может в процессе изучения JavaScript вы наткнетесь на статью о node.j и поймете, что вертели Вы этот фронтэнд и уйдете в бекэнд. Начинайте с базы, а база одинакова для всех.
После базовых знаний Вы уже сами решите для себя, что Вам нужно — это я Вам ГАРАНТИРУЮ! Вы будете достаточно хорошо понимать, что Вам нужно или что хотелось бы. И чтобы к этому прийти, разберитесь на «пятёрочку» в этих, как сказали, «трех китах»

Топ-пост этого месяца:  Библиотека jQuery UI эффекты

Начните с постановки задачи, например.

Как вы сами сказали, можно дать 200 направлений и все они будут относится к front-end. Но если у вас есть задача, то количество этих направлений (необходимых для её решения) сокращается к минимуму или к различным вариантам – наборам направлений.

На вопрос какой набор направлений выбрать вам, ответите только вы сами. Пробуйте. Стройте. Ломайте. И снова стройте 🙂

Современная front-end разработка. Плюсы и минусы.

За последние несколько лет front-end разработка ушла далеко вперёд. От банальной верстки html-страниц при помощи CSS c минимальной динамикой, задаваемой javascript/jquery, практически не осталось и следа. Если вы не работали хотя бы с одним из сборщиков front-end проектов (grunt, gulp, webpack), не слышали слова «транспайлер» (babel), не знаете, что на front end тоже можно писать тесты (jasmine, mocha, chai), и запускать их автоматически в любом браузере (karma), то вы весьма сильно отстали от жизни. А ведь есть ещё React.js (библиотека для построения интерфейсов), ES6 (новейший стандарт языка javascript, который ещё не поддерживается большинством браузеров, но если очень хочется, то уже можно использовать в production-коде), Node.js (платформа, позволяющая исполнить мечту любого front-end разработчика — писать не только front end, но и back end проекта на любимом javascript) и многое-многое другое.

Но как и любое новшество, данный скачок в развитии имеет две стороны медали. Мы попытаемся разобраться, какие есть недостатки и достоинства в работе с самыми новыми front-end технологиями и как постараться избежать проблем при старте работы с ними.

Работая над проектами в Anadea Inc., мы успели испробовать не только все вышеназванные, но и многие другие инструменты front-end разработчиков. Это был длинный и тернистый путь, и теперь мы хотим поделиться полученным опытом, дабы помочь вам приоткрыть дверь в мир современной javascript-разработки.

Поговорим о преимуществах использования передовых front end инструментов.

  • рост скорости решения задач;

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

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

  • повышение качества кода;

В последнее время стали популярными линтеры (jslint, jshint, eslint) — инструменты, позволяющие определить стиль кода в вашем приложении и указывать на места, где выбранный стиль не соблюдается. В зависимости от настроек окружения, это может происходить во время push’a изменений в репозиторий, во время deploy’a на сервер, либо в реальном времени прямо внутри вашего текстового редактора/IDE. Линтеры позволяют в значительной степени улучшить состояние вашего кода, избежать простых ошибок. Однако линтеры не являются решением всех проблем — они лишь укажут на места, где ваш код явно «плохо пахнет». Но это не исключает изучение pattern’ов и лучших практик программирования, чтение чужого кода, общение с более опытными коллегами и всё так же придётся рефакторить ранее написанный код. Только так удастся добиться повышения качества кода.

  • значительное снижение дублирования кода;

Ещё один полезный момент, который можно извлечь из использования линтеров — это возможность отслеживать дублирование в коде и избавляться от него. Но это не главный инструмент сокращения дублирования кода в мире современной javascript-разработки. К основным можно отнести Node.js, который при правильной архитектуре позволяет использовать один и тот же код и на back end, и на front end. Также снизить дублирование позволяет компонентный подход, применяемый многими библиотеками (например, React.js), и удобная система управления пакетами — npm. Компонентный подход позволяет инкапсулировать логику, стиль и отображение. Npm предоставляет несложный способ распространения (share) таких компонентов.

  • возможность программирования в реальном времени;

И самый «горячий» плюс в современной front-end разработке это — hot reload — возможность делать изменения в коде и видеть их на экране браузера без перезагрузки страницы и без потери текущего состояния данных. Эта feature доступна на данный момент только тем, кто использует в качестве builder’a проекта webpack. Если вам интересно как это выглядит, можете посмотреть пример с React.js.

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

  • высокий порог вхождения в окружение;

Как бы ни было, за всем разнообразием front-end инструментов скрываются три технологии: javascript, html, css. Но чтобы вывести банальный «Hello, world!» на экран своего монитора современным способом, вам придётся ознакомиться не меньше чем с десятком документаций, написать несколько не самых очевидных файлов конфигурации и запустить череду команд в терминале. Всё это отпугивает как новичков, так порой и опытных программистов, не желающих познавать новое. Настройка окружения действительно важный этап в современном мире front end’a. Хорошая новость в том, что это необходимо будет сделать «практически» один раз. Плохая — если вы постараетесь проскочить этот этап, бездумно скопировав чьи-то решения, то он постоянно будет возвращаться к вам часами серфинга просторов интернета в поисках решения банальных проблем.

  • «усталость от javascript инструментов»;

В javascript-community всё чаще стал звучать термин «javascript fatigue», под которым подразумевается усталость от разнообразия инструментов и их бесконечных версий. Некоторые авторы называют 2020 «годом борьбы» с побочным эффектом роста числа инструментов и предполагают, что в этом году усилия javascript-сообщества будут направлены на решение этой проблемы.

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

  • большой выбор способа конфигурации модулей;

Мы долго сомневались, к достоинствам или недостаткам относить этот пункт, но так как статья рассчитана на новичков, то чаша весов всё-таки склонилась к недостаткам. И вот почему.

Практически каждая большая зависимость (webpack, karma, gulp, eslint и т.п.) в вашем проекте будет предоставлять более одного способа конфигурации: с помощью своего конфигурационного файла; через конфигурационный файл родительского модуля; с помощью флагов в shell-скриптах и т.д. Казалось бы, дополнительная гибкость — что плохого? А то, что на начальных этапах вы обязательно столкнётесь с ситуациями, когда настроив один инструмент, захотите добавить второй, расширяющий функциональность первого, и поймёте, что новый инструмент не работает. Виной тому часто становится банальная недосказанность в документациях инструментов о том, как они должны взаимодействовать и неосознанность возможных способов конфигурации этого взаимодействия.

  • нехватка ресурсов для поиска ответов;

Из-за неимоверного количества инструментов в мире современного front end’a пытаться удержать в голове знания о каждом становится практически невозможно. Для решения данной задачи программисты часто прибегают к помощи ресурсов для поиска ответов проверенных временем (stackoverflow.com, experts-exchange.com, superuser.com, github.com и др.). Но в нашем случае проблема в том, что инструменты и их новые версии появляются настолько быстро, что мы фактически являемся их бета-тестерами и сталкиваемся с проблемами, нигде ранее не описанными, отчего не можем даже понять, возможно ли их решить или же это баг библиотеки, которую мы решили использовать.

Как избежать проблем

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

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

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

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

Заключение

Современная front-end разработка находится уже далеко за пределами чистых js/html/css. Число инструментов, призванных помочь разработчикам, растёт в геометрической прогрессии. Но это ведёт не только к позитивным последствиям. Чем больше инструментов, тем сложнее рассмотреть среди них действительно стоящие — те, которые отслужат верой и правдой на протяжении всей жизни проекта и не подведут в ответственный момент. Именно такие инструменты мы попробуем помочь вам выбрать в следующей статье.

От нуля до героя фронтенда (Часть 1)

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

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

Руководство разбито на две части для более простого усвоения материала. Часть 1 посвящена разработке интерфейсов на HTML и CSS. Часть 2 будет о Javascript, фреймворках и паттернах дизайна.

Основы HTML и CSS

В разработке фронтенда все начинается с HTML (рус. — здесь и далее примечание переводчика с указанием языка статьи по ссылке) и CSS (рус.). HTML и CSS контролируют то, что вы видите на странице. HTML диктует содержимое в то время как CSS регулирует стили и раскладку.

Для начала прочитайте пособия по HTML (рус.) и CSS (рус.) от Mozilla Developer Network (MDN). MDN предоставляет пошаговые объяснения важных концепций HTML и CSS. К тому же каждая глава длинной всего в один экран и проиллюстрирована интерактивными демо на CodePen и JSFiddle.

После прочтения этих материалов загляните на курс Создай сайт (англ.) от CodeAcademy. Потребуется всего несколько часов для прохождения этого курса. Он даст хорошую основу для построения сайтов на HTML и CSS. Если вы хотите больше, то Построение веб-форм (англ.) — еще одно руководство от CodeAcademy, которое научит вас создавать и стилизовать веб-формы.

Чтобы попрактиковаться в CSS попробуйте CSS Diner (англ.). Это забавная игра с задачками по CSS. Другой важный аспект HTML и CSS — раскладка. LearnLayout (рус.) интерактивный учебник, показывающий как создавать раскладки на HTML и CSS.

Так же изучите как пользоваться Google Fonts (англ.) при помощи статьи Основы Google Font API (англ.) от CSSTricks или Руководство по Google Font API (рус.). Типографика — это фундаментальная основа интерфейса. Когда у вас появится время, я крайне рекомендую вам прочитать эту бесплатную онлайн-книгу Professional Web (англ.) от Donny Truong. Она научит вас всему, что вы должны знать о типографике во фронтенд-разработке.

Изучая все эти ресурсы, не беспокойтесь особо о том, чтобы все запомнить. В первую очередь сосредоточьтесь на понимании того, как HTML и CSS взаимосвязаны.

Практика основ HTML и CSS

Теперь, когда вы имеете представление об основах HTML и CSS, давайте повеселимся. В этом разделе есть два эксперимента для вашей практики создания сайтов и интерфейсов. Я использую термин “эксперимент” поскольку в ходе эксперимента вы осознаете на сколько сильно ваш успех зависит от ваших неудач.

Эксперимент 1

В нашем первом эксперименте мы будем использовать CodePen. CodePen это площадка для фронтенда (“песочница”), где вы можете писать HTML и CSS код без создания файлов на вашем компьютере. Там так же есть функция живого предпросмотра, которая обновляется сразу после сохранения кода.

Используя CodePen, вы убиваете двух зайцев сразу. С одной стороны вы практикуете HTML и CSS. C другой стороны вы создаете основу для портфолио с иллюстрациями вашего прогресса. Мы так же будем использовать Dribbble, который полон вдохновляющего дизайна.

Идите на Dribbble и найдите дизайн, код для которого вы сможете написать за пару часов. Я выбрал несколько примеров, с которых вы можете начать: 1, 2, 3, 4 и 5. Я выбирал дизайны, ориентированные в первую очередь на мобильную разработку, потому что они менее сложны, чем их аналоги для обычных экранов. Тем не менее вы вольны выбрать вариант для десктопов.

Когда вы определились с дизайном, идите и попробуйте сверстать его на CodePen. Если вы застряли, помните что StackOverflow (англ.) ваш друг. Другой полезной практикой будет пойти на такие сайты, как Medium, AirBnB и Dropbox и при помощи инструментов разработчика (англ.) посмотреть как реализована разметка и стили. Так же взгляните на некоторые примеры на CodePen. Я прикрепляю несколько хороших ссылок:

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

Если у вас нет за плечами опыта в дизайне, вероятнее всего, ваш дизайнерский глазомер не настроен. Фронтенд-разработчик с хорошим дизайнерским чутьем будет в состоянии отличить хороший дизайн и сверстать его идеально. Я написал статью несколько недель назад о том, как развить свое дизайнерское чутье (рус.).

Эксперимент 2

Надеюсь, первый эксперимент дал вам определенную уверенность в написании HTML и CSS. Для эксперимента 2 мы заглянем на ряд сайтов, затем напишем код нескольких компонентов.

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

  • Dropbox for Business: Попробуйте повторить их секцию с баннерами (так называемые hero image (англ.))
  • AirBnB: Попробуйте повторить их футер
  • PayPal: Попробуйте повторить их навигацию
  • Invision: Попробуйте повторить секцию регистрации (signup) в нижней части страницы
  • Stripe: Попробуйте повторить секцию оплаты

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

Вы можете использовать CodePen для своих экспериментов или выполните их на своем компьютере. Если вы планируете работать локально, то так же можете скачать этот пример проекта в качестве шаблона или создать файлы с нуля. Я советую вам использовать редакторы Atom или Sublime.


К тому же помните, что вы всегда можете посмотреть HTML или CSS любого сайта. Просто кликните правой кнопкой мыши на странице или на определенном элементе, выберите “Просмотреть код” и появится панель с HTML кодом в левой части и CSS кодом в правой. После окончания верстки или в момент, когда вы в тупике проинспектируйте свой код и посмотрите, как взаимодействуют ваши HTML и CSS.

Лучшие практики HTML и CSS

То, что вы узнали выше — основы HTML и CSS. Следующим шагом будет изучение лучших практик. Лучшие практики представляют из себя набор правил, которые улучшат качество вашего кода.

Семантичная разметка

Одним из лучших правил для HTML и CSS это написание семантичной разметки. Хорошая веб-семантика означает использование подходящих HTML тегов и “говорящих” названий классов в CSS, которые будут передавать структурный смысл.

Например, тег h1 говорит нам, что вложенный текст является важным заголовком. Другим примером является тег footer, который говорит нам что элемент должен располагаться внизу страницы. Для дальнейшего изучения прочтите Основы семантической верстки на HTML5 (рус.) и Для чего нужна семантика в именах классов (англ.) от CSSTricks.

Соглашение об именах в CSS

Следующая важная хорошая практика в CSS собственно соглашение об именах. Хорошее именование, как семантичная разметка, передает смысл и помогает сделать наш код предсказуемым, удобным для чтения и поддержки. Вы можете почитать о разных соглашениях в статье OOCSS, ACSS, BEM, SMACSS: что это? Что мне использовать? (англ.) или Правильный CSS: OOCSS, SMACSS, BEM и SASS (рус.).

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

Сброс CSS

Браузеры имеют небольшие различия при отрисовке стилей, начиная от отступов и до высоты строк. По этой причине всегда сбрасывайте CSS. MeyerWeb — самый популярный способ. Если вы хотите копнуть глубже, то можете почитать Создайте свой собственный файл Reset.css (англ.).

Кроссбраузерная поддержка

Кроссбраузерная поддержка означает что ваш код поддерживает большую часть современных брузеров. Некоторые свойства CSS^ например transition, требуют префиксов (англ.) для их верной работы в разных браузерах. Можете почитать о префиксах в статьях CSS Vendor Prefixes (англ.) или Вендорные префиксы (рус.). Главное что вы должны запомнить — тестируйте свои сайты во всех браузерах, включая Chrome, Firefox и Safari.

Препроцессоры и постпроцессоры CSS

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

Препроцессоры представляют из себя расширения для языка CSS, которые добавляют наворотов типа переменных, миксинов и наследования. Два самых главных препроцессора Sass и Less. На 2020 год Sass более распространен. Bootstrap, популярный CSS фреймворк, переключился с Less на Sass. К тому же когда большинство людей заводят речь о Sass, то они на самом деле говорят о SCSS (рус.).

Постпроцессоры CSS вносят изменения в код после того, как он был написан или после компиляции препроцессора. Например, некоторые постпроцессоры, тот же PostCSS, имеют плагины для автоматического добавления префиксов.

Топ-пост этого месяца:  Изучение WP_User_Query

Когда вы впервые открываете для себя препроцессоры и постпроцессоры, появляется соблазн использовать их везде. Тем не менее начните с простого и добавляйте переменные, миксины только там, где это действительно необходимо. Статья, о которой я упоминал ранее, CSS у Medium чертовски хорош (англ.), так же рассказывает о том, какие возможны излишки при работе с препроцессорами.

Система сеток и отзывчивость

Сетки в CSS это структура, позволяющая вам “укладывать” элементы горизонтально и вертикально.

Такие фреймворки, как Bootstrap, Skeleton и Foundation предусматривают стили, управляющие строками и колонками в раскладке. В то время как фреймворки, безусловно, полезны, стоит понимать саму суть работы сеток. Прекрасные обзоры на эту тему: Понимание CSS сеток (англ.) и Don’t Overthink Grids (англ.).

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

Вы можете почитать больше на тему медиавыражений в статье Введение в медиавыражения (англ.). Так же, поскольку мы вступили в эру mobile-first (рус.), загляните в Введение в медиавыражения Mobile-First (англ.).

Отработка лучших практик HTML и CSS

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

Эксперимент 3

В рамках эксперимента 3 выберите один из прошлых экспериментов и проведите рефакторинг своего кода с использованием советов, которые вы узнали выше. Рефакторинг означает редактирование вашего кода так, чтобы он стал проще, в том числе в плане читаемости.

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

Ниже несколько вопросов, на которые вы должны себе ответить в процессе рефакторинга.

  • Не двусмысленны ли названия классов? Через полгода я все еще смогу понять, что означает название класса?
  • Семантичен ли мой HTML и CSS? Можно ли с первого взгляда определить структуру и взаимоотношения элементов?
  • Использую ли я одни и те же цвета в коде? Не будет ли логичнее вынести их в переменные Sass (англ.)?
  • Работает ли мой код в Safari так же хорошо, как в Chrome?
  • Нельзя ли заменить часть кода на систему сеток, например Skeleton?
  • Не слишком ли часто я использую !important? Как я могу это исправить?

Эксперимент 4

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

В качестве последнего эксперимента создайте собственный сайт-портфолио. Для фронтенд-разработчика портфолио—самый важный актив. Сайт-портфолио предназначен для демонстрации ваших работ. Что еще более важно, это постоянно обновляющийся отчет вашего прогресса в разработке. Поэтому создавайте портфолио даже если у вас 1–2 работы.

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

Будьте в курсе

До тех пор, пока HTML и CSS не выйдут из употребления, важно оставаться в курсе всех событий в области фронтенда.

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

Учитесь на примерах

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

Стайлгайды

Стайлгайды в вебе это наборы CSS компонентов и паттернов, которые могут быть использованы на разных сайтах. Ключевой вещью для обучения является понимание того, как повторно использовать компоненты на основе HTML и CSS и не нарушать принцип “Не повторяйся” (рус.).

Соглашения о коде

Соглашения о коде призваны сделать ваш код читабельным и легким в поддержке. Некоторые из этих ссылок, например CSS Guidelines (англ.), являются набором советов по улучшению написания HTML и CSS в то время, как другие ссылки, например Github internal CSS toolkit and guidelines (англ.) являются примерами эффективного кода.

Сворачиваемся

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

Эта статья первая из двух запланированных. Во второй части мы поговорим об интерактиве с помощью JavaScript и библиотеках/фреймворках. Кроме того если вы хотите чтобы я подробно на чем-то остановился или у вас появились вопросы, то не стесняйтесь писать мне в Twitter.

P.S. Поделитесь этой статьей с друзьями, если она вам понравилась. Это много значит для меня.

Нашли ошибку? Воспользуйтесь функцией Private notes: выделяете текст с ошибкой, нажимаете на символ замка в появившемся дудле и оставляете свой комментарий. Спасибо!

Frontend — rак все поменялось за последние 15 лет

Все материалы сюжета:

Мы живем в удивительное время. На наших глазах рождаются, развиваются и транформируются во что-то иное не только технологии, но и целые профессии. Именно так случилось с системными администраторами, которые сейчас практически исчезли, уступив место DevOps-инженерам. С frontend-разработкой все наоборот: она сейчас переживает самый расцвет. Почему так?

В те времена, когда компьютеры были большими, а интернет очень маленьким, никто толком не знал, что же в этом загадочном интернете можно делать. Как ты наверняка помнишь, почти все сайты были очень простые: текст с информацией, пара ссылок на аналогичную страницу и всё. Браузеры тоже были очень простые, а зачастую даже чисто текстовые (например, консольные), поэтому и странички состояли из самых базовых тегов HTML, которые размечали структуру текстового документа. Глядя на все, что происходит сейчас, можно сказать, что именно тогда и был золотой век семантики и теги использовались действительно по прямому назначению. Впрочем, золотое детство интернета быстро прошло, появились первые большие сайты с повышенными требованиями к внешнему виду, а значит, и к верстке.

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

Как следствие, не было никаких «фронтенд-разработчиков», поскольку не было самого фронтенда. Были верстальщики, и были программисты. Программисты делали все крутые вещи, а верстальщики рыдали и ждали IE6, в котором будет поддерживаться столько крутых вещей, например полупрозрачность PNG! Наивные, да?

Началом рождения того фронтенда, который мы сейчас наблюдаем, было появление возможности асинхронных запросов через XHR. Все сайты захотели себе AJAX, чтобы быть крутыми, быстрыми и отзывчивыми, а верстальщики открыли для себя, что JavaScript можно не только писать в атрибут onclick , но и вообще активно его использовать для оживления страниц. Поскольку программисты не хотели марать руки в «каком-то скриптовом языке для браузеров», делать всю работу пришлось верстальщикам. И, как это обычно и бывает, работы становилось только больше.

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

Рождение фронтенда

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

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

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

Кеширование — это запоминание полученного по конкретному запросу ответа, чтобы в дальнейшем избежать запросов к базе данных и последующей обработки. Кеширование — это не всегда задача фронтенда, часто ее перекладывают на HTTP-сервер, однако совсем избавиться от этой части не получится: все равно никто лучше фронтенда не знает, как именно надо кешировать какие разделы сайта. У тебя может лежать статический файлик, который можно закешировать на год, а рядом будет AJAX’овая ручка, которая выдает актуальный статус системы и которую можно дергать несколько раз в секунду, получая разный ответ. Обрати внимание, что кешировать можно как готовый HTML, так и ответ от бэкенда по каким-то популярным запросам.

Ну и конечно же, огромным толчком для развития фронтенд-разработки стало появление Node.js. Если говорить точнее, то само появление Node.js явилось следствием повышающегося значения JavaScript, о котором мы говорили раньше. Но кого волнуют такие тонкости? Фронтенд-разработчики захотели свой собственный движок на знакомом языке, и они получили его. А вместе с движком они получили кучу возможностей.

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

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

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

Структура современного фронтенда

Современная клиентская часть может быть устроена очень по-разному, и, как правило, ее вид очень сильно зависит от требований конкретного сайта. В каких-то случаях идеальным вариантом будет single page application с большим количеством динамики на клиенте, в других же нужны лишь отдельные интерактивные элементы в обычной структуре сайта. Так или иначе большая или меньшая интерактивность ложится на клиентскую сторону, общая сложность создания сайта (фронтенд + клиент) обычно одинаковая. Цикл жизни запроса от пользователя обычно состоит из следующих этапов:

  • Запрос приходит на HTTP-сервер. Там запрос уже может быть отклонен (а-та-та, кто лезет на неправильный порт) или перенаправлен на статический раздел (например, если запрашивают CSS или JS) или собственно в наше приложение.
  • Приложение получает запрос с определенной метаинформацией и осуществляет роутинг, то есть решает, какой кусок кода (контроллер) должен обрабатывать подобные запросы. Например, пользователю без куки логина на этом этапе можно отправить форму авторизации.
  • Контроллер получает запрос и смотрит, какие данные ему нужно получить, причем это может быть многоэтапный процесс, целые цепочки запросов по определенным условиям.
  • Контроллер агрегирует полученные данные и отправляет их на шаблонизацию.
  • Шаблонизатор шаблонизирует шаблоном и отдает пользователю полученный результат.

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

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

Собственно, в упоминавшиеся нами старые времена все эти этапы тоже присутствовали, просто всем, кроме написания шаблонов (а зачастую и ими тоже), занимались бэкенд-программисты. Сейчас же JavaScript может все (а если он чего-то не может, смотри пункт первый), поэтому и зона ответственности бывших верстальщиков сильно выросла. Говорят, что бэкенд-программистам тоже стало сложнее, какая-то Big Data и мапредьюсы, но мне кажется, это все отмазки, чтобы не делать свою работу, а перекладывать ее на нас, несчастных фронтендеров.

Моя история: как я стала писать код front-end, советы новичкам

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

Все очень просто, мой парень программист, только-только выпустившийся из университета. Я также в этом году закончила бакалавр. Перед нами встал вопрос что же мы хотим делать дальше. И мы пришли к общему выводу, что время до 27-30 лет мы хотим посвятить себе, что значит дружно жить, вкусно кушать и самое главное много-много путешествовать. Дальше мы поставили себе вопрос о том, как это можно сделать. Первое, нужны деньги. Я не скажу, что нужно много денег, но минимум 4000 евро в месяц на двоих. Мне кажется, этих денег вполне достаточно на двоих. Следующее, много путешествовать, то есть иметь возможность, жить в другой стране месяцами, а то и годами. Следовательно, офисная работа нам не подходит. Работать удаленно? Да, круто, но не придел мечтаний, потому что иногда приходится выполнять работу, которая совсем тебе не по душе. Мы идеалисты, мы хотим заниматься тем, что нам нравится. В итоге, мы решили создать свою компанию и заниматься разработкой собственных проектов.

Но стоп, я ж ни черта не шарю в программировании!

C такой мыслью, я начала искать ресурсы, которые научили бы меня основам разработки. Начала я по стандарту c html и css. Изначально, я знала, что буду заниматься front-end разработкой. html и css показался мне очень-очень прост. Я не говорю, что за неделю я стала мастером html, и даже сейчас спустя пол года я оооочень многого не знаю, и часто ищу помощь в интернете, но сам ПРИНЦИП работы не сложный. Мне хватило одного видео на YouTube, где парень делал сайт с Bootstrap.

После просмотра, я начала активно создавать собственные html странички. В основном это были сайты кафе, ресторанов и пиццерий. Мне нравилось и самое главное у меня как, мне казалось, неплохо получалось.

Тем временем, мой парень занимался разработкой приложения Gaspal, которое позволяет сравнивать цены на заправках. Оно доступно только во Франции и в Испании (мы живем во Франции). Я сделала дизайн для приложение и первый лендинг, который вышел в свет. Я была очень счастлива и даже на секундочку подумала, что я программист. Ха-ха-ха.

Дальше, новый проект — одновременная публикация постов в разных социальных сетях на разных языках. Я начала изучать Ruby on Rails. Базу я выучила с codeacademy.

А дальше началась практика. Честно скажу, было тяжело, многое не понимала, искала помощь в Интернете. Очень важно в IT индустрии владеть английским. К счастью, я умею говорить на английском, а в интернете есть ответы на ВСЕ вопросы, ну по-крайней мере вопросы для начинающих. И все наши старания воплотились в нашем проекте crosspost.

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

Следующий проект, наш главный проект на сегодняшний момент, это upload.express.

Помните вирусный ролик на YouTube: «А каким файлообменником ты пользуешься? Конечно же, Скайпом» ? Так вот, upload.express это альтернатива скайпу. Я, конечно, шучу, у нас кроме скайпа хватает конкурентов, особенно на французском рынке, но если есть конкуренция, значит продукт нужен и полезен.

Я полностью занималась front-end разработкой этого сайта. Оцените, неплохо ведь, да? Сайт сделан с помощью JavaScript, а именно библиотеки React.js.

Настоятельно рекомендую канал The Net Ninja всем начинающим front-end разработчикам, очень много полезных обучалок. Именно с ним я учила Реакт.

upload.express это проект, в который я искренне верю и считаю его крутым. Сам файлообменник бесплатный, но есть версия Pro, которая позволяет персонализировать свой файлообменник, следить за аналитикой и продвигать свой собственный бренд.

Конечно, за чуть больше чем пол года я не смогла полностью освоить front-end разработку, но я смогла создать достойные проекты, которыми горжусь. Если смогла я, то сможете и вы!

Идеальный план изучения front-end разработки, по-моему мнению:

2. Ruby on Rails;

3. JavaScript (React.js);

А как считаете Вы? Мне очень интересно знать и ваше мнение, потому что я еще тоже новичок этом деле.

Материал опубликован пользователем.
Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Как показывает опыт успешных и добившихся товарищей, чтобы «вкусно кушать и самое главное много-много путешествовать и т.п.» до 27-30 лет надо не куи пинать, а много-много вкалывать и учиться. Для этого как раз самый продуктивный возраст.Сначала ты работаешь на репутацию, потом она на тебя. Как-то так.

Топ-пост этого месяца:  Мобильные приложения «Вконтакте» стали поддерживать AMP

Абсолютно с Вами согласна! Вот и я учусь, работаю и развиваюсь, чтобы иметь все,что я хочу в будущем.

Хахаха.
В 30 лет, когда ещё и желание есть и силы — вместо работы много-много путешествовать?
В 40 лет, когда ещё и силы есть и опыт — вместо работы много-много путешествовать?
В 50 лет, когда и опыт есть и ресурсы — вместо работы много-много путешествовать?

А в чем крутость проекта upload.express? Вы даже не представляете, сколько сожрет AWS за постоянное хранение данных пользователей бесплатно.

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

Технически может у вас и норм, благо там функционала-то, но. где условия использования сервиса? Где хоть какая-то справка об ограничениях? Сколько можно загрузить, сколько будет хранится? Есть ли предпросмотр картинок? Почему я не узнаю ничего из этого, даже после загрузки файла?

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

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

Почему мне пришлось искать малюсенькую ссылку «тарифы» вверху страницы? И она хотя бы не продублирована в футере?

Что такое «Обмен файлами» и почему это есть в бесплатном тарице, но нет в обоих платных?
Что такое «Загрузка одним файлом»? Загрузка чего? Судя по всему, вы имели ввиду возможность _скачать_ несколько файлов архивом. Но везде вы пишете только про загрузку, а скачивание — это другое.
«4 Гб за загрузку» — это что такое? Максимальный размер загружаемого файла? А сколько за одну загрузку на остальных тарифах? И сколько лимит дискового пространства базового тарифа? Домен входит в стоимость платных тарифов и на кого он оформляется? Или возможно только прикрепление уже имеющегося домена?

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

Frontend- и backend-разработка: принципы и отличия

Этот материал расскажет о том, что такое frontend- и backend-разработка, чем они отличаются и как взаимодействуют между собой.

Что такое frontend-разработка?

Frontend — это разработка пользовательского интерфейса и функциональности, которые работают на клиентской стороне веб-сайта или приложения. К этому виду разработки можно отнести все, что видит пользователь, открывая web-страницу. Frontend-разработчик сотрудничает с дизайнерами, программистами и UX-аналитиками, чтобы создавать удобный и востребованный продукт.

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

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

К frontend-разработке относятся:

  • HTML (HyperText Markup Language) — язык разметки документов, при помощи которого формируется структура страницы: заголовки, абзацы, списки и так далее;
  • CSS (Cascading Style Sheets) — язык для описания и стилизации внешнего вида документа. Благодаря CSS-коду ваш браузер понимает, как именно отображать элементы. CSS задает цвета и параметры шрифтов, определяет, как будут располагаться разные блоки сайта, и так далее. Еще он позволяет выводить один и тот же документ в разных стилях, например, для печати (обычной или шрифтом Брайля), вывода передачи на экран или чтения голосом;
  • JavaScript — это язык, который создавался для того, чтобы оживить веб-страницы. Его задача — реагировать на действия пользователя, обрабатывать клики мышкой, перемещения курсора, нажатия клавиш. Еще он посылает запросы на сервер и загружает данные без перезагрузки страницы, позволяет вводить сообщения и многое другое.

Что такое backend-разработка?

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

Например, когда вы вводите запрос на странице поисковика и жмете клавишу Enter, frontend заканчивается и начинается backend. Ваш запрос отправляется на сервер Google или Яндекса, где расположены алгоритмы поиска. Именно там случается все «волшебство». Как только на мониторе появилась информация, которую вы искали, — вновь происходит возвращение в зону frontend .

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

Backend — это процесс объединения сервера с пользователем.

Backend-разработчик может применять любые инструменты, доступные на его сервере. Он вправе выбрать любой из универсальных языков программирования, например, Ruby, PHP, Python, Java.

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

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

Как взаимодействуют frontend и backend?

Взаимодействие frontend и backend происходит по кругу: frontend отправляет пользовательскую информацию в backend, там она обрабатывается и возвращается обратно, приняв понятную форму.

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

Существует несколько вариантов взаимодействия frontend и backend:

  • HTTP-запрос напрямую отправляется на сервер, сервер ищет информацию, встраивает ее в шаблон и возвращает в виде HTML-страницы;
  • Вариант с использованием инструментария AJAX (Asynchronous JavaScript and XML). В этом случае запрос отправляет JavaScript, загруженный в браузер, а ответ приходит в формате XML или JSON;
  • Одностраничные приложения, которые загружают данные без обновления страницы. Это делается также при помощи AJAX или фреймворков Angular и Ember;
  • Ember или библиотека React помогают использовать приложение и на сервере, и в клиенте. Frontend и backend взаимодействуют через AJAX и HTML-код, который обрабатывается на сервере.

Как мы видим, современная разработка — это сложный и многоуровневый процесс, который делится на две части: клиентскую и серверную. В арсенале frontend- и backend-программистов есть масса инструментов, выбор которых зависит от поставленных задач и сложности проекта. Оба вида разработки включают в себя технические и творческие компоненты.

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

Начать свой путь во frontend- и backend-разработке можно с 12-месячного курса Skillbox «Профессия веб-разработчик». Он подходит для новичков и программистов с небольшим опытом. За год слушатели курса на практике изучат основные языки программирования и создадут собственное портфолио, которое поможет найти перспективную и хорошо оплачиваемую работу.

Front end разработка: что это такое или как сделать живой и умный сайт

Браузер отображает всё, что получает от сервера и «понимает». Это даёт основание определить процесс отображения и процесс формирования данных на две составляющие. Посетитель, просматривая страницу, предпринимает действия, что даёт основания функционалу страницы «управлять» сервером.

Сервер формирует первую страницу, когда браузер «заходит» на сайт. Затем сервер ожидает «указаний». При таком положении вещей: front end и back end разработка действительно повод дать работу двум категориям разработчиков параллельно.

Сайт — это единая система

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

На науку инфосфера ещё не тянет. Этап «строительства» программ и сайтов уже позади. Область информационных технологий спокойно развивается, а разработчики действуют на свой страх и риск, уважая мнение коллег, не особенно критикуя варианты работы каждого, принимая происходящее как есть, во всём его многообразии.

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

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

О возможностях front-end

Книга «Front-end. Клиентская разработка для профессионалов» — своего рода концентрат качественного и практичного описания JavaScript, HTML5 и CSS3, ориентированного на квалифицированного разработчика, стремящегося к разработке качественного «клиентского» кода.

Node.js, ES6, REST, практичные примеры и отличный стиль. Вне сомнения, «Front end: клиентская разработка для профессионалов» — это отличное и полезное издание, фундаментальные основы для разработчика — библия знаний и процессов их эффективного применения.

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

Сложилось мнение, что есть независимые квалификации по гипертексту (HTML), по языку XML, по таблицам каскадных стилей (CSS) и другим направлениям. Естественно, трудно не разделить работу:

Так сказать, очевидно, front end разработка — что это: принципиально важно, но это вовсе не работа на сервере.

Об особенностях back-end

Мир интернета обслуживает великое множество серверов и технологий. Здесь Apache, во всех его действующих версиях, по-прежнему законодатель мод. Семейство юниксоидов по сей день не уступило пальму первенства в серверном деле никаким другим платформам.

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

Это уровень серверных технологий, то есть, это не front-end разработка, что это значит — вроде как ясно: здесь нет браузера, но есть PHP или другой серверный язык.

Протокол HTTP (или другой) позволяет браузеру обратиться к серверу за получением страницы, и браузер отвечает взаимностью. Серверный язык отрабатывает функционал, созданный разработчиком «back-end» и передаёт «front-end» в браузер. Это может быть первая страница, обновление страницы или переход к другой странице, включая переход по ссылке на другой сайт, то есть на другой сервер.

Совмещение back-end + front-end разработка: что это, возможно ли это?

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

  • интернет-робот;
  • «паук» — модный бренд в сфере парсинга;
  • иное программное изделие.

Браузеров много, но его DOM-ская логика и JavaScript в 99.9% случаев — основа для отображения ответа сервера. Любой поток информации от сервера браузер пытается трансформировать в DOM и предполагает в нем найти:

Эта святая троица составляет front-end и разработку: что это такое и как это применить — вроде как предельно ясно.

DOM — это дерево, так привычно и традиционно звучит. На самом деле DOM — это, отлично продуманная система, а JavaScript — её родной язык. В этом контексте знания — Front-end: клиентская разработка для профессионалов в pdf-формате — это очень хорошо, но идеально в формате настольной книги, которая всегда на виду.

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

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

Система клиент + сервер

Если говорить о браузере, это всегда законченное изделие, у него есть собственная аура, и он обязан исполнять конкретный функционал, иначе он — не браузер. Сервер — также законченное изделие, функциональность которого гораздо шире, а ответственность гораздо выше.

И браузер, и сервер — совершенно самостоятельные и независимые системы. Кстати говоря, сайты — вовсе не единственное, н что способны и браузеры, и серверы. Это просто отличные программные системы, удовлетворяющие конкретным сферам применения.

Веб-ресурс — причина, по которой браузер и сервер начинают взаимодействие и продолжают его до тех пор, пока клиент не уйдёт на другой сайт.

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

Сайт могут создавать несколько разработчиков, но это должна быть команда. Команда квалифицированная и тесно связанная. Один может создавать CSS-правила, другой — компоновать только теги HTML, третий вдохновенно расписывать функционал на JavaScript по тегам, правилам и событиям. Но это должна быть взаимосвязанная команда, которая учитывает серверную часть, не отделяя ее от браузерной.

Невозможно написать код на PHP, который не владеет тем, что написал CSS-разработчик, скомпоновал специалист по HTML и обозначил JavaScript-программист. Иначе сайт не станет системой, а если сайт — не система, то это не сайт, а пустая трата сил и времени на создание страниц front-end’a, которые отражают то, что смогут разобрать в полученном от back-end’a. Последний отвечает взаимностью, понимая так, как получается, все что прилетает от браузера.

Точка всемирной сети: сайт = система

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

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

Если веб-ресурс удовлетворяет определённым требованиям — он есть и доступен в сети. Если нет, то не важно, как соотносится back-end и front-end — что это такое, так и останется тайной.

Frontend интернет-магазина и проблемы с ним

Внешний вид сайта интернет-магазина это не только UI и UX, но и куча неявных и неочевидных механизмов их формирования. Дизайн «вообще», всплывающие модальные окна, интерактивность взаимодействия с пользователем, кроссбраузерность отображения сайта в разных браузерах, корректное представление на мобильных устройствах и т.д. и т.п. — это все фронтенд / front-end / frontend. При всей своей «очевидности» и «естественности» он имеет скрытые, хронически наследуемые технологические болезни, которые совершенно всегда трансформируются в бизнес-проблемы.

Эти проблемы связаны с дисциплиной фронтенд-разработки

Фронтендом сайтов занимаются люди, которых называют, в профессиональной среде, — фронтенд-разработчиками. В основе профессии фронтендера лежат

  1. работа с каскадными стилями — CSS и их расширенными версиями — LESS, SCSS, SASS и т.д.
  2. работа с javascript и различными библиотеками / фреймворками — jQuery, Prototype, TypeScript, Angular, Vue и т.д.
  3. работа с html и фреймворками — Bootstrap, Bulma, Foundation и т.д.

Также, практически неотъемлемой частью, является работа со всевозможными утилитами-помощниками: менеджерами пакетов, сборщиками проекта, таск-менеджерами и тому подобными вещами — Webpack, Gulp, Bower и т.д. и т.п. К этому можно добавить шаблонизаторы — Smarty, Twig, Volt — и прочие плюшки типа Node.js Плюс, конечно же, свои фирменные «велосипеды» и корпоративные решения.

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

Особо следует заметить, что технологии в части front-end разработки развиваются просто сумасшедшими темпами! Мода на то или иное решение или инструмент меняется с угрожающей стабильности скоростью. Теперь представьте, что Коля в 2014 работал в своей манере, Вася в 2020 — в своей, а Юра в 2020 — вообще по супермодному. Вполне логично, что в 2020 году, владелец интернет-магазина или нескольких e-commerce проектов будет иметь полнейший ералаш в части этого самого фронтенда.

Неконтролируемое многообразие приемов frontend-разработки порождает технологический хаос

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

Вы представляете, что будет чувствовать Марат в 2020 году, когда попытается разобраться в том, что до него делали Коля, Вася и Юра каждый на свой лад?

Да, сотрудникам надо давать «поиграться» с чем-то новым-модным-интересным, но только не на боевых проектах! Процесс опробации-изучения-допиливания не имеет временных пределов и эмоциональных границ, поэтому бизнес приносящий деньги не должен страдать от «хотелок» конкретного фронтендера.

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

Не надо тренироваться на проектах приносящих деньги

Добавить комментарий