JavaScript *

Примечание переводчика. Оригинальная статья была опубликована в 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 файла, то редактору тяжело их различить и он может не успевать анализировать информацию пока пишется код, а это пропущенные ошибки, и тяжелая проверка кода на глаз. Да, можно каким-то образом это настроить, но зачем с этим связываться, если есть доступные решения, которые легко с этим справляются. Чтобы устранить вышеупомянутую проблему с микросервисами приходится после каждого переключения между проектами перезагружать редактор.

Когда мы решили вывести на прод Telegram‑мини‑приложение для «капельных» (drip) TON‑платежей, довольно быстро стало ясно: обычный CRUD‑фронт тут не выживет. Сразу накрыла волна специфичных задач — от гранулярного онбординга в Web‑App до борьбы с ограничениями API‑ключей и тонкостей работы с TON SDK во встроенном браузере Telegram. Каждый шаг требовал не только кода, но и аккуратного выбора архитектурных приёмов, иначе продукту грозили дубли запросов, «белые экраны» и несогласованность состояний.

В этой статье я разобрал пятнадцать самых характерных «боевых» сложностей, показал, каким паттерном мы их укрощали, и какой антипаттерн поджидал за поворотом. Это не академический список, а выжимка из коммитов и ночных дебаг‑сессий, которая поможет тем, кто строит похожие интеграции между Telegram, TON и React.

С приходом ИИ сильно вырос соблазн заниматься простым человеческим вайб-кодингом: пишешь себе промпты, копируешь готовый код, вставляешь в проект - и готово! И бизнес рад, и времени меньше уходит… В чем подвох? Пожалуй, в том, что таким образом все меньше полезной информации оседает в голове.
В этой статье я хочу поделиться своим методом, с помощью которого я внедряю новые фичи в проект, над которым работаю, при этом получая новые знания и опыт (как в старые добрые времена), затрачивая гораздо меньше времени.

Ранее на Piccalilli Сэм Роуз поделился реальными примерами использования вспомогательных типов (utility types) TypeScript. Сегодня я хочу продолжить эту тему и поделиться несколькими продвинутыми возможностями TypeScript для работы с типами, которые, на мой взгляд, особенно полезны и применимы в реальных проектах.

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

Если вы когда-нибудь, запуская рабочую станцию с операционной системой Windows, обнаруживали, что ваш Full HD монитор показывает лишь изображение с разрешением не более 1024x768 и определяется как «Стандартный не Plug-n-Play монитор», и по какой-то причине вы не имеете возможности переключить монитор на другой видеовход, не поленитесь заглянуть под кат, где я растолкую, как «временно» выкрутиться минимальными усилиями.

Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.

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

Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.

В этой статье я хочу поделиться своим взглядом на то, как каждый из принципов SOLID может быть применен в разработке React-приложений. Здесь не будет революционных идей, особенно для опытных разработчиков, но, возможно, эта информация окажется полезной для начинающих разработчиков, стремящихся писать более качественный и поддерживаемый код.