Зря вы забыли эти HTML- и CSS-фичи

currentColor широко используется в svg, он точно не забыт. Хотя вот я сейчас узнал, что можно не только в svg )

Верните мне 2008-й: немного ностальгии

Дней медведевских прекрасное начало

Вообще, кажется, сейчас начинается золотое время в IT

То ли Гайдара, то ли Чубайса

CSS-in-JS vs CSS Modules: что выбрать в 2026?

У css-modules есть досадный минус: из коробки они плохо типизированы. Если написать import styles from './Comp.module.css'; , то styles оказывается просто Record<string, string>. Есть какие-то дополнительные нашлепки, которые генерят *.d.ts, но это так себе.

На текущем проекте используем vanilla-extract, вполне устраивает.

Почему JS/TS — не функциональный язык (и почему это важно понимать)

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

Отправим стукачей в ГУЛАГ

Человек не может объективно оценивать период, в который он был молод, ностальгия неизменно измажет всё яркими красками.

Pretext — библиотека, которая считает текстовую вёрстку в 500 раз быстрее браузера. Зачем это нужно и как работает

Странно конечно, что canvas всё равно выигрывает. Возможно потому, что там не "честные" глифы рисуют.

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

Pretext — библиотека, которая считает текстовую вёрстку в 500 раз быстрее браузера. Зачем это нужно и как работает

А если держать на странице отдельный iframe с минимумом верстки, и измерять текст внутри него - это тоже будет долгий layout рефлоу?

Pretext — библиотека, которая считает текстовую вёрстку в 500 раз быстрее браузера. Зачем это нужно и как работает

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

TypeScript врёт — а вы об этом не знаете. Валидация ответов сервера

По разному бывает. На моей прошлой работе, например, схему (в дополнение к ТЗ) составляли аналитики, натурально записывая файлы вручную.

Утечки памяти в замыканиях JavaScript

Видимо у всех замыканий внутри функции общее окружение

Так я об этом и написал )

Утечки памяти в замыканиях JavaScript

Ну не совсем всё, arr не попал в копилку. А вот дальше разбираться не стали. Но возможно (хотя и нельзя сказать наверняка), что оптимизирующий компилятор v8 более аккуратно отследит все ссылки и таки выкинет data на мороз, тут не знаю.

Хотя конкретно в этом примере компилятор может не знать дальнейшую судьбу функции, переданной в arr.find, но эффект воспроизводится даже в таком случае, где всё очевидно:

function make(arr, data) {
    const cb = () => data;

    return () => {}
}

TypeScript врёт — а вы об этом не знаете. Валидация ответов сервера

Поддерживать TS-типы как источник правды намного проще (они все равно нужны в приложении), чем описывать схемы в Zod-стиле.

Но схемы умеют делать дополнительные проверки, например по регексу.

А вообще, имхо, источником правды должен быть сваггер/openApi, из которого на фронте генерятся типы и (при необходимости) валидаторы.

O(log n) или O(n)? Разбор алгоритмов поиска для собеседований и практики

Уже где-то писал, что в бинарном поиске (который "обычный") среднее количество итераций будет почти как как максимальное, log(n). То есть lowerBound и upperBound требуют в среднем в два раза меньше сравнений, поэтому обычный поиск лучше сделать через один из них, а не писать отдельно.

Утечки памяти в замыканиях JavaScript

В v8 (и наверно не только) всё ещё интереснее:

function make(arr, data) {
    console.log(arr.find((item) => item === data));

    return () => {}
}

const func = make([], {x: 1});

console.dir(func); // разворачиваем, смотрим [[Scopes]]

В замыкание попала data. Это потому, что все упоминаемые во внутренних функциях объекты садятся в одну "лодку", на которую все эти внутренние функции будут ссылаться. И неважно, что (item) => item === data в мусорке, общий объект продолжает жить - на него ссылается func

Интересный способ сгруппировать натуральный ряд

А, понял. Да, согласен, решение рабочее. Можно ли его обобщить на N групп (по которым распределяются числа k, 2k, ..., N*k)?

Мой вариант для 6 групп: определяем в числе степени множителей 2, 3 и 5, пусть это будут a, b, c. Тогда число попадает в группу (a + 3b + 5c) % 6. Для N групп надо рассматривать степени всех простых множителей меньше N, но не совсем понятно, как подобрать коэффициенты для суммы..

Интересный способ сгруппировать натуральный ряд

И тогда остается вопрос, что делать с числами, делящимеся на 7

Да, этот момент всё портит) Пока не уверен, что здесь можно пофиксить.

Моё решение немного другое

Интересный способ сгруппировать натуральный ряд

Вопрос: при каком максимальном d существует решение при такой постановке?

Любопытный апгрейд. Разбивку 2n чисел можно сделать, если d равен наибольшему нечетному простому числу, которое меньше чем n. Тогда каждому четному можно подобрать пару в виде нечетного. Причем если вышло так, что d = n-1, то больше точно нельзя (тривиально доказывается). Но вот всегда ли это максимум, не совсем понятно...

Интересный способ сгруппировать натуральный ряд

Разбиение ряда на группы - прикольная тема. Я вот что вспомнил: как разбить весь натуральный ряд (все целые больше 0) на 6 групп, так чтобы для любого k, числа k, 2k, 3k, 4k, 5k и 6k попадали в разные группы. Там тоже простое изящное решение в духе статьи.

В Китае бум компаний, в которых работает всего один человек — за всё остальное отвечают ИИ‑агенты

Интересный пример one-person компании - Photopea, веб-аналог фотошопа. Чел за несколько лет без всякого ИИ запилил весь код в одно лицо, неплохо поднимает на рекламе и платных подписках