Forwarded from Вебня (Sergey Rubanov)
Вышел Babel 7.10.0. Среди нововведений:
- поддержка пропозала Ergonomic brand checks for Private Field (stage 1)
- совместимая с ES2015 поддержка экранирования символов
- улучшения поддержки optional chaining (ES2020)
- поддержка module attributes (stage 1) парсером
- улучшенный три-шейкинг для React
- парсинг import.meta (ES2020) включен по умолчанию
- поля классов (stage 3) добавлены в shippedProposals, так как начинают появляться в браузерах
- новая архитектура для поллифилов. Теперь как альтернативу core-js можно использовать набор полифиллов из es-shims
- поддержка пропозала Ergonomic brand checks for Private Field (stage 1)
- совместимая с ES2015 поддержка экранирования символов
- улучшения поддержки optional chaining (ES2020)
- поддержка module attributes (stage 1) парсером
- улучшенный три-шейкинг для React
- парсинг import.meta (ES2020) включен по умолчанию
- поля классов (stage 3) добавлены в shippedProposals, так как начинают появляться в браузерах
- новая архитектура для поллифилов. Теперь как альтернативу core-js можно использовать набор полифиллов из es-shims
babeljs.io
7.10.0 Released: Class Fields in preset-env, '#private in' checks and better React tree-shaking · Babel
We just released a new minor version of Babel!
Google объявил о том, что показатели Web Vitals будут влиять на ранжирование сайтов в поиске — "Evaluating page experience for a better web".
Google учитывает сотни сигналов, которые влияют на ранжирование, например, адаптированность страниц под мобильные устройства, поддержку https, удобный доступ к контенту и т.п. К этим сигналам будет добавлен Web Vitals. То есть среди сайтов с примерно одинаковым контентом и сигналами предпочтение будет отдаваться тем, которые работают быстрее. Также будет изменён алгоритм попадания контента новостных сайтов в "Top Stories" — теперь необязательно, чтобы сайт предоставлял AMP-версию страниц, достаточно, чтобы он работал быстро.
Алгоритм ранжирования будет обновлён не ранее 2021 года. За шесть месяцев до обновления будет ещё один анонс. У владельцев сайтов есть много времени, чтобы улучшить показатели Web Vitals.
#seo #performance #google
https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html
Google учитывает сотни сигналов, которые влияют на ранжирование, например, адаптированность страниц под мобильные устройства, поддержку https, удобный доступ к контенту и т.п. К этим сигналам будет добавлен Web Vitals. То есть среди сайтов с примерно одинаковым контентом и сигналами предпочтение будет отдаваться тем, которые работают быстрее. Также будет изменён алгоритм попадания контента новостных сайтов в "Top Stories" — теперь необязательно, чтобы сайт предоставлял AMP-версию страниц, достаточно, чтобы он работал быстро.
Алгоритм ранжирования будет обновлён не ранее 2021 года. За шесть месяцев до обновления будет ещё один анонс. У владельцев сайтов есть много времени, чтобы улучшить показатели Web Vitals.
#seo #performance #google
https://webmasters.googleblog.com/2020/05/evaluating-page-experience.html
Official Google Webmaster Central Blog
Evaluating page experience for a better web
We’re introducing page experience as a new ranking signal that provides a holistic picture of the quality of a user’s experience on a web page.
Руководители Trello, Vimeo, Canva и Tinder дали интервью изданию Icrement про фронтенд в своих компаниях — "Frontend at scale".
Фронтенд-команды всех компаний используют похожий стек: React и TypeScript (Tinder не учитываю, так как её представитель в интервью рассказывал только про iOS). Все компании в своих процессах разработки объединяют дизайнеров и разработчиков. В Canva пошли немного дальше — у них некоторые дизайнеры параллельно занимаются разработкой.
Были очень разные ответы на вопрос про ключевые инструменты, которые используются разработчиками. Представитель от Trello рассказал про prettier и eslint, от Vimeo — немного про внутренний инструмент для пререндеринга React-приложений, от Canva — про Storybook и его интеграцию в пулл-реквесты.
Не бомбическое интервью, но местами было интересно. Рекомендую почитать, если интересно узнать про особенности фронтенд-стека в больших компаниях.
#interview
https://increment.com/frontend/frontend-at-scale/
Фронтенд-команды всех компаний используют похожий стек: React и TypeScript (Tinder не учитываю, так как её представитель в интервью рассказывал только про iOS). Все компании в своих процессах разработки объединяют дизайнеров и разработчиков. В Canva пошли немного дальше — у них некоторые дизайнеры параллельно занимаются разработкой.
Были очень разные ответы на вопрос про ключевые инструменты, которые используются разработчиками. Представитель от Trello рассказал про prettier и eslint, от Vimeo — немного про внутренний инструмент для пререндеринга React-приложений, от Canva — про Storybook и его интеграцию в пулл-реквесты.
Не бомбическое интервью, но местами было интересно. Рекомендую почитать, если интересно узнать про особенности фронтенд-стека в больших компаниях.
#interview
https://increment.com/frontend/frontend-at-scale/
Increment
Frontend at scale
Leaders at Atlassian, Canva, Tinder, and Vimeo discuss frameworks, tooling, and rapidly evolving technologies.
Аксель Раушмайер опубликовал статью про новый пропозал — "A first look at records and tuples in JavaScript".
Records и Tuples (записи и кортежи) — это новые иммутабельные и сравниваемые по значению примитивные типы данных. Record — это аналог объекта, tuple — массива. Для их создания используются похожие на массив и объект литералы с префиксом "#":
Благодаря иммутабельности записи и кортежи можно безопасно использовать по всей программе без необходимости в клонировании (как в случае с обычными массивами и объектами). Также их можно использовать в тех ситуациях, где не имеет особого смысла использовать обычные литералы массивов и объектов, например, при сравнении в условиях
На данный момент пропозал находится на первой стадии добавления в стандарт. Есть полифилл (использует экспериментальные
#js #proposal
https://2ality.com/2020/05/records-tuples-first-look.html
https://habr.com/ru/post/504092/ (перевод на русский язык)
Records и Tuples (записи и кортежи) — это новые иммутабельные и сравниваемые по значению примитивные типы данных. Record — это аналог объекта, tuple — массива. Для их создания используются похожие на массив и объект литералы с префиксом "#":
#[1, 2], #{a: 1}.Благодаря иммутабельности записи и кортежи можно безопасно использовать по всей программе без необходимости в клонировании (как в случае с обычными массивами и объектами). Также их можно использовать в тех ситуациях, где не имеет особого смысла использовать обычные литералы массивов и объектов, например, при сравнении в условиях
#[1, 2, 3] === #[1, 2, 3] и в качестве ключа Set и Map.На данный момент пропозал находится на первой стадии добавления в стандарт. Есть полифилл (использует экспериментальные
WeakRef и FinalizationRegistry ).#js #proposal
https://2ality.com/2020/05/records-tuples-first-look.html
https://habr.com/ru/post/504092/ (перевод на русский язык)
Хабр
Первый взгляд на записи и кортежи в JavaScript
В этом посте мы вкратце рассмотрим предложение в стандарт ECMAScript «Record & Tuple» от Робина Рикарда и Рика Баттона. Это предложение добавляет два вида состав...
Increment — журнал про разработку — в этом месяце был полностью посвящён фронтенду. Там много постов от разработчиков из мира фронтенда. Среди них есть статья Эвана Ю "The process: Making Vue 3", где он рассказывает про разработку Vue 3 и особенности его работы.
К 2018 году в кодовой базе Vue 2 накопился технический долг и прояснились архитектурные проблемы. К этому моменту все браузеры стали поддерживать
Из статьи узнал, что первые прототипы были написаны с использованием Flow, но команде приходилось поддерживать тайпинги для TS, которые были востребованы гораздо больше чем Flow-тайпинги. В итоге от Flow отказались в пользу TypeScript. Ещё в статье есть интересные технические детали работы Vue 3. В новой версии компилятор шаблонов был полностью переписан. В его основу лёг пайплайн на базе AST-трансформаций, который позволил компоновать оптимизации времени компиляции в виде плагинов трансформаций. Статический анализ шаблонов и новая архитектура позволили ускорить работу с Virtual DOM до 10 раз в бенчмарках рендеринга.
Очень хорошая статья. Советую почитать всем, даже тем, кто не работает с Vue.
#vue #internals #history #jsframeworks
https://increment.com/frontend/making-vue-3/
К 2018 году в кодовой базе Vue 2 накопился технический долг и прояснились архитектурные проблемы. К этому моменту все браузеры стали поддерживать
Proxy, благодаря чему можно было сделать новую систему реактивности с исправлением проблем старой. Также вторая версия не очень хорошо дружила со статической типизацией. Все эти факторы послужили причиной полного переписывания фреймворка и перехода на новую мажорную версию.Из статьи узнал, что первые прототипы были написаны с использованием Flow, но команде приходилось поддерживать тайпинги для TS, которые были востребованы гораздо больше чем Flow-тайпинги. В итоге от Flow отказались в пользу TypeScript. Ещё в статье есть интересные технические детали работы Vue 3. В новой версии компилятор шаблонов был полностью переписан. В его основу лёг пайплайн на базе AST-трансформаций, который позволил компоновать оптимизации времени компиляции в виде плагинов трансформаций. Статический анализ шаблонов и новая архитектура позволили ускорить работу с Virtual DOM до 10 раз в бенчмарках рендеринга.
Очень хорошая статья. Советую почитать всем, даже тем, кто не работает с Vue.
#vue #internals #history #jsframeworks
https://increment.com/frontend/making-vue-3/
Increment
The process: Making Vue 3
Lessons from rewriting the next major version of Vue.js.
Forwarded from Вебня (Sergey Rubanov)
Я Серёжа Рубанов, приглашённый эксперт #TC39 (комитета, занимающегося разработкой ECMAScript) и основатель канала @juliarderity.
Сегодня начигается 76я встреча TC39, которая станет второй полностью удалённой. В этот раз встреча будет длиться 4 дня по 5 часов вместо 2 дней по 7 часов и заключительного 6-часового.
Повестка очень интересная! Я уже писал обо всех пропозалах, которые готовятся к продвижению на следующий стейдж. С этой публикацией можно ознакомиться вот тут.
Как всегда буду рассказывать всё самое интересное в этом канале. Если что-то невероятно интересное или важное то сразу же лайвом, а также буду публиковать результаты каждого дня ближе к ночи.
Время проведения встреч — 15:00 - 20:00 UTC, для большинства читателей это будет 18:00 - 23:00 (по Москве, Киеву, Минску).
Мне будет приятно если Вы поделитесь этой записью в своих каналах или в сообществах, участникам которых это может быть интересно. Ещё можно поддержать на Patreon.
Сегодня начигается 76я встреча TC39, которая станет второй полностью удалённой. В этот раз встреча будет длиться 4 дня по 5 часов вместо 2 дней по 7 часов и заключительного 6-часового.
Повестка очень интересная! Я уже писал обо всех пропозалах, которые готовятся к продвижению на следующий стейдж. С этой публикацией можно ознакомиться вот тут.
Как всегда буду рассказывать всё самое интересное в этом канале. Если что-то невероятно интересное или важное то сразу же лайвом, а также буду публиковать результаты каждого дня ближе к ночи.
Время проведения встреч — 15:00 - 20:00 UTC, для большинства читателей это будет 18:00 - 23:00 (по Москве, Киеву, Минску).
Мне будет приятно если Вы поделитесь этой записью в своих каналах или в сообществах, участникам которых это может быть интересно. Ещё можно поддержать на Patreon.
Прочитал пост Пауло Кальвано про эвристическое кеширование в браузерах — "HTTP Heuristic Caching (Missing Cache-Control and Expires Headers) Explained".
Для установки времени жизни контента в кэше браузера веб-серверы отправляют http-заголовки
Очень полезная статья. Рекомендую почитать.
#http #cache
https://paulcalvano.com/index.php/2018/03/14/http-heuristic-caching-missing-cache-control-and-expires-headers-explained/
Для установки времени жизни контента в кэше браузера веб-серверы отправляют http-заголовки
Cache-Control и Expires. Если установлены оба заголовка то приоритет получает Cache-Control. Есть ошибочное мнение, что если не отдавать эти заголовки, то браузеры не будут кэшировать контент, но на самом деле браузеры всё равно будут его сохранять. Время жизни обычно составляет 10% от промежутка времени между датой последнего изменения файла Last-Modified и текущей датой. Этот нюанс может принести много проблем, поэтому не рекомендуется удалять заголовки Cache-Conrol и Expires. Для отключения кэширования лучше всего использовать Cache-Control: no-store или Cache-Control: max-age=0.Очень полезная статья. Рекомендую почитать.
#http #cache
https://paulcalvano.com/index.php/2018/03/14/http-heuristic-caching-missing-cache-control-and-expires-headers-explained/
Сегодня вышел Firefox 77. Флориан Шольц и Гарольд Киршнер рассказали про все новинки релиза — "New in Firefox 77: DevTool improvements and web platform updates".
Продолжается раскатка WebRender — нового движка рендеринга, написанного на Rust и использующего GPU для отрисовки элементов страницы. Была улучшена служебная страница управления сертификатами —
Был добавлен новый метод из будущего стандарта ES2021 для поиска и замены подстроки
Есть улучшения и исправления ошибок в инструментах разработчика. Была ускорена работа отладчика и исправлены многие проблемы с source maps. Теперь во время отладки можно выбрать фрейм и сразу же продолжить отладку внутри него без необходимости прокликивания "step out". Был добавлен интерфейс для установки брекпойнтов на чтение свойства объекта или его запись.
#firefox #release
https://hacks.mozilla.org/2020/06/new-in-firefox-77-devtool-improvements-and-web-platform-updates/
Продолжается раскатка WebRender — нового движка рендеринга, написанного на Rust и использующего GPU для отрисовки элементов страницы. Была улучшена служебная страница управления сертификатами —
about:certificate. Пользователям UK стали доступны рекомендации лучших статей при открытии нового таба.Был добавлен новый метод из будущего стандарта ES2021 для поиска и замены подстроки
String.prototype.replaceAll(). У объектов IDBCursor было добавлено новое поле request для более удобной работы с врапперами. В SVG была добавлена поддержка атрибута transform-origin. Он используется для задания точки, относительно которой применяются трансформации.Есть улучшения и исправления ошибок в инструментах разработчика. Была ускорена работа отладчика и исправлены многие проблемы с source maps. Теперь во время отладки можно выбрать фрейм и сразу же продолжить отладку внутри него без необходимости прокликивания "step out". Был добавлен интерфейс для установки брекпойнтов на чтение свойства объекта или его запись.
#firefox #release
https://hacks.mozilla.org/2020/06/new-in-firefox-77-devtool-improvements-and-web-platform-updates/
Mozilla Hacks – the Web developer blog
New in Firefox 77: DevTool improvements and web platform updates
Firefox 77 is now available with a variety of developer tool updates and new web platform features. With your feedback, we've removed performance bottlenecks, resulting in faster, leaner JavaScript debugging. ...
Эверт Пот написал статью про синтаксис ECMAScript 4 — "ECMAScript 4: The missing version".
ECMAScript 4 бы очень большим проектом по модернизации JavaScript. Работа над этой спецификацией шла 9 лет (1999-2008), но была полностью переосмыслена, переродившись в ES5 и ES2015.
В ECMAScript 4 хотели добавить стогую систему типов с поддержкой классов (в итоге они появились в ES2015) и интерфейсов. Было запланировано добавление новых типов: byte, int, unit, double, decimal. Практически ни один из этих типов не попал в последующие версии языка, но на данный момент ведётся работа над пропозалом для добавления в JS типа decimal. Планировали добавить пакеты (packages) для организации кода. Но вместо пакетов в ES2015 решили добавить модульную систему. Существовало расширение ES4 — E4X, которое позволяло работать с XML прямо в JavaScript. Можно сказать, что E4X стал прародителем современного JSX.
Интересная статья. Рекомендую почитать, если интересуетесь историей JavaScript.
#js #history #specification
https://evertpot.com/ecmanoscript-4-the-missing-version/
ECMAScript 4 бы очень большим проектом по модернизации JavaScript. Работа над этой спецификацией шла 9 лет (1999-2008), но была полностью переосмыслена, переродившись в ES5 и ES2015.
В ECMAScript 4 хотели добавить стогую систему типов с поддержкой классов (в итоге они появились в ES2015) и интерфейсов. Было запланировано добавление новых типов: byte, int, unit, double, decimal. Практически ни один из этих типов не попал в последующие версии языка, но на данный момент ведётся работа над пропозалом для добавления в JS типа decimal. Планировали добавить пакеты (packages) для организации кода. Но вместо пакетов в ES2015 решили добавить модульную систему. Существовало расширение ES4 — E4X, которое позволяло работать с XML прямо в JavaScript. Можно сказать, что E4X стал прародителем современного JSX.
Интересная статья. Рекомендую почитать, если интересуетесь историей JavaScript.
#js #history #specification
https://evertpot.com/ecmanoscript-4-the-missing-version/
Evertpot
ECMAScript 4: The missing version
Карлес Ньюнез столкнулся с проблемой при использовании нативной ленивой загрузки изображений, разобрался с ней и написал статью "Deep dive into lazy loading images".
Нативная ленивая загрузка изображений, которую можно активировать с помощью атрибута
В отличие от других подобных библиотек lazysizes дружит с SEO. Google при обходе страниц не использует прокрутку. Библиотека проверяет, может ли user agent использовать прокрутку, и если нет, то сразу загружает все изображения.
Рекомендую почитать статью. Карлес в статье добрался до самых исходников Chromium.
#performance #lazy
https://dev.to/carlesnunez/deep-dive-into-lazy-loading-images-211f
Нативная ленивая загрузка изображений, которую можно активировать с помощью атрибута
loading="lazy", появилась в Chrome 76 и Firefox 75. Браузеры начинают загружать изображения по-разному. В Chrome минимальное расстояние до изображения, при котором начинается его загрузка, составляет 3000 пикселей. Автору статьи это не подходило, и он для ленивой загрузки остановился на библиотеке lazysizes.В отличие от других подобных библиотек lazysizes дружит с SEO. Google при обходе страниц не использует прокрутку. Библиотека проверяет, может ли user agent использовать прокрутку, и если нет, то сразу загружает все изображения.
Рекомендую почитать статью. Карлес в статье добрался до самых исходников Chromium.
#performance #lazy
https://dev.to/carlesnunez/deep-dive-into-lazy-loading-images-211f
DEV Community
Deep dive into lazy loading images 🖼
The first question is... why? In the current web app world saving time and network when a...
Вчера в рассылке Web Platform News пришёл апдейт про поддержку новых псевдоклассов — "CSS :is() and :where() are coming to browsers".
Псевдоклассы
Пример использования
Поддержка новых псевдоклассов уже есть в Safari Tech Preview 106 и Firefox Beta 78. В Chrome их реализация пока находится за флагом. Для ускорения внедрения можно поставить звезду соответствующим тикетам в баг-трекере Chromium (ссылки можно найти в оригинальном посте).
#css
https://webplatform.news/issues/2020-06-04
Псевдоклассы
:is() и :where предназначены для написания CSS-правил без дублирования селекторов. Они отличаются между собой только специфичностью. Специфичность :is() определяется наиболее специфичным селектором, переданным в аргументах. У :where() специфичность всегда нулевая. :where() полезен для создания дефолтных правил, которые могут перекрываться другими правилами без увеличения специфичности селекторов и без использования !important.Пример использования
:is():/* До */
.embed .button:hover,
.attachment .button:hover {
opacity: 1;
}
/* После */
:is(.embed, .attachment) .button:hover {
opacity: 1;
}
Поддержка новых псевдоклассов уже есть в Safari Tech Preview 106 и Firefox Beta 78. В Chrome их реализация пока находится за флагом. Для ускорения внедрения можно поставить звезду соответствующим тикетам в баг-трекере Chromium (ссылки можно найти в оригинальном посте).
#css
https://webplatform.news/issues/2020-06-04
webplatform.news
Web Platform News
News content for web developers written by Šime Vidas
Эдди Османи и Дэмиан Рензулли рассказали о тех случаях, когда нужно отключать предварительную подгрузку и пререндер — "What (not) to Prefetch/Prerender".
Предварительную подгрузку и пререндер не следует использовать:
— для страниц аутентификации, чтобы предотвратить разлогины, непредсказуемый сброс пароля и т.п.;
— в ситуациях когда слишком большое количество запросов может вызвать DOS;
— для страниц оформления заказа и корзины, чтобы избежать случайного добавления товаров в корзину или запуска процесса оформления заказа;
— для файлов большого размера: mp4, zip, gif, pdf. Загрузка объёмных ресурсов без ведома пользователя — это плохая практика;
— для рекламы, так как такие запросы могут привести к ложному всплеску маркетинговых показателей;
— для всех протоколов кроме http/https (tel:, mailto:, javanoscript: и т.п.), в зависимости от браузера, предварительная загрузка такой ссылки может непредсказуемо стригерить действие.
Рекомендую почитать статью, если используете prefetch/prerender на своём сайте.
#performance
https://addyosmani.com/blog/what-not-to-prefetch-prerender/
Предварительную подгрузку и пререндер не следует использовать:
— для страниц аутентификации, чтобы предотвратить разлогины, непредсказуемый сброс пароля и т.п.;
— в ситуациях когда слишком большое количество запросов может вызвать DOS;
— для страниц оформления заказа и корзины, чтобы избежать случайного добавления товаров в корзину или запуска процесса оформления заказа;
— для файлов большого размера: mp4, zip, gif, pdf. Загрузка объёмных ресурсов без ведома пользователя — это плохая практика;
— для рекламы, так как такие запросы могут привести к ложному всплеску маркетинговых показателей;
— для всех протоколов кроме http/https (tel:, mailto:, javanoscript: и т.п.), в зависимости от браузера, предварительная загрузка такой ссылки может непредсказуемо стригерить действие.
Рекомендую почитать статью, если используете prefetch/prerender на своём сайте.
#performance
https://addyosmani.com/blog/what-not-to-prefetch-prerender/
Addyosmani
What (not) to Prefetch/Prerender
Александра Сикора поделилась мыслями о проблемах статей, посвящённых разработке, — "Most tech content is bullshit".
Александра пишет про то, что в большинстве статей есть много проблем, хотя они преподносятся как истина в последней инстанции. Она призывает критически относиться к материалам, даже если они публикуются авторитетными источниками. Проще всего взять готовое решение, не задав вопрос, почему оно именно такое, какое есть, и насколько хорошо оно подходит к текущей ситуации. Но обычно у нас нет времени, чтобы разобраться в вопросе, мы не верим в собственные силы или просто ленимся. Основной посыл статьи — не потребляйте контент слепо, создавайте, задавайте вопросы, будьте любопытны.
Готов подписаться под каждым словом. Очень хорошая статья, рекомендую почитать всем без исключения.
#musings #programming
https://www.aleksandra.codes/tech-content-consumer
Александра пишет про то, что в большинстве статей есть много проблем, хотя они преподносятся как истина в последней инстанции. Она призывает критически относиться к материалам, даже если они публикуются авторитетными источниками. Проще всего взять готовое решение, не задав вопрос, почему оно именно такое, какое есть, и насколько хорошо оно подходит к текущей ситуации. Но обычно у нас нет времени, чтобы разобраться в вопросе, мы не верим в собственные силы или просто ленимся. Основной посыл статьи — не потребляйте контент слепо, создавайте, задавайте вопросы, будьте любопытны.
Готов подписаться под каждым словом. Очень хорошая статья, рекомендую почитать всем без исключения.
#musings #programming
https://www.aleksandra.codes/tech-content-consumer
www.aleksandra.codes
Most tech content is bullshit
“One of the great commandments of science is, "Mistrust arguments from authority." Too many such arguments have proved too painfully wrong. Authorities must prove their contentions like everybody else.” ~ Carl Sagan
Орта Терокс рассказал про изменения в процессе принятия пулл реквестов в репозиторий DefinitelyTyped — "Changes to How We Manage DefinitelyTyped".
DefinitelyTyped — это один из самых крупных репозиториев на GitHub, в котором находятся TypeScript-определения для js-библиотек. Этот проект был создан сообществом, позже к процессу поддержки подключилась команда из Microsoft. Каждую неделю из команды назначается один дежурный, который помогает майнтейнерам DefinitelyTyped с мёржем открытых пулл-реквестов.
Для ускорения принятия изменений в репозиторий недавно был добавлен бот, который помогает владельцам файлов определений сливать изменения без обязательной проверки майнтейнеров. Это стало возможным благодаря покрытию тестами файлов определений. Тесты проверяют на ошибки и на деградацию производительности в IDE. Проверка со стороны майнтейнеров остаётся только для изменений файлов определений самых популярных библиотек (с 5 миллионами загрузок каждый месяц).
#typenoscript #announcement
https://devblogs.microsoft.com/typenoscript/changes-to-how-we-manage-definitelytyped/
DefinitelyTyped — это один из самых крупных репозиториев на GitHub, в котором находятся TypeScript-определения для js-библиотек. Этот проект был создан сообществом, позже к процессу поддержки подключилась команда из Microsoft. Каждую неделю из команды назначается один дежурный, который помогает майнтейнерам DefinitelyTyped с мёржем открытых пулл-реквестов.
Для ускорения принятия изменений в репозиторий недавно был добавлен бот, который помогает владельцам файлов определений сливать изменения без обязательной проверки майнтейнеров. Это стало возможным благодаря покрытию тестами файлов определений. Тесты проверяют на ошибки и на деградацию производительности в IDE. Проверка со стороны майнтейнеров остаётся только для изменений файлов определений самых популярных библиотек (с 5 миллионами загрузок каждый месяц).
#typenoscript #announcement
https://devblogs.microsoft.com/typenoscript/changes-to-how-we-manage-definitelytyped/
Microsoft News
Changes to How We Manage DefinitelyTyped
Definitely Typed is now allowing contributors to self-merge their pull requests after a reviewer has accepted their changes.
Тут в интернете поднялся кипеш по поводу Яндекс.Маркета. Иван Вахрушев на хабре опубликовал статью "Тёмная сторона работы в Яндекс.Маркете", в ней он рассказал о своём опыте работы.
Хочу поделиться с вами своим опытом, не претендую на объективность, и это всего лишь личное мнение. Да, сразу стоит сказать, что мне никто ничего не платил за этот пост. Этот пост получился очень большим и не влез в лимиты телеграма. Полную версию статьи можно почитать по ссылке ниже.
Я работал разработчиком интерфейсов в Маркете с 2016 по 2019 год, пилил фронт, занимался BFF на ноде, принимал участие в разработке инфраструктурных штук. В общем было весело. В октябре 2019-го позвали поработать над стартапом — зачесались руки сделать что-то абсолютно новое с нуля. Не мог не воспользоваться таким шансом и в итоге ушёл. Ни на кого в Маркете не держу зла, и, в целом, у меня остались хорошие воспоминания, хотя было по-разному. Затрону самые важные на мой взгляд темы.
В статье Ваня пишет про переработки. Это очень больная тема. С одной стороны барикад работники хотят поддерживать work-life balance, не хотят выгореть и чувствовать себя хорошо, а с другой стороны есть бизнес, которому надо, чтобы фичи пеклись как блинчики. Лично я иногда перерабатывал, мог сидеть за фичей до поздней ночи. Зачем? Потому что был дурак, а не потому что меня заставлял бизнес. Тимлид напоминал идти домой, ну а я продолжал работать. Так продолжалось очень долго, пока не стал замечать за собой странные вещи — постоянная усталость, проблемы с вниманием, импульсивность и т.п. Подумал, что это ни к чему хорошему не приведёт и решил прекратить себя мучить. Последний год работалось очень хорошо, стал более продуктивен, хотя по факту тратил меньше времени, чем раньше. Никто не предъявлял претензий за то, что ухожу домой вовремя.
По поводу дохода. это очень мутная тема, так как есть много факторов, которые надо учитывать. В целом, компенсация была достойная для Новосибирска, хотя, наверное, мог бы зарабатывать больше. Рефликсируя на эту тему, сделал вывод, что надо было просто уметь себя продавать, когда устраивался. Но не жалуюсь — за моё время работы меня несколько раз повышали. Вывод — развивайте soft skills.
Качество кода. По Кенту Беку в коде фронта Маркета в целом ок. Нет дублирования, код тестируется, используется минимальное количество необходимых сущностей. С интентом правда была иногда проблема и приходилось чесать репу, разбираясь в кишках какой-нибудь инфраструктурной либы. В целом, код Маркета был предсказуем и довольно приятен в работе.
Всё ли было идеально? Нет. Всё ли было ужасно? Абсолютно нет. Как и у любой другой компании у Яндекс.Маркета есть и преимущества, и недостатки. Имхо, в этом нет ничего удивительного. Жаль, что не у всех людей не такой опыт как у меня. Но (по моим наблюдениям изнутри) Маркет и Яндекс в целом берут на заметку негативный опыт и стараются улучшить ситуацию.
P.S. 500-ый пост в канале (это не специально).
#musings #yandex
https://defront.ru/posts/2020/06-june/09-my-experience-at-yandex-market/
Хочу поделиться с вами своим опытом, не претендую на объективность, и это всего лишь личное мнение. Да, сразу стоит сказать, что мне никто ничего не платил за этот пост. Этот пост получился очень большим и не влез в лимиты телеграма. Полную версию статьи можно почитать по ссылке ниже.
Я работал разработчиком интерфейсов в Маркете с 2016 по 2019 год, пилил фронт, занимался BFF на ноде, принимал участие в разработке инфраструктурных штук. В общем было весело. В октябре 2019-го позвали поработать над стартапом — зачесались руки сделать что-то абсолютно новое с нуля. Не мог не воспользоваться таким шансом и в итоге ушёл. Ни на кого в Маркете не держу зла, и, в целом, у меня остались хорошие воспоминания, хотя было по-разному. Затрону самые важные на мой взгляд темы.
В статье Ваня пишет про переработки. Это очень больная тема. С одной стороны барикад работники хотят поддерживать work-life balance, не хотят выгореть и чувствовать себя хорошо, а с другой стороны есть бизнес, которому надо, чтобы фичи пеклись как блинчики. Лично я иногда перерабатывал, мог сидеть за фичей до поздней ночи. Зачем? Потому что был дурак, а не потому что меня заставлял бизнес. Тимлид напоминал идти домой, ну а я продолжал работать. Так продолжалось очень долго, пока не стал замечать за собой странные вещи — постоянная усталость, проблемы с вниманием, импульсивность и т.п. Подумал, что это ни к чему хорошему не приведёт и решил прекратить себя мучить. Последний год работалось очень хорошо, стал более продуктивен, хотя по факту тратил меньше времени, чем раньше. Никто не предъявлял претензий за то, что ухожу домой вовремя.
По поводу дохода. это очень мутная тема, так как есть много факторов, которые надо учитывать. В целом, компенсация была достойная для Новосибирска, хотя, наверное, мог бы зарабатывать больше. Рефликсируя на эту тему, сделал вывод, что надо было просто уметь себя продавать, когда устраивался. Но не жалуюсь — за моё время работы меня несколько раз повышали. Вывод — развивайте soft skills.
Качество кода. По Кенту Беку в коде фронта Маркета в целом ок. Нет дублирования, код тестируется, используется минимальное количество необходимых сущностей. С интентом правда была иногда проблема и приходилось чесать репу, разбираясь в кишках какой-нибудь инфраструктурной либы. В целом, код Маркета был предсказуем и довольно приятен в работе.
Всё ли было идеально? Нет. Всё ли было ужасно? Абсолютно нет. Как и у любой другой компании у Яндекс.Маркета есть и преимущества, и недостатки. Имхо, в этом нет ничего удивительного. Жаль, что не у всех людей не такой опыт как у меня. Но (по моим наблюдениям изнутри) Маркет и Яндекс в целом берут на заметку негативный опыт и стараются улучшить ситуацию.
P.S. 500-ый пост в канале (это не специально).
#musings #yandex
https://defront.ru/posts/2020/06-june/09-my-experience-at-yandex-market/
Хуссейн Джирде в блоге web.dev рассказал, как можно предотвратить сдвиг контента из-за загрузки web-шрифтов — "Prevent layout shifting and flashes of invisibile text (FOIT) by preloading optional fonts".
В черновике спецификации CSS Fonts Module Level 4, есть раздел, который говорит о том, что загрузка опциональных шрифтов (
Так как эта фича ещё не в официальном стандарте, команда Chrome ждёт обратной связи.
#fonts #performance
https://web.dev/preload-optional-fonts/
В черновике спецификации CSS Fonts Module Level 4, есть раздел, который говорит о том, что загрузка опциональных шрифтов (
font-display: optional ) не должна приводить к перерасчёту лайаута. Браузеры в этом случае могут блокировать отрисовку страницы на небольшой промежуток времени, пока загружается необходимый web-шрифт. Чтобы избежать блокировки с версии Chrome 83, можно использовать комбинацию font-display: optional и <link rel="preload"> для загружаемого шрифта. Браузер с большой вероятностью загрузит шрифт до первой отрисовки, и в результате страница отобразится сразу с необходимым шрифтом без сдвига контента.Так как эта фича ещё не в официальном стандарте, команда Chrome ждёт обратной связи.
#fonts #performance
https://web.dev/preload-optional-fonts/
web.dev
Prevent layout shifting and flashes of invisible text (FOIT) by preloading optional fonts | Articles | web.dev
By optimizing rendering cycles, Chrome 83 eliminates layout shifting when preloading optional fonts. Combining with font-display: optional is the most effective way to guarantee jank-free rendering of custom fonts.
Хочу продолжить вчерашнюю тему. Эдди Османи написал пост про решение проблем сдвига контента — "Optimize Cumulative Layout Shift".
Cumulative Layout Shift (CLS) — это метрика Web Vitals, которая измеряет нестабильность контента, складывая смещение всех элементов, которое происходит независимо от действий пользователя. То есть если на странице происходит сдвиг после пользовательского ввода, например, пользователь открыл список-аккордеон после загрузки страницы, то такое смещение не будет влиять на CLS.
Самые распространённые причины нежелательных смещений:
— изображения без заданных размеров (можно исправить добавлением атрибутов
— реклама, iframe, встраиваемый контент (можно исправить, предварительно выделив необходимое место);
— динамически добавляемые блоки — GDPR-сообщения, похожие товары и т.п. (вместо них можно использовать временные заглушки);
— web-шрифты, вызывающие FOIT/FOUT (такое смещение можно устранить с помощью
В свете последних новостей о том, что Google будет использовать показатели Web Vitals для ранжирования сайтов, очень советую почитать статью.
#performance #metrics
https://web.dev/optimize-cls/
Cumulative Layout Shift (CLS) — это метрика Web Vitals, которая измеряет нестабильность контента, складывая смещение всех элементов, которое происходит независимо от действий пользователя. То есть если на странице происходит сдвиг после пользовательского ввода, например, пользователь открыл список-аккордеон после загрузки страницы, то такое смещение не будет влиять на CLS.
Самые распространённые причины нежелательных смещений:
— изображения без заданных размеров (можно исправить добавлением атрибутов
width и height );— реклама, iframe, встраиваемый контент (можно исправить, предварительно выделив необходимое место);
— динамически добавляемые блоки — GDPR-сообщения, похожие товары и т.п. (вместо них можно использовать временные заглушки);
— web-шрифты, вызывающие FOIT/FOUT (такое смещение можно устранить с помощью
font-display: optional и <link rel="preload"> ).В свете последних новостей о том, что Google будет использовать показатели Web Vitals для ранжирования сайтов, очень советую почитать статью.
#performance #metrics
https://web.dev/optimize-cls/
web.dev
Optimize Cumulative Layout Shift | Articles | web.dev
Cumulative Layout Shift (CLS) is a metric that quantifies how often users experience sudden shifts in page content. In this guide, we'll cover optimizing common causes of CLS such as images and iframes without dimensions or dynamic content.
Джек Арчибальд написал статью "Event listeners and garbage collection". В ней рассказывается про способ прерывания любого асинхронного API и объясняется, почему этот способ не приводит к утечкам памяти.
Все современные браузеры поддерживают отмену fetch-запросов с помощью AbortController API. В статье есть код небольшого хелпера, который позволяет использовать AbortController с любым асинхронным API:
В нём используется обработчик события "abort", который вызвал подозрение у читателя Джека. В статье очень подробно объясняется, почему этот обработчик не приводит к утечке — при завершении работы асинхронного кода функция удаляется из стека выполнения, поэтому все объекты, которые были связаны с этой функцией, без проблем удаляются сборщиком мусора.
Очень хорошая статья. Рекомендую посмотреть примеры, особенно если вы раньше не работали с AbortController.
#web #api
https://jakearchibald.com/2020/events-and-gc/
Все современные браузеры поддерживают отмену fetch-запросов с помощью AbortController API. В статье есть код небольшого хелпера, который позволяет использовать AbortController с любым асинхронным API:
async function abortable(signal, promise) {
if (signal.aborted) {
throw new DOMException('AbortError', 'AbortError');
}
return Promise.race([
promise,
new Promise((_, reject) => {
signal.addEventListener('abort', () => {
reject(new DOMException('AbortError', 'AbortError'));
});
}),
]);
}В нём используется обработчик события "abort", который вызвал подозрение у читателя Джека. В статье очень подробно объясняется, почему этот обработчик не приводит к утечке — при завершении работы асинхронного кода функция удаляется из стека выполнения, поэтому все объекты, которые были связаны с этой функцией, без проблем удаляются сборщиком мусора.
Очень хорошая статья. Рекомендую посмотреть примеры, особенно если вы раньше не работали с AbortController.
#web #api
https://jakearchibald.com/2020/events-and-gc/
Jakearchibald
Event listeners and garbage collection
The browser is pretty smart when it comes to GCing listeners…
Крис Сейнти рассказал про фреймворк от Microsoft для создания SPA-приложений на C# — "What’s behind the hype about Blazor?".
Blazor для C#-разработчиков сейчас очень хайповая тема, потому что благодаря ему можно создавать SPA без использования JavaScript. Его архитектура состоит из двух основных частей: App/Component Model (отвечает за компонентную модель, роутинг и другие невизуальные задачи) и Renderer/Hosting Model (отвечает за обновление и отображение UI).
На данный момент есть два стабильных рендерера: WebAssembly Renderer и Server Renderer. Первый используется для создания привычных SPA-приложений (объявлен стабильным в мае этого года). Второй — для клиентских приложений, которые работают на внешнем сервере, браузер клиента в этом случае отвечает только за обновление DOM. Есть ещё два экспериментальных рендерера: для мобильных приложений (использует нативные UI-элементы) и десктопных приложений (работает поверх Electron/WebWindow).
Если всё взлетит, то Blazor в будущем может стать конкурентом React Native и Flutter.
#webassembly #frameworks
https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-about-blazor/
Blazor для C#-разработчиков сейчас очень хайповая тема, потому что благодаря ему можно создавать SPA без использования JavaScript. Его архитектура состоит из двух основных частей: App/Component Model (отвечает за компонентную модель, роутинг и другие невизуальные задачи) и Renderer/Hosting Model (отвечает за обновление и отображение UI).
На данный момент есть два стабильных рендерера: WebAssembly Renderer и Server Renderer. Первый используется для создания привычных SPA-приложений (объявлен стабильным в мае этого года). Второй — для клиентских приложений, которые работают на внешнем сервере, браузер клиента в этом случае отвечает только за обновление DOM. Есть ещё два экспериментальных рендерера: для мобильных приложений (использует нативные UI-элементы) и десктопных приложений (работает поверх Electron/WebWindow).
Если всё взлетит, то Blazor в будущем может стать конкурентом React Native и Flutter.
#webassembly #frameworks
https://stackoverflow.blog/2020/02/26/whats-behind-the-hype-about-blazor/
Stack Overflow Blog
What’s behind the hype about Blazor?
Blazor is a new client-side UI framework from the ASP.NET team. Its big selling point is the ability to write rich web UI experiences using HTML, CSS, and C# instead of JavaScript—something a lot of developers have been dreaming of.
Новости и благодарности
В этом месяце закончил большую работу — перенёс все статьи из канала на сайт defront.ru. Теперь этот сайт — официальное место обитания проекта в большом интернете. Также у проекта начинают появляться контрибьюторы. Тимур Хазамов два дня назад добавил на сайт поддержку тёмной темы.
Хочу напомнить, что у канала есть чат — @defrontchat. Присоединяйтесь! Подписывайтесь на мой твиттер https://twitter.com/myshov. Там я пишу новости и апдейты, которые иногда не попадают в канал.
Канал существует благодаря вашей поддержке на патреоне. Хочу сказать огромное спасибо моим патронам: Андрею, Артёму, bafonins, brqte, Олегу, Павлу, th1rt3nth, Роману, Сергею, Владу, Денису, Дмитрию и Сергею! Благодарю всех за то, что читаете канал и рассказываете про него своим друзьям и коллегам. Если вам нравится то, что я делаю, и хотите поддержать канал, то это можно сделать тут https://www.patreon.com/myshov.
#спасибо
В этом месяце закончил большую работу — перенёс все статьи из канала на сайт defront.ru. Теперь этот сайт — официальное место обитания проекта в большом интернете. Также у проекта начинают появляться контрибьюторы. Тимур Хазамов два дня назад добавил на сайт поддержку тёмной темы.
Хочу напомнить, что у канала есть чат — @defrontchat. Присоединяйтесь! Подписывайтесь на мой твиттер https://twitter.com/myshov. Там я пишу новости и апдейты, которые иногда не попадают в канал.
Канал существует благодаря вашей поддержке на патреоне. Хочу сказать огромное спасибо моим патронам: Андрею, Артёму, bafonins, brqte, Олегу, Павлу, th1rt3nth, Роману, Сергею, Владу, Денису, Дмитрию и Сергею! Благодарю всех за то, что читаете канал и рассказываете про него своим друзьям и коллегам. Если вам нравится то, что я делаю, и хотите поддержать канал, то это можно сделать тут https://www.patreon.com/myshov.
#спасибо
Twitter
Alexander Myshov (@myshov) | Twitter
The latest Tweets from Alexander Myshov (@myshov). Software engineer from Siberia (ex-Yandex) excited by music, science, yoga and other stuff. Author of project "History of JavaScript" (https://t.co/8jlI4GJao6). Russia
Аксель Раушмайер написал статью про логические операторы присваивания — "ECMAScript proposal: Logical assignment operators".
Пропозал добавляет в стандарт новые составные операторы присваивания:
Логические операторы присваивания находятся на третьем этапе добавления в стандарт. Его поддержка появилась в Firefox 77 Nightly, Safari Technology Preview 107, и в V8 v8.4 (Chrome 85).
#js #proposal
https://2ality.com/2020/06/logical-assignment-operators.html
Пропозал добавляет в стандарт новые составные операторы присваивания:
a ||= b, a &&= b и a ??= b. Благодаря этим операторам можно компактно комбинировать присваивание с коротким циклом вычислений логических операций (short-circuit). Например, запись a ??= b эквивалентна выражению a ?? (a = b). В нём присваивание происходит только в том случае, когда в a находится null или undefined. Пример использования:const books = [{
isbn: '123',
}, {
noscript: 'ECMAScript Language Specification',
isbn: '456',
}];
// Добавление дефолтного заголовка там, где его нет
for (const book of books) {
book.noscript ??= '(Unnoscriptd)';
}
assert.deepEqual(books, [{
isbn: '123',
noscript: '(Unnoscriptd)',
}, {
noscript: 'ECMAScript Language Specification',
isbn: '456',
}]);Логические операторы присваивания находятся на третьем этапе добавления в стандарт. Его поддержка появилась в Firefox 77 Nightly, Safari Technology Preview 107, и в V8 v8.4 (Chrome 85).
#js #proposal
https://2ality.com/2020/06/logical-assignment-operators.html