34 лучших инструмента для frontend-разработчика

PM — Project manager

менеджера проектовPMPM

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

• английский Upper Intermediate и выше, так как ПМ коммуницирует со стороной заказчика от лица команды;
• широкие технические знания, но не сильно глубокие, чтобы можно было понимать, кто чем занимается, как происходит работа в целом, не сильно углубляясь;
• навыки управления проектами и участвующими в них командами;
• сильнейшие коммуникационные навыки, так как работа PM в основном состоит из коммуникаций с членами команды, руководством;
• развитые навыки ведения переписки. К примеру, часто нужно посылать письма на email заказчика от лица команды, компании, и письмо неправильно составленное или с ошибками никто не оценит;
• аналитический склад ума, который будет полезен при решении проблем, возникающих во время работы над проектом;
• навыки тайм-менеджмента, использование которых позволит держать проекты в рамках графика и бюджета (ведь время=деньги);
• навыки планирования ресурсов и задач.

700$1200-4500$В кого можно вырасти:

• delivery manager (DM) — прямое продолжение PM-a, стоит сразу над группой PM-ов и координирует их проекты на более высоком уровне;
• program manager — координирует несколько взаимосвязанных проектов, но я сам не сильно понимаю различие с DM-ом;
• chief technical officer (CTO) — технический директор, несущий ответственность за разработку продуктов и улучшение их процессов создания;
• chief executive officer (CEO) — главный исполнительный директор;
• account manager (AM) — менеджер по работе с клиентами;
• переучиться и перейти в другую специальность ))

С чего начать и что читать? Чек-лист обучения

1. Как работает Веб

• How the Web Works: A Primer for Newcomers to Web Development or anyone really (FreeCodeCamp);
• Как работает Веб — Mozilla (MDN);
• Всё, что нужно знать про HTTP.

2. Среда разработки

• VSCode — бесплатный быстрый редактор с большим количеством дополнений для разработки;
• JetBrains WebStorm — полноценная IDE, есть пробный период и возможность получить доступ по студенческой лицензии;
• Если у вас возникает потребность отправить другому человеку фрагмент кода, быстро проверить или сохранить код в сети, можно воспользоваться онлайн-редактором, например, Codepen.

3. Основы HTML

• Руководство по HTML — Mozilla (MDN);
• Справочник по HTML, уроки по HTML и CSS — Webref;
• FreeCodeCamp — Learn to code at home — очень полезный источник для практического изучения HTML, CSS, JS и др. (пошаговые задачи в интерактивном режиме обучения);
• Введение в Chrome DevTools. Панель Elements для просмотра HTML-элементов сайта;
• Семантика (HTML5 Semantic Tags: What Are They and How To Use Them!, рус. перевод);
• Доступность (Writing HTML with accessibility in mind, рус. перевод).

4. CSS

• CSS и CSS3. Свойства для форматирования HTML элементов — Html5Book;
• Cascading Style Sheets (CSS) — Mozilla (MDN);
• Справочник по CSS — Webref;
• Инструменты разработчика Chrome DevTools для просмотра стилей;
• Вёрстка на Flexbox в CSS. Полный справочник (перевод и оригинал на CSS Tricks);
• 10 modern layouts in 1 line of CSS от Google;
• БЭМ Методология;
• БЭМ для начинающих. Очевидные и неочевидные вопросы верстки.

5. Система контроля версий Git

• Интерактивный тур по GIT для начинающих — GitHowTo;
• Github — крупнейший веб-сервис для хостинга IT-проектов и их совместной разработки.

6. Язык программирования JavaScript

• Современный учебник JavaScript — отличный источник с множеством примеров;
• Серия книг «Вы не знаете JS» — подробный гид по основным механизмам языка (каждая книга подробно разбирает часть языка);
• Не забывайте про уже упомянутый FreeCodeCamp с задачками для практики JS;
• Онлайн-курс по JavaScript для начинающих в виде рассылки писем от Дэна Абрамова (разработчик из Facebook, создатель Redux и Create React App);
• Chrome Dev Tools. Отладка JavaScript кода.

11. Препроцессоры CSS

• Sass (SCSS);
• Stylus;
• Less.

• Модульность. Вы сможете создавать CSS-код в разных файлах и импортировать стили при необходимости.
• Вложенность. Вкладывайте селекторы друг в друга для компактности и логичной структуры кода. Это улучшит читабельность и уменьшит дублирование (будет особенно удобно, если вы станете использовать BEM-методологию для написания CSS).
• Использование CSS-переменных и функций (миксинов).
• Вы можете выбрать препроцессор с удобным для вас синтаксисом (например, CSS-код без фигурных скобок и точек с запятой).

PostCSS

стандарт компании Airbnb

• Prettier;
• ESLint;
• EditorConfig;
• Husky.

14. Изучение фреймворка/UI-библиотеки

официальной документацииModern React and Reduxпроверка типов с помощью PropTypesJSDocцикл статейReduxпереводомGetting Started with Reduxдокументация

16. Углубленное

• Как браузеры рендерят сайт (Ryan Seddon: So how does the browser actually render a website | JSConf EU 2015);
• Как работают браузеры — Html5Rocks;
• Филипп Робертс: Что за чертовщина такая event loop? | JSConf EU 2014;
• CSS-модули (статья Glen Maddern);
• Оптимизация производительности фронтенда;
• Вводный курс по VSCode для JS разработчиков (Владилен Минин);
• Руководство для начинающих по HTTP и REST;
• Что такое CORS;
• Паттерны проектирования (книга Javascript Design Patterns);
• Progressive Web Applications;
• Redux-Saga для продвинутого управления состоянием React-приложения.

Оплата труда

Ступеньки карьеры и перспективы

Начинающий фронт-энд разработчик должен обладать навыками верстальщика. Далее карьера может развиваться в нескольких направлениях:

специализация в бэк-энд разработках (Python, РНР) приведёт его к профессии бэк-энд разработчика;
увлечение пользовательским интерфейсом — к профессии фронт-энд разработчика;
внимание к дизайнерской части проекта — к профессии дизайнера;
совместное владение навыками фронт-энд и бэк-энд разработчика — к профессии фулл-стак разработчика. 

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

Интересные факты о профессии

Типы разработчиков

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

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

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

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

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

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

Автор Флюра Ягофарова

Двигаемся к Модели приложения (Application model)

Вскоре стало понятно, что Application State не может быть полностью изолирован от GUI. Всегда существует какая-то логика представления (Presentation logic) или состояние представления (View state), которые необходимо поддерживать.

Но это может вызвать проблемы. Давайте возьмем наш предыдущий пример счетчика. Когда наш счетчик достигнет 10, мы должны изменить цвет метки с черного на красный, чтобы указать предупреждение. Такое поведение изменения цвета на самом деле не является бизнес-логикой или задачей. Это чисто эстетическая часть (UX), которая должна быть учтена. Настоящий вопрос — где? Это должна быть Модель или Представление?

Поскольку эта Логика представления или Состояние представления в основном представляет собой состояние, полученное из Модели предметной области, оно должно поддерживаться в Модели. Но Модель предметной области, поддерживающая визуальный аспект, — то есть красный цвет — по определению не очень хорошо. Если же мы поместим это в объект Представление, то это создаст еще один набор проблем. Наш виджет больше не является шаблонным. Мы не можем использовать его в другом месте. Кроме того, добавление условия с жестко закодированным числом 10 в наш объект View означает, что мы ограничиваем некоторую часть бизнес-логики.

Чтобы решить эту проблему, в исходную MVC была добавлена еще одна сущность — Модель приложения (Application Model, AM). Как видно на рисунке, с Моделью приложения пара View-Controller не имеет прямого доступа к модели. Вместо этого они регистрируются в событиях Модели приложения и используют его для доступа к необходимым данным.

Потоки данных остаются такими же, как и у классического MVC. Конечно, у каждой модели есть свои плюсы и минусы, и AM-MVC не исключение. Наиболее заметная проблема заключается в том, что Application Model не имеет прямой ссылки на объект View и, следовательно, не может манипулировать им напрямую, даже если Application Model предназначена для поддержания состояния View.

QA Automation

QA AutomationQA ManualQA AutomationQA ManualQA ManualQA Automationобязанности AQA входит

• изучение требований, спецификации и прочей документации;
• создание и настройка тестовых сред для выполнения тестовых случаев и сценариев;
• проектирование, создание и выполнение автоматизации тестовых сценариев (планов тестирования) с использованием Selenium в соответствии с определенными стандартами и методологиями обеспечения качества;
• изучение ручного тестирования приложения и внесение предложений по возможности автоматизации;
• поддержание актуальных автоматизационных тестовых случаев;
• написание документации;
• поддержание необходимого уровня тестового покрытия (test coverage);
• при необходимости — помощь с ручным тестированием. Может выполнять вручную тестовые примеры и сценарии для разрабатываемых продуктов с помощью инструментов управления тестированием;
• участие в разработке, а именно — в администрировании процесса контроля качества;
• коммуникация с командами разработчиков о несоответствиях функционала и багах.

CIНеобходимые навыки:

уровень английского — Intermediate;
хорошее понимание методологий и практик обеспечения качества;
отличное знание синтаксиса одного языка (например, Java или JavaScript), ведь на чём-то нужно писать тесты;
написание автоматизационных тестов с помощью Selenium;
знакомство с CI/CD;
умение работать с Git;
внимание к деталям;
критичный склад ума. AQA

AQA

• QA lead;
• переучиться и перейти в другую специальность.

QA Automation600$1700-2500$4000$английский язык

Что почитать еще:
Кто есть кто в IT. Чем занимаются HR, админы, DevOps и бизнес-аналитики

MVC предков — Первоисточник

Отделение данных от представления является основной темой графических пользовательских интерфейсов (как веб-ориентированных, так и настольных). С MVC — Model View Controller, отделение представления (View) от доменной области (Model) было основной мотивацией проектирования. И, без сомнения, MVC была плодотворной работой, которая повлияла на будущие поколения.

MVC был представлен для Smalltalk-80. В MVC объект View отображает данные, хранящиеся в объекте Model. Прежде чем мы сможем полностью изучить потоки данных в MVC, мы должны понять среды прикладных программ того времени (около 1970-х годов):

• Этот MVC был предназначен только для настольных приложений. Веб еще не родился. Мы говорим о десятилетии до этого.
• Забудьте о Web. Сложных операционных систем с графическим интерфейсом не существует.
• Это означает, что прикладное программное обеспечение было очень близко «железу» систем.

Эти ограничения имели важные последствия для MVC. Обязанностью объекта Controller стало реагирование на пользовательские вводы, такие как клавиатура или мышь, и их преобразование в действия над моделью. Кроме того, отсутствие графических элементов в операционных системах означает, что Представление (View) не соответствует тому, что на экране.

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

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

С точки зрения связей:

1. View и Controller содержат прямую ссылку на Model, но не наоборот. Это означает, что Model не зависит от пользовательского интерфейса и может меняться, не беспокоясь о проблемах пользовательского интерфейса.

2. Модель реализует шаблон Observer, и на него подписывается один или несколько объектов View. Когда Model изменяется, она вызывает событие, и View обновляется после реакции на событие.

В MVC есть два разных потока данных. Во View-потоке Model не участвует. Это только изменение пользовательского интерфейса. Показ эффекта нажатия кнопки или реакция на событие прокрутки мыши — пример View-потока.

Сегодня мы больше не используем этот MVC и поэтому иногда его называют классическим MVC или MVC предков (father’s MVC).

TypeScript. Adopt

Недавно мы провели внутренний опрос фронтенд-разработчиков (как State of Frontend, только по Тинькофф), который прошли 159 фронтенд-разработчиков. В опросе была секция про TypeScript, ответы на которые дали нам уверенность, что TypeScript стал стандартом разработки фронтенда, по крайней мере в Тинькофф.

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

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

В нашем блоге вы можете найти пару полезных статей про TypeScript:

• Простые TypeScript-хитрости, которые позволят масштабировать ваши приложения бесконечно
• 12 советов по внедрению TypeScript в React-приложениях

Какие трудности могут быть? Ошибки в начале пути

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

Иногда будет казаться, что лучше сразу изучать какой-нибудь популярный фреймворк или библиотеку. Это достаточно частая ошибка, особенно во фронтенде: люди начинают изучать React или верстают с помощью Bootstrap и Material UI, не разобравшись в основах и не получив достаточных знаний по HTML, CSS и JavaScript. Можно использовать такой подход, если вы «бежите на короткую дистанцию» и вам нужно быстро сделать какой-нибудь проект. Но если вы планируете стать разработчиком, это не принесет нужного результата.

Нет необходимости знать наизусть абсолютно все CSS-свойства или методы в JS, вы сможете поискать их, если забудете

Важно понимание основных концепций и тонкостей: это то, что будет вашим крепким фундаментом во фронтенд-разработке

Обучение — это труд, самодисциплина и много практики

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

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

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

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

Копирование чужого кода

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

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

Не доверяйте на 100% коду, который вы находите

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

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

Что говорит статистика

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

• по данным StackOverflow, JavaScript в списке инструментов фронтенда лидирует с огромным отрывом (90,5%);
• исследование компании O’Reilly, проведенное среди европейских программистов в конце 2016 года, тоже ставит JavaScript на первое месте.

Далее идут различного рода фреймворки и библиотеки, самые популярные из которых Angular, Node.js, React. Кроме обязательного JavaScript, фронтенд-разработчики также используют и другие языки, хоть и не так часто. Лидируют PHP, SQL, Java и С#. И, конечно же, не обойтись фронтендщику без навыков работы с CMS. Самый популярный выбор — WordPress.

Данные StackOverflow

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

Данные StackOverflow

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

Серверная MVC a.k.a. Модель 2

Первой известной реализацией серверной MVC является Модель 2 от Sun Microsystems для веб-приложений на Java.

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

Некоторые вещи, на которые стоит обратить внимание:

• Десктопный MVC имеет два цикла данных (Data cycles), а веб-MVC — три цикла данных.
• Есть два цикла Представления (View cycles). Первый — это цикл Представления клиента, такой как событие прокрутки, ввод с клавиатуры и т.д. Второй — цикл Представления сервера, такой как обновление страницы, активация гиперссылки и т.д.
• Наконец, у нас есть цикл модели (Model cycle), который имеет дополнительную сложность по времени, поскольку он пересекает границу клиент-сервер.
• Front Controller: компонент, обычно предоставляемый базовым технологическим стеком для обработки отправки HTTP-запросов. Например, контейнер сервлетов в веб-приложениях Java, IHttpHandler в классе ASP.NET или HTTP.Server в Node.js.

Считается, что сегодня SSR (Server Side Rendering) — рендеринг на стороне сервера означает совершенно другую концепцию. Однако это не совсем так. Поскольку весь HTML/контент создается сервером, а клиентский код JavaScript не используется, веб-приложения, полностью созданные с использованием серверной MVC, все еще рассматриваются как SSR.

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

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

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

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

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

Язык CSS. Практически на всех курсах CSS преподается вместе с HTML. CSS – это система стилей, за счет которых сайты смотрятся красиво.

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

Третий фундаментальный элемент – Джава Скрипт. Это, наверное, самое сложное и самое ценное во фронтенде. Джава скрипты помогают изменять HTML коды так, чтобы решать проблемы пользователя.

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

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

Что следует знать фронтендщику о дизайне и не только

Сетка. Практически все макеты строятся на основе сетки. Зная её, верстать становится проще, а учитывая, что теперь у нас есть grid, это превращается в удовольствие.
Основы Figma. Говорить с дизайнером на одном языке и понимать особенности и отличия вёрстки в Figma и WEB-е.
БЭМ

Неважно, как вы верстаете, будь то CSS-in-JS или CSS-modules, методология позволяет навести порядок в голове и мыслить правильными категориями.
Наследование стилей. Многие CSS свойства наследуются от родительского блока, в Figma это отсутствует.Чтобы не переписывать все стили, не глядя , помните, какие свойства берутся от родителя, а какие объявляются в самом элементе.
Конечные автоматы

Понимать, сколько состояний может быть у того или иного элемента на странице.

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

Интересные люди

• Mathias Bynens — разработчик V8, высокопроизводительного JavaScript- и WebAssembly движка от Google с открытым исходным кодом.
• Jake Archibald — веб-евангелист и представитель браузера Google Chrome, один из лучших экспертов компании, автор множества докладов на уникальные темы.
• Phil Walton — инженер в Google, работающий над браузером Chrome, имеет опыт разработки с 1998 года и ведет персональный блог.
• Monica Dinculescu — “emojineer”, работает в Google над проектом Magenta, создавая музыку и изобразительное искусство с помощью машинного обучения.
• Tim Kadlec — технический консультант по производительности, делающий веб более быстрым, автор нескольких книг и участник конференций.
• Léonie — специалист по доступности и сооснователь W3C Web Platform WG.
• Eric Meyer — эксперт в области HTML и CSS, автор множества статей и книг, создатель нескольких полезных инструментов и ресурсов. Более подробно — на его личном сайте.
• Una — веб-евангелист и директор по дизайну продуктов в Bustle Digital Group.
• Harry Roberts — независимый веб-консультант по производительности, работающий с крупнейшими международными корпорациями. Приглашенный эксперт Google, отмеченный наградами разработчик, международный докладчик и посол по вопросам эффективности в SHIFT Commerce.
• Alex Russell — техлид по стандартам команды Chrome, участник группы технической архитектуры W3C и разработчик ECMA TC39 (стандарт JavaScript).
• Surma — веб-евангелист в Google.
• Manuel Matuzović — профессиональный веб-разработчик с 2008 года и фрилансер с 2010 года, специалист в HTML, доступности, CSS-верстке и архитектуре.
• HJ Chen — веб-евангелист в Nexmo.
• Jen Simmons — дизайнер-евангелист в Mozilla, член рабочей группы CSS, который знает, как CSS Grid меняет веб-дизайн.
• Martin Splitt — евангелист OSS1 и разработчик в Google.
• Maximiliano Firtman — независимый разработчик мобильных и веб-приложений, ментор и докладчик, занимающийся прогрессивными веб-приложениями, производительностью, мобильностью и веб-платформой. Автор множества технических статей и книг о программировании.
• Rachel Andrew — веб-разработчик, член рабочей группы CSS и главный редактор Smashing Magazine.
• Roma Komarov — frontend-разработчик, специализирующийся на CSS, создатель Hayaku, bemto-компонентов, bemto для Pug.js и так далее.
• Addy Osmani — руководитель команды Speed Team в Google Chrome, которая делает веб быстрее. Также Addy работает над несколькими проектами с открытым исходным кодом — более подробно на персональном сайте.

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

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

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

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

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

• Меню приложения
• Виджет Twitter
• Простое плоское меню

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

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

Disappearing Frameworks. Assess

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

Кандидаты в эту категорию: Stencil, Svelte, Solid и Angular Elements.

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

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

Более подробно познакомиться с подходом Disappearing Frameworks можно в статье Питера О’Шонесси.