Кент Си Доддс опубликовал у себя в блоге статью про то, как управлять состоянием приложения, не используя сторонние библиотеки, "Application State Management with React".

Кент в статье критикует Redux и пишет про то, что с использованием хука useState и Context можно организовать полноценное управление состоянием приложения в удобном виде и показывает это на примерах. Описанный подход можно реализовать с использованием обычных компонентов, но результат будет не так красив как с хуками. Разработчики React в последних версиях библиотеки благословили использование Context в обычных приложениях (а не только в библиотеках для управления состоянием), поэтому его можно использовать не опасаясь, что с обновлением React в вашем приложении что-то может сломаться.

Напоследок поделюсь своими мыслями. В React теперь есть механизм управления состоянием. Означает ли это, что разработчики будут трансформировать библиотеку в полноценный фреймворк? Наверное нет, так как React всегда позиционировался как гибкое решение. Добавление механизма хуков упростило работу со стейтом, и благодаря этому хук useReducer был добавлен в React как органичное дополнение (моё имхо, конечно).

#react #statemanagement #musings

https://kentcdodds.com/blog/application-state-management-with-react

Бюрк Холланд из Microsoft написал статью с объяснением причин, почему приложения, написанные на Node.js, обычно не запускают напрямую в продакшене "You should never ever run directly against Node.js in production. Maybe."

Если в приложении возникнет исключение, которое не будет обработано, Node.js упадёт (в статье следовало бы упомянуть про глобальную обработку uncaughtException, либо автор просто потроллил). Также не исключены ситуации, когда Node.js может упасть из-за других причин, например, если будет утечка памяти (про это почему-то автор статьи не рассказал). Если ничего не предпринимать, пользователи не смогут воспользоваться приложением. Поэтому необходимы средства, которые будут мониторить процесс ноды и в случае проблем заново запускать приложение. Для этого можно использовать pm2, systemd, kubernetes и т.п. В статье основной упор был сделан на pm2, но и про другие механизмы есть немного информации.

В общем, это неплохой обзор того, как работают с Node.js в продакшене. Статья написана с юмором — автор не стесняется шутить над собой.

#nodejs #pm2 #systemd

https://medium.freecodecamp.org/you-should-never-ever-run-directly-against-node-js-in-production-maybe-7fdfaed51ec6

Сегодня прочитал большую статью Пауло Ренато Де Атайдеса "Comparing JVM alternatives to JavaScript". Интересное чтиво, если вам хочется узнать, какие инструменты могут использовать Java-программисты, когда перед ними стоит задача создания SPA-приложения.

Пауло мотивирует свой подход использования Java-инструментов тем, что современный фронтенд очень сложный. Зачем тянуть тянуть в свой Java-проект ещё одну систему сборки, когда можно воспользоваться существующим тулчейном Java.

В статье рассматривается 6 проектов, которые позволяют написать фронтенд-приложение с использованием Java или JVM-based языков:

- GWT - Java-source-to-JS, серверный и клиентский фреймворк
- TeaVM - Java-bytecode-to-JS компилятор
- JSweet - Java-source-to-JS (и TypeScript) компилятор со своей экосистемой
- CheerpJ - Полная имплементация JVM для браузера (+ Swing)
- Vaadin Flow - Java-source-to-JS-source, серверный и клиентский фреймворк
- Bck2Brwsr - Java-bytecode-to-JS компилятор

В конце статьи есть сравнение реализации одного и того же простого приложения с использованием 5 проектов (Bck2Brwsr у автора не завёлся) и традиционного приложения на React. В замере производительности победил JSweet, в общем размере скачиваемых ресурсов победа опять за JSweet, число строк кода для простого компонента — Vaadin. Если вы не пишете код на Java (например, как я), то статью интересно прочитать только ради общего развития.

#js #java #jvm

https://renato.athaydes.com/posts/comparing-jvm-alternatives-to-js.html

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

Статья описывает то, что следует знать всем программистам. Пунктов больше 30: С++, компиляторы, ассемблер, мультитредность, аппаратное обеспечение, процессоры, дискретная математика, вычислимость, языки программирования, алгоритмы и комбинаторная оптимизация, численные методы, машинное обучение, теория информации и многое другое. У тех пунктов, где это имело смысл, есть список рекомендуемых авторов и тем для изучения. При этом есть уклон в C++ и Windows.

После прочтения статьи у меня был только один вопрос: "Что это было?". Сначала я думал, что это шутка, но потом прочитал комментарии и апдейты к статье и немного переварил информацию, и да, это не троллинг. Предполагается, что на изучение всех этих тем может потребоваться около 5 лет (или больше). Если вам повезло учиться в таком ВУЗе, где это всё было в программе, я могу вам только позавидовать. В общем, рекомендую эту статью к прочтению, чтобы составить себе план для развития на годы вперёд.

#programming #musings

https://sharpc.livejournal.com/67583.html

Два дня назад на конференции F8 была представлена новая версия facebook.com. Команда разработчиков рассказала о технологиях, которые лежат в основе новой версии социальной сети.

Новый сайт — это полноценное SPA-приложение. За данные отвечают GraphQL и Relay, которые позволяют получать только те данные, которые нужны компонентам на текущей странице. Такой подход помог избавиться от загрузки избыточных данных и сделал возможным загрузку данных параллельно коду. Очень много внимания уделили Code-Splitting'у. С помощью Relay был достигнут Data-Driven Code-Splitting — вместе с данными указываются компоненты, которые нужны для отрисовки кода. Ещё реализовали пару дополнительных функций для разделения кода в зависимости от фаз отрисовки страницы: показ начальной страницы загрузки, отрисовка страницы, добавление интерактивности.

Также рассказали про изменения в CSS. Теперь за каждое правило отвечает отдельный класс (Atomic Stylesheets), что позволило снизить общее количество скачиваемых стилей. Используют React.Suspense, для того чтобы улучшить UX. Рассказали про свою работу над Chromium: скоро зарелизят новое браузерное API isInputPending. С помощью этого API станет возможным прерывать работу JS, если известно, что пользователю результат выполнения кода не нужен. Например, если код на первой странице приложения ещё не отработал, а пользователь уже попытался перейти на следующую страницу.

Информации очень много, рекомендую посмотреть.

#relay #codesplitting #facebook

https://developers.facebook.com/videos/2019/building-the-new-facebookcom-with-react-graphql-and-relay/

Крис Закариас написал занимательный пост "A Conspiracy To Kill IE6" про то, как Youtube начал движение против IE6.

IE6 очень плохо поддерживал стандарты. Ещё в нём были очень неприятные баги. Например, если разработчики забывали указать у тега <img> атрибут src, тогда изображение превращалось в некое подобие <iframe> — начиналась загрузка корня сайта. На корневой странице это приводило к бесконечному циклу. В результате либо падал браузер, либо возникал синий экран смерти.

В то время аудитория IE6 составляла 18%, поэтому менеджеры не хотели бросать его поддержку. Но разработчики очень сильно устали от багов в IE6, поэтому тайком от руководства добавили на главную страницу youtube баннер, который говорил о том, что в IE6 сайт скоро будет недоступен и который предлагал установить современные браузеры. Это послужило триггером для других команд в Google поставить подобный баннер. Затем примеру youtube последовали и другие сайты, не связанные с Google. В итоге это привело к очень сильному снижению доли пользователей, использующих IE6, что позволило избавиться от его поддержки.

Зачинщики этой подрывной деятельности готовились к самому худшему. Они думали, что их уволят, но всё обошлось. Ребята из pr-отдела даже пожаловались, что они пропустили такой прекрасный инфоповод.

#ie6 #history #google

http://blog.chriszacharias.com/a-conspiracy-to-kill-ie6

Пару недель назад вышла новая версия Svelte. Рич Харрис опубликовал статью с описанием новых возможности — "Svelte 3: Rethinking reactivity".

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

Вот простой пример компонента, который отображает на кнопке количество нажатий:

<noscript>
 let count = 0;
 function handleClick() {
  count++
 };
</noscript>

<button on:click={handleClick}>{count}</button>

При компиляции хендлер превращается в такой код:

count++; $$invalidate('count', count);

Таким образом view, которое использует переменную count, обновится после вызова $$invalidate.

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

#jsframeworks #svelte #reactivity

https://svelte.dev/blog/svelte-3-rethinking-reactivity

Пару дней назад разработчики Chrome твитнули про то, что реализация нового предложения в JS — Promise.allSettled — была добавлена в Chrome 76. Также поддержка нового предложения уже есть в ночных сборках Firefox.

Новая фича — это дополнение к уже существующему Promise.all(). Если all() прекращает работу как только любой из промисов возвращает reject, то allSettled() дожидается выполнения всех промисов и возвращает массив снапшотов состояния с результатами работы промисов вне зависимости от того были ли среди них промисы с reject.

В рамках текущего стандарта можно обработать все промисы подобно allSettled, если сделать дополнительную функцию (+обратите внимание на promises.map(reflect)):

function reflect(promise) {
  return promise.then(
    v => ({status: 'fulfilled', value: v }),
    error => ({status: 'rejected', reason: error})
  );
}

const promises = [fetch('good.html'), fetch('bad.html')];
const results = await Promise.all(promises.map(reflect));
const successfulPromises = results.filter(
  p => p.status === 'fulfilled'
);

С использованием allSettled этот код становится гораздо проще:

co

nst promises = [fetch('good.html'), fetch('bad.html')];
const results = await Promise.allSettled(promises);
const successfulPromises = results.filter(
  p => p.status === 'fulfilled'
);

Promise.allSettled() находится в stage 3. Это значит, что скорее всего он попадёт в стандарт либо в этом, либо в следующем году.

#js #proposal #async

https://github.com/tc39/proposal-promise-allSettled

Прочитал статью Мишель Баркер про то, где лучше использовать grid, а где flexbox "To Grid or to Flex?"

Появление в CSS поддержки grid не означает, что flexbox устарел, наоборот, они дополняют друг друга. В общем случае, если вам необходимо сделать раскладку элементов в одном измерении, то лучше всего для этого подойдёт flexbox, для раскладки в двух измерениях — grid. Но здесь есть нюансы, например, в статье рассматривается случай двумерной раскладки, которую гораздо проще сделать с помощью flexbox и наоборот.

Статья хорошая советую почитать и посмотреть примеры. На хабре есть перевод.

P.S. Хочу немного дополнить статью. В ней говорится, что поддержки гридов в IE11 нет. Это не совсем верно. Если постараться, то можно реализовать раскладку на гридах в IE. Как это сделать, написано в серии статей Дэниала Тонона "CSS Grid in IE".

#css #layout

https://css-irl.info/to-grid-or-to-flex/

Сегодня на TechCrunch появилась новость про выпуск React Native for Windows. Там же увидел комментарий, в котором говорится, что на самом деле он был выпущен три года назад. Действительно, старый анонс от Microsoft очень легко найти в интернете https://www.microsoft.com/developerblog/2016/05/26/creating-universal-windows-apps-with-react-native/.

Основная новость заключается в другом. Разработчики отчётливо заявили о том, что меняют вектор разработки React Native for Windows. Он будет переписываться на C++ для лучшей производительности и для того чтобы не изобретать заново то, что было уже было сделано другими, тем самым помогая в развитии core bridge React Native от Facebook.

Лично мне очень отрадно видеть, что Microsoft начинает активнее взаимодействовать c Google и Facebook. В итоге в выигрыше остаются все.

#reactnative #microsoft #announcement

https://github.com/microsoft/react-native-windows/pull/2409

Рич Харрис — автор Svelte, Shimport и других библиотек — сегодня твитнул про свою интересную находку в коде three.js.

Если вам нужно удалить один элемент из массива, можно воспользоваться array.splice(index, 1). Но если у вас огромный массив, то splice() будет работать очень медленно, так как будет происходить сдвиг всех элементов (линейная сложность).

Для тех массивов, где порядок элементов не важен, разработчики three.js используют такой код для удаления элемента:

array[index] = array[array.length - 1];
array.pop();

То есть здесь удаляемый элемент заменяется последним элементом массива и последний элемент удаляется (константная сложность).

В комментариях к твиту пишут, что при разработке на ассемблере для RISC-процессора PlayStation 1 подобный трюк был очень распространён.

#algorithm #js #trick

https://twitter.com/rich_harris/status/1125850391155965952?s=21

Год назад Google представил концепцию порталов для бесшовного перехода между страницами. Пару дней назад появилась подробная статья про то как их использовать "Hands-on with Portals: seamless navigations on the Web".

Порталы используют тэг <portal>. Они очень похоже на старый-добрый <iframe> — контент одного сайта внедряется в другой сайт. Но при этом у порталов есть метод activate(), который позволяет бесшовно перейти на внедрённую страницу, то есть со сменой URL в строке навигации. Анимация перехода может быть абсолютно любой, например, в статье разбирается пример с масштабированием портала с помощью CSS-перерхода.

Новая фича выглядит круто, но порталы пока доступны только в Chrome Canary за флагом chrome://flags/#enable-portals.

#wicg #webplatform #chrome

https://web.dev/hands-on-portals

На Microsoft Build 2019 пару дней назад был интересный доклад Дэниала Розенвассера про новые возможности в TypeScript "What’s new in TypeScript".

Разработчики компилятора последний год работали над скоростью. В версии 3.4 добавили инкрементальную сборку сборку проекта с сохранением состояния между сборками с помощью флага --incremental.

Было добавлено ключевое слово readonly, которое можно использовать вместо ReadonlyArray. Ещё теперь можно разворачивать кортеж типов в rest-параметрах функции, что позволяет избавиться от перечисления всех возможных параметров с помощью перегрузки типов. Это позволило улучшить типизацию методов bind и call у функций. Пример использования:

type MyTuple = [string, number];
declare function foo(...args: MyTuple): string;

После доклада автор TypeScript — Андерс Хайлсберг — отвечал на вопросы. Среди них был вопрос про компиляцию в WebAssembly. Если говорить кратко, это не имеет смысла. Для запуска TypeScript в WebAssembly необходим скомпилированный в WebAssembly JavaScript-движок, таким образом появляется избыточный слой (речь шла про браузерное окружение).

В общем, доклад хороший, советую посмотреть.

#typenoscript #webassembly #talk

https://www.youtube.com/watch?v=Au-rrY0afe4

Джереми Кейт написал у себя в блоге статью "Timing out" про то, как он использует Service Workers, чтобы улучшить пользовательский опыт при "Lie-Fi" (при неустойчивом соединении с сетью).

Стратегия работы с кэшом Service Worker'а выглядит следующим образом. Когда пользователь пытается загрузить страницу, сначала происходит попытка загрузки этой страницы из сети. Если это не удаётся, запрошенная страница берётся из кэша. Если в кэше страницы нет, показывается специальная страница для offline-режима. При этом, если запрашиваемая страница загружается слишком долго (Lie-Fi), пользователю отдаётся закэшированная страница.

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

Если вам потребуется делать что-то подобное, советую заглянуть в статью, там очень подробно разбирается код, который реализует описанную стратегию.

#offlinefirst #serviceworker #cache

https://adactio.com/journal/15122

Посмотрел доклад с прошедшего Google I/O'19 "Next-Generation 3D Graphics on the Web" про настоящее и будущее 3D-графики в Web'е.

Из первой части доклада запомнилось использование веб-компонентов для снижения сложности кода при использовании WebGL-фич. Вот так выглядит пример вставки просмотрщика 3D-моделей на страницу:

// импорт библиотеки
<noscript type="module" src="model-viewer.js"></noscript>
// добавление просмотрщика на страницу
<model-viewer src="astronaut.glb"></model-viewer>

Вторая часть доклада для меня была самой интересной. Она была посвящена новому API — WebGPU. Показали демо, где на сцене рендерилось 10000 объектов. Всё работало довольно производительно (~40fps). WebGPU способен отправить в три раза больше команд на отрисовку относительно WebGL.

Рассказали про то, что с помощью WebGPU теперь можно эффективнее работать с фильтрами пост-процессинга и алгоритмами машинного обучения, так как WebGPU гораздо гибче чем WebGL — он позволяет работать с разделяемой памятью GPU. Это также открывает возможность вынесения симуляции жидкости, скиннинга, параллельной сортировки и других алгоритмов с CPU на GPU.

Новое API доступно пока в Chrome Canary на macOS в экспериментальном режиме. API включается с помощью флага chrome://flags/#enable-unsafe-webgpu. Над новой спецификацией работают производители всех браузеров.

#talk #webgl #webgpu

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

Хоть я и пользуюсь для разработки Vim'ом, не могу пройти мимо этой новости. Недавно разработчики Visual Studio Code анонсировали поддержку удалённой разработки в WSL, контейнерах и на удалённых машинах через SSH — "Remote Development with VS Code".

Иногда бывает так, что локально развернуть проект для разработки либо сложно, либо невозможно. В этом случае можно синкать файлы на удалённую машину или примонтировать локально удалённую директорию. При таком подходе используются те инструменты, которые доступны локально, что бывает не очень удобно. Можно разрабатывать полностью на сервере, запустив удалённо Vim/Emacs, но это подойдёт далеко не всем. Разработчики VS Code попробовали улучшить опыт удалённой разработки, и, по-моему, у них это получилось.

Они сделали поддержку запуска VS Code одновременно на сервере (development services) и на клиентской машине. Серверная часть работает непосредственно с кодом: реализует поддержку IntelliSense, go to definition, поиск и т.п. Локальная версия VS Code выступает "тонким клиентом". Благодаря этому становится возможна отладка linux-приложений в VS Code, запущенном на Windows, и многое другое.

Поддержка удалённой разработки доступна в insiders build. Когда она будет доступна в стабильном релизе, пока неизвестно.

#vscode #devexperience #microsoft

https://code.visualstudio.com/blogs/2019/05/02/remote-development

Томаш Лакоми написал неплохую статью о том, как приготовить хороший технический доклад "What I wish someone told me about speaking at tech conferences".

Сначала в статье даются рекомендации, как подаваться на большую конференцию. Запомнился совет про то, чтобы дать прочитать тезисы доклада своим коллегам. Советует не сдаваться, если получили отказ, и продолжать подавать доклад на другие конференции и локальные митапы. (Кстати, если вы хотите выступить с докладом, то можете написать мне. Я один из организаторов митапа JS Party Nsk.)

Далее Томаш пишет про подготовку слайдов. Делится тем советом, который запомнился ему больше всего: "Люди либо могут вас слушать, либо читать ваши слайды. Они не будут делать это одновременно". Меня немного удивило то, что он предлагает разместить ник, использующийся в социальных сетях, на всех слайдах в углу, кажется, что в этом есть смысл.

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

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

#conference #softskills

https://dev.to/tlakomy/what-i-wished-someone-told-me-about-speaking-at-tech-conferences-3opp

Сегодня прочитал хорошую статью Юана Чуана про нестандартное свойство -webkit-box-reflect "Chinese Window Lattice And CSS".

В статье рассказывается, как с помощью CSS нарисовать традиционный китайский узор. Идея заключается в том, чтобы выделить минимальный элемент, который с помощью отражений можно преобразовать в сложный паттерн, используя подход похожий на разворачивание сложенного листа бумаги. Достигается это с помощью нестандартного CSS-свойства -webkit-box-reflect, который используется на вложенных друг в друга div'ах. Каждый уровень увеличивает число отображаемых элементов экспоненциально.

Обязательно загляните в статью, так как без иллюстраций описать красоту этого подхода сложно.

P.S. Ссылку на эту статью мне прислал телеграм-товарищ, ex-Amazon бэкендер Олег Ковалёв. Олег ведёт канал @oleg_log, в котором много полезной (и не очень, но весёлой) инфы. Пишет в основном про бэкенд. Читаю его каждый день, интересно, даже если что-то непонятно. В общем, рекомендую.

#css #experimental

https://yuanchuan.dev/2019/05/15/window-lattice-and-css.html

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

Артур обратил внимание на то, что опция для перехода с мобильной версии сайта на десктопную в мобильных браузерах с русской локализацией называется как "Полная версия". Так же называется и ссылка для перехода на десктопную версию на многих российских сайтах. Подсознательно это воспринимается так, что мобильные версии какие-то неполные или урезанные. Соответственно, если в них есть баги или лаги, то мы как разработчики и как пользователи можем воспринимать их несерьёзно. Это же не "полная" версия.

В англоязычном интернете, нет ссылок и опций с названием "Full version", там есть "Desktop site". Артур завёл тикеты на изменение локализации в Chrome, Firefox, Safari и Яндекс.Браузере. "Версия для ПК" уже появилась в стабильном Chrome для Android и iOS. Также был заведён баг в ВК, ребята отнеслись с пониманием и поменяли ссылку на «Версия для компьютера».

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

#musings #mobile #web

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

Сегодня наткнулся на список ресурсов по accessibility от Марси Саттон. Нашёл я его через твит Флориана Бэйенса — разработчика из Нидерландов. Флориан слеп с самого рождения, поэтому его рекомендации стоит уделить как минимум немного внимания.

В этом списке есть много ссылок на ресурсы от W3C, сайты, курсы, инструменты и книги, посвящённые a11y:
- A11y Style Guide
- Google/Udacity Web Accessibility course
- Accessibility Wins
- Inclusive Design Patterns
- Accessibility for Everyone
- и т.д.

Я не специалист по a11y, но кажется, что подборка очень хорошая. Добавил себе в закладки.

#a11y #list

https://marcysutton.com/web-accessibility-resources

Ингвар Степанян из Cloudflare написал статью про объяснение принципа работы Binary AST — "Faster noscript loading with BinaryAST?"

Binary AST — это предложение в TC39, цель которого ускорить парсинг JavaScript. Парсинг может быть основной причиной медленного старта приложений на слабых устройствах. Например, на флагманских смартфонах парсинг 1Мб JavaScrpt занимает 100ms, в то время как на слабых устройствах (Moto G4) — более секунды. С помощью Binary AST на этапе сборки можно представить AST JavaScript в бинарном виде с дополнительными хинтами, которое позволяет ускорить парсинг до 90% в синтетических тестах.

Ингвар в статье также рассказывает про то, каким образом Cloudflare внедрил поддержку Binary AST. Они используют кодировщик Binary AST, который написан на Rust. Исходный JavaScript при этом парсится с помощью Shift в инстансе v8. На данный момент их следующая цель — сбор данных с реальных проектов, чтобы улучшить формат представления AST.

Binary AST находится на первом этапе рассмотрения в TC39. Прототип реализации уже добавлен в Nightly-версию Firefox. Над развитием стандарта работает Mozilla, Cloudflare, Facebook и Bloomberg.

#js #proposal #tc39

https://blog.cloudflare.com/binary-ast/