Defront — про фронтенд-разработку и не только – Telegram
Defront — про фронтенд-разработку и не только
13.5K subscribers
21 photos
1.09K links
Ламповый канал про фронтенд и не только. Всё самое полезное для опытных web-разработчиков

Обсуждение постов @defrontchat

Также советую канал @webnya
Download Telegram
Недавно на youtube появился очень ламповый документальный фильм, посвящённый Ember.js. В нём создатели Ember.js рассказывают про историю появления фреймворка и рассказывают про то, какое место он занимает в современном мире фронтенд разработки.

Ember.js - эволюционное развитие SproutCore, фреймворка, котрый был разработан в Apple (используется на icloud.com). Чарльз Джоли, который был лидом SproutCore, вместе с Йехуда Катц основали стартап, в котором Йехуда и Том Дейл фуллтайм работали над новым фреймворком Amber.js, который затем переименовали в Ember.js. Сейчас вокруг Ember есть небольшое сильное коммьюнити. Фреймворк используют как в стартапах (Tilde), так и в больших корпорациях (linkedin.com). Ребята видят рост популярности React, Angular и Vue.js, но сдаваться не собираются.

Интересный факт - Йехуда и Том разрабатывали абсолютно всё с помощью парного программирования.

#jsframeworks #emberjs #documentary #history

https://www.youtube.com/watch?v=Cvz-9ccflKQ
Продолжаем чтение статей Акселя Раушмайера (что поделать, они очень хороши). В этот раз попалась статья про оптимизацию хвостовых вызовов (tail call optimization - TCO) в ES2015.

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

Наличие оптимизации хвостовых вызовов помогает реализовывать рекурсивные алгоритмы более органично. Жаль только, что TCO, похоже, не скоро будет добавлен в v8 (Chromium) и SpiderMonkey (Firefox) из-за проблем с его реализацией. Поддержка TCO пока только есть в Safari.

#js #tco #fp #es2015

http://2ality.com/2015/06/tail-call-optimization.html
В январе этого года на www.javanoscriptjanuary.com опубликовали статью гуглера Майка Самуэля "Defensive JavaScript" про то, каких подходов следует придерживаться, чтобы писать безопасный код.

Просто перечислю основные пункты из статьи. Не доверяйте кастомным проверкам, так как в процессе тестирования ложно-негативные случаи выявляются с меньшей вероятностью, лучше воспользоваться готовым и проверенным временем инструментом. Проверяйте предположения перед тем, как делать то, что нельзя отменить, например, предположение о том, что строка безопасна, при использовании myDOMNode.innerHTML = x; или response.write(x); на сервере. Не стоит пренебрегать дополнительными уровнями защиты, даже если они кажутся избыточными. Если вы используете статическую типизацию, это не повод отказываться от дополнительных проверок пользовательских данных.

Статья хорошая, несмотря на то что есть проблемы с форматированием. Всегда интересно прочитать про то "как там у них". Очень оценил большое количество ссылок на релевантные темы. В общем, рекомендую.

#js #security

https://www.javanoscriptjanuary.com/blog/defensive-javanoscript
В рассылке сайта dev.to попалась статья про прфессинальное выгорание. Это очень серьёзная проблема, к которой, к сожалению, иногда относятся несерьёзно.

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

Пожалуйста, берегите себя и тех, кто вас окружает.

#productivity

https://dev.to/molly_struve/i-cant-do-it-all-my-burnout-story-1e54
Для того чтобы разобраться в нюансах настройки кэширования ресурсов на стороне клиента, советую прочитать очень хорошую статью Гарри Робертса "Cache-Control for Civilians", которую он опубликовал буквально пару дней назад.

В статье разбираются как распространённые методы управления кэшом, например, использование заголовка Cache-Control, так и новые механизмы, например, директива immutable и заголовок Clear-Site-Data. Рассказывается про кэш-бустинг. Из этой части я узнал, что cloudflare удаляет query string, если он используются для бустинга ассетов. То есть style.css?v=1.2.14 превращается просто в style.css. Ещё в статье есть пара практических советов настройки кэширования для определённых видов страниц.

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

#http #cache

https://csswizardry.com/2019/03/cache-control-for-civilians/
Кайл Симпсон (автор "You Don't Know JS") у себя в твиттере поделился своими наблюдениями про то, как иногда используются функции, содержащие this.

Если вы замечаете, что вам становятся нужны стрелочные функции для сохранения контекста и что вы чрезмерно используете .bind() или старый-добрый var self = this;, то всё это симптомы того, что вы боритесь с this. Например, если такой класс используется в вашей программе автономно:

class Foo {
constructor(x) {
this.x = x;
this. bar = () => this.baz(this.x + 1);
this.baz = v => v * 2;
}
}

var a = new Foo(20);
btn.addEventListener("click",a. bar); // 42


То его можно заменить паттерном "Модуль":
fu
nction Foo(x) {
return { bar, baz };
function bar() { return baz(x + 1); }
function baz(v) { return v * 2; }
}

var a = Foo(20);
btn.addEventListener("click",a. bar); // 42

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

#js #context

https://twitter.com/getify/status/1101491957916938240?s=21
В 2017-ом году Анна Селезнёва из Злых Марсиан выступала на Web Standards Days с докладом "Знакомьтесь, модальное окно".

Это очень хороший доклад про то, какие есть подходы при создании модальных окон в вебе. Аня делится практическими советами реализации модальных окон и затрагивает вопросы доступности и юзабилити. Из доклада я узнал про экспериментальный атрибут inert, с помощью которого можно сделать так, чтобы элементу нельзя было выставить фокус с клавиатуры, и focus-lock - библиотеку для захвата фокуса.

Доклад был в 2017-ом году. На данный момент его можно дополнить тем, что элемент <dialog> стал официальной частью стандарта HTML 5.2 в 2018-ом году.

#webstandards #ui #a11y #talk

https://www.youtube.com/watch?v=s6PI8pKQxgo
Наткнулся на пост, написанный Рейчел Эндрю в 2016 году, в котором она рассказывает про то, почему не будет CSS4 "Why there is no CSS4 - explaining CSS Levels".

В статье Рейчел говорит про то, что cамая последняя монолитная спецификация была версии 2.1. Участники рабочей группы решили, что для более эффективной разработки новых стандартов её стоит разбить на части. Поэтому следующая спецификация уже состояла из отдельных документов, так называемых "модулей". И если вы читаете какую-то книгу или статью про CSS3, на самом деле вы читаете про набор разных документов.

Существующим стандартам, которые являются развитием предыдущей версии CSS2.1 был присвоен "Level 3" (например, "CSS Selectorls Level 3"). А новым фичам, которых раньше не было - "Level 1" (например, "CSS Flexible Box Layout Module Level 1"). Такое разбиение позволяет участникам рабочей группы работать независимо над разными частями CSS, не блокируя релизы новых версий спецификаций соседних модулей.

#css #webstandards #csswg

https://www.rachelandrew.co.uk/archives/2016/09/13/why-there-is-no-css4-explaining-css-levels
Бенедикт Мюрер - разработчик 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 #ecmanoscript

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