Сегодня разработчики React зарелизили новую версию библиотеки (v16.8) с поддержкой хуков.

Для React-сообщества это большое событие, так как подобное масштабное изменение апи было довольно давно, когда в 14-ой версии были добавлены функциональные компоненты. С помощью хуков можно использовать стейт, lifecycle-методы и другие фичи React, не используя class-based компоненты. Хуки расширяют возможности библиотеки, то есть от class-based компонентов React отказываться не будет. По ссылке в разделе "What are hooks?" есть небольшая подборка хороших статей и доков, для того чтобы начать погружение в новое апи.

В следующем квартале (2019 Q2), команда React планирует зарелизить конкурентный режим (Concurrent Mode). С помощью него такие события, как ввод текста или наведение курсора на элемент, смогут приостанавливать текущий рендеринг дерева компонентов в основном потоке браузера, для того чтобы приложение было более отзывчивым.

https://reactjs.org/blog/2019/02/06/react-v16.8.0.html

#react #hooks #release

Никита Прокопов один из самых известных представителей российского Clojure-сообщества. Время от времени он публикует очень интересные статьи у себя в блоге tonsky.me.

В ноябре 2018 года Никита написал небольшой пост "Решайте ту проблему, которую нужно решить". Основной посыл статьи в том, что тот код, в котором предусматриваются потенциальные проблемы, которые на данный момент не имеют смысла, создает больше проблем, чем приносит пользу. Такой код сложнее понимать и сложнее поддерживать. Он также говорит про то, что наверное не все смогут принять: обычно наши предсказания по поводу развития требований не сбываются, и получается, что мы усложняем код только ради усложнения кода...

"Вот чему научила меня экосистема Clojure. Все должно быть конкретным. У Clojure просто нет средств для переобобщения кода. Он либо конкретен как бетон, либо его нет".

#musings #clojure #programming

http://tonsky.me/blog/concrete-vs-abstract/

Недавно слушал подкаст JavaScript Jabber, где Бэн Ко (разработчик Istanbul и DevOps NPM) рассказывал про свою жизнь и работу. Из этого подкаста я узнал, что он разрабатывает новый инструмент для измерения покрытия кода юнит-тестами - c8.

С8 интересен тем, что он не использует выделенный парсер и инструментатор кода как Istanbul, он использует встроенные возможности движка v8 для сбора покрытия, поэтому работает быстрее своего старшего брата.

Можно ли c8 уже использовать в продакшене? Наверное, нет, так как ещё есть нерешённые проблемы. Но тем не менее это очень интересный экспериментальный проект, который имеет потенциал превратиться в основной инструмент для измерения покрытия кода в мире JavaScript.

https://github.com/bcoe/c8

#nodejs #testing #tool #experimental

Интересная складывается ситуация: Chromium в последние годы очень сильно разогнался и браузеры, построенные на его основе, заняли большую часть рынка. Есть мнение, что это может негативно сказаться на развитии web-платформы. Об этом пишет в своём посте Джеффри Зельдман. Я готов подписаться под каждым абзацем, хотя и использую основную часть своего времени Chromium-based браузеры.

Джеффри пишет о том, что разнообразие браузеров и их конкуренция это именно то, что послужило бурному росту платформы. Он предлагает вспомнить, что было в мире фронтенд-разработки, когда доминировал Internet Explorer. Он переносит опыт с IE на текущую ситуацию с Chromium, и это по-настоящему заставляет задуматься.

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

#web #chromium #musings

https://www.zeldman.com/2018/12/07/browser-diversity-starts-with-us/

Как продолжение предыдущего поста сегодня мы отправляемся в 2008 год. На компьютерах большинства пользователей установлен Windows XP/Vista с IE 6/7. Мы пишем js-код var str = 'Hello world'; var char = str[0]; и он падает...

Мэтт Джука, объясняет, что это связано с тем, что в IE 6/7 был имплементирован JScript - надмножество ECMAScript 3, и в стандарте не было возможности получения символа по индексу с помощью квадратных скобок, для получения элемента надо было использовать стандартизированный метод charAt(). Затем вышел новый стандарт ECMAScript 5, в котором эта проблема была решена и в IE8 наконец-то стало возможным использовать var char = str[0].

Теперь давайте немного посчитаем. IE6 вышел в 2001 году, IE8 - в 2009 году. 8 лет потребовалось, чтобы сделать жизнь JS-разработчикам немножко лучше. Вот яркий пример, к чему может привести монополия.

#js #history

https://unspecified.wordpress.com/2008/06/15/portable-javanoscript-string-indexing/

В прошедшую субботу в Яндексе был митап "Я❤️Frontend". На нём выступал мой коллега Антон Кастрицкий с докладом «Вебпак, вид сквозь монокль». Для меня это был один из самых интересных и полезных докладов.

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

В общем, рекомендую посмотреть, даже если вы давно пользуетесь Webpack. Информации много и представлена она очень хорошо и доступно.

#webpack #talk

https://www.youtube.com/watch?v=iWPu3Crpys0&t=6077

Франческо Черилло – автор метода помидора из тайм-менеджмента – оказывается опытный программист. В 2007 году он запустил кампанию "Anti-If". Идея компании состоит в распространении знаний наилучших инженерных практик в сфере разработки, повышая осознанность об одной из самых негативных практик – чрезмерном использовании if.

Конечно, в самом if ничего страшного нет, но только тогда, когда он используется очень умеренно. Большое же количество этих инструкций приводит к запутанному коду и его связности, разбираться в нем очень тяжело.

В общем, это интересная кампания, которая заслуживает того, чтобы вы про неё по крайней мере узнали.

https://francescocirillo.com/pages/anti-if-campaign

#programming #softwaredesign

Вчера я рассказал про "Anti-If", но на сайте кампании нет практических примеров про то, каким образом можно избавиться от большого количества ветвлений в коде. Статья "Anti-If: The missing patterns" восполняет этот пробел.

Для того, чтобы уменьшить количество ветвлений разбивайте методы на более мелкие, если их логика зависит от логического параметра. Вместо использования switch, можно использовать полиморфизм. Не делайте явные проверки на null, используйте Optional типы либо альтернативы. Заменяйте if выражениями. Локализуйте проверки на граничные значения в одном месте, не позволяйте им расползаться по коду.

Да, статья использует Java, но, если вы сталкивались с типизацией в JS, разобраться в примерах не составит труда.

#programming #java #softwaredesign

https://code.joejag.com/2016/anti-if-the-missing-patterns.html

Попалась на глаза серия из двух статей про CSS-in-JS от автора библиотеки JSS Олега Исонена. В первой части рассказывается про причины появления этого подхода.

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

При этом в статье есть очень спорный момент. Автор пишет про то, что для решения некоторых описанных проблем были придуманы разные методологии наименования стилей и организации кода. При этом эти методологии очень сложны во внедрении, когда над проектом работает большое количество людей. По-моему личному опыту это не так. Конечно, какое-то недопонимание может быть в самом начале, но когда все участники разработки видят, что та структура, которую даёт BEM, Beavis и подобные методологии, лишает их головной боли, никаких проблем во внедрении быть не должно. Проблема потенциально может возникнуть только на уровне коммуникации, когда она доносится неправильно, и команда не видит в ней объективных преимуществ.


#cssinjs #css #bem

https://medium.com/dailyjs/what-is-actually-css-in-js-f2f529a2757

Вчера я поделился своими мыслями о первой части статьи "What is actually CSS-in-JS". Сейчас хочу рассказать про вторую часть - "The tradeoffs of CSS-in-JS", которая перечисляет существующие недостатки подхода.

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

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

#cssinjs #css

https://medium.com/@oleg008/the-tradeoffs-of-css-in-js-bee5cf926fdb

Технический долг – одна из самых больных тем, которые возникают при продуктовой разработке. На него вечно не хватает времени, и бизнес часто не видит необходимости в его устранении. Статья "How great Product Managers deal with technical debt" приводит в пример некоторые инсайты, которые помогут в снижении долга.

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

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

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

#pm #product

https://productcoalition.com/how-great-product-managers-deal-with-technical-debt-453edec3d473

"XML and JSON Are Like Cardboard" - статья, рассказывающая про то, что представляют собой для современного мира слабоструктурированные (Semi-structured) текстовые форматы обмена данными.

Автор сравнивает XML и JSON с картоном. Практически любая промышленность использует картон для упаковки товара. Если вы закажите маленький чип в интернет-магазине, его вам доставят упакованным в большое количество картона, вес которого будет в несколько раз больше. Тем не менее использование избыточного количества картона в упаковке, превышает потенциальные потери, которые могут быть вызваны при транспортировке без него.

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

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

#musings #xml #json

https://queue.acm.org/detail.cfm?id=3143320

Давайте поговорим про js-фреймворки, а именно про будущий Vue 3.0. Кажется, что прошло совсем немного времени с момента релиза второй версии, но разработчики уже готовы выпустить следующий мажорный релиз. Статья "What Does Vue 3.0 Mean for Web Development?" рассказывает о том, чего нам ждать в будущем.

Основной упор был сделан на оптимизации производительности. Движок отслеживания изменений был переписан на ES2015 Proxy. Это позволило ускорить начальную инициализацию компонентов в 2 раза и снизить потребление памяти. Также разработчики разбили фреймворк на ещё большее количество модулей, что позволило уменьшить ядро до 10Кб (в gzip). Во второй версии были эксперименты с использованием Vue на нативных платформах аля React Native. В третей версии поддержка нативных платформ заявлена как основная фича. Под шумок разработчики переписывают код с Flow на TypeScript, мотивируя это тем, что пользователей TS гораздо больше. Очень много внимания уделили Developer Experience.

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

#vue #js #jsframeworks

https://medium.com/@mattmaribojoc/what-does-vue-3-0-mean-for-web-development-851052fc0138

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

Как оказалось в v8 оператор in не оптимизирован. Все его вызовы приводят к дорогостоящим рантайм проверкам. В пропозале идёт речь про переход к использованию инлайн кешей и jit-оптимизаций при использовании in. Но есть известные проблемы, когда перебираются все ключи объекта, в этом случае оптимизаций нет.

Были произведены замеры с тестовой реализацией v8 на методе Array.prototype.indexOf, который вызывался 10 раз у массива с 10 миллионами элементов. Результаты хорошие - заметно ускорение в 4-10 раз на разных типах массивов.

#js #v8 #performance

https://docs.google.com/document/d/1tIfzywY8AeNVcy_sen-5Xev21MeZwjcU8QhSdzHvXig/edit

Для меня было небольшим открытием, что на сайте npm есть semver-калькулятор.

Вводите в поле "pick a package" интересующий пакет, в поле "enter a range" диапазон версий и вуаля - зелёным цветом будут показаны все нужные версии.

В самом низу есть небольшая шпаргалка по тому, как задавать разные диапазоны версий. Удобно.

#npm #tool

https://semver.npmjs.com

Может быть конвертация строки в число сама по себе простая операция, но только не в JavaScript, где существует множество возможностей выстрелить себе в ногу. Валерий Карпов в статье "Convert a String to a Number in JavaScript" описывает суть проблемы с конвертированием и приводит возможные решения с хорошим объяснением нюансов.

Автор предлагает использовать Number(), если вы готовы мириться с граничными случаями при конвертации, например, Number(''); // 0, и parseFloat(), если вам нужна большая строгость parseFloat(''); // NaN. Для проверки, является ли число NaN, советует использовать метод Number.isNaN(), который был добавлен в ES2015. Призывает отказаться от использования глобального isNaN(), так как isNaN('string') === true, а Number.isNaN('string') === false, то есть в последнем варианте аргумент не приводится к числу и таким образом этот метод "честнее" для разработчика.

Странно, что в статье про parseInt() ничего нет. Видимо, подразумевается, что мы работаем в основном с десятичной системой счисления.

#js #quirks

http://thecodebarbarian.com/convert-a-string-to-a-number-in-javanoscript.html

С развитием прогрессивных web-приложений (PWA) необходимость в нативных платформах становится не такой острой как раньше, особенно когда web-приложения взаимодействует только с серверами. Но, к сожалению, они проигрывают, когда необходимо организовать общение с устройствами, например, роутером, дроном, умной лампой и т.п. Чтобы избавиться от этого недостатка, в современных браузерах реализуют новый стандарт WebBluetooth API. Статья "An Introduction To WebBluetooth" от Ниелса Линхера служит хорошей отправной точкой для начала его изучения.

Работа с устройствами очень проста при использовании WebBluetooth. Достаточно подключиться к устройству по bluetooth через браузер (интересно, что в терминах WebBluetooth API устройство является сервером) и выбрать нужный сервис на устройстве. После выбора нужного сервиса можно начинать записывать в определённые характеристики сервиса значения, чтобы изменить поведение устройства, например, изменить цвет у умной лампы, или узнать текущие характеристики, например, уровень белого цвета у той же лампы.

Я считаю, что перспективы у этого стандарта очень хорошие. С учётом того, что на рынке появляются всё больше и больше устройств с поддержкой bluetooth, ещё большее распространение API (сейчас оно доступно только в Chromium-based браузерах и Samsung Internet) может послужить импульсом для появления очень креативных web-приложений.

#webapi #bluetooth #WebBluetooth

https://www.smashingmagazine.com/2019/02/introduction-to-webbluetooth/

Прочитал очень интересную статью Эрика Эллиота "The Forgotten History of OOP". В ней очень детально разбирается история появления ООП и то как оно трансформировалось с течением времени.

Всё началось с биолога и математика Алана Кея, который был вдохновлён идеей создать вычислительные части одной системы "клетками". Его идея воплотилась в одном из первых ООП языке - Smalltalk'е. На него большое влияние оказали Lisp и Simula. Наследование в него было добавлено позже уже другим человеком. Алан считает, что наследование послужило той причиной по которой его основные идеи, которые он вложил в понятие ООП, не получили большего внимания. Основными ингредиентами ООП по его мнению являются передача сообщений, инкапсуляция и динамическое связывание. То есть по большей части совсем не то, что подразумевают большинство современных программистов, когда слышат это понятие (инкапслуяция, наследование, полиморфизм).

Эрик предлагает вернуться к изначальным идеям Алана Кея и начать разрабатывать системы в парадигме MOP (термин предложен Эриком как сокращение от Message Oriented Programming). При проектировании таких систем компоненты не должны знать о внутреннем состоянии других компонентов, всё взаимодействие между ними должно быть построено на передаче сообщений, при этом они могут работать распределённо.

После прочтения статьи меня не оставляет ощущение, что эти идеи очень сильно перекликаются с микросервисной архитектурой.

#oop #history #musings

https://medium.com/javanoscript-scene/the-forgotten-history-of-oop-88d71b9b2d9f

Давно смотрю в сторону elm, но пока с ним ничего серьёзного не делал. Тут попалась статья "Elm changed my mind about unpopular languages", после прочтения которой снова захотелось что-нибудь написать на этом языке.

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

У elm много плюсов: элегантный командный интерфейс, поставляющаяся с платформой утилита для автоматического форматирования кода, обязательное следование semver у пакетов, дебаггер с поддержкой time-travel, отличная производительность, хорошо проработанный интерфейс взаимодействия с JS. Также есть минусы: высокий порог входа для программистов, привыкших работать с императивными языками, нельзя использовать на сервере, недостаёт высокоуровневых возможностей других функциональных языков, например, Haskell.

#elm #fp

https://blog.realkinetic.com/elm-changed-my-mind-about-unpopular-languages-190a23f4a834

Мне очень нравятся статьи Ире Адеринокун - просто и по делу. Недавно она опубликовала статью "Tips for making interactive elements accessible on mobile devices", с советами как облегчить жизнь пользователям мобильных сайтов.

В статье много советов, и они должны быть достойны вашего внимания. Размещайте интерактивные элементы в доступных местах на странице. Старайтесь делать интерактивные элементы так, чтобы пользователь понимал, что с ними можно взаимодействовать. Предоставляйте инструкции для нестандартных жестов, например, как в Twitter при обновлении ленты твитов. Увеличивайте расстояние между элементами и область тапа, чтобы интерактивные элементы можно было удобно нажимать пальцем. Группируйте объекты, выполняющие одинаковые действия. Используйте возможности HTML5, для настройки раскладки клавиатуры при работе с <input>. Предоставляйте альтернативу ввода с помощью клавиатуры.

На написание статьи Ире сподвигнули рекомендации W3C - Web Content Accessibility Guidelines 2.1, которые были обновлены в июне 2018 года.

#ui #a11y #mobile

https://bitsofco.de/tips-for-making-interactive-elements-accessible-on-mobile-devices/