Defront — про фронтенд-разработку и не только
5.36K subscribers
21 photos
1.09K links
Ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков

Обсуждение постов @defrontchat

Также советую канал @webnya
Download Telegram
Пару дней назад Себастьян Маккензи — отец Babel и Yarn — представил новый проект Rome. Джейсон Миллер сделал небольшой обзор нового инструмента — "Rome, a new JavaScript Toolchain".

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

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

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

#js #experimental #tool

https://jasonformat.com/rome-javascript-toolchain/
https://github.com/facebookexperimental/rome
Брайан Карделл — один из участников w3c — написал небольшую статью про проблему сломанных ссылок в вебе — "Making Sure Content Lives On..."

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

Сейчас можно добавлять страницы в архив только вручную: с помощью специальной формы на сайте или добавив http://web.archive.org/save/ в начале url страницы, которую нужно сохранить. Брайан связался с техническим директором Internet Archive и сделал более удобный сервис для автоматизированного сохранения страниц. Сейчас он открыт для всех, если эксперимент будет успешен, то Internet Archive реализует что-то подобное у себя.

Если публикуете контент на больших и серьёзных сайтах (habr, medium, dev.to), то стоит задуматься о том, чтобы добавлять свои статьи в Internet Archive. Я же с этого момента буду добавлять в архив все статьи из канала. Если какая-то ссылка будет сломана, то её можно будет найти в интернет архиве.

#web #experimental

https://bkardell.com/blog/ArchivingByDefault.html
Томас Штейнер в блоге web.dev написал статью про новое экспериментальное API — "WebSocketStream: integrating streams with the WebSocket API".

WebSocketStream в отличие от стандартного WebSocket API может ограничить поток входящих и исходящих сообщений в зависимости от текущей нагрузки (backpressure). Это особенно полезно для приложений, которые передают много траффика: видеоконференции, шаринг рабочего стала и т.п. В текущей версии WebSocket API реализовать backpressure для входящих сообщений невозможно, для исходящих сообщений — возможно, но только постоянно опрашивая WebSocket.bufferedAmount, что неэффективно и неэргономично.

WebSocketStream доступен только в Chrome. От команд Firefox и Safari пока не было сигналов о добавлении этой фичи.

#net #experimental

https://web.dev/websocketstream/
Томас Штайнер рассказал про Local Font Access API — экспериментальное API для доступа к шрифтам, которые установлены в системе пользователя.

Это API решает несколько проблем. Текущие возможности web'а не позволяют получить доступ к низкоуровневой информации о шрифтах, что критично для профессиональных средств для дизайна. Без этих данных невозможно применять векторные фильтры к шрифтам или менять форму глифов. Local Font Access API предоставляет доступ к этим данным. Также лицензии некоторых шрифтов разрешают их использование, но без разрешения распространять их через web. Доступ к такому шрифту может быть получен с помощью этого API.

На данный момент Local Font Access API доступен только в Chrome за флагом #font-access. Разработчики призывают попробовать поработать с новым API и поделиться своим фидбеком.

#fonts #experimental

https://web.dev/local-fonts/
В Chromium планируется добавление Raw Sockets API — API для прямых сетевых соединений. Register опубликовал статью про это API — "Chromium devs want the browser to talk to devices, computers directly via TCP, UDP. Obviously, nothing can go wrong".

Идея Raw Sockets API заключается в том, чтобы предоставить браузерным приложениям возможность работать напрямую с сетевыми сокетами. Это открывает новые сценарии использования web-приложений для работы к сетевыми устройствами (сканеры, принтеры) и реализации полноценных ssh-клиентов, irc-клиентов, клиентов децентрализованных p2p-сетей и т.п с помощью web-технологий. Не все разработчики высказываются положительно относительно нового API. Эприл Кинг — инженер по безопасности Mozilla — очень скептически отзывается о попапе как средстве защиты от нежелательных соединений.

Raw Sockets API находится на стадии разработки прототипа. Предварительный план состоит в том, чтобы добавить его поддержку сначала в Chrome OS, а затем в Chromium.

#experimental #chromium

https://www.theregister.com/2020/08/22/chromium_devices_raw_sockets/
https://github.com/WICG/raw-sockets
Джейсон Миллер и Мэйсон Фрид представили экспериментальную поддержку Declarative Shadow DOM в Chrome.

Declarative Shadow DOM позволяет описывать разметку web-компонентов декларативно в коде HTML-страницы без использования императивного API с помощью JavaScript. Это очень важная фича для развития экосистемы web-компонентов. Про неё уже был пост в канале, его можно найти тут.

Самое главное на что стоит обратить внимание при использовании Declarative Shadow DOM. Построение Shadow DOM производится на этапе парсинга страницы, за счёт этого компоненты на странице рендерятся быстрее по сравнению с традиционным императивным подходом. Элемент template c атрибутом shadowroot становится теневым корнем (shadow root) и автоматически прикрепляется к родительскому элементу. Для сериализации DOM дерева с Shadow DOM можно использовать новый метод getInnerHTML().

Экспериментальная поддержка Declarative Shadow DOM появилась в Chrome 85. Ожидается, что она будет включена по умолчанию в Chrome 88. Браузеры без поддержки Declarative Shadow DOM могут использовать полифилл.

#experimental #webcomponents

https://web.dev/declarative-shadow-dom/
Томас Штейнер в блоге web.dev написал статью про текстовые фрагменты — "Boldly link where no one has linked before: Text Fragments".

В url страницы после символа # можно подставить идентификатор элемента, к которому браузер должен подкрутить страницу. Эта фича появилась очень давно, но у неё есть недостаток — на странице должен существовать элемент с необходимым идентификатором.

С помощью текстового фрагмента (text fragment) можно задать любой текст, который нужно "подсветить" на странице. Текстовый фрагмент задаётся в url страницы с помощью конструкций #:~:text=textStart или #:~:text=textStart,textEnd. Также можно указать необходимый контекст с помощью префиксов и суффиксов #:~:text=somePrefix-,text,-someSuffix.

Текстовый фрагмент — экспериментальная фича, её поддержка есть только в браузерах на базе Chromium. На данный момент участники W3C скептически относятся к изменению формата url, но Google уже начал использовать текстовые фрагменты в production-коде поисковых сниппетов.

#spec #experimental #chromium

https://web.dev/text-fragments/
Рич Харрис на Svelte Summit 2020 рассказал про новые фичи фреймворка, над которыми работает основная команда разработчиков Svelte — "Futuristic Web Development".

Идёт работа над интеграцией возможностей Sapper (фреймворк для построения приложений на базе Svelte с роутингом, код-сплиттингом и т.п.) в основную кодовую базу Svelte. В перспективе разработка Sapper будет остановлена.

Добавлена возможность создания гибридных приложений. В таких приложениях некоторые страницы могут быть пререндерены заранее в статический HTML.

Svelte будет полагаться на поддержку ESM в современных браузерах, так как для менеджмента зависимостей будет использоваться Snowpack. Благодаря этому не нужно постоянно собирать приложение при изменении кода. Rollup будет использоваться только для сборки финального оптимизированного бандла приложения.

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

#svelte #jsframeworks #talk #experimental

https://www.youtube.com/watch?v=qSfdtmcZ4d0
В начале этого месяца Николь Салливан из Google твитнула о старте работ над внедрением в Chromium долгожданной фичи — выражений от контейнера (container queries). Через некоторое время Брайан Карделл написал статью о проделанной работе над выражениями от контейнера со стороны Igalia.

Над отзывчивыми элементами (aka responsive elements или container queries) авторы спецификаций и разработчики браузерных движков бьются уже несколько лет. До недавнего времени они не могли найти такое решение, которое было бы эффективно и которое бы не требовало изменения архитектуры текущих реализаций CSS-движков. Работа продвинулась после реализации во всех браузерах ResizeObserver. Благодаря отзывчивым элементам можно описывать стили элементов, которые зависят от ширины элементов, не используя JavaScript.

На данный момент разработчики браузеров подходят к разработке фичи с разных сторон. Брайан и его команда из Igalia работают над новой CSS-функцией switch(), которая будет служить основой для добавления нового синтаксического сахара в будущем, например, синтаксиса выражений от контейнера. Эмилио Кобос из Mozilla работает над похожим примитивом nth-value() (по сути альтернативный синтаксис switch() ), который можно очень легко интегрировать в текущую кодовую базу любого браузера. (Уже после публикации статьи Брайан Карделл дал фидбек по статье и рассказал, что идея switch() была предложена архитектором Google, который отвечает за движок layout'а в Chrome). Разработчики из Google идут другим путём и хотят сразу реализовать поддержку выражений от контейнера без добавления в CSS новых примитивов. Стоит сказать, что Igalia и Google не конкурируют друг с другом по этому вопросу. Их работа в конечном счёте будет дополнять друг друга.

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

UPD: Обновил статью с учётом фидбека Брайана и Николь

#css #experimental

https://bkardell.com/blog/AllThemSwitches.html
https://twitter.com/stubbornella/status/1324524942650601472
Томас Штайнер в блоге web.dev рассказал про File Handling API — "Let web applications be file handlers".

С помощью File Handling API можно открывать файлы из операционной системы в установленном pwa как в обычном нативном приложении. Это ещё один шаг в направлении сближения возможностей web и нативных платформ.

Для создания ассоциации файлов с pwa-приложением в манифесте в разделе file_handlers нужно указать соответствие между url и типом открываемых файлов. В самом приложении нужно обработать очередь файлов с помощью launchQueue:

if ('launchQueue' in window) {
launchQueue.setConsumer((launchParams) => {
// если очередь пустая, ничего не делать
if (!launchParams.files.length) {
return;
}
for (const fileHandle of launchParams.files) {
// обработка файлов
}
});
}


File Handling API находится на стадии активной разработки. На данный момент он доступен только в Chromium за экспериментальным флагом file-handling-api.

#pwa #experimental

https://web.dev/file-handling/
Сегодня разработчики React представили новую фичу библиотеки — серверные компоненты.

Серверный компонент — это неинтерактивный React-компонент с расширением .server.js. Он полностью работает на стороне сервера, что позволяет внутри кода компонента сделать запрос к базе данных или прочитать файл с файловой системы сервера. Благодаря комбинированию клиентских (обычных) и серверных компонентов можно улучшить производительности приложения и улучшить UX. Ещё одна важная особенность серверных компонентов — их код не попадает в клиентский бандл приложения. Они не предназначены для замены обычных компонентов — решение об их использовании остаётся на усмотрение разработчиков приложений.

Серверные компоненты — это экспериментальная фича, которая находится в стадии активной разработки, но её уже можно пощупать и поделиться своим фидбэком в RFC.

#jsframeworks #react #experimental

https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
Рйо Ота рассказал, как можно сделать SSH-клиент, VNC-клиент и мессенджер без использования веб сокетов и WebRTC — "The Power of Pure HTTP – screen share, real-time messaging, SSH and VNC".

Обычно HTTP используется для передачи относительно небольших объёмов данных. Разработчики браузеров сейчас работают над возможностью отправки по сети ReadableStream с помощью fetch, то есть создания канала для передачи бесконечного потока данных. В статье разбираются примеры, как использовать эту фичу вместе с piping server, который позволяет организовать взаимодействие между двумя браузерами с помощью обычных GET- и POST-запросов. С помощью такого подхода можно сделать приложение просмотра удалённого рабочего стола, SSH-клиенты и другие подобные приложения, которые работают внутри браузера и используют обычный HTTP-канал в качестве транспорта.

На данный момент возможность передачи ReadableStream с помощью fetch есть только в Chrome в экспериментальном режиме.

#experimental #http #api

https://dev.to/nwtgck/the-power-of-pure-http-screen-share-real-time-messaging-ssh-and-vnc-5ghc
Ахмад Шадид написал статью про CSS Container Queries — "Say Hello To CSS Container Queries".

Для управления контекстным отображением компонентов можно использовать медиавыражения, но они не подходят для случаев, когда компонент может быть размещён в контейнерах с разной шириной. Эту проблему решают выражения от контейнера (Container Queries). Благодаря им у нас появляется возможность задавать элементам стили, которые зависят от размера контейнера:

@container (min-width: 400px) {
.c-article {
display: flex;
flex-wrap: wrap;
}
}


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

На данный момент выражения от контейнера доступны только в Chrome Canary за экспериментальным флагом.

#css #experimental

https://ishadeed.com/article/say-hello-to-css-container-queries/
Карло Пиовесан — разработчик Cheerp — попробовал выяснить, можно ли в автоматическом режиме преобразовать JavaScript-код в эквивалентный более производительный JavaScript-код и поделился результатами своего исследования в статье "A JavaScript optimizing compiler".

Карло написал очень ограниченный транспилятор из JavaScript в C++. Прогнал через него код бенчмарков. Затем получившийся C++-код скомпилировал обратно в JavaScript-код с помощью Cheerp с применением оптимизаций на уровне компилятора (Cheerp — это компилятор, построенный на базе LLVM, аналог Emscripten).

В результате такого преобразования кода, большинство бенчмарков показали прирост производительности. Особенно хорошо показал себя код для проверки простых чисел — он стал быстрее на 80%.

Этот подход нельзя использовать в продакшене, так как транспилятор из JavaScript в C++ очень хрупкий и покрывает только небольшое подмножество JavaScript. Тем не менее проведённый эксперимент говорит о том, что у этой стратегии оптимизации есть право на жизнь.

#experimental #js #performance

https://medium.com/leaningtech/a-javascript-optimizing-compiler-3fd3f49bd071
Брайан Карделл из Igalia поделился планами по прототипированию поддержки CSS-селектора :has() — "Can I :has()".

Cелектор :has() добавляет в CSS возможность стилизации элемента на основе его содержимого. Это единственный селектор в таком роде — другие селекторы работают по направлению от детей к родителям. Он появился в черновике спецификации Selectors Level 4 в 2011 году, но до сих пор не был имплементирован в браузерах. Основная сложность заключается в том, что :has() ломает принципы работы со стилями, которые лежат в основе многих оптимизаций, благодаря которым браузеры могут поддерживать стабильные 60 fps.

На протяжении десяти лет в рабочей группе CSS возникали обсуждения по поводу :has(), но они никуда не вели, потому что никто не брался за прототипирование. Недавно компанию Igalia наняла компания eyeo (разрабатывает Adblock Browser и Adblock Plus) для того, чтобы сдвинуть эту фичу с мёртвой точки. Ребята планируют сделать прототипы и в принципе понять, возможно ли реализовать :has() без проблем для производительности. Этот эксперимент определит дальнейшую судьбу селектора. Либо он будет добавлен в браузеры, либо его функциональность будет реализована в другом виде, например, на уровне DOM API.

#css #experimental

https://bkardell.com/blog/canihas.html