Бенедикт Мюрер - разработчик v8 - пару дней назад опубликовал дизайн-документ, посвящённый оптимизации конкатенации строк в JS.

Конкатенация строк - одна из основных операций над строками, у которой, как оказывается, есть хороший потенциал для ускорения. Если конкатенация будет оптимизирована, то решения для сервер сайд рендеринга станут ещё быстрее (именно на этом примере Бенедикт показывает важность оптимизации).

В документе также рассказывается про текущий механизм оптимизации строк - "ropes". Приводится пример того, как можно написать один вид конкатенации в двух разных вариантах: оптимизированном и неоптимизированном. Но разработчики v8 предупреждают, чтобы мы не кидались переписывать свой код. Движки будут учиться конкатенировать строки более эффективно самостоятельно, если с этим возникнут проблемы, тогда (возможно) в языке появится новый StringBuilder API.

#js #v8 #strings #future #performance

https://twitter.com/bmeurer/status/1102452256794906625

Недавно инженер из Facebook Феликс Клинг опубликовал небольшое веб-приложение, с помощью которого можно разобраться в тонкостях работы алгоритма нестрогого сравнения. Этот алгоритм ("Abstract Equality Comparison") работает тогда, когда сравниваются два значения с помощью оператора ==.

С помощью этого приложения можно наглядно увидеть, почему '\n' == false или [0] == ![0] дадут истинный результат.

#js #tool #ecmascript

https://felix-kling.de/js-loose-comparison/

Алексей Федосов из 2ГИС написал интересную статью про то, как команда веб-карт оптимизирует генерализацию маркеров в новой версии 2gis.ru.

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

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

#map #webgl #algorithm #2gis

https://habr.com/ru/company/2gis/blog/442720/

В феврале Дмитрий Мананников опубликовал в своём блоге новую статью - "Код ревью".

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

В статье всё сказано по делу. Добавить что-то к ней мне особо нечего, наверное, это из-за того, что мы в Яндекс Маркете придерживаемся тех же подходов, про которые пишет Дмитрий.

#musings #codereview #programming

https://slonoed.net/ru/code-review/

Хочу поделиться полезной статьёй Мартина Чаова "Using SSE Instead Of WebSockets For Unidirectional Data Flow Over HTTP/2", в которой он описывает преимущества и недостатки разных подходов к реализации общения браузера и сервера.

В статье делается небольшой обзор Polling и WebSocket и подробно разбирается работа Server-Sent Events (SSE). Главное преимущество SSE относительно Polling состоит в том, что при его использовании нам достаточно одного соединения. Преимущество относительно WebSocket - нет необходимости устанавливать полноценное двунаправленное соединение между клиентом и сервером, которое приводит к более сложной архитектуре и большей требовательности к ресурсам, что очень критично для мобильных устройств.

SSE полезен в том случае, когда вам достаточно однонаправленного потока данных с сервера. При этом в браузере поддержка SSE обеспечивается с помощью интерфейса EventSource,  который появился в стандарте HTML5.

#polling #sse #realtime #websocket

https://www.smashingmagazine.com/2018/02/sse-websockets-data-flow-http2/

Увидел интересный тред в твиттере (по сути статью), в котором Colm MacCárthaigh, рассказал про основные принципы работы современных алгоритмов шифрования. Мне понравился доступный язык, которым в статье объясняются сложные вещи, поэтому очень захотелось перевести её на русский язык.

В статье без погружения в детали разбирается работа современных алгоритмов симметричного шифрования: DES, 3DES, AES, RC4, ChaCha20. Объясняется общий принцип работы этих алгоритмов, что такое вектор инициализации, как формируются поток случайных данных, с которым происходит XOR-инг, схемы проверки целостности и т.п. Ещё в статье упоминается пара интересных атак на шифры.

Несмотря на устрашающий заголовок статья очень доступная. Подобные статьи вдохновляют на изучение чего-то нового. Советую её прочитать просто ради общего развития.

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

#cryptography #security

Вадим Демедес опубликовал небольшую статью про "Ink".

Ink - это разработанная Вадимом библиотека для написания интерактивных консольных интерфейсов с использованием React-компонентов. Ink поддерживает flexbox-лайаут с помощью yoga-layout.  Вокруг библиотеки есть небольшая экосистема: можно найти готовые компоненты text-input, spinner, tab, select, gradient и другие.

Ребята из npm и jest выразили свою заинтересованность в проекте, и, возможно, они будут использовать его в будущем.

#library #react #cli

https://vadimdemedes.com/posts/building-rich-command-line-interfaces-with-ink-and-react

Пару недель назад у нас в Новосибирске был митап для фронтендеров JSParty. Один из докладов был от Тима Чаптыкова из ВКонтакте: "Оптимизация графики на практике".

В докладе Тим рассказал про практические приёмы оптимизации векторной и растровой графики. Очень подробно разобрал настройки при экспорте изображений из Photoshop, Illustrator и Sketch. Поделился наиболее оптимальными настройками для SVGO, малоизвестными трюками при работе с изображениями и хорошими чек-листами, с которыми можно сверяться при экспорте графики для веба. В докладе есть пара историй из жизни про генерацию графики на клиенте. Не знаю почему, но из доклада я запомнил такой факт, что при сжатии больших JPEG для Retina-дисплеев достаточно качества 51%.

К сожалению, записи видео не было, но есть запись доклада с Frontfest Moscow 2017. Обновлённые слайды можно найти тут.

#graphic #optimization #talk

https://www.youtube.com/watch?v=wexOXAflVX0

Павел Лаптев написал статью "Lesser-known CSS properties in GIFs" про малоизвестные CSS-свойства и функции, которые позволят в некоторых случаях отказаться от JavaScript. Каждое свойство в статье иллюстрируется gif-кой.

C помощью функции element() (поддерживается только в Firefox) можно "склонировать" в бэкграунд визуальное представление другого элемента. В Chrome и Safari TP доступны конические градиенты, с помощью которых можно делать красивые эффекты и круговые диаграммы. С помощью motion-path можно задать траекторию анимации. Очень полезное свойство, которое поддерживается почти во всех браузерах и которое позволяет делать отзывчивые карусели, scroll-snap. Ещё хочется отметить свойство line-height-step, с помощью которого можно задать вертикальный ритм текста (доступно в Chrome за флагом).

Некоторые CSS-фичи, перечисленные в статье, например, element() доступны уже долгое время. В то время как другие, например, @media (shape: rect), пока существуют на уровне чернового стандарта.

https://medium.com/@PavelLaptev/lesser-known-css-properties-in-gifs-966a143497ba

#css #future

Алессандро Сегала опубликовал небольшой пост про нормализацию 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