Front-end engineer
Обычно, в подобных статьях я выступаю на позитивной стороне и говорю, что не все так плохо, что умелыми руками можно делать прекрасные вещи. Однако, недавно со мной произошло несколько историй, которые заставили меня пересмотреть некоторые вещи.
В этой статье я перескажу истории с некоторыми техническими деталями и порассуждаю, что делать дальше.
Началось все с устройства на новую работу. Новый проект казался интересным, коллеги – доброжелательными, так что я с радостью принял оффер. Первое время я только погружался в проект, разбирался с его особенностями и особо ничего не критиковал. Все-таки я тут новичок, ещё не в курсе всей ситуации, и вообще, в чужой монастырь со своим уставом не лезут.
Однако по окончании испытательного срока я уже понял, что в команде я остаюсь, а значит было бы неплохо влиять на будущее проекта и активнее выражать свое мнение, даже если оно кажется непопулярным. Проект уже разрабатывался долгое время, в нем накопилось немало технического долга, который меня сильно расстраивал. Я пытался его постепенно разбирать, работая по скаутскому принципу – оставлять поляну (в данном случае код) чище, чем она была до моего прихода. Однако, этого было мало, нужно было склонить к этому и остальных коллег тоже, чтобы пока я улучшал в одном месте, они не накапливали долг в другом.
Как мне казалось, все предложения я вносил конструктивно, ни о какой токсичности подумать и не мог, но в реальности все вышло иначе.
В этом году будет 10 лет как я зарегистрирован на этом сайте и немногим больше я занимаюсь веб-разработкой, в основном фронтендом. Я начал в маленькой веб-студии на 5 человек, а теперь работаю в многотысячной мировой компании.
Кажется это хороший повод посмотреть как это было, может быть и вы заметите какие-то параллели со своим опытом.
Существует довольно популярный сайт https://custom-elements-everywhere.com где показывается как работают веб-компоненты в разных фреймворках. Почти у всех фреймворков там красивый 100% результат, но у React там очень настораживающие 71%.
Многие пользователи смотрят на эту страничку и делают вывод, что React плохо поддерживает не только веб-компоненты, но и DOM API в принципе. Так ли это? Действительно ли все плохо?
Давайте разбираться!
Прошло больше года с моей публикации "Веб-компоненты в реальном мире" и у меня накопились новые наблюдения, что ещё не так с этой технологией. Возможно, эти моменты позволят кому-то избежать тупикового пути для своих проектов.
Сейчас популярно мнение, что текущие Javascript-фреймворки непомерно большие, а новый фреймворк Svelte очень компактный. Поэтому всем нужно переходить на него, и проблема размера JavaScript решится сама собой.
Недавно вышла статья "Хороший ли выбор Svelte для реализации виджета?" с опытом реализации проекта с критичным размером бандла. Это отличный повод проверить обещания пиарщиков Svelte на реальном проекте.
Давайте его проанализируем!
Если спросить разработчиков, почему они выбрали веб-компоненты для своего проекта, довольно часто можно услышать такие аргументы
Аргументы выглядят логичными и справедливыми в обычной ситуации, но в случае веб-компонентов есть нюансы, которые я попробую раскрыть в этой статье.
Node.js 13.2.0 идет с поддержкой ECMAScript модулей, известных по своему синтаксису import и export. Ранее эта функциональность была за флагом --experimental-modules, который больше не требуется. Однако, реализация все еще экспериментальная и может меняться.
От переводчика: это долгожданная фича наконец-то позволит нам использовать стандартный модульный синтаксис, уже доступный в современных браузерах, а теперь еще и в Node.js без флагов и транспайлеров
Сегодня я был изумлен тем, как обычно позитивное и дружелюбное сообщество Vue.js скатилось в печальное противостояние. Две недели назад создатель Vue Эван Ю опубликовал предложение (RFC) с новым функциональным API для компонентов в грядущем Vue 3.0. Сегодня критическое обсуждение на Reddit и аналогичные комментарии на Hacker News вызвали наплыв разработчиков в изначальный RFC с возмущениями, порой даже чересчур резкими.
Я пишу это в основном для себя в будущем, чтобы у меня было куда сослаться, когда кто-нибудь спросит меня, почему я скептичен в отношении веб-компонентов и почему Svelte не компилируется в веб-компоненты по умолчанию. (Тем не менее, он может компилироваться в веб-компоненты, а так же интегрироваться с ними, что подтверждается превосходной оценкой на Custom Elements Everywhere).
Ничто из написанного ниже не должно восприниматься как критика тяжелого труда, проделанного над веб-компонентами. Возможно, я также допустил ошибки в этой публикации, в этом случае я с удовольствием внесу поправки. Также я не заявляю, что вы не должны пользоваться веб-компонентами. У них есть своя область применения. Я же просто объясняю, почему они не подходят для меня.
Photo by NeONBRAND
Веб-компоненты – это общее название набора технологий, призванных помочь веб-разработчикам создавать переиспользуемые блоки. Компонентый подход создания интерфейсов хорошо закрепился во фронтенд-фреймворках, и кажется хорошей идеей встроить эту функциональность нативно в браузеры. Поддержка этой технологии браузерами уже достигла достаточного уровня, чтобы можно было всерьез задуматься об использовании этой технологии для своих рабочих проектов.
В этой статье мы посмотрим на особенности использования веб-компонентов, о которых почему-то не говорят евангелисты этих технологий.
Текущий статус поддержки ECMAScript-модулей (ESM) в Node.js:
В октябре Modules Team опубликовала "План по реализации Новых Модулей". Этот пост объясняет, что в нем содержится.
Этот пост является развернутым ответом на вопросы из этого разговора в Твиттере. Автор оригинала, Сунил Пай, является автором относительно популярной библиотеки glamor и работает разработчиком в Facebook.
Каким образом Javascript оказывается более удобным чем CSS? Как написание CSS внутри JS делает его более поддерживаемым?
Буду счастлив пообщаться на эту тему. Сразу скажу, что у CSS-in-JS решений есть накладные расходы, но обычно эта цена оправдана теми преимуществами, которые они приносят. Иногда они могут быть полезными, но также это не значит, что CSS-in-JS должен использоваться всегда и везде.
SwiftOnSecurity пишет на тему недавнего перехода на Chromium в качестве встроенного в Windows движка рендеринга:
Это не только про Chrome, это также про ElectronJS. Microsoft думает, что EdgeHTML не может достичь полного паритета по функциональности с Chromium, чтобы заменить его в приложениях Electron. Дублирование движка Electron в каждой программе становится значительной проблемой производительности. Вместо этого они хотят иметь один на всех экземпляр Electron вместе со своими дополнениями.
Electron это рак, убивающий и macOS, и Windows по мере распространения. Microsoft должна предложить ему замену с нативными оптимизациями, чтобы улучшить производительность и использование ресурсов.
Я не совсем разделяю их пессимизм по поводу нативных приложений, но Electron – это, без сомнений, бич платформы. Я думаю, что Mac окажет большее сопротивление, чем Windows, потому что платформа Mac привлекает большее число неравнодушных людей. Но тем не менее, я беспокоюсь.
Если вы работаете с Javascript, то скорее всего вы заметили много шума об уязвимости в npm-пакете event-stream. (На Хабре тоже опубликовали пост об этом — пер.) К сожалению, детальный анализ ситуации похоронен под более чем 600 комментариями в issue на Github, большая часть которых – флейм о состоянии npm, open-source в целом и т.д. Я подумал, что это плохо, потому что нам самом деле бэкдор исключительно умный и интересный с технической точки зрения, а также преподает нам важный урок о том, как поддерживать безопасность в приложениях на Javascript. Так что я решил написать пост с детальным объяснением, как сработала эта атака и что может сделать Javascript сообщество, чтобы лучше защититься от подобных атак в будущем.
Полгода назад Google представила обновленную версию своего почтового сервиса. Несмотря на то что многие пользователи были недовольны редизайном, в том числе и на Хабре, это теперь основной интерфейс для пользователей.
Среди прочих недостатков, люди жалуются на ухудшение производительности новой версии, особенно на слабых компьютерах. Давайте же посмотрим, почему так происходит и что может быть такого тяжелого в почтовом интерфейсе. В этой статье мы будем пользоваться инструментами разработчика в Google Chrome, так что эта статья будет еще и напоминанием о том, какие возможности там имеются.
Я посетил встречу Messaging, Malware and Mobile Anti-Abuse Working Group (m3aawg.org) в Бруклине, Нью-Йорк. Я ожидал лучшей погоды, чтобы побродить по городу, насладиться конференцией, и широким выбором еды на районе. Я настолько был уверен в ясности неба, что даже не взял с собой ничего от дождя. И всю неделю шел дождь. Это вынудило меня оставаться в моем номере в отеле с бесплатным WiFi и моим рабочим ноутбуком. Я решил потратить это время за исследованием Node.js и их сопутствующих пакетов, доступных на https://www.npmjs.com.
Там есть тысячи пакетов от пользователей, доступные для скачивания и установки в ваш проект. Я поискал в NPM по популярным названиям пакетов, таких как file, backup, download, или upload. Последний поисковый запрос показал мне проект под названием jQuery file upload от пользователя Blueimp. Его описание показалось достаточно интересным, чтобы скачать и исследовать его.
На прошлой неделе разработчики Yarn (пакетного менеджера для Javascript) анонсировали новую фичу – Plug'n'Play установку. Эта возможность позволяет запускать Node.js проекты без использования папки node_modules, в которую обычно устанавливаются зависимости проекта перед запуском. Описание фичи декларирует, что node_modules больше не понадобится – модули будут загружаться из общего кеша пакетного менеджера.
Одновременно с ними разработчики NPM также анонсировали свое аналогичное решение проблемы.
Давайте посмотрим на эти решения повнимательнее и попробуем протестировать их в реальных проектах.
Сегодня я узнал, что проект Lerna добавил примечание к MIT-лицензии у себя в проекте, запрещающее использование этого продукта для длинного списка организаций, из-за несогласия с политическим выбором, который сделали эти организации.
Говоря как один из соавторов Определения Open Source, я констатирую факт: после этого добавления, лицензия Lerna больше не совместима с этим определением. В особенности нарушается совместимость с пятым пунктом ("Никакой дискриминации против отдельных людей или групп").
Соответственно, Lerna отступила от open-source сообщества и должна избегаться каждым, кто ценит здоровость этого сообщества. Я не буду контрибьютить в этот проект и побуждаю других не делать этого, до тех пор, пока это изменение не будет аннулировано.
Несколько недель назад я обнаружил пост "Окисляем Source Maps с Rust и WebAssembly"
распространяющийся по Твиттеру и расказывающий о выигрыше в производительности от замены обычного JavaScript в библиотеке source-map на Rust, скомпилированный в WebAssembly.
Пост возбудил мой интерес не потому, что я большой фанат Rust или WASM, скорее потому что я всегда интересовался фичами языков и оптимизациями, которых не хватает Javascript для того чтобы достичь аналогичной производительности.
Так что я скачал библиотеку с GitHub и отправился в небольшое исследование производительности, которое я документирую здесь практически дословно.