Несколько месяцев назад я написал статью — «Observable — удобный state‑manager», что было скорее заметкой, и за что мне здорово досталось в комментариях! Уважаемым комментаторам — спасибо, я постарался учесть все замечания.
Сегодня представляю вам kr‑observable 2.0 — библиотеку для реактивного программирования на JavaScript. И удобный state-manager тоже.
Что такое TypeScript? Официальная документация отвечает так: “TypeScript — это JavaScript с синтаксисом типов”. Однако некоторые считают TypeScript своеобразным слиянием двух языков: языка для манипулирования значениями JavaScript и языка для манипулирования типами.
Cистема типов TypeScript Тьюринг-полная. Это означает, говоря по-простому, что система может решить любую вычислительную задачу при наличии некоторого представления входных и выходных данных.
Можно ли использовать это знание на практике? Как избежать крайностей от примитивного аннотирования типов до избыточного усложнения?
Эта статья для разработчиков, которые уже используют TypeScript, но хотят выйти за рамки базовых практик. Мы не будем обсуждать синтаксис или настройку конфигураций. Вместо этого сосредоточимся на стратегиях, которые помогут:
Грандиозная история вокруг микро open-source проекта который неожиданно выстрелил и вытащил меня из ямы
Недавно мне попался следующий твит от OneHappyFellow:
Кажется, я понял, что меня настолько напрягает при программировании на языках с динамической типизацией. Дело в том, что никогда нет уверенности, будет ли конкретная библиотека работать определённым образом, и не сломается ли код при очередном минорном обновлении версии.
— One Happy Fellow (@onehappyfellow) 5 мая 2025
Этот тезис меня заинтересовал. Дело в том, что по работе мне в основном приходится иметь дело с Clojure. Это динамический язык, но его экосистема на редкость известна своей стабильностью. В этой статье мы подробно разберём, почему именно так сложилось, но для начала я приведу некоторые доказательства, подкрепляющие мою точку зрения.
Асинхронность в JavaScript, где и как использовать в web разработке на frontend и backend. Цепочка промисов и их параллельные выполнение.
Примечание переводчика. Оригинальная статья была опубликована в 2012 году. Соответственно, актуальность статьи и практическая применимость для современной разработки ставится некоторыми разработчиками под сомнение. В то же время, если, по какой-то причине, вам необходимо ознакомиться с MVC и MVP, данная статья может быть полезна.
Прежде чем изучать какие-либо JavaScript-фреймворки, помогающие в структурировании приложений, может быть полезно получить базовое представление об архитектурных шаблонах проектирования. Шаблоны проектирования являются проверенными решениями распространенных проблем разработки и могут предложить структурные парадигмы, которые помогут нам организовать наше приложение.
Я думаю, паттерны очень интересны, поскольку они фактически представляют собой массовые усилия, опирающиеся на коллективный опыт опытных разработчиков, которые ранее сталкивались с теми же проблемами, с которыми сталкиваемся мы сейчас. Хотя разработчики 10 или 20 лет назад, возможно, не использовали те же языки программирования для реализации паттернов, мы можем извлечь из их усилий много уроков.
В этом разделе мы рассмотрим два популярных шаблона – MVC и MVP. Контекст нашего исследования будет заключаться в том, как эти шаблоны связаны с популярным фреймворком JavaScript Backbone.js, который будет рассмотрен более детально позже.
Решил написать простенькую статейку по следам реализации небольшой программки на С++ под Виндоус, которая содержит в себе TCP сервер. Мы получаем от клиента http запрос. Соединение не защищенное.
На чем реализован клиент нам неизвестно: может на php (curl,socket,stream_contex_create,...), может на js (ajax), вообще может быть на чем угодно.
Надо задача реализовать http парсинг запроса и контента, выполнить задание (на каком-то подключенном к серверу оборудовании) и ответить клиенту о результате.
Примечание: автор реализует http сервер на устаревшем Qt4, используем QTcpServer. Но для http сервера это не принципиально.
Во время обдумывания чем можно было бы завершить цикл «Новый взгляд на старые игры» в памяти всплыл специфический, технический текст, перевод которого некогда застрял на стадии полировки терминологии. Сегодня вашему вниманию предлагается, насколько то дозволила сложившаяся специфика, доработанная версия.
Об оригинальной игре я ранее рассказывал в рамках материала из другого цикла, здесь же речь пойдёт именно о ремейке и, преимущественно, его front‑end специфике.
Перевод выкладывается с разрешения Scott‑а Schiller‑а. Характер статьи изобилует заметками / элементами монолога автора с самим собой. При переводе было решено оставить заданную подачу как есть, без радикальной стилистической коррекции или смены формата.
Осуществлял дополнительный анализ JavaScript‑терминологии — oldalexi. Выступал в качестве дополнительного редактора — Newbillius.
Однажды я мучился в попытках победить бесконечные ререндеры, причиной которых, как я считал, были ивенты в приложении, и тогда мне в голову пришла гениальная мысль сделать свой обработчик ивентов, который удовлетворял бы моим потребностям и решал еще парочку архитектурных проблем, тогда на свет появился этот код...
По данным сразу нескольких вышедших в 2025 году отчётов исследователей, объём генерируемого ботами трафика в интернете впервые превысил человеческий. Боты теперь составляют более половины интернета, из них 3/4 — вредоносные.
В этой статье я хочу поделиться своим опытом настройки WSL для комфортной разработки, а также размышлениями о том, почему такой подход оказался для меня оптимальным. На это влияет несколько факторов.
Во-первых, иногда требуется специфический софт, который доступен только под Windows. Да, в других ОС могут быть аналоги, но зачастую они менее удобны или требуют дополнительной настройки.
Во-вторых, для разных проектов нужно разное окружение. WSL позволяет легко изолировать среды разработки, настраивая их под конкретные задачи или группы проектов. Это гораздо удобнее, чем держать несколько физических машин или постоянно переустанавливать систему.
Наконец, есть и субъективный фактор — привычка. Я с самого начала работал с Windows, и, несмотря на все преимущества Linux, полностью перестроить рабочий процесс оказалось сложно. WSL в этом плане — идеальный компромисс: Linux-окружение под рукой, но без необходимости отказываться от удобств Windows.
Привет, Хабр! Меня зовут Евгений, я работаю разработчиком в Университете Кембриджа (UK). В начале апреля я запустил llm7.io - полностью бесплатный LLM-провайдер, совместимый с популярными библиотеками chat completion. Цель была простая: проверить, насколько эффективно можно построить отказоустойчивую архитектуру под настоящую high-load-нагрузку, и при этом дать всем желающим доступ к мощным языковым моделям - без регистрации, API-токенов, смс и прочих барьеров.
Всем привет!
Cypress — это современный инструмент для автоматизации тестирования веб-приложений на базе JavaScript. С помощью него можно создавать unit, e2e и интеграционные тесты.
В статье вы узнаете:
Преимущества инструмента и когда его можно использовать;
Как установить, настроить Cypress и написать с помощью него первый тест;
О хуках, кастомных командах, создании запросов, заглушках и другом...
7–8 апреля прошла самая крупная в РФ IT‑конференция, просвещённая JavaScript development и всему с ней связанному.
Итак, HolyJS — пожалуй самая крупная «семья» во всем сообществе javascript‑разработчиков, продуктивности и дружелюбности которой можно бесконечно поражаться и восхищаться! Ребята собирают под своим крылом лучших экспертов‑спикеров со всей России...
В статье — о том, как мы решили отказаться от PropTypes в пользу TypeScript для автоматического извлечения типов пропсов React-компонентов.
Наши разработчики давно просили эту возможность, справедливо возмущаясь: «Зачем описывать типы дважды — в TypeScript и PropTypes?». Тем более, что аналогичный механизм уже работал в Storybook.
Если вы недовольны текущими решениями для организации библиотек компонентов или просто любите технические кейсы — добро пожаловать под кат!
Я начал этот небольшой проект под названием isomorphic-validation, как эксперимент, в основном в образовательных целях. Несмотря на то, что существует множество других библиотек валидации, я решил все равно изобрести велосипед. Это была попытка скрыть все сложности, связанные с условными операторами и асинхронностью при создании пользовательского интерфейса...
Всем привет, меня зовут Александр, я являюсь фронтенд разработчиком более 4-х лет. В этой статье хочу поделится с вами почему решил перейти с горячо любимого и удобного и комфортного vscode в новый редактор neovim. Что из этого получилось давайте посмотрим дальше.
Что такое neovim и причины перехода на него
Думаю, что все сталкивались с этими текстовыми редакторами, когда решали мердж конфликты или рибейзили ветки в своих проектах. Да, это были редакторы nano или vim. Так вот, редактор neovim — это форк от редактора vim с улучшенными доработками. Если кого-то интересует более подробное описание — вы можете найти его на сайте самого редактора neovim.
Причины перехода на neovim?
В данный момент я использую в качестве основного редактора VsCode для работы во frontend разработке и редактор заточен чисто под нее. Работе с ним я столкнулся со следующими проблемами: долго грузит обновление маппингов между переключениями в ветках гитхаба, когда что-то меняешь в файле юай компонента, то также долго обновляется информация об изменении в файле; если это длится целый день — то тратится много времени в пустую на ожидаение. Еще одной проблемой стала — это работа с микросервисами: при наличии в проекте более одного typescript файла, то редактору тяжело их различить и он может не успевать анализировать информацию пока пишется код, а это пропущенные ошибки, и тяжелая проверка кода на глаз. Да, можно каким-то образом это настроить, но зачем с этим связываться, если есть доступные решения, которые легко с этим справляются. Чтобы устранить вышеупомянутую проблему с микросервисами приходится после каждого переключения между проектами перезагружать редактор.
