Jake Archibald: “HTTP/2 push is tougher than I thought”

— HTTP/2 turns out to be pretty low-level, inconsistent between browsers and having poor DevTools support (ie: only Chrome).
— Safari’s behavior is unpredictable. Jake recommends to disable server push for it at all.
— You can use HTTP preloading as a replacement for server push. It’s more reliable, but still has its own problems.

WEBPACK 3

The webpack team is working on a new major version, 3.0.0. These are the answers about it you might find useful.

What’s in the new version?
The most significant change is module concatenation. By default, webpack has always bundled the app modules the way that each module is wrapped in a function. In webpack 3, you can enable the bundler to concatenate multiple modules into a single function wrapper. This makes the bundle smaller and slightly faster. (In fact, that’s just what Rollup does, but with working code splitting and other webpack features.)

See the Tobias Kopper’s technical post for more details.

Why a breaking change? Should I change something?
According to Sean Larkin: “we made internal changes that could break 3rd party plugins.”

So, if you’re a webpack user, you don’t have to change anything. If you’re a plugin author, then, well, check the list of the breaking changes.

When it’s ready?
I don’t know. The webpack 3 milestone is now 66% complete but it can be changed.

Aaand... webpack 3 is already here :D
Release notes: https://github.com/webpack/webpack/releases/tag/v3.0.0

The Microsoft Edge team does some great work with page responsiveness:
— Since EdgeHTML 15, the user input events are now prioritized over the page events. This means that if you click a link on a page while it’s still loading, the click will be processed immediately. No more lagging!
(EdgeHTML is the Edge engine)

— The same applies to scrolling. The page will scroll even when it’s completely blocked (e.g. with an infinite loop). (By the way, there’s also a separate post on making scrolling more responsive.)

— Also, Edge has learned to prioritize browser events above anything else. This means that things like opening a new tab should  work instantly, even if the current tab is frozen. This is something other browsers (at least Chrome) do already have, but it’s still great to see the progress.

Check the post for the GIFs: https://blogs.windows.com/msedgedev/2017/03/08/scrolling-on-the-web/#chIWuP6kTqYlqFuP.97

A new article!
Case: improving the Polished size for webpack users – https://iamakulov.com/notes/polished-webpack/

Polished is a utility library for writing CSS-in-JS under the umbrella of styled-components. Turns out it has a problem: doing import { opacify } from 'polished' generates a bundle twice larger than import opacify from 'polished/lib/colors/opacify.js'.

In the post, I do a detailed step-by-step analysis of why the library has this problem and how to solve it.

Meanwhile, I’ve submitted a PR, aaand it’s released: https://twitter.com/b_hough/status/878199097605459969

Так, кажется, здесь все русскоязычные, так что давайте по-русски :–)

(Seems like everybody speaks Russian here, so let’s use it)

Я только что чуть не потерял полтора часа работы, затупив и запустив git clean -fd в репозитории с кучей изменений. Так что мне два урока, а вам полезная информация:

Урок 1. Запомнить флаг гита --dry-run (или -n, если коротко), который имитирует выполнение команды, но не выполняет её. И никогда не выполнять git clean, не проверив его заранее с этим флагом

(Флаг, вообще говоря, работает почти во всех гитовых командах. Для мержа есть своя альтернатива)

Урок 2. Знать о фиче Local History в Webstorm и том, что с её помощью можно отменить любые изменения за последние пару дней. Слава тем, кто это придумал

(Я знаю только про WebStorm, но, по идее, такая возможность должна быть во всех IDE — или встроенная, или как плагин)

Субхас Дандапани описал 10 ошибок овер-инжиниринга. Важное:

Не пытайтесь обобщать весь код
Есть принцип DRY — Don’t Repeat Yourself — который рекомендует избегать дублирования кода. Но на самом деле, в том, чтобы продублировать код пару раз, нет ничего страшного.

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

В тему: Prefer duplication over the wrong abstraction

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

Остальные 8 ошибок — в статье.

Наконец-то настроил у себя на сайте кеширование. Вот что вам нужно знать, если вы тоже хотите.

Заголовки
Есть 4 заголовка, которые включают кеширование: Cache-Control/Expires и Last-Modified/ETag. Первые два — основные; они включают кеширование и говорят браузеру, сколько времени хранить ресурс. Вторые два — дополнительные; они нужны, когда срок кеширования истёк, и помогают проверить, изменился ли файл (если нет, то браузер просто берёт старый ресурс и продолжает использовать его дальше).

На практике из этого всего вы выбираете один основной заголовок, один дополнительный и используете их вместе. Использовать все 4 нет смысла — браузер всё равно выберет только два из них.

Я рекомендую использовать Cache-Control + ETag. Cache-Control даёт возможность настраивать полезные штуки, которые не настроить с Expires. ETag, согласно MDN, более надёжный, чем Last-Modified.

Жизненный цикл
Если у нас есть картинка pic.jpg, то её обычный жизненный цикл будет таким:

1. Браузер посылает запрос за pic.jpg. Сервер отдаёт файл с заголовками, например, Cache-Control: max-age=60, ETag: deadbeef123.

↓

2. Пользователь обновляет страницу. Если прошло меньше 60 секунд (60 — значение из Cache-Control: max-age), браузер НЕ делает запрос за pic.jpg, а просто берёт ресурс из кеша и использует его.

↓

3. Пользователь обновляет страницу. Если 60 секунд прошло (60 — значение из Cache-Control: max-age), картинка в кеше становится невалидной. Браузер снова делает запрос за pic.jpg и прикрепляет туда заголовок If-None-Match: deadbeef123 (deadbeef123 — значение из ETag, которое браузер получил на первом этапе).

Когда сервер получает запрос, он читает файл и вычисляет для него ETag. ETag — это хеш, который меняется, если меняется файл. А дальше:
— если etag остаётся deadbeef123, сервер возвращает пустой ответ со статусом 304 Not Modified
— если etag оказывается другим (это значит, что файл изменился), сервер возвращает картинку со статусом 200 OK и свежими заголовками Cache-Control и ETag

Отдохните и посмотрите, как два человека забираются по стене: http://i.imgur.com/KZ50JFn.gifv

И поехали дальше.

Полная иммутабельность
Обычно на третьем этапе (↑), когда срок кеширования истекает, браузер делает запрос на сервер. Если файл не меняется, браузер получает 304 Not Modified и не загружает файл. Это хорошо, но лишний запрос на сервер всё равно происходит.

Если вы точно знаете, что файл никогда не поменяется и проверять это нет смысла, вы можете в заголовке Cache-Header указать значение immutable:

Cache-Control: max-age=60, immutable
или просто
Cache-Control: immutable

Тогда браузер всегда будет считать закешированный ресурс валидным и никогда не будет посылать за ним проверочные запросы. Это как если бы вы установили max-age в 1000 лет.

Cache-Control: immutable — это новое значение заголовка. Пока что оно работает только в Firefox и Edge.

Версионирование
У себя на сайте я настроил Cache-Control: immutable для всех изображений, стилей и скриптов. Чтобы при изменении файла подхватывались изменения, я добавляю к имени файла дату изменения: /images/pic.jpg?hash=1499433448. Так браузер посылает запросы на сервер только тогда, когда файл (и, следовательно, его имя) меняется, а всё остальное время хранит его в кеше.

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

Cache-Control: immutable ещё не успело стать стандартной практикой, но его уже использует, например, Facebook, так что вы тоже можете пробовать.

Джеймс добавляет про то, как сделать immutable кроссбраузерным (спасибо!)

Чтобы immutable кеш работал везде, лучше делать max-age: 999999999, immutable

Опубликовал статью на Реддите, разработчики оставили полезные комментарии. Почитайте:
https://www.reddit.com/r/programming/comments/6m037s/modern_overengineering_mistakes_too_much/djy3m9o
https://www.reddit.com/r/javascript/comments/6lufqg/modern_overengineering_mistakes_too_much/djx8z1p/

Есть книга «Getting Real» компании Basecamp (бывшие 37 Signals). Она рассказывает, как умнее, быстрее и проще создавать веб-приложения (это я сейчас подзаголовок перевожу, но он хорошо описывает содержание). Книга очень классная, я бы её вообще назвал одной из классических.

Андрей Романов сейчас начал читать Getting Real и постит конспекты основных мыслей в ВК. Если вы не читали книгу, конспекты вряд ли смогут заменить её, но главные мысли передадут. Если читали, конспекты помогут освежить содержание (я вот как раз освежаю): https://vk.com/feed?section=search&q=%23getting_real

Если заинтересуетесь, вот полная книга. Она бесплатная. Очень рекомендую прочитать её целиком: https://gettingreal.37signals.com

Теф, автор блога «programming is terrible», написал, как строить крупные приложения, чтобы их было легко поддерживать: http://programmingisterrible.com/post/139222674273/write-code-that-is-easy-to-delete-not-easy-to

Пост довольно цельный, поэтому я не могу выделить какие-то ключевые пункты — лучше прочитайте его целиком. Но вот несколько интересных отрывков:

Про Single Responsibility Principle
«Unfortunately, some problems are more intertwined and hard to separate than others. Although the single responsibility principle suggests that ‘each module should only handle one hard problem’, it is more important that ‘each hard problem is only handled by one module’

When a module does two things, it is usually because changing one part requires changing the other. It is often easier to have one awful component with a simple interface, than two components requiring a careful co-ordination between them.»

Про обработку ошибок (интересный подход)
«Erlang/OTP is relatively unique in how it chooses to handle failure: supervision trees. Roughly, each process in an Erlang system is started by and watched by a supervisor. When a process encounters a problem, it exits. When a process exits, it is restarted by the supervisor.

(These supervisors are started by a bootstrap process, and when a supervisor encounters a fault, it is restarted by the bootstrap process)

The key idea is that it is quicker to fail-fast and restart than it is to handle errors. Error handling like this may seem counter-intuitive, gaining reliability by giving up when errors happen, but turning things off-and-on again has a knack for suppressing transient faults.»

Про IMAP (боль и страдания)
«Error handling is one of the many ways in which a system can be tightly bound together. There are many other examples of tight coupling, but it is a little unfair to single one out as being badly designed. Except for IMAP.

In IMAP almost every each operation is a snowflake, with unique options and handling. Error handling is painful: errors can come halfway through the result of another operation.

Instead of UUIDs, IMAP generates unique tokens to identify each message. These can change halfway through the result of an operation too. Many operations are not atomic. It took more than 25 years to get a way to move email from one folder to another that reliably works. There is a special UTF-7 encoding, and a unique base64 encoding too.»

Актуальное. Пожалуйста, не коммитьте закомментированный код: https://medium.com/@kentcdodds/please-don-t-commit-commented-out-code-53d0b5b26d5f

Закомментированный код повышает когнитивную нагрузку
У меня каждая встреча с закомментированным кодом вызывает вопросы:
— зачем его оставили закомментированным, а не удалили,
— насколько он свежий и актуальный,
— можно ли его удалить, или он нужен другому члену команды.

Это всё отвлекает от основных мыслей.

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

Есть Git
Все изменения кода остаются в Git-е. Оттуда код можно достать с таким же успехом, как и из комментария.

В статье ещё и другие мысли.