Hello world!

На днях я прочитал статью о WebTransport API как будущей альтернативе или даже замене WebSockets. Мне стало интересно, что это такое и с чем его едят. Давайте разбираться вместе.

Казалось бы, простая задача - сверстать список пар ключ-значение. Бери <div> и делай. Но что, если захотелось подушнить? Этим и займёмся в статье...
Рассмотрим три подхода к решению этой задачи: <div>, <dl>, <dt>, и <dd>, и <table>. Обсудим преимущества, недостатки и примеры.
Цель - помочь выбрать наиболее подходящий подход для конкретной задачи.

Каждый из нас, хотя бы раз, слышал о сборке мусора. Мы знаем, что где-то там работает сборщик мусора, убирая за нами ненужные объекты и массивы. Но сколько из нас знают, как он устроен под капотом?

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

Погнали собирать мусор!

Продолжение перевода статьи «Reimagine Atomic CSS» двухлетней давности одного из членов команды Vue core Anthony Fu, автора UnoCSS, в которой рассматривается уже сам UnoCSS.

На Хабре не раз и не два обсуждались эргономичные клавиатуры разных видов. В частности — сплит‑клавиатуры, которые представляют собой две половинки целой клавиатуры, соединённые между собой либо проводами, либо беспроводным каналом связи. Я расскажу о собственном пути к сплитам, который занял много лет.

"Как жить без стрелок" или не так страшен сплит...

Источник

Введение

В последнее время на Хабре появляется всё больше статей о кастомных клавиатурах вообще и об эргономичных сплит клавиатурах (эргосплит) в частности. И это хорошо, ведь, глядя на ассортимент клавиатур в магазинах электроники, можно подумать, что альтернативы стандартным клавиатурам нет, а это далеко не так. Однако…
Не так давно вышла статья Эргономичная раздельная клавиатура. Iris. И знаете, какой комментарий набрал наибольшее количество голосов?

Что вы там этими клавиатурами набираете? Как жить без стрелок, PgUp/PgDn и прочего? А для почти всех IDE нужны F-клавиши.
Переключаться между десятком режимов, забивая ими голову, и скроллить через HJKL?
Каждый раз, когда вижу такие изделия, впечатление что это для того, чтобы было "как в кино у хакеров".
Эргономика должна быть не только для пальцев, но и для мозга.

Неужели с эргосплитами всё так плохо?

В прошлом месяце исполнилось 13 лет с момента появления "красного щита" Angular. AngularJS стал отправной точкой для новой волны JavaScript-фреймворков, появившихся для поддержки растущей потребности в богатом веб-опыте. Сегодня с новым внешним видом и набором перспективных функций мы ведем всех в будущее с версией 17, устанавливая новые стандарты производительности и удобства для разработчиков.

В большинстве браузеров уже есть те или иные механизмы блокировки third-party кук. В одних браузерах это ограничивается тем, что third-party куки разрешено отправлять только на посещенные пользователем сайты. В других браузерах внедряют различные "enhanced" и "intellegent" tracking protection, либо совсем блокируют third-paty куки. Для тех, кто захочет разобраться детально в перипетиях отдельных браузеров, есть прекрасные статьи.

В 2019 году волей сообщества дефолтное поведение кук в браузерах изменилось с SameSite=None на SameSite=Lax. Что, впрочем, привело лишь к тому, что большинство сервисов перевело свои трекеры в режим SameSite=None.

Консенсус в сообществе свелся к тому, что:
- Нужно запретить отслеживать пользователя между сайтами
- First-party - это вполне ОК. Сайт внутри себя может позволить себе любые манипуляции с пользовательскими данными
- Third-party - в целом тоже ОК, но только если ограничить third-party куки одним сайтом (следите за руками ниже)

Так какие же есть решения для того, чтобы отказаться от third-party кук и ничего не сломать?

Я хочу посвятить эту статью известной задаче в математике, относящейся к теории вероятности. Так же мы попытаемся решить эту задачу на JavaScript. Я сразу приступлю к условию задачи.

Все мы знакомы с широко используемыми HTML тегами, такими как <div>, <p>, <a>, и <img>. Однако, существуют HTML - теги, которые могут упростить жизнь, и вместо написания дополнительного кода, выполнят всю работу :)

Всем привет! Сегодня я хочу поделиться приемами улучшения производительности фронтенда путем оптимизации RxJS стримов.

В этих двух статьях я буду сравнивать TailwindCSS с чистым CSS + BEM. Цель - разобраться что является лучшим решением для хорошей архитектуры приложения. Это не вопрос предпочтений, от этого выбора будет зависеть очень многое на поздних этапах разработки и оно должно быть очень хорошо обосновано. Начну со сравнения производительности. Tailwind позволяет значительно уменьшить размер итогового CSS и тем самым ускорить время отображения страницы. Но это сработает только в том случае, если Tailwind классы будут написаны прямо в HTML коде, а не в виде @apply в CSS. Tailwind уменьшает CSS, но увеличивает HTML. Давайте посчитаем разницу с учетом HTML. Будем сравнивать чистый Tailwind с чистым CSS + BEM.

Прошу простить заранее за несколько кликбейтный заголовок )

Не так давно писал в соцсетях хейт‑пост по поводу «алгоритмических секций» при приёме на работу в Яндекс.

Да и многие другие софтверные компании это практикуют и считают навыки написания алгоритмов — чуть ли не самым важным навыком для программистов.

И ставят данной компетенции очень высокий приоритет при приёме на работу.

Попробую сегодня развить эту мысль и объяснить почему ставить навыки написания алгоритмов на первый план — не правильно, почему этот «алгоритмический» критерий не релевантен и не отражает реальной ценности / уровня / потенциальной пользы от данного программиста.

Статья рассматривает возможные задачи верстки на разных проектах и как с ними справляются две разные архитектуры: Tailwind CSS и ванильный CSS + BEM.

Это ответ на статью, что алгоритмические собеседования не нужны. Простите за кликбейтный заголовок, но он такой и в статье, на которую я отвечаю.

Сразу скажу, что моя статья относится лишь к условному ФААНГу. Многие аргументы из этой статьи теряют значимость в других случаях: если у вас маленькая фирма, мало кандидатов или у вас всего 10 пользователей.

Я утверждаю, что алгоритмические интервью - лучший вариант для ФААНГа из всех пока придуманных.

Привет👋 В последние годы среди фронтенд разработчиков Typescript используется практически везде по умолчанию, начиная небольшими пет-проектами и заканчивая огромнейшими веб-приложениями. Однако, до сих пор на некоторых проектах можно встретить кучу any и Function. Давайте разберемся используете ли вы этот невероятно мощный инструмент правильно?

Разрабатывая на TypeScript, можно столкнуться с ситуациями, в которых код будет работать не так, как ожидается. В статье разберем несколько таких моментов. Часть просто придется иметь ввиду, часть решается обновлением, а часть исправляется – обо всем по порядку.

Если вам будет удобно сразу же проверять каждый пример, читая статью, можно это делать в редакторе. Он удобен тем, что версию TypeScript в нем можно переключать.

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