0 просмотренных постов скрыто
А что, если семья в игре сможет жить без игрока? Делаю симулятор домашнего уклада
Представьте обычное утро.
На кухне осталась посуда. Ребёнку через сорок минут в школу. Один взрослый не выспался, второй уже опаздывает на работу. Еда в холодильнике есть, но завтрак никто не приготовил.
И тут персонаж решает не мыть тарелки.
Не потому, что сломался ИИ. Не потому, что игрок забыл поставить команду в очередь. А потому, что он устал, вчера уже убирался, считает распределение обязанностей несправедливым и обещал ребёнку помочь с уроками.
Я попробовал сделать игру, в которой подобное поведение — не ошибка, а основа симуляции.
Рабочее название проекта — «Домашний уклад».
Не кукольный дом, а живая система
Обычно в симуляторе жизни игрок выбирает персонажа и говорит ему:
Проснуться
→ сходить в туалет
→ приготовить завтрак
→ поесть
→ помыть посуду
→ пойти на работу
То есть персонаж остаётся куклой, а игрок становится его внешней волей.
Мне хотелось сделать наоборот.
Члены семьи должны сами:
замечать собственные потребности;
оценивать обстановку;
помнить об обязанностях;
учитывать отношения;
выбирать доступное действие;
жить с последствиями своего выбора.
Игрок не управляет человеком напрямую. Он управляет условиями его жизни.
Можно купить посудомоечную машину, изменить распорядок, перераспределить обязанности, выделить личное время или решить, что сейчас семье важнее деньги, а не идеальная чистота.
Но нельзя просто схватить Павла невидимой рукой и заставить мыть тарелки.
Павел — субъект. Пусть пока очень примитивный, но уже обладающий собственной логикой.
Минимально достаточный человек
Игра не пытается честно смоделировать человеческое сознание. Для этого не хватит ни компьютера, ни моей жизни.
Вместо этого используется минимальная модель субъектности.
У каждого персонажа есть несколько внутренних состояний:
энергия;
голод;
стресс;
близость;
автономия;
здоровье.
А также более устойчивые черты:
ответственность;
общительность;
любовь к порядку;
потребность в независимости.
При выборе действия персонаж примерно оценивает:
Насколько мне это сейчас нужно?
+ Привык ли я это делать?
+ Обещал ли я это сделать?
+ Поможет ли это близкому человеку?
+ Считаю ли я это своей обязанностью?
− Сколько потребуется сил?
− Насколько мне это неприятно?
− Что я не успею сделать вместо этого?
После этого он выбирает действие самостоятельно.
Это не настоящий разум. Но если причинно-следственная связь достаточно понятна, игрок начинает видеть не набор коэффициентов, а характер.
Не кукольный дом, а живая система
Игрок управляет не людьми, а укладом
В этой игре игрок — не один из родителей и не всемогущий бог.
Скорее, он представляет собой волю домашнего хозяйства.
Его инструменты:
планировка квартиры;
покупка предметов;
семейный бюджет;
распорядок дня;
общие приоритеты;
распределение ответственности;
крупные жизненные решения.
Например, нельзя приказать:
«Мира, немедленно приготовь ужин».
Но можно договориться, что готовка — её ответственность.
И даже после этого Мира может отказаться. Если она истощена, перегружена или считает договорённость несправедливой, формальное назначение не превращает её в робота.
Тогда игроку придётся менять систему:
передать готовку Павлу;
снизить другие обязанности Миры;
купить готовую еду;
приобрести бытовую технику;
пожертвовать частью дохода ради свободного времени;
временно согласиться на менее чистый дом.
Здесь нет идеального решения. Есть только разные последствия.
Дом одновременно является миром и интерфейсом
Графически игра вдохновлена компактными менеджмент-стратегиями с изображением здания в разрезе.
Весь дом виден сразу:
Спальня | Гостиная
Ванная | Кухня
Рабочая зона | Детская
Каждая комната — не просто декорация, а функциональный блок системы.
Кухня преобразует продукты, время и энергию в готовую еду. Спальня преобразует время и покой в восстановление. Рабочее место превращает силы человека в деньги и стресс. Гостиная может создавать близость — или конфликт.
Игрок смотрит на дом как на живую кибернетическую схему.
Люди в ней не фишки. Они сами перемещаются между помещениями и используют доступные возможности.
Игрок управляет не людьми, а укладом
Главный ресурс семьи — не деньги
Деньги важны, но настоящий дефицит — время и внимание.
У каждого человека только один день.
Если Павел берёт дополнительные смены:
Доход растёт
→ Павел сильнее устаёт
→ меньше участвует в быту
→ нагрузка переходит на Миру
→ у Миры исчезает личное время
→ растёт раздражение
→ ухудшается атмосфера дома
→ Лена получает меньше спокойного внимания
Дополнительная работа была рациональным решением. Семье действительно нужны деньги.
Но локально правильное решение может сделать всю систему менее устойчивой.
Именно это меня интересует больше всего: момент, когда простые и понятные действия образуют сложные последствия, которых никто не планировал.
Даже еда — это цепочка
Персонаж не должен терять деньги в тот момент, когда ест домашний ужин. Деньги были потрачены раньше.
Полная цепочка выглядит так:
Работа
→ деньги
Деньги + время
→ покупка продуктов
Продукты + время + энергия
→ готовые порции + грязная посуда
Готовая порция
→ снижение голода
Грязная посуда + время + энергия
→ чистота
Если никто не купил продукты, готовить не из чего.
Если продукты есть, но никто не приготовил еду, ребёнок всё равно останется голодным.
Если еда приготовлена, но вся кухня завалена посудой, бытовая нагрузка никуда не исчезает — она просто перенесена в будущее.
Так из нескольких простых преобразований появляется домашняя экономика.
Главный ресурс семьи — не деньги
Что такое семейный климат
Кроме индивидуальных состояний, у дома есть общий эмоциональный климат.
Это не ресурс, который можно потратить, как деньги. Скорее, это температура семейной среды.
На неё влияют:
средний стресс;
близость;
совместное время;
неравномерность бытовой нагрузки;
накопившиеся конфликты;
забота;
выполненные и нарушенные обещания.
Климат меняется медленно.
Одна ссора не уничтожает семью мгновенно. Но если напряжение сохраняется, оно начинает воздействовать на всех:
Стресс людей
→ ухудшение климата
→ дома труднее отдыхать
→ стресс растёт ещё сильнее
Получается опасная петля обратной связи.
Но возможен и обратный процесс:
Помощь
→ снижение нагрузки
→ меньше раздражения
→ больше возможностей для общения
→ восстановление близости
→ улучшение климата
Игра заключается не в том, чтобы один раз заполнить шкалу счастья. Игрок должен заметить, в какой контур попала семья, и изменить условия раньше, чем система начнёт воспроизводить собственный кризис.
Что такое семейный климат
Семья как единый организм
В какой-то момент субъектом становится не только отдельный человек.
Вся семья начинает вести себя как организм:
Семейная система — Похожая функция
Доход — Получение энергии
Еда — Поддержание жизнедеятельности
Домашний труд — Обслуживание организма
Забота — Восстановление и развитие
Распорядок — Внутренний ритм
Семейный климат — Общее психическое состояние
Накопления — Запас устойчивости
При этом внешне благополучная семья может быть внутренне хрупкой.
Дом чист. Деньги есть. Ребёнок накормлен.
Но всё держится на одном человеке, который работает, готовит, убирает и заботится об остальных.
Система выглядит эффективной — до первой болезни.
Что считается победой?
Я не хочу делать единственную шкалу «идеальной семьи».
Потому что тогда игра очень быстро сообщит, что существует один правильный образ жизни.
Вместо этого семья постепенно формирует собственные ценности:
близость;
безопасность;
свобода;
порядок;
образование;
карьера;
взаимопомощь;
личное пространство.
Нельзя максимизировать всё.
Семья, постоянно проводящая время вместе, может подавлять автономию. Карьерный успех может уничтожить свободное время. Идеальный порядок может держаться на хроническом истощении одного человека.
Вопрос игры не в том, насколько семья совершенна.
Вопрос в другом:
Какой она стала — и какой ценой?
Что считается победой?
Что уже есть в прототипе
Сейчас собран браузерный MVP:
PHP;
JavaScript;
MySQL;
запуск на обычном хостинге;
автономная симуляция в браузере;
автоматические сохранения;
комнаты, действия и предметы, описанные в базе данных;
самостоятельный выбор действий персонажами;
приоритеты и распределение обязанностей;
бытовые ресурсы;
нагрузка;
семейный климат;
хроника событий.
Большую часть новых действий можно добавлять без переписывания движка.
Например, объект «посудомоечная машина» не просто повышает абстрактное счастье. Он изменяет конкретные процессы:
меньше времени на уборку
→ ниже бытовая нагрузка
→ больше времени на отдых
→ меньше стресс
→ выше вероятность общения
То есть предмет становится не бонусом, а вмешательством в систему обратных связей.
Самый важный тест
У проекта есть простой критерий качества:
Если игрок ничего не делает, устойчивая семья должна продолжать жить самостоятельно.
Игрок нужен не для того, чтобы отправлять каждого персонажа в туалет. Он нужен в моменты, когда меняется сама жизнь:
родился ребёнок;
кто-то заболел;
изменилась работа;
закончились деньги;
приехал пожилой родственник;
семья переехала;
старый распорядок перестал работать.
Прежнее равновесие разрушается, и приходится создавать новое.
Именно это я хочу симулировать: не идеальную семью, не бытовую рутину и не кукольный домик, а живую систему автономных людей, вынужденных делить пространство, время, труд и заботу.
Самый важный тест
Пока это только MVP, но сама модель уже начала выдавать маленькие истории, которых никто заранее не писал.
И теперь мне интересно:
Хотели бы вы играть в симулятор, где персонажи могут отказаться выполнять ваши планы?
Что должно сильнее всего влиять на атмосферу семьи?
Нужны ли прямые приказы хотя бы в экстренных ситуациях?
Какие жизненные события стоило бы добавить первыми?
Где проходит граница между интересной автономией и раздражающим поведением ИИ?
Потому что создать послушную куклу относительно просто.
Гораздо интереснее создать кого-то, с кем придётся договариваться.
Показать полностью
7
Доработка приложения
Приветствую! Есть работающее приложение на Laravel. ERP система для контроля и управления производственными процессами. Сейчас успешно работает на 2-х предприятиях. Для дальнейшего продвижения нужно провести
- аудит и код-ревью текущей кодовой базы (Laravel),
- выявление узких мест, - доработка и развитие фронтенда,
- подготовка к масштабированию для большого количества предприятий.
Нужен специалист отлично знающий PHP, JavaScript, HTML, CSS, Laravel. Если есть интерес, пишите в личку, все подробно расскажу и покажу.
Интернет-магазин или всё таки розничная сеть? Какой тип бизнеса выбрать? Или пункты ПВЗ?
Имею действующий универсальный интернет-магазин товаров: радиоэлектроника, хозтовары, одежда, обувь, хобби, сувениры, подарки, некоторые товары для бизнеса и прочее. Есть постоянный ассортимент, который приносит прибыль. Есть действующий сайт, работает с 2015 года, есть постоянные клиенты. Сайт работает на старом движке (CMS), дизайн уже сильно устарел, но клиенты и заказы есть, в том числе и новые. Авторизация и оформление заказов сильно упрощены.
Есть постоянные товары, которые я лично закупаю, а есть товары, которые я покупаю у оптовых компаний, если есть заказы на них, также могу просто перепродавать товары из других розничных магазинов с небольшой наценкой, вы будете смеяться, но это работает)) Например, мы выставляем товары из соседних розничных магазинов на сайте с наценкой 10-30% и пишем В наличии, человек покупает, оплачивает, мы идём в этот магаз, покупаем его и отправляем человеку)) Например, в магазине товар 10000 рублей, мы продаём за 13000 рублей.
Основные заказы идут с сайта, сайт находят через Ютуб, ТГ, ТикТок, Медиа и Авито. Также на своём сайте добавил загрузку видео товаров, что повлияло на заказы.
Оборот около 1 млн рублей, до пандемии оборот был больше 2-4 млн рублей. Чистыми около половины. Заработанные деньги обычно сразу вкладываю на закупку ходового товара. Раньше со мной работало пару человек, кому я платил ЗП, сейчас остался я и ещё мой помощник, работаем вдвоём по сути.
На данный момент я работаю только через интернет, то есть отправляю товары по России и СНГ через Озон Доставку, Почту, Яндекс и другие ТК. Также есть заказы самовывозом в моём городе со склада.
Сейчас я раздумываю и ближе к зиме хочу обновлять сайт, отсюда много мыслей.
Мой помощник говорит, чтобы я не трогал сайт, пока он работает, пусть работает...
Куда двигаться в будущем?
Оставаться как интернет-магазин с одной постоянной точкой самовывоза и отправки товаров или всё таки разрабатывать сайт, чтобы была возможность вести учёт товаров в разных местах, например (основной склад 100 шт, розничный магазин на Ленина 20 шт, розничный магазин на Романова 1 шт) и чтобы люди на сайте могли оформлять заказы с разных мест? Если выбирать второй вариант это сильно усложнит логику сайта, но наверное будет легче работать... Я хочу улучшить учёт товаров и добавить адресное хранение и прочее.
И самое главное, вопросы к процессу оформления заказов на сайте, как людям показывать наличие товаров? При заходе на сайт форсировать их и заставлять выбирать город, далее в карточках товаров отображать наличие конкретно этого города или просто на странице товара вываливать наличие всех локаций? Но тогда это может пугать потенциальных клиентов, например человек из Москвы ищет какую-то запчасть, заходит в карточку товара и видит: основной склад Екб 984 шт, розничный магазин Екб 23 шт, мне кажется это его спугнёт (он подумает, ааа магаз в Екб, а я в Москве и уйдёт)? 🤔 Или предлагать выбирать локацию в корзине при оформлении заказа?
Есть ещё один вариант, оставить всё примерно как есть, оформление на сайте будет намного проще, наличие только основного склада, но в будущем двигаться в сторону работы как Озон, самовывоз со своего ПВЗ (всё едет с главного склада)...
Но честно, почему-то мне кажется, если открывать розничные магазины, это принесёт больше прибыли и быстрее, но и проблем в плане разработки тоже будет много...
И технический вопрос к прогерам и DEVам,
Какую СУБД выбрать для обновленного сайта: MSSQL, MySQL или PostgreSQL... Я склоняюсь к последней... Я хочу сделать связку Ubuntu 24 + PHP + PostgreSQL... Нынешний сайт работает на SQL Server Express 🤦🏻♂️ Количество товаров SKU на данный момент 30К, но знаю что их будет намного больше...
Что ещё можете посоветовать?
Извините за кашу... Просто брейншторминг... 😁
Показать полностью
Я 15 лет в IT, и меня достало делать «кнопочки». Пошёл на hh.ru, пересчитал все вакансии и выбрал бэкенд. Спойлер: PHP ещё жив
Сергей, Ульяновск. В IT с середины 2000-х: jQuery, ExtJS, Backbone, ранний Angular. Сейчас React и TypeScript. Коммерческий фронтенд — три года. До этого — всё подряд.
Полгода назад упёрся.
Не в деньги — в развитие. Делаешь сложные формочки. Микрофронтенды. Стейт-машины на XState. А хочется понимать систему целиком. Почему API тормозит. Как данные идут в базу. Что там, под капотом.
Fullstack. Но какой бэкенд?
На YouTube — ролики «ТОП-5 ЯЗЫКОВ, ПОКА НЕ ПОЗДНО». Парень с укладкой, Hello World три месяца назад. Я пошёл на hh.ru и начал считать сам.
Вот что вышло.
---
## Как я считал
Два источника.
**hh.ru.** Только совпадения в названиях вакансий. Без поиска по описанию — там слишком много шума. Пятнадцать запросов: Python, Java, Go, PHP, Node.js, C# — плюс их комбинации с fullstack и React. Фильтр: вся РФ, зарплата любая.
**Хабр Карьера.** 43 716 анкет, июль 2026. Медианы, а не средние — чтобы пара зарплат из Яндекса не перекосила картину.
Даты: 14–20 июля 2026. Всё руками. Без скриптов.
Что нельзя гарантировать:
Поиск по заголовкам режет абсолютные цифры. Вакансия «Senior разработчик» без языка в названии — мимо выборки. Но пропорции держиЎ смещение одно и то для всех языков.
Это срез недели. Не годовой тренд.
Закрытый рынок (внутрянка, рекомендации) не виден. Совсем.
Регионы: Москва и Ульяновск — разные галактики. Мои цифры — среднее по стране, а не по столице.
И всё же. Для карьерного решения точности достаточно.
---
## Общий рынок: Python — 519. Но это ловушка
Беру все бэкенд-вакансии. Без фильтрации. Грубая масса:
> 📊 **[ВСТАВИТЬ КАРТИНКУ: horiz_bar.png]**
- Python — 519
- Java — 468
- C#/.NET — 227
- PHP — 207
- Go — 141
- Node.js — 62
- TypeScript (бэкенд) — 53
- Ruby — 15
Python вдвое опережает C#. Картинка ясная?
Нет.
Я открыл эти 519 вакансий. Добрая половина — Data Science. Нейросети. ML. Автоматизация. Python-разработчик в банке может не писать API вообще — он обучает скоринговые модели. К fullstack это имеет слабое отношение.
Сырые цифры врут. Красиво врут — но врут. Нужна другая выборка.
Теперь Node.js и TypeScript. Если считать их одним (TypeScript-бэкенд — NestJS или Next.js, технически Node.js), вместе — 115. Третье место, сразу за Python и Java. По-моему, так честнее. Но в таблицах ниже я их разделяю — для прозрачности.
Go — 141. Много для 15-летнего.
PHP — 207. Язык, который «умер» в 2012. В 2015. В 2018. В 2020. 207 вакансий. Никак не добьют.
Ruby — 15.
---
## Fullstack-срез: PHP на первом месте. Я перепроверил трижды
Дальше — фильтрую. Только вакансии, где в заголовке или первом абзаце чётко: «фронтенд + бэкенд». Пришлось вручную просмотреть около 200 штук. Некоторые заголовки врут: написано «Fullstack Developer», внутри — чистый бэкенд.
> 📊 **[ВСТАВИТЬ КАРТИНКУ: fullstack_bar.png]**
- PHP — 30
- Python — 29
- Java — 28
- C#/.NET — 21
- Node.js — 15
- TypeScript — 10
- Go — 2
- Ruby — 1
PHP.
На первом месте.
Я не поверил. Пересчитал. Ещё раз. Цифра честная.
Только вот интерпретация. PHP вырвался не потому, что это лучший язык для веба — а потому что Laravel-экосистема исторически fullstack. Фреймворк даёт бэкенд и Blade-шаблоны из коробки. В вакансиях на Laravel ищут одного человека: база, API, фронт — всё он. Это артефакт экосистемы. Не сигнал «беги учить PHP».
Node.js + TypeScript — 25. Второе место. Я ждал меньше. Думал, fullstack занят PHP и Java, а Node.js где-то в нише. Ошибся.
Go — две вакансии на всю страну.
Две.
Не случайность. Go проектировали для микросервисов, не для fullstack. Искать fullstack на Go — как спорткар с кузовом универсал. Можно, но зачем.
### Несколько цифр без прикрас
- Fullstack-вакансий в выборке: 330
- Удалёнка: 190 (58%)
- Senior: 61, Middle: 24
- hh.индекс: 8,3 — конкуренция
- Динамика: вакансий +8%, резюме −2%
61 senior, 24 middle. В 2,5 раза.
Fullstack — не входная точка в IT. Сначала стань кем-то одним. Потом расширяйся. Рынок ждёт опытных, а middle-позиции подбирает по остаточному принципу.
---
## React + бэкенд: график, ради которого я это затеял
Главный вопрос. Какие бэкенды реально ищут в паре с React? Не «упомянут где-то в глубине требований» — прямо в заголовке или первом абзаце:
> 📊 **[ВСТАВИТЬ КАРТИНКУ: react_combos.png]**
- React + Node.js — 16
- React + PHP — 9
- React + Python — 8
- React + Java — 6
- React + .NET — 5
- React + Go — 1
16 против 9. Node.js отрывается почти вдвое.
И вот что интересно. На общем рынке Node.js — скромный середняк: 62 вакансии. В fullstack-нише — третье-четвёртое место. А в связке с React — уверенное первое.
Не самый массовый бэкенд вообще. Но для React-фронтендера — самый частый выбор нанимателя.
Почему? Четыре причины, которые, по-моему, не случаются сами собой:
**Один язык.** TypeScript на клиенте и на сервере. Типы кочуют туда-сюда без переписывания. DTO описал один раз — работает везде.
**Next.js размывает границу.** API routes, Server Components, Server Actions. Разработчик на Next.js пишет бэкенд, часто не замечая.
**NestJS — когда Next.js маловато.** Модульная архитектура, DI, guards, interceptors. Enterprise-уровень на знакомом TypeScript.
**Общий тулинг.** Zod для валидации, date-fns для дат, shared-библиотеки в монорепе. Никакого дублирования.
React + PHP (9 штук) — обычно Laravel на бэке, React как админка или SPA. Работает. Особенно в e-commerce.
React + Go (1 штука).
Одна.
Кто-нибудь вообще видел такую вакансию вживую? Отпишитесь, мне правда интересно, что за проект.
---
## Деньги: где самый толстый скачок
Хабр Карьера, 43 716 анкет. Медианы.
> 📊 **[ВСТАВИТЬ КАРТИНКУ: salaries.png]**
- Intern — 66 000 ₽
- Junior — 95 000 ₽
- Middle — 177 000 ₽
- Senior — 303 000 ₽
- Lead — 378 000 ₽
Ступеньки: Junior → Middle — плюс 82 тысячи. Middle → Senior — плюс 126 тысяч. Senior → Lead — плюс 75 тысяч.
Самый крутой подъём — между middle и senior. Рынок платит за глубину. Fullstack-middle, который «всё понемногу», стоит сильно дешевле fullstack-senior, который глубоко знает оба направления.
Что за кадром:
Разброс внутри грейдов — пропасть. Senior fullstack в региональной веб-студии и senior fullstack в финтехе живут в разных финансовых измерениях.
Хабр Карьера смещена вверх. Те, кто получает мало, реже заполняют анкеты.
Зарплаты по языкам — за регистрацией. Я не знаю, получает ли PHP-senior столько же, сколько Node.js-senior. Подозреваю, что нет. Доказательств у меня нет.
---
## Удалёнка: 190 из 330
190 fullstack-вакансий из 330 — удалённые.
Я в Ульяновске. Ближайшие офисы крупных IT — Казань, Самара. С удалёнкой это не проблема: работаешь на Москву или Питер из квартиры с видом на Волгу.
Деталь: большинство удалённых fullstack-позиций — аутсорсинг и стартапы. Enterprise осторожничает. Банки. Телеком. Им всё ещё нужен офис. Хотите Java в банке — готовьтесь к гибриду как минимум.
---
## Что я выбрал
Node.js + NestJS + TypeScript.
Не «потому что модно». Пять вещей, которые перевесили:
**Язык один.** Пишу на TypeScript больше пяти лет. Декоратор `@controller()` в NestJS — продолжение того, что знаю. Не прыжок в другую вселенную.
**16 против 1.** React + Node.js — 16 вакансий, React + Go — одна. Работодатель, которому нужен fullstack на React, ждёт Node.js. Мне не надо его переубеждать.
**Потолок далеко.** Простой CRUD на NestJS — за вечер. Дальше — CQRS, event-driven, микросервисы на Kafka/NATS. Есть куда расти.
**Next.js как трамплин.** Server Actions и API Routes — это бэкенд, просто в рамках одного фреймворка. Переход к NestJS — структурирование тех же концепций.
**Одна кодовая база.** Типы, валидация, утилиты живут в одном месте. Без дублирования.
Что через год-два? Не знаю. Может, вторым языком возьму Python + FastAPI — мост в AI/ML-проекты. Может, останусь в Node.js и пойду в ширину: базы данных, инфраструктура, девопс.
Посмотрим.
---
## Если примерять к себе
Ты React/TypeScript-фронтендер? **Node.js, NestJS.** Язык знаешь, рынок подтверждает, вход плавный.
Ты в Data Science / ML? **Python, FastAPI.** Строить веб вокруг ML-моделей — редкая комбинация. Только учти: вакансий меньше, чем в чистом вебе.
Ты в enterprise или планируешь? **Java / C#.** Стабильно. Дорого. Порог входа высокий, экосистема тяжёлая.
Любишь highload и инфраструктуру? **Go.** Fullstack-позиций почти нет. Но как чистый бэкенд — мощно.
Нужна работа прямо сейчас? **PHP, Laravel.** 30 fullstack-вакансий — больше всех. Только готовься к культурной адаптации после TypeScript.
---
Четыре вещи, которые остались после подсчётов.
Node.js — не самый большой рынок. Но для React-фронтендера — точка входа с наименьшим сопротивлением. 16 против 1. Не погрешность.
Fullstack — не старт. 61 senior-вакансия, 24 middle. Сначала глубина. Потом ширина.
Один язык на клиенте и сервере — не «удобно». Это скорость. Меньше ошибок, общий тулинг, никаких «забыл обновить типы после смены API».
Цифры — не догма. Срез июля 2026. Через полгода пересчитаю — и не поручусь, что картина не изменится.
Пишите в комментариях, какой бэкенд выбрали вы. И главное — почему. Реальный опыт интереснее любых цифр.
А если кто-то видел fullstack на Go вживую — маякните. Мне правда интересно.
---
*Данные: hh.ru и Хабр Карьера, 14–20 июля 2026, РФ. Поиск по заголовкам — абсолютные цифры занижены, пропорции репрезентативны. Детальные зарплаты по языкам — за регистрацией, не включены. Региональные перекосы возможны.*
Показать полностью