Алессандро Сегала опубликовал небольшой пост про нормализацию Unicode-строк "When 'Zoë' !== 'Zoë'. Or why you need to normalize Unicode strings".

Unicode - очень интересная тема, которая таит в себе много особенностей. Каким образом текст из заголовка статьи не может быть равен самому себе? Дело в том, что символ "ё" в Unicode может быть представлен как одиночным кодпойнтом, так и комбинацией двух кодпойнтов: символа "e" и символа умлаут. Из-за этого сравнение двух одинаковых (по внешнему виду) строк может вернуть false. Для решения этой проблемы необходимо воспользоваться Unicode-нормализацией. В стандарт ES2015 для этого был добавлен метод String.normalize() с четырьмя формами нормализации: NFC, NFD, NFKC, NFKD.

В конце статьи Алессандро призывает всегда приводить пользовательский ввод к каноничной форме – NFC.

#unicode #normalization

https://withblue.ink/2019/03/11/why-you-need-to-normalize-unicode-strings.html

На Humble Bundle появился бандл книг, посвященный Web-разработке, от издательcтва O'Reilly. Я бы не стал про него писать, если бы там не было по-настоящему хороших книг. За доллар можно купить "CSS: The Definitive Guide" Эрика Мейера ("книга с рыбками") и книгу из серии "You Don't Know JS".

Из этого бандла я лично хочу полистать "Data Visualization with Python & JavaScript" и "Vue.js Up & Running", хотя у последней книги не очень высокий рейтинг на Amazon, но всё равно интересно. Все книги DRM-Free.

#books #deals

https://www.humblebundle.com/books/web-programming-oreilly-books

Майлз Боринз три дня назад открыл пулл-реквест в Node.js с обновлённой имплементацией поддержки ES2015 Modules.

Самое значимое изменение – возможность использовать новые модули в файлах с расширением *.js. Теперь в Node.js есть три возможности работать с новыми модулями:
1) используя расширение *.mjs;
2) используя расширение *.js и type: module в package.json;
3) используя расширение *.js и флаги командной строки --type=module / -m.

Причиной изменения подхода стала критика со стороны сообщества предыдущего механизма, когда работа с ES модулями была доступна только в файлах *.mjs. Для сохранения совместимости с CommonJS было добавлено специальное расширение *.cjs.

Разработчики Node.js пока не рекомендуют использовать ES модули в публикуемых пакетах. Релиз поддержки новых модулей без флага запланирован до выхода LTS версии Node.js 12 (октябрь 2019).

#nodejs #modules #esm #es2015

https://github.com/nodejs/node/pull/26745

Сегодня на hackernews запостили ссылку на старое письмо Линуса Торвальдса, в котором он рассказывает про то, почему не любит дебаггеры.

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

В комментариях на HN бурно обсуждают, прав ли Линус или не прав. Кстати, некоторые комменты там очень интересны. Я лично согласен с доводами Линуса, хотя и использую дебаггер время от времени. Плюс сейчас у меня есть ещё один аргумент в бесконечных спорах "IDE vs текстовые редакторы".

#linux #debug #torvalds #programming

https://lwn.net/2000/0914/a/lt-debugger.php3

Продолжаем тему дебаггинга. Пару лет назад Андре Стальц (Медейрос) (автор cycle.js, xstream) написал статью "Why debugging is all about understanding".

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

"Поиск ошибок в два раза тяжелее написания кода. Таким образом, если вы пишете код настолько изобретательно насколько возможно, то, по определению, вы не достаточно умны для того, чтобы найти в нём ошибку".

Брайан Керниган (соавтор Unix)

#debug #programming

https://www.futurice.com/blog/why-debugging-is-all-about-understanding/

Почему браузеры скачивают стили для несматченных медиавыражений, рассказывает Томас Штайнер в небольшом посте "Why Browsers Download Stylesheets With Non-Matching Media Queries".

Если у вас есть страница, на которой подключаются файлы стилей с разными медиазапросами:

<link href="print.css" rel="stylesheet" media="print">
<link href="mobile.css" rel="stylesheet" media="screen and (max-width: 600px)">

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

В этом нет ошибки. Cтраницы отображаются в динамичной среде. Вы можете изменить размер браузера или перенести окно с одного монитора на другой с другим разрешением и плотностью пикселей, поэтому браузеры скачивают все стили для несматченных медиавыражений с низким приоритетом. Более того, браузеры должны загружать стили для невалидных media queries в соответствии с правилами игнорирования, описанными в спецификации.

#css #mediaqueries #performance

https://blog.tomayac.com/2018/11/08/why-browsers-download-stylesheets-with-non-matching-media-queries-180513

Вчера Эдди Османи твитнул про то, что на сайте web.dev появился новый интерактивный туториал про настройку сжатия brotli "Minify and compress network payloads with brotli".

Brotli – это относительно новый формат сжатия, который поддерживается во всех современных браузерах (кроме IE). Brotli обгоняет gzip на 14% при сжатии JS, на 21% при сжатии HTML, на 17% при сжатии CSS.

В туториале рассматривается два способа настройки сжатия для Express: динамичное сжатие ("на лету") и статичное сжатие. Для сжатия динамичных страниц подходит динамичная стратегия, для статичных страниц - статичная. Для последних можно выставить максимальное сжатие и эта настройка не будет влиять на время отклика сайта.

Примеры в статье очень понятные, объясняется чуть ли не каждая строка кода вплоть до конфигов Webpack. Сам по себе сайт тоже очень крут. Это интерактивная песочница, где можно поправить пример и сразу же посмотреть результат.

#brotli #compression #performance #nodejs

https://web.dev/fast/reduce-network-payloads-using-text-compression/codelab-text-compression-brotli

Мне очень нравится копаться в истории web'а. Никогда не задумывались о том, что за прикол с использованием "www" в качестве поддомена сайта? Крис Лав рассказывает причины возникновения этого префикса в именах сайтов в статье "Should You Use the WWW Subdomain? Why is it Even a Thing? Plus Some Advice".

Всё началось до появления web'а. В то время имена сервисов использовались в качестве поддомена для облегчения конфигурирования серверов, например, ftp.example.com, smtp.example.com. Когда появился world wide web администраторы по привычке выделяли для http-серверов соответствующий поддомен - www. Потом web захватил Интернет, и компании стали продвигать свои сайты ради моды с доменом "www", чтобы показать, что они находятся в сети. Этот факт очень сильно проник в нашу современную культуру и теперь, даже если просто набрать имя компании в поисковой строке браузера и нажать ctrl+enter, то до перехода на сайт ваша введённая строка будет обрамлена в "www" и "com".

На сегодняшний день сайты либо редиректят с поддомена www на основной домен, либо наоборот. Для поисковиков наличие или отсутствие www не имеет значения. Так что использовать "www" или не использовать – это просто персональный выбор владельцев сайтов.

#web #www #history

https://love2dev.com/blog/www-subdomain/

Валентин Федяков опубликовал на хабре статью "Знакомство с lit-element и веб-компонентами на его основе".

Lit-element – это обёртка над web-компонентами, с помощью которой можно создавать react-подобные компоненты (именно такое первое впечатление они на меня произвели). Для рендеринга элементов lit-element использует библиоетку lit-html. Для работы со свойствами элементов используются декораторы.

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

#webcomponents #litelement #library

https://habr.com/ru/post/445438/

Самое большое событие последних дней в мире web'а – анонс работы над системным интерфейсом для WebAssembly (WASI). В статье "Standardizing WASI: A system interface to run WebAssembly outside the web" Лин Кларк подробно разбирает основные принципы, лежащие в проектировании WASI: безопасность и переносимость.

С помощью WASI можно будет запускать WebAssembly-код на любых системах с любой архитектурой, где будет представлен рантайм WebAssembly. Как пример, поддержка WebAssembly с WASI в Node.js позволит отказаться от node-gyp для создания системных модулей, так как такие модули можно будет распространять в виде переносимого кода WebAssembly. Также очень много внимания при проектировании WASI уделяется безопасности. Код сможет использовать только те системные вызовы, доступ к которым был предоставлен явно.

Мы становимся свидетелями того, как спираль истории совершает очередной виток. Раньше Sun очень хотела сделать Java языком web'а, теперь же web метит на то, чтобы занять часть ниши Java. И мне кажется, что шансов у WebAssembly c WASI больше, потому что это будет полностью открытая платформа.

Эх, пойду задоначу немного денег Mozilla Foundation.

#webassembly #wasi #mozilla

https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/

Раз уж пошла такая пьянка, давайте продолжим тему WebAssembly, тем более, что сегодня произошло ещё одно интересное событие – компания Fastly открыла исходный код WebAssembly-рантайма с поддрежкой WASI – Lucet.

Lucet разрабатывает компания Fastly – один из игроков в мире edge-computing. Edge-computing подразумевает работу с большим количеством запросов, поэтому здесь очень большую роль играет потребляемые ресурсы. Использование Lucet позволяет инстанциировать WebAssembly-модули менее чем за 50 микросекунд с потреблением памяти в несколько килобайт (для сравнения, v8 – 5 миллисекунд с десятками мегабайт потребляемой памяти). Основа Lucet – генератор кода Cranlift, который разрабатывается Mozilla для поддержки WebAssembly в Firefox. Ребята из Fastly непосредственно участвовуют в проектировании дизайна и разработке Cranlift, поэтому я доверяю цифрам, представленным выше.

Кажется, что мы наблюдаем зарождение чего-то очень интересного.

#webassembly #wasi #lucent

https://www.fastly.com/blog/announcing-lucet-fastly-native-webassembly-compiler-runtime

Мэт Рейер в своей статье "A JavaScript-Free Frontend" поделился опытом написания web-приложения с минимально-возможным количеством JavaScript.

Мэт рассказывает о том, что его приложение для выставления счетов slimvoice, сначала было написано на Angular, потом на React, а в последствии переписано с самым минимальным количеством JavaScript кода. Он хотел доказать, что возможно написать современное надёжное web-приложение без JavaScript, тем самым сильно снизив сложность кода. Модальные окна были сделаны с использованием скрытого чекбокса, раскрывающийся элемент списка с помощью HTML-тегов <details> и <summary>, валидация ввода и форма также были сделаны на чистом HTML с помощью возможностей HTML5. JavaScript остался только для реализации функции автозаполнения. В итоге самая тяжёлая страница на его проекте стала занимать 230 Кб. После кэширования каждый просмотр страницы генерирует всего лишь 6 Кб скачиваемых данных.

Статья заканчивается резонной критикой того, куда движется развитие стандартов. У нас есть WebVR, WebBluetooth, но нет встроенных семантических средств для создания модальных окон.

#webdevelopement #javanoscript

https://dev.to/winduptoy/a-javanoscript-free-frontend-2d3e

В канале веб-стандратов увидел хорошую статью Ричарда Раттера про автоматические переносы строк в CSS "All you need to know about hyphenation in CSS" (перевод на хабре).

Автоматические переносы строк особенно критичны в тех языках, где словосочетания объединяются в длинные слова, как в немецком языке - Verbesserungsvorschlag. Чтобы включить переносы, достаточно добавить язык в тег html - <html lang="ru"> и CSS-правило hyphens: auto; (в Safari и IE/Edge с префиксом -webkit и -ms). Работают переносы во всех современных браузерах. Ещё в некоторых браузерах доступны разные настройки переносов строк, которые можно увидеть в Word и inDesign. Самое полезное правило (по моему скромному мнению) - ограничение максимального количества идущих подряд переносов hyphenate-limit-lines, но оно пока доступно только в Safari и IE/Edge (с префиксами).

#css #typography

http://clagnut.com/blog/2395

Камиль Заграбский рассказал о своём двухлетнем опыте использования TypeScript в статье "After two years with TypeScript – was it worth it?"

Камиль начинает статью с перечисления недостатков. Настройка конфигурации это не простой copy-paste – подключение TypeScript в проект требует вдумчивых действий. Например, у него были проблемы с тем, чтобы подружить TypeScript с Jest и CSS-modules. Также есть проблема с файлами определений типов для библиотек (d.ts). Эти файлы могут быть устаревшими или с ошибками. Для некоторых библиотек может не оказаться d.ts-файлов.

Затем перечисляются плюсы. Статическая типизация помогает найти проблемы в коде на стадии компиляции. Типы позволяют точнее определить намерения разработчика. Интерфейсы помогают определить контракты между объектами. Классы в TypeScript гораздо богаче классов JavaScript – свойства классов могут быть static, private и read only. Также классы очень похожи на классы в других языках. Код на TypeScript гораздо понятнее не JavaScript-разработчикам.

Автор решил вынести кривую обучения отдельно от плюсов и минусов. Сам по себе TypeScript не очень сложен, но если его начать изучать в контексте фреймворка, который вы не использовали раньше, тогда может быть сложновато. В итоге Камиль остался очень доволен своим решением использовать TypeScript.

#typenoscript #musings

https://ecom.software/en/after-two-years-with-typenoscript-was-it-worth-it/

Пару недель назад была большая новость о том, что в Chrome 74 в экспериментальном режиме включили поддержку built-in модуля для нового асинхронного key-value хранилища:

import {storage, StorageArea} from 'std:kv-storage';

Новое API разрабатывается с прицелом на то, чтобы улучшить developer experience при работе с данными в браузере. Проблема в том, что нативное API IndexedDB не очень тривиально, а localStorage из-за синхронного API, который блокирует главный поток, влияет на производительность приложения.

kv-storage – первая ласточка в будущем наборе built-in модулей. Основное преимущество API, поставляемых с помощью встроенных модулей, (они начинаются с префикса std:) – снижение потребления ресурсов системы. Браузеру в этом случае не надо загружать в память API, чтобы предоставить к нему доступ через глобальный скоуп.

Для использования новой фичи в тех браузерах, которые её не поддерживают, разработчики Google предлагают использовать progressive enhancement подход с использованием ещё одной экспериментальной фичи – import maps и полифилла для kv-storage.

#builtinmodule #kvstorage #chrome #future

https://developers.google.com/web/updates/2019/03/kv-storage

Гириш Пунтахил из IBM опубликовал статью "Easily identify problems in Node.js applications with Diagnostic Report", посвящённую новой экспериментальной функции в Node.js v11.8 – Diagnostic Report.

На самом деле эта фича существовала и раньше как отдельный пакет (`npm i node-report`). Команда Node.js решила поставлять её как часть дистрибутива, потому что это незаменимый инструмент при диагностике проблем: утечек памяти, повышенного потребления CPU, крэшей и т.п.

Diagnostic Report генерирует отчёт в виде JSON'а. В отчёте содержится исчерпывающая информация об окружении, в котором было запущено приложение, и обо всех интересующих аномалиях, если запустить node с соответствующими флагами. В статье есть несколько примеров того, как работать с этим инструментом и интерпретировать его результат.

Я считаю, что Diagnostic Report полезная фича, но попадёт ли она в стабильный релиз, пока неизвестно.

#nodejs #troubleshooting #experimental

https://developer.ibm.com/articles/easily-identify-problems-in-your-nodejs-apps-with-diagnostic-report/

Николас Закас – автор нескольких книг по JS и оригинальный автор eslint – в январе написал статью про то, почему он решил не использовать дефолтные экспорты в своих модулях. Статья называется "Why I've stopped exporting defaults from my JavaScript modules".

Для меня самое полезное в статье (как это ни странно) не причины, из-за которых автор отказался от дефолтных экспортов, а принципы, которыми он руководствуется при разработке и которые ценно вспоминать время от времени:
1. явное лучше неявного;
2. имена должны быть консистентны во всех файлах;
3. выкидывайте исключений как можно раньше и чаще;
4. меньшее количество решений - более быстрая разработка;
5. необходимость переключать контекст (side trips) замедляет разработку;
6. избыточная когнитивная нагрузка замедляет разработку.

Николас в статье рассказывает, почему дефолтные экспорты противоречат перечисленным принципам. При этом он не машет флагом, призывая к их уничтожению, наоборот, он говорит про то, что если вы любите использовать модули с дефолтными экспортами, в этом нет ничего плохого. Используйте то, что наиболее подходит вашему стилю разработки. Но мне лично доводы Николаса кажутся вполне разумными.

#javanoscript #modules #esm #musings

https://humanwhocodes.com/blog/2019/01/stop-using-default-exports-javanoscript-module/

Послушал подкаст с Ричардом Фельдманом (автор книги “Elm in Action” и директор по технологиям NoRedInk), в котором он рассказал про общее положение дел в мире Elm.

Последняя версия языка 0.19 вышла в августе 2018 года. В этой версии был переписан компилятор, что драматически снизило время сборки проекта. Так же при переписывании компилятора упор делался на таком коде, который будет эффективно сжиматься uglify.js и Google Closure Compiler.

Ведущие подкаста задали вопрос про потенциальную опасность для проекта, если Эван Чаплицкий (создатель языка и основной разработчик компилятора) перегорит и бросит всё. Ричард ответил, что для Эвана сложнее всего работать не с кодом, а с сообществом, поэтому они в NoRedInk ему с этим очень сильно помогают. И если всё-таки случится так, что Эван захочет уйти работать на ферму выращивать бобы, то это будет очень большая потеря для проекта.

Ещё Ричарда спросили про то, когда выйдет Elm 1.0. Он ответил, что в будущем ожидаются мажорные изменения языка, которые будут ломать совместимость с предыдущими версиями, поэтому в ближайшее время не планируется выпуск версии 1.0. Разработчики Elm не хотят идти по пути Angular, который кардинально изменил подход к разработке приложений при переходе с первой на вторую версию. Для Elm выпуск версии 1.0 будет означать то, что мажорных изменений в языке не будет очень долго. При этом текущая версия 0.19 является production-ready. На данный момент в NoRedInk весь фронтенд (300 тысяч строк кода) написан на Elm.

#elm #podcast #interview

https://dev.to/jsjabber/jsj-354-elm-with-richard-feldman

Пару дней назад Эрик Мейер написал небольшую статью про восьмичисленные шестнадцатиричные коды цветов "Color Me FACE1E55".

Исторически шестнадцатиричные коды, которые похожи на обычные английские слова (DEADBEEF, DEAD10CC и т.п.), использовались (и используются), например, для обозначения определённых участков памяти или типов исключений в отчётах об ошибках. Эрик в статье приводит примеры того, каким цветам соответствуют эти коды и ещё до кучи придумывает парочку своих.

Новый формат цветов описывается в стандарте CSS Color Module Level 4 – его формат #RRGGBBAA. Два последних числа – это альфа-канал. Его значениям соответствуют числа от 00 для полностью прозрачного цвета до FF для непрозрачного. Ещё существует сокращённая запись таких цветов - #RGBA, то есть теперь можно раскрашивать div'ы в цвет #CAFE или #F00D.

Восьмичисленные цвета поддерживается уже во всех современных браузерах, кроме IE/Edge.

#css #colors

https://meyerweb.com/eric/thoughts/2019/04/01/color-me-face1e55/

Вчера Эдди Османи из Google написал в своём блоге про новый экспериментальный атрибут для ленивой загрузки изображений и iframe'ов – loading.

Новый атрибут позволяет отложить загрузку элемента до того момента, как он будет готов попасть во viewport. Это очень критично для мобильных устройств, так как изображения и фреймы, которые находятся на странице, отъедают память устройства и потребляют траффик, но при этом пользователь может до них просто не доскроллить.

Раньше задачу отложенной загрузки можно было решить только с помощью JavaScript, например, используя библиотеку lazysizes. Сейчас в Chrome 73 с помощью флага можно включить поддержку нового атрибута loading. У атрибута есть три возможных значения: lazy (ленивая загрузка), eager (загрузка изображения сразу же), auto (будет ли изображение загружаться лениво, решает браузер):

<img src="img1.jpg" loading="lazy" />
<img src="img2.jpg" loading="eager" />
<img src="img3.jpg" loading="auto" />

Loading – это экспериментальный атрибут, стандарт которого находится на стадии черновика. Поддержка loading без флага должна появиться в Chrome 75.

#html #lazy #future #chrome

https://addyosmani.com/blog/lazy-loading/

Сейчас занимаюсь написанием документации про юнит-тесты в Яндекс Маркете. Искал подходящие статьи по теме и наткнулся на очень большой блог-пост Виталия Зайдмана "An Overview of JavaScript Testing in 2019", в котором он рассматривает инструменты для всех видов тестирования в JavaScript.

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

В общем, если вы ищите хороший обзор современных инструментов тестирования, использующих JavaScript, то вам точно стоит взглянуть на эту статью.

#testing #js #overview

https://medium.com/welldone-software/an-overview-of-javanoscript-testing-in-2019-264e19514d0a