VueJS *

В прошлой статье я познакомил вас с существованием малоизвестных "суперплатформ" управления данными. На абстрактном примере реализации показал как легко кастомизируется платформа - от идеи, к готовому UI. У кого-то это вызвало отвращение, у кого-то просто шок, а кто-то увидел возможность.

Настало время на деле показать как с помощью современного стека разработки (который возможно уже через пару лет станет опять старым) - дать второе дыхание морально устаревшим системам из прошлого, взяв из них лучшее, а именно философию и надёжные концепции и при этом не страдать от старого, дурно пахнущего legacy.

В общем расскажу про импортозамещение Dassault Systèmes 3DExperience, далее Enovia, а точнее - той её части, которая на протяжении многих лет востребована многими крупными предприятиями: гибкого движка для построения бизнес-приложений, с возможностями управления жизненным циклом (без привязки к тяжелому САПР).

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

В прошлой статье я также упоминал, что у Сергея получилось запустить мой проект на Tauri в режиме разработки на Arch. Он поделился со мной информацией в issue на GitHub и тем самым внёс вклад в проект. Поэтому я решил попробовать исправить проблему на основе его issue. Заодно расскажу, что такое issue и как оно выглядит.

Заваривайте чай, доставайте вкусняшки — пора «снимать первый урожай помидор»! 🍅

Всем привет! Написал сервис для проектирования интерфейсов с возможностью импорта и экспорта Vue шаблонов.

Привет, меня зовут Арина, я фулстек‑разработчик.
Есть задачи, которые годами возвращаются в твою жизнь. Для меня такой задачей стало бронирование столиков.
Давайте посмотрим, как я делала её трижды. Правило трёх попыток: один раз — ошибка, два — опыт, три — паттерн поведения.

В предыдущей статье мы разобрали trackOpBits — механизм оптимизации трекинга зависимостей во Vue 3.
Но тогда мы смотрели на систему через одну конкретную оптимизацию.

Сегодня поднимемся уровнем выше.

Почти всё, что вы делаете во Vue:

Привет, Хабр.

Это моя первая статья здесь. Долгое время не решался что-то публиковать, хотя регулярно читал и разбирал материалы других авторов.

Для первой публикации я выбрал тему внутренней оптимизации реактивности во Vue 3 — trackOpBits и работу ReactiveEffect. Этот механизм почти не заметен при обычной работе с фреймворком, но он напрямую влияет на производительность рендера компонентов и поведение вложенных computed.

В статье разберём, какую проблему решает trackOpBits, как именно он используется внутри системы реактивности и почему эта оптимизация важна в реальных приложениях.

У нас случилась классика: бэкенд уже отдает данные, бизнес ждет экран «вчера», а фронтендера в команде нет и ближайшие фронты заняты.

Мы рискнули и собрали MVP‑интерфейс за неделю — без выделенного фронта, но на корпоративном стеке (Vue/TypeScript) и с дизайн‑системой.

Это не история «AI все сделал». Это история про то, как правила + дизайн‑система + ревью как для джуна могут делать из AI‑ассистента нормальный инструмент, а не генератор мусора.

Что должен делать разработчик, чтобы проект, над которым он работает, не имел проблем? Очевидно — нужно просто исправить все баги и больше не писать новых. 

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

В 2026 году обновят JavaScript. Окончательный список изменений сформируется из проектов ECMAScript, достигших 4 этапа к марту. Но многие из них уже на заключительной стадии, а другие готовы и доступны в некоторых браузерах и средах. Под катом — что ждёт разработчиков и какие проблемы будут решены в этом апдейте.  

Всем привет!

Долго я возился с маркдауном в своих проектах и, честно говоря, знатно подгорел. Первая проблема — это вечный выбор библиотеки.

С одной стороны, есть «конструкторы» типа 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 и клиентского рендеринга

- Настройка на уровне провайдера: можно легко прокинуть свои компоненты из дизайн-системы

- Компонентный подход: полный контроль над рендерингом каждой части приложения

Архитектура сложных форм. WEB-Frontend.
(VueJS, TypeScript, Compositions API, Pinia)

Архитектура форм, в которых:
- сложная бизнес логика
- множество полей
- валидация (frontend + backend)

Уже скоро год, как запущена AI-платформа для хранения и аналитики персональных медицинских данных Lissa Health. Недавно в ней появился отчет «Профиль здоровья», который учитывает любую информацию, которую пользователь предоставил о себе. Чтобы его реализовать, нам пришлось полностью переработать идеологию движка системы.

Мы совершили качественный переход от документо‑центрической к фактор‑центрической модели данных, где атомом информации о здоровье человека является медицинский факт с уникальным кодом и контекстом.

Ниже — техническое описание новой структуры.

Когда у тебя несколько клиентов (web + расширение + десктоп), API быстро развивается, а данных много и они сложные — «контракт» между бэком и фронтом начинает дрейфовать.
Я решил это так:

В данной статье я попытаюсь переписать часть приложения Kawai-Focus на стек: FastAPI + Vue.js + Tauri + Ionic. Также я соберу приложение только с экраном «Таймеры» под Linux в AppImage, которое подойдёт для большинства Linux-дистрибутивов. Реализация одного экрана не будет слишком долгим процессом, а финальная сборка приложения позволит оценить сложность и удобство полного цикла разработки.

Эта cтатья не будет подробным гайдом, так как размер переписанного кода и его описание слишком велики для одной статьи. Однако я покажу часть кода проекта и расскажу о выбранном стеке, а также о трудностях и преимуществах, с которыми я столкнулся в процессе переписывания проекта. Я буду использовать часть кода старого проекта, который не касается Kivy и KivyMD, поэтому его душа не умрёт, а обновится.

Заваривайте чай, доставайте вкусняшки — пора «старый стек превращать в удобрение для новых помидор»! 🍅

Привет, Хабр! Меня зовут Андрей Слесаренко — frontend‑разработчик с опытом работы более 8 лет. Прошёл путь от джуна до тимлида, работал над разными высоко‑нагруженными проектами. В начале этого года начал активно использовать LLM‑агентов в повседневной работе — и за это время набил немало шишек.

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

Как сократить Time-to-Market в 7 раз и научить бэкенд-разработчиков собирать страницы за 15 минут? В этой статье я делюсь опытом внедрения Meta-Driven UI в ERP-системе. Расскажу, как я «душила» легаси с помощью Strangler Fig Pattern, внедрила FSD-архитектуру на Vue 3 и почему Render-функции оказались эффективнее обычных шаблонов.

Тренды в ИТ — это не про красивые слова и не про вечные «угрозы» о том, что нас вот-вот заменит ИИ и пора срочно выбирать другую профессию.

Тренды — это про то, как изменится работа с архитектурой и безопасностью в ближайшие годы, как трансформируются подходы к разработке и само мышление инженеров.тМы попросили экспертов ГК «Юзтех» поделиться своим взглядом на ИТ-тренды 2026 года.

3… 2… 1 — поехали. Ждём горячее обсуждение в комментариях.

Декларативные шаблоны Vue решают 90% задач фронтенда. Но периодически возникают ситуации, где шаблонного синтаксиса оказывается мало. Нужен более тонкий контроль над рендерингом или возможность вынести часть компонента за пределы его естественной позиции в DOM-дереве. Для таких случаев Vue 3 послал нам render-функции и встроенный компонент Teleport.

После интеграции nuxt/i18n в несколько моих проектов я пришел к однозначному выводу: это, безусловно, лучшее i18n-решение для JS-фреймворков.

Его «plug&play» настройка, загрузка пространств имен (namespaces) и встроенная маршрутизация, настоящее удовольствие в работе.

Однако у этого решения есть серьезная проблема: загруженные пространства имен не подвергаются «тришейкингу» (tree-shaking).

Несмотря на то, что JSON-файлы могут загружаться динамически для каждой локали, Nuxt в итоге объединяет их, что означает, что файл locale/zh/about.json загружается на всех страницах.

Привет, Хабр! Меня зовут Карлен, я Lead Fullstack разработчик в ITFB Group. В этой статье хочу поделиться своим мнением о том, как выбрать библиотеку или фреймворк для вашего следующего проекта. 

Этот выбор напоминает мне подбор гардероба для важного мероприятия: ошибешься — и проект ждут дополнительные проблемы, угадаешь — и ты на вершине успеха! Чтобы не попасть в просак с выбором, давайте детально разберем ключевые различия между React и Vue и определим, на что стоит обратить внимание.