Команда JavaScript for Devs подготовила перевод статьи Адди Османи к 17-летию Google Chrome. За эти годы браузер прошёл путь от «минималистичного проекта с комиксом» до полноценной платформы для приложений с ИИ. Скорость, безопасность, стабильность и простота остаются его основными принципами, а впереди — новая эра с локальными AI-API и встроенным ассистентом Gemini.
Без сомнений, JavaScript — крайне популярный язык программирования. И разработчики постоянно создают обновления, которые позволяют писать код проще, короче и понятнее. Одним из таких инструментов стала деструктуризация — способ получения данных
Привет, Хабр! Меня зовут Александр Дудукало, я автор базового курса по JavaScript. В этом тексте на примерах разберемся, как работает синтаксис и как деструктуризировать массив. Подробности под катом!
Как и многие начинающие разработчики, я давно мечтал сделать свой первый pet-проект — чтобы почувствовать себя «настоящим программистом» и перестать бояться собеседований. В итоге решился: буду писать веб-приложение для личных заметок.
На самом деле я не совсем новичок. Раньше у меня уже были попытки освоить разные языки программирования, но дальше пары строчек кода дело редко заходило. Умение «гуглить правильно» и искать ответы на StackOverflow пока давалось тяжело, поэтому довести что-то до результата было сложно.
В этот раз я решил пойти по трендам и подключить в процесс AI. Спасибо Хабру, что в нужный момент подкинул статью про Koda. С неё и начался мой эксперимент. А команде Koda хочу выразить респект за то, что всё бесплатно.
Наконец, настал этот момент, и я решился написать статью. Давно хотел, но как-то не хватало мотивации. А ведь, знаете, как говорят: «гнев — лучший мотиватор». Есть же такое выражение?
Предыстория
Я приглашаю вас в путешествие, но сначала нужно расставить декорации. Представьте, что вы работаете в некой компании X, и один из ваших сервисов на Next.js крякнулся. Ну и поскольку это Next.js, то мы понятия не имеем, что конкретно произошло, так как логирование процессов по умолчанию включено только при разработке.
И теперь перед нами квест — найти и настроить механизм логирования для продакшена. Будет нелегко, но нам как бы не привыкать.
По мере роста фронтенд-приложений управление пользовательскими взаимодействиями становится все более важным. Добавление обработчика событий на каждый интерактивный элемент — плохая практика: это усложняет код, увеличивает расход памяти и снижает производительность. Здесь на помощь приходит делегирование событий (event delegation).
Каждая интерактивная веб-страница опирается на Document Object Model (DOM) и ее систему событий. Когда мы нажимаем кнопку, вводим текст в поле или наводим курсор на изображение, возникает событие. Но оно не происходит само по себе — событие проходит по дереву DOM в процессе, который называется распространением события (event propagation).
Продолжение статьи о safe-fetch — библиотеке без try/catch для HTTP.
Через день после первой публикации произошла эволюция: stable релиз 1.0 + экспериментальный адаптер для React Query.
Рассказываю, как фидбек сообщества превратил простую обертку в экосистему с монорепо.
Показать данные красиво и понятно бывает сложнее, чем написать саму бизнес-логику. Нужно не просто вывести цифры, а сделать так, чтобы ими было удобно пользоваться: масштабировать, сравнивать, фильтровать. Можно ли совместить мощь, интерактивность и гибкость в одной библиотеке визуализации — и при этом без боли интегрировать ее в React? Спойлер: да, и это ECharts.
Привет, Хабр! Меня зовут Ольга Китова, я разработчик в IBS. Эта статья — про ECharts, один из самых сильных и гибких инструментов для визуализации данных. Я покажу, какие возможности дает эта библиотека, как она устроена «под капотом», в чем ее плюсы и минусы и как использовать ECharts в React-приложениях, на практике.
Telegram Music Hub (TMH) — это open-source решение, которое превращает ваш Telegram-канал в единое цифровое пространство для музыки, блога и сообщества.
И всё это — на самом обычном виртуальном хостинге, без баз данных, без сложных зависимостей, без дорогих серверов.
Всем привет! На связи Сергей, ведущий фронтенд-разработчик в команде привлечения Центрального университета. Расскажу историю, как валидировал ссылку и попал впросак. Я использовал браузерный URL API для своих целей и думал, что знаю, как он работает. И прежде чем кидать в меня помидоры, как в разработчика, который не читает документацию, дайте шанс рассказать свою историю.
Плохой URL путает пользователей, хороший — работает как швейцарский нож. Разбираем анатомию, правила построения иерархичных путей, мощь Query-параметров и истинное назначение Hash. Практика на JavaScript и чеклист готовых решений.
С ростом сложности фронтенда разработчики начали уделять больше внимания архитектуре. Кто-то предпочитает «чистую», кто-то — её производные, например, FSD. В той или иной степени этот вопрос волнует многих. В данной статье я предлагаю присмотреться повнимательнее к аспекту, который часто остаётся в тени при обсуждении архитектуры, — к маршрутизации.
Давайте вспомним как мы строим роутинг в наших приложениях. В примере ниже – react-router-dom, но в других фреймворках/библиотеках все примерно также:
Когда команда разработчиков начинает активно расти, неизбежно возникают вопросы консистентности кода. Разные стили написания, различные подходы к форматированию и отсутствие единых стандартов могут серьезно замедлить разработку и усложнить поддержку проекта.
В данной статье мы рассмотрим пошаговую настройку ESLint и Prettier на примере нашего веб-приложения, построенного на Next.js и TypeScript.
Ситуация: пишешь код на JS, хочешь обработать исключение, пробрасываешь throw, ловишь его с помощью try‑catch. Но добавим нюанс: пусть это нужно сделать для setTimeout. Эта функция использует окружения браузера — не JS‑функция, асинхронная.
Загвоздка: catch не сможет поймать ошибку.
Этот пример — одна из нескольких особенностей JS, из‑за которых я считаю обработку исключений «из коробки» на этом языке неудобной. Но есть и хорошие новости — для JS существуют альтернативные способы работы с исключениями, с которыми дела обстоят получше; например, паттерн «контейнерный тип».
Давайте разбираться.
5 месяцев назад я публиковал материал про пет-проект календаря домаших тренировок. Сегодня хочу рассказать, что было сделано мной за прошедшее с тех пор время.
Самим приложением пользуюсь регулярно. На главной странице для незарегистрированных пользователей в качестве примера как раз показывается моя статистика. Помимо меня есть ещё 53 зарегистрированных пользователя с подтверждённым email.
https://github.com/dergunovs/fit - исходный код приложения
https://vkvideo.ru/playlist/15313879_11 - видео про разработку
Frontend: Typescript, Vite, Vue, Tanstack Query, Vitest, Vue I18n, Tauri
Backend: Typescript, Fastify, Mongoose, MongoDB, Swagger
Публикация приложения в RuStore
С помощью Tauri добавил генерацию формата APK. Зарегистрировался в RuStore в качестве разработчика, заполнил поля с описанием, сделал скриншоты. Модерация прошла очень быстро. Теперь приложение можно удобно скачивать и обновлять. Сам APK файл весит около 10 мегабайт. За 4 месяца с момента публикации в RuStore оттуда было 65 установок приложения.
Каждый фронтендер знает эту боль: пишешь запрос через fetch - и автоматически добавляешь try/catch. Где-то ловишь TypeError, где-то 500-й статус, где-то подвисший запрос с AbortController. В итоге половина кода в проекте - это обработка ошибок, а не бизнес-логика.
Я прожил с этим годами. Чем больше становился проект, тем больше росла копипаста: таймауты, ретраи, проверки на res.ok, костыли для разных браузеров. Одно и то же, снова и снова.
И вот в какой-то момент я понял: проблема не в том, что ошибки случаются. Проблема в том, что сам fetch вынуждает нас ловить их вручную, каждый раз, в каждом запросе.
Так появилась библиотека @asouei/safe-fetch. Маленькая (3kb), без зависимостей, но с тем, чего нет у самого fetch: общий таймаут, умные ретраи, нормализов��нные ошибки и поддержка Retry-After.
🌟 Библиотека добавлена в Awesome TypeScript — один из крупнейших мировых списков лучших TypeScript-проектов
Всем привет! Я являюсь создателем распределённого поисковика rats-search на базе DHT ( GitHub ). Его принцип работы довольно прост: поисковик собирает торренты у всех участников сети и формирует большую распределённую базу для поиска, включая метаданные (например, описания и прочую информацию).
В этой статье я хочу рассказать о своей новой библиотеке для построения распределённых приложений (p2p), где знание IP-адресов участников не обязательно, а поиск ведётся через различные протоколы — DHT, mDNS, peer-exchange и другие. Думаю, с учётом постоянных неприятностей, которые происходят вокруг, это может оказаться полезным ;-).
В этой статье, Я рассказываю, как сделал приложение для сопоставления резюме с вакансиями, используя tRPC, TypeScript и Google Vertex AI. Проект принимает PDF-резюме и описания вакансий, извлекает из них текст, применяет базовое NLP для выявления навыков, а затем обращается к Gemini 1.5 Flash для более глубокого анализа. По ходу статьи я объясняю, почему tRPC показался мне быстрее и чище, чем REST или GraphQL для MVP, показываю примеры кода из репозитория и обсуждаю как преимущества, так и ограничения такого подхода.
Недавно я провёл небольшой эксперимент: проверил, как разные модели от OpenAI справляются с одной и той же задачей — создать красивую симуляцию «жидкостей в стакане» с помощью HTML5 Canvas и JavaScript.
На словах всё звучит просто, но на деле это проверка и кода, и физики, и UX.
Результаты получились очень показател��ные, а кое-где даже удивительные. Делюсь наблюдениями и видео 👇
Рассуждаю о проблеме регулярного создания файлов и о том, как поддержать архитектуру и автоматизировать рутину.
Написал утилиту на Go для генерации структур файлов по шаблонам, которая, думаю, будет полезна многим.
Записки одного QA. Вспомогательная часть автотестов: советы и практики (Playwright + Typescript)
В статье рассматриваются подходы к организации вспомогательной части для автотестов на Playwright: структура проекта, Page Object, helpers, constants и шаги. Приведены практические примеры того, какие решения помогают поддерживать автотесты читаемыми и масштабируемыми, а каких стоит избегать. Материал будет полезен QA-инженерам и разработчикам, начинающим работать с Playwright.
