Блокчейн разработка меняется со скоростью света. Решив вникнуть, купил несколько лет назад книгу, но к сегодняшнему дню она уже безнадежно устарела. Инструменты описанные в ней web3.js, Truffle, Ganache, заброшены, подходы и стандарты изменились.
В праздники, дописал и залил в сеть web3 демо-магазин на solidity/ethers.js. Поделюсь ньансами разработки и современными инструментами.
Бывало такое: смотрите вы на красивую страницу интернет-магазина, открываете консоль разработчика (ту самую, по F12 или через правый клик), а там — лес из тегов, который вообще не похож на то, что вы видите глазами?
Привет, Хабр! Меня зовут Александр Дудукало, я автор курса по JavaScript. В этой статье мы продолжаем знакомиться с элементами страницы, а именно с DOM. Эти знания вам точно понадобятся в работе с любым проектом. Давайте же больше узнаем, что это за дерево и как с ним работать. Поехали.
В 2026 году обновят JavaScript. Окончательный список изменений сформируется из проектов ECMAScript, достигших 4 этапа к марту. Но многие из них уже на заключительной стадии, а другие готовы и доступны в некоторых браузерах и средах. Под катом — что ждёт разработчиков и какие проблемы будут решены в этом апдейте.
В первой части мы разобрали эволюцию архитектуры React Native. Теперь перейдем к практическим вопросам: как организован процесс разработки и какие платформенные особенности встретятся в работе.
Процесс разработки
Выбор между классическим подходом и Expo – одно из первых архитектурных решений в проекте. Разберем оба варианта.
Bare React Native
Процесс требует настройки окружения (Xcode для iOS, Android Studio для Android). В упрощенном виде процесс запуска приложения для разработки выглядит следующим образом:
В данной статье я расскажу, с какими проблемами, связанными с бинарником, столкнулось моё решение при запуске на Arch Linux у моих знакомых, и почему у меня оно работает нормально на Debian 12 и 13. Также я разберу преимущества и недостатки текущей реализации, покажу возможные пути решения и альтернативы, а лучшее решение применю на практике.
Я снова попрошу Сергея и Ивана запустить моё приложение на Arch Linux, чтобы проверить его работу.
Заваривайте чай, доставайте вкусняшки — пора «удобрять почву для выращивания помидоров»! 🍅
Всем привет!
Долго я возился с маркдауном в своих проектах и, честно говоря, знатно подгорел. Первая проблема — это вечный выбор библиотеки.
С одной стороны, есть «конструкторы» типа unified, remark и rehype. Штуки мощные, но настраивать весь этот AST-конвейер и систему плагинов — это какой-то оверхед и лишняя сложность, имхо.
С другой стороны, есть @next/mdx, который вроде и ок, но слишком завязан на страницах и вообще не умеет работать на клиенте.
Раньше я обычно выбирал что-то вроде markdown-to-jsx или react-markdown.
DX у них приятнее, работают и на клиенте, и на сервере, весят мало.
Но вот беда: они «из коробки» не переваривают HTML или MDX, и ты снова вязнешь в настройке плагинов. А если добавить туда i18n (типа i18next или next-intl), начинается настоящий ад. Куча if/else в коде, чтобы отрендерить нужный язык, и бандл раздувается до небес. Плюс вечные косяки с front-matter. Ну и до недавнего времени всё это было только для React.
В общем, решил я написать свое решение для intlayer. Чтобы просто работало.
> К слову, за основу я взял форк markdown-to-jsx v7.7.14 (от quantizor), который базируется на simple-markdown v0.2.2 (от Khan Academy).
Когда пилил этот парсер, ставил перед собой такие цели:
- Максимально легкий вес
- Кросс-фреймворковость (React, Vue, Svelte, Angular, Solid, Preact)
- Простая настройка: никаких бесконечных цепочек плагинов
- Поддержка SSR и клиентского рендеринга
- Настройка на уровне провайдера: можно легко прокинуть свои компоненты из дизайн-системы
- Компонентный подход: полный контроль над рендерингом каждой части приложения
Привет! Это второй выпуск Frontend Status — дайджеста по фронтенд-разработке. В выпуске — два десятка материалов: от коротких демо до гайдов и спецификаций.
В подборке — то, чем живёт фронт прямо сейчас: свежий CSS, AI-инструменты (генеративный UI, офлайн-поиск по сайтам, Figma → React), записи (Remotion, ИИ и верстка), апдейты браузеров и платформ (geolocation, Grid Lanes, WebNN, угрозы и учётные данные). Плюс React и Angular, WASM-язык COI, Temporal API и обход блокировок Cursor/Claude через OpenCode.
Всем привет.
В этой статье мы продолжим дорабатывать базовые инструменты для работы с инвестициями и начнем изучать индикаторы.
React Native прошел путь от решения с фундаментальными архитектурными ограничениями до платформы с современным, производительным ядром. В этой статье мы разберем, как работала старая архитектура на основе Bridge, как ее заменили JSI, Fabric и Hermes, и в каких случаях React Native - оптимальный выбор для проекта.
Старая архитектура с Bridge
В основе этой архитектуры лежат асинхронный Bridge. Нативный код и JavaScript работали в отдельных потоках. Общение между ними происходило через Bridge, который передавал сообщения в формате JSON.
В изолированной корпоративной сети с полумиллионом файлов стандартный поиск превращается в рутину. Облачные сервисы недоступны, серверные решения избыточны, а встроенные инструменты ОС не справляются с объёмами и разнородностью клиентов (Windows и Linux).
Мы столкнулись с этой задачей и вместо развёртывания сложной инфраструктуры пошли другим путём: упаковали весь поисковик в один HTML-файл. Фоновая индексация на Python раз в сутки — и сотрудники получают мгновенный поиск по путям прямо в браузере.
В статье разбираем архитектуру решения: как относительные пути решают проблему разных точек монтирования, почему плоский JS-массив оказался эффективнее сложных структур, и как уместить индекс 560+ тысяч файлов в 120 МБ без потери скорости.
Не полнотекстовый поиск, а инструмент для навигации по глубокой файловой структуре, где важная информация закодирована в путях. Работает там, где нельзя поставить Elasticsearch, но нужно быстро находить документы.
В JavaScript есть уникальная особенность, переменную или функцию можно использовать по коду выше, её объявление...
Недостаток знаний часто подталкивает людей к чрезмерно сложным решениям, и рано или поздно это отражается на производительности.
Возьмем content-visibility: auto. Он дает тот же эффект, что и React-Window, но без единой строчки JS и без увеличения размера сборки. Аналогичная ситуация с современными единицами высоты окна (dvh, svh, lvh): наконец-то приведена в порядок "мобильная" высота, которую годами пытались компенсировать через window.innerHeight.
Обе технологии в 2024 году получили более 90% поддержки современных браузеров и полностью готовы для продакшна. Однако мы по привычке продолжаем решать такие задачи с помощью JS, просто потому, что CSS незаметно ушел вперед, пока мы спорили о React Server Components.
Мне кажется, я знаю, как должен быть устроен идеальный электродвигатель, но чтобы это доказать, нужен инструмент. Существующий софт убивал все желание: медленно, дорого или неудобно.
За зимние каникулы мы с Gemini (да, почти весь код написал ИИ) создали свой солвер на WebGPU. Весь софт - это один HTML-файл. Он работает в браузере, считает сетки до 16К в реальном времени и умеет то, чего нет у аналогов.
2026 год на дворе. Нейросети уже пишут музыку, рисуют картины, сочиняют сценарии и даже спорят с вами в комментариях.
А вы всё ещё вручную переписываете for на list comprehension? Пора признать: кодинг тоже изменился. Теперь ваш главный навык – не только знать синтаксис, но и уметь чётко и ясно объяснять задачу тому самому ИИ-напарнику, который уже ждёт в соседней вкладке.
Но как объяснить, чтобы не получилось «ну ты понял»? Как заставить модель генерировать идиоматичный, чистый и работающий код с первого раза? Ответ – в промптах, продуманных, отточенных и готовых к использованию шаблонах.
Мы собрали для вас 10 таких промптов – от перевода кода между языками до рефакторинга и документирования. Ваш ChatGPT теперь станет в разы полезнее.
Погнали разбираться!
В первой части цикла мы разобрались, зачем вообще нужен Capacitor и почему он стал адекватным выбором для кроссплатформенной разработки.
Теперь переходим к самому болезненному и интересному этапу: миграции уже существующего веб-приложения.
Здравствуйте, снова я — Дмитрий, React-разработчик. Все мы видели с вами такие карты, именуемые картойдами, в данном случае — карта России, я взял первую попавшуюся из интернета, для примера.
Привет, Хабр! (И тебе, случайный читатель, который думает, что "код - это магия", а процессор - маленький гномик, который внутри ноутбука читает for i in range(10) и послушно бегает кругами.)
Сегодня разберёмся с вопросом, который в какой-то момент приходит в голову каждому разработчику, а потом быстро вытесняется дедлайном:
Как вообще компьютер “читает” Python или 1С или любой другой язык программирования, если он понимает только 0 и 1? И почему ваш идеальный код иногда превращается в "segmentation fault" / "Неопределённая ошибка" / “Пользователь не найден (хотя он сидит напротив)”?
Вот и мне спустя годы в разработке пришла идея изучить этот ваш старомодный Computer Science и понять вообще, что такое программа и компьютер на самом деле.
Поехали. Будет без хардкора уровня “компилятор за 21 день”, но с понятными аналогиями, для статьи упростил всё до минимума. Реально постарался переварить информацию и выдать её в красивой упаковке. Кстати, в статье будут примеры из двух разных миров Python и 1С, так что будет интересно…
После Приорбанка я думал, кого взять следующим для небольшого публичного аудита. Недавно минула пора праздников, и что-то мне подсказывает, что многие делали покупки в онлайн-маркетах, чтобы приобрести подарки близким. Этот период — высокий сезон для таких приложений. Они зарабатывают много денег в это время, но и нагрузка на инфраструктуру идёт колоссальная.
Мой личный топ из всех популярных онлайн-маркетов — это Wildberries. Я люблю этот сервис и активно им пользуюсь. Мне кажется, это уже хороший повод посмотреть, насколько он доступен людям с различными ограничениями. Безусловно, это очень популярная платформа в странах СНГ, но это, конечно же, не значит, что она одновременно и доступна на 100%.
Сразу хочу оговориться: я не пытаюсь подчеркнуть какой-то изъян платформы. В конце концов, у каждого продукта свои бизнес-приоритеты, и доступность (если она не обязательна с точки зрения законодательства) — это личное дело каждого бизнеса. К примеру, мой продукт тоже не удовлетворяет всем критериям доступности, да и многие другие, на которых я работал. При том что моя личная аналитика прошлого года показала, что 20% моей пользовательской базы меняют размер шрифта для лучшего восприятия, но не факт, что есть хотя бы один (я бы сказал, его и нет) кто использует продукт, будучи полностью незрячим, со скринридером.
Часто интерес к этой теме больше у юридических фирм. Понимая лазейки в законах, они сами находят «жертву» — компанию, не удовлетворяющую требованиям. Затем находят людей с ограничениями, от имени которых подают многомиллионный иск и зарабатывают себе деньги. При том что сами люди с ограничениями этими продуктами могли вовсе и не пользоваться.
Кратко о том, почему я не использую фреймворки, зачем пишу всё с нуля и к чему это привело.
Я написал полноценный SDK для web-приложений как концепт альтернативной ветви развития, если бы web-индустрия пошла по пути игровых движков.
Как Angular Ivy находит зависимости за O(1)? Глубокое погружение в алгоритм резолва: от генерации уникальных ID токенов до битовой магии Блум-фильтров. Разбираем, почему строковые токены замедляют ваше приложение и как работает наследование кумулятивных масок в LView.
