Сатья Гунасекеран из команды разработчиков v8 сегодня твитнул про, то что в новом релизе Chrome 75 была добавлена реализация предложения TC39 Numeric Separators (stage 3).

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

const million = 1_000_000;
const billion = 1_000_000_000;

В твите есть ссылка на хорошую статью Акселя Раушмаера про новое предложение с разными примерами его использования и замечаниями, в каких случаях разделители в числах лучше не использовать.

#v8 #proposal #js

https://twitter.com/_gsathya/status/1120389255619055616?s=21

Самая большая новость прошедшего дня — выпуск Node.js 12. Команда разработчиков Node сделала обзор нововведений в статье "Introducing Node.js 12".

V8 был обновлён до версии 8.7.4. Теперь в Node есть поддержка асинхронных стек-трейсов, быстрый await, был ускорен парсинг JS. Была добавлена поддержка TLS 1.3, но из-за проблем с совместимостью по-умолчанию Node работает по TLS 1.2. Доступная для Node память теперь по умолчанию ограничена объёмом доступной памяти в системе, ранее доступная память по-умолчанию была ограничена 700Mb или 1400Mb для 32- и 64-разрядных систем соответственно (наследие браузеров). Дефолтный http-парсер теперь llhttp. Продолжается работа над упрощением работы с нативными модулями, написанными на языках C, C++, Rust и т.п. Node.js теперь запускается быстрее на 30% благодаря тому, что code-cache для встроенных модулей добавляется прямо в бинарный файл на этапе сборки. Продолжается работа над ESM-модулями (доступны за флагом `--experimental-modules`) и Worker Threads. Добавлен Diagnostic Reports, про который я писал несколько недель назад. Сборка теперь требует GCC6, Xcode 8 или Visual Studio 2017. Минимально поддерживаемая версия macOS 10.10 “Yosemite”, Windows 7, 2008 R2 или 2012 R2. Платформы, использующие glibc, для поддержки Node.js 12 должны включать минимальную версию glibc не ниже 2.17.

#nodejs #release #announcement

https://medium.com/@nodejs/introducing-node-js-12-76c41a1b3f3f

Разработчики Wasmer — рантайма для WebAssembly — представили пакетный менеджер WAPM.

WAPM расшифровывается как "WebAssembly Package Manager". Он состоит из двух частей: приложения командной строки wapm и реестра пакетов wapm.io. Цель нового пакетного менеджера — упрощение работы с модулями WebAssembly (запуск, распространение), поддержка разных видов ABI (WASI, Emnoscripten), простая интеграция с разными экосистемами языков (Python, PHP, Ruby, JavaScript). В разделе про NPM разработчики пишут про то, что WebAssembly на сервере — это совершенно новый сценарий использования технологии, поэтому при создании WAPM они решили отказаться от экосистемы JavaScript.

Проект, определённо, стоящий, но (имхо) всё ещё экспериментальный, так как у меня с первой попытки не заработал простой пример из статьи.

https://medium.com/wasmer/announcing-wapm-the-webassembly-package-manager-18d52fae0eea

#webassembly #package #announcement

Пару дней назад вышел релиз Chrome 74. Пит Лепаж сделал обзор новых возможностей, которые будут интересны разработчикам.

Были добавлены приватные поля классов:

class IncreasingCounter {
  // Private class field
  #privateValue = 0;
  get value() {
    return this.#privateValue;
  }
  increment() {
    this.#privateValue++;
  }
}

Появилась поддержка нового медиа-выражения, которое позволяет определить, отключены ли анимации во всей системе @media (prefers-reduced-motion: reduce). Это очень полезное выражение, так как некоторые пользователи могут испытывать симптомы укачивания на страницах с параллакс-эффектом, зумом и другими эффектами движения.

Добавлены события CSS-transitions (transitionrun, transitionstart, transitionend, transitioncancel) и обновлено API Feautre Policy, например, можно получить список всех доступных фич, с помощью document.featurePolicy.allowedFeatures().

В статье ещё есть много ссылок с подробным объяснением всех новых фич.

P.S. Если среди подписчиков канала кто-нибудь завтра идёт на Я.Субботник в Москве, где я буду рассказывать про кодмоды, подходите сказать привет, буду рад услышать ваш фидбек про канал.

#announcement #chrome #release

https://developers.google.com/web/updates/2019/04/nic74

Прочитал статью Эрика Эллиота 2017-го года "Getting to 10x (Results): What Any Developer Can Learn from the Best". В ней рассказывается про то, какими качествами обладают эффективные программисты.

Эрик опросил более 1000 программистов. Он попросил поделиться мнением о том, какими качествами обладали самые экстроординарные программисты, с которыми им приходилось работать (так называемые "десятикратники" - 10x). В топ-5 попали: эффективный поиск решения проблем, много умеет (skilled), учитель/ментор, отличный ученик, любит то, чем занимается. Затем в статье разбирается каждое качество и как их можно улучшить. Затронул тему менторства, приведя такой пример. Если два 1x становятся 5x, под менторством одного 10x, то они могут сделать работу десяти программистов уровня 1x, даже если 10x будет заниматься только менторством.

Ещё в опросе он попросил поделиться качествами самых худших программистов. В топ-5 попали: некомпетентность, высокомерие, неспособность к эффективной работе с другими, немотивированность и упрямство. Для каждого качества даются советы, что можно с ними сделать, чтобы эффективнее двигаться в сторону 10x.

От себя хочу добавить, что не стесняйтесь просить фидбек своих коллег о том, над чем вам стоит поработать.

#programming #psychology #productivity

https://medium.com/javanoscript-scene/getting-to-10x-results-what-any-developer-can-learn-from-the-best-54b6c296a5ef

Кент Си Доддс опубликовал у себя в блоге статью про то, как управлять состоянием приложения, не используя сторонние библиотеки, "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