Пользователь
Когда-нибудь задумывались над тем, чем, в сущности, является программирование?
Случилось так, что я показывал коллегам дуговую зажигалку и удивлялся что про них в принципе мало кто знает (с другой стороны я и сам о них не знал, пока не подарили). Ну и обронил при этом фразу "Вроде бы это даже моя сфера, но не знал", на что мне резонно заметили что как бы физика электричества от программирования далека. И в целом это так, но с другой стороны...
18 апреля 2022 года, после 5 лет доработки (первый коммит от 30 апреля 2017 года), proposal по декораторам наконец-то достиг 3 стадии, что означает что у него есть спецификация, тестовая имплементация и осталась только полировка на основе фидбека от разработчиков. Учитывая что это уже четвертая (!) итерация декораторов, их переход в стадию принятия это эпохальное событие для JS - не припомню ни одной другой фичи, которая прошла такой длинный и тернистый путь, с диаметрально разными подходами и аж двумя разными legacy-имплементациями, в Babel и TypeScript. Давайте же посмотрим на неё повнимательней.
После взлёта тайпскрипта (извини, flow) нетипизированные области фронтенда стали мозолить глаза гораздо сильнее. Логика уже давно на TS, вёрстка, при необходимости, на TSX, а вот у CSS ситуация посложнее.
Можешь использовать CSS файлы (с диалектами и модулями по вкусу) и указывать классы в вёрстке руками - но типизация здесь на уровне "препроцессор может сгенерировать тайпинги со списком классов прямо в рабочем дереве", да и в общем интеграция с рантаймом никакая. При этом гибкость диалекта достигается с помощью плагинов - которые, в общем случае, друг с другом (и, тем более, с IDE) могут и не дружить.
Либо бери любое из CSS-in-JS решений, предоставляющих полную типизацию и интеграцию с остальным кодом, но готовься платить ощутимое пенальти в рантайме - всё же парсинг объектов/строк со стилями занимает ощутимое время. Гибкость при этом, разумеется, максимальная.
Где-то в промежутке между ними находятся проекты вроде linaria или astroturf, которые предполагают парсинг CSS-in-JS на этапе компиляции (примерно как с graphql-tag). Типизация на уровне, производительность в рантайме - тоже, однако это всё ещё препроцессоры строк, пусть и более умные, так что расширяемость оставляет желать лучшего.
Вот тут-то в дело и вступает vanilla-extract. Пару месяцев назад Mark Dalgleish (один из создателей CSS модулей, кстати) решил узнать что получится, если использовать для препроцессинга стилей... сам тайпскрипт!
Спойлер: получилось очень хорошо. Впрочем, обо всём по порядку.
Идея что фронтенд это "для джунов", расстраивает меня тем, что никто не скажет так про другие специализации.
Кто-то может сказать, что неплохо, если б автор компилятора был более "фуллстековым".
Но они не скажут, что "писать компиляторы это для джунов".
Это перевод треда Yehuda Katz из твиттера. Под фронтендом здесь подразумеваются именно браузерные приложения на JS (и, отчасти, вся JS-экосистема).
yarn install из скриптов CI, мы начинаем очередную великую JavaScript-смуту. Если вкратце:Если вы не хотите обновлять все ваши проекты, просто запустите yarn policies set-version ^1 (смотри legacy.yarnpkg.com/en/docs/cli/policies) в репозиториях, которые должны остаться на Yarn 1 и закомитьте результат. Тогда Yarn будет использовать локальные бинарники Yarn 1 вместо глобальных так что все в команде будут использовать одну версию!Делал я тут небольшой проект на чистом JS и в ходе оного потребовалось работать с Rest API. Ну не ручками ведь XMLHttpRequest дёргать, решил я, наверняка есть бесчисленное количество готовых решений для такой простой задачи?..
Как можно догадаться по КДПВ, я несколько ошибался; впрочем, обо всём по порядку. Но если вкратце — получился вот такой симпатичный велосипедик, с которым запросы к Rest API получаются, как и обещано в заголовке, компактными и красивыми.
