Master-webЯ смотрел это доклад Вадима Макиашвили раньше, когда мне еще не было 36. Хотел пересмотреть когда исполниться 36 и вот, правда не в День рождения, а с опозданием в пол года сделал это.
Рекомендую к просмотру всем, кто в профессии и кто достиг или на грани возраста. Это софт-скилс. Без этого никак.
Чуть более года назад, я написал пост Мой новый любимый редактор — Atom, в котором рассказал о смене старого-доброго Саблайма на Атом. Но время шло, и по мере моего все большего увлечения JavaScript и, в частности TypeScript и Angular, как средствами написания правильного модульного кода, мне пришлось снова сменить редактор. И вот уже порядка 5-6 месяцев я пишу код, используя VS Code. Почему так сложилось, потому, что изначально VS Code заточен под работу с TypeScript, не мудрено ведь и редактор и «язык» детища Microsoft, а там постарались, чтобы они как нельзя подходили друг другу. По моему сугубо личному мнению — это вообще два наиболее удачных продукта компании. Но сейчас не об этом, сейчас а том, как дополнить VS Code, чтобы писать приложения на Angular 4 на нем было максимально удобно.
В статье Фронтенд по фэн-шуй. Часть 2, я писал об инструментах для генерации стайл-гайдов, но все они так или иначе зависели от технологии разработки, или делали вас зависимыми от нее. Однако, в том обзоре я большое внимание уделил PatternLab, мейнтенером которого является Бред Фрост. А в предыдущем посте-ссылке, я рекомендовал вам к прочтению материал из блога Бреда Фроста о разработке дизайн-систем независимых от технологии. Бред не просто говорит об этом, но и пытается воплотить это в жизнь.
В блоге Бреда Фроста появились два очень интересных поста. Они не очень велики по содержанию, но затрагивают поистине важнейшие вопросы разработки фронтенда. Думаю у многих зависимость от технологии на которой строиться ваш ресурс было решающим в выборе инструментов для разработки фронтенда. Как правило, хочеться иметь максимально интегрированные решения, но как раз здесь и кроется спорный вопрос. Возможно, «священным граалем» как раз может стать решение разработки фронта максимально независимого от контекста. То есть, на уровне стайл-гайда или библиотеки компонентов вы выбираете решения, которые можно вписать в любую среду (ну или почти любую). В общем, если вы задумывались об этом, то в посте бреда есть очень неплохие мысли.
https://bradfrost.com/blog/post/managing-technology-agnostic-design-systems/
И продолжением предыдущего поста стала заметка об независимых от технологии шаблонизаторах в разработке фронтенда.
https://bradfrost.com/blog/post/template-technology-agnosticism/
В сегодняшней, третьей части, статьи мы поговорим о компонентном подходе в разработке фронтенда. Тем, кому интересно начало истории, можно ознакомиться с первой и второй частью этой статьи. Итак, без лишних вступлений — начинаем.
Очень сложно придерживаться модульности и компонентного подхода во фронтенде. Многое часто зависит от конкретного проекта. Важно как вы рендерите фронт, что используете. Однако, если у вас есть возможность придерживаться компонентного подхода в разработке фронтенда — вы должны это делать. Не обязательно придерживаться хрестоматийного определения компонентов, но вы должны, как минимум держать все вместе.