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

Пишут о том, что последний год решали фундаментальные проблемы Flow: скорость и оптимизацию потребления памяти. Оптимиазция по скорости снизила число запросов от IDE, занимающих более одной секунды, с 1 млн./день до 25 тыс./день. Уважают решение разработчики сторонних библиотек о переходе с Flow на TypeScript, но для Facebook Flow остается очень важной технологией. Еще обещают быть более открытыми по поводу своих планов на будущее.

https://medium.com/flow-type/what-the-flow-team-has-been-up-to-54239c62004f

#flow

Прочитал интересную статью Джека Арчибальда про относительно недавний хак npm-пакета event-stream. В ней очень много дельных советов про то, как свести к минимуму подобные атаки и ликвидировать их последствия.

Чтобы вредоносный пакет не смог своровать ваши ssh-ключи с компьютера или что-нибудь натворить на сервере, используйте сандбоксинг с помощью Docker или обычную виртуальную машину во время разработки. С предотвращением атак на пользователей сайта, на котором работает вредоносный скрипт, всё гораздо сложнее. Для себя я выделил следующие моменты: аудит зависимостей тех приложений, которые работают с финансами, разделение процесса сборки на два этапа (“trusted”, “untrusted”) и подключение на сайт политик csp, чтобы минимизировать риски для атакованного пользователя.

Ещё в статье мне понравился интересный трюк с полной очисткой всех сохранённых сайтом данных (куки, кеши, localStorage, sessionStorage и т. п.) Для этого серверу достаточно отправить http-заголовок Clear-Site-Data: *, браузер почистит всё сам, но работает пока это только в Chrome и Firefox.

https://jakearchibald.com/2018/when-packages-go-bad/

#security #npm

Идея web-компонентов была представлена широкой общественности в 2011 году. Ребята из Google за это время смогли убедить сообщество в том, что их идея достойна того, чтобы стать частью официальных web-стандартов.

Сейчас нативная поддержка web-компонентов версии 1 в той или иной степени есть в Chrome, Safari и Firefox. Полноценная поддержка в Edge появится скорее всего уже после перехода на Chromium (маловероятно, что Microsoft будет инвестировать разработку в текущий движок). Поэтому, если web-компоненты прошли мимо вас, сейчас самое время начать с ними знакомиться. Отправной точкой может послужить довольно свежая статья в блоге Mozilla Hacks “The Power of Web Components”.

https://hacks.mozilla.org/2018/11/the-power-of-web-components/

#webcomponents #webstandards

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

Для macOS советую попробовать gitup — очень быстрый и приятный в использовании gui-инструмент с полностью открытым исходным кодом. С его помощью можно не только посмотреть, как ветки вливались друг в друга, но и при желании заребейзиться, черри-пикнуть или засквошить коммиты и сделать много всего другого.

https://gitup.co

#macos #tool

Сегодня меня занесло в 2013-ый год. Прочитал статью журнала ACM, про оптимизацию сайтов для мобильных устройств. Несмотря на то, что статья была опубликована 6 лет назад и кое-какие моменты уже не так актуальны, очень многие идеи в ней до сих пор остаются полезными.

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

Раздел про оптимизации с помощью JavaScript немного устарел. От себя добавлю, что во всех современных браузерах, для того чтобы загрузка скрипта не блокировала рендеринг (что очень актуально для мобильных устройств) можно использовать атрибуты async или defer тега noscript. Для того чтобы избавиться от задержки в 300 мс при кликах на тач-девайсах, используйте <meta name="viewport" content="width=device-width"> в <head> документа.

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

#performance #mobile

Youtube в рекомендациях предложил посмотреть доклад Себастьяна Маккинзи с JSConf 2015. Стоит смотреть, если вам интересен небольшой общий рассказ про Babel от его создателя.

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

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

#babel #talk #js

Уже больше недели в открытых вкладках у меня висела статья Эрика Эллиота о прогнозах про web и технологии на 2019 год.

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

Также по его мнению не стоит сбрасывать со счетов крипто-индустрию. Несмотря на текущее затишье, в будущем она будет продолжать расти. Стоит посматривать на следующие технологии: PWA, машинное обучение, виртуальная/дополненная реальность, робототехника, квантовые вычисления.

https://medium.com/javanoscript-scene/top-javanoscript-frameworks-and-topics-to-learn-in-2019-b4142f38df20

#web #js #musings

Сегодня Антон Виноградов из Яндекса опубликовал статью на хабре про историю объединения React и БЭМ. Честно говоря, я давно хотел прочитать подобную статью. В ней приводятся хорошие аргументы того, почему потребовалось скрещивать технологии между собой.

Если говорить кратко, React хорош для манипуляций с DOM, но при этом БЭМ позволяет очень точно управлять зависимостями, доставляя только нужный код клиенту. При этом БЭМ и React никогда не воевали между собой и не было цели их противопоставлять друг другу: "Компании не соревнуются в создании лучшего фреймворка на Земле. Если компания начнёт тратить меньше времени на инфраструктурные задачи при той же продуктивности, все от этого только выиграют".

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

https://habr.com/ru/company/yandex/blog/438598/

#yandex #bem #react

Сегодня разработчики 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