Два фронтенда, один C#-мозг — что действительно различается, что похоже сильнее, чем принято считать, и что говорит рынок труда.

До 2019 года моим фронтендом были семантический HTML и CSS. Div'ы, классы, разметка, которую я мог удержать в голове. Я был бэкенд-разработчиком, и меня это вполне устраивало.

Потом случились две вещи. Компания попросила меня залезть в проект на Vue, а Microsoft выпустила Blazor. В следующие годы я плотно поработал с обоими: с Vue — у двух работодателей, с Blazor — на личном проекте, который до сих пор работает.

Это не статья с бенчмарками. Это про то, как эти две технологии ощущаются, когда мышление у тебя C#-овое.

Как я оказался в Vue

В 2019 году я пришёл в Dolphin Software бэкенд-разработчиком. Вскоре меня спросили, смогу ли я внести небольшие правки во фронтенд-проект. Он был написан некоторое время назад удалённым разработчиком из Индии — и написан на Vue.

Проект был простой, правки лёгкие. Я мог отказаться. Вместо этого мне стало любопытно.

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

Через год я перешёл в одно из агентств Министерства здравоохранения — как раз в коронавирусный период. Большая организация означает музей технологий: старые страницы на ASP.NET, много ASP.NET MVC, команды на Angular, команды на React. Vue был основной фронтенд-технологией, когда я пришёл, а примерно через два года новые проекты начали писать на React, тогда как старые остались там, где были.

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

Мы использовали Vue 2 с Vuetify, это примерно Vue плюс компоненты в духе Material Design.

Как я оказался в Blazor

Blazor появился вместе с .NET Core 3.1, и я сразу пошёл в серверную модель, потому что она была простой.

Что сразу бросилось в глаза — насколько он похож на Razor Pages. Razor я писал. Синтаксис был знакомым, модель мышления знакомой, а документация Microsoft оказалась достаточно хорошей, чтобы находить нужное, не перелопачивая форумы.

Из любопытства я попробовал WebAssembly и отказался от него. Сборка шла долго, первая загрузка шла долго. Если это неудобно мне во время разработки, то посетителю сайта будет хуже.

Так что VideoFloppy, мой пет-проект, — это Blazor Server. Он остаётся единственным проектом на Blazor, который я довёл до конца, и именно довёл, а не забросил, — для меня это важное различие.

Сходства, о которых не говорят

Большинство сравнений подаёт эти две технологии как противоположности. С бэкендерского кресла общего у них больше.

Обе компонентные. Ты собираешь небольшие куски со своей разметкой, состоянием и поведением и составляешь из них целое. Файл выглядит иначе; мышление — нет.

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

Ни одна не навязывает функциональное программирование. Вот это я бы подчеркнул для других бэкендеров. Vue с Options API и Blazor с обычными C#-классами позволяют писать в том стиле, в котором ты уже думаешь. Тебе не обязано перестраивать голову под хуки и функциональное управление состоянием, прежде чем отрисовать таблицу.

И инструментарий подходит обоим. Если API — отдельный проект, NSwag Studio возьмёт ссылку на Swagger и сгенерирует клиент: TypeScript для стороны Vue, C# для стороны Blazor, из одной и той же спецификации. Сгенерированный клиент внедряется через DI, и ты вызываешь его методы как у любого другого сервиса. Понадобится переопределить метод запроса, чтобы добавлять токен авторизации в заголовок, и при желании — обработку ошибок, если нужно реагировать на конкретные коды. Штука действительно расширяемая, и она означает, что форма общения фронтенда с бэкендом между этими двумя меняется слабо.

Именно поэтому обе оказались доступными — и почему для человека из C# расстояние между ними меньше, чем расстояние от любой из них до React.

В чём выигрывает Blazor

Это C#. Тот же язык, что и на бэкенде, та же IDE, тот же отладчик. Visual Studio — отличная и быстрая среда, и мне не приходилось из неё выходить.

Но настоящее преимущество тоньше, чем «никакого JavaScript», и тут я хочу быть точным: JavaScript я всё равно использую. В VideoFloppy стоит Alertify для алертов и промптов — сообщения об успехе, об ошибке, диалог с запросом ключа альбома. Blazor не устраняет JavaScript. Он снижает частоту, с которой тот нужен.

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

В чём выигрывает Vue

Vue лёгкий. Он быстро собирается и быстро запускается, а это складывается в реально сэкономленное за рабочий день время. Blazor Server, напротив, держит соединение с сервером для каждого пользователя, а Blazor WebAssembly заставляет человека ждать, прежде чем что-то появится.

На тулинг Vue жалуются больше, чем он того заслуживает. Да, есть npm, есть бандлеры, есть папка node_modules пугающего размера. Честно? Мне это не мешало. npm или yarn — разницы я не почувствовал. Это просто другой конфигурационный файл вместо appsettings.json, а не другая философия.

И TypeScript заслуживает отдельного слова. После C# статическая типизация на фронтенде ощущается так, будто наконец открыли окно.

Трение

Проблема, которую я помню лучше всего, специфична для Blazor Server, и о ней стоит знать заранее: твой код выполняется на сервере, поэтому запросы из Blazor-слоя к твоему же API приходят с IP хостинга, а не пользователя. Очевидно, когда сказано вслух; не очевидно в час ночи. Я решил это так: забирал клиентский IP на уровне Blazor и передавал дальше в зашифрованном виде.

Такова форма проблем Blazor Server вообще. Не «это сложно», а «это ломается способом, который тебе и в голову не придёт, потому что рендеринг происходит не там, где ты подсознательно считаешь».

Сама отладка была нормальной в обоих случаях. Эти проекты я делал до бума ИИ, без модели, у которой можно спросить, и ни одна из технологий не заставила меня мучиться.

Экосистема JavaScript укусила меня один раз, хотя и не через Vue: в VideoFloppy изначально стоял виджет донатов PayPal, он сломался, и я перешёл на криптоплатежи. Сторонние виджеты — риск на любом фронтенде и на любом языке.

Что говорит рынок труда

Вот часть, которую сложно писать человеку, которому Blazor нравится.

Вакансий на Blazor я видел примерно ноль. Не мало. Я не припомню ни одной.

Vue регулярно встречается в Восточной Европе — особенно в Польше, и, кажется, в некоторых странах Балтии. В Великобритании и США фронтенд-рынок — это подавляюще React и Angular, и в Грузии то же самое. Здесь хватает и чисто бэкендовых, и фулстек-позиций, но фулстек хотят на React или Angular.

И дальше парадокс: вакансии на ASP.NET MVC и Razor Pages по-прежнему есть, потому что легаси-системам нужны люди для поддержки. У более старой технологии спрос выше, чем у более новой, построенной на тех же идеях.

Что бы я выбрал

Для личного проекта или внутреннего инструмента в компании, которая и так живёт на .NET, где команда бэкенд-тяжёлая и никто не хочет тащить отдельный фронтенд-стек, — Blazor Server, без колебаний. Он правда приятный, и для C#-разработчика порог входа почти нулевой.

Для всего, над чем будут работать другие люди, или где я однажды захочу кого-то нанять, или где важно время первой загрузки, — Vue.

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

Blazor многому меня научил. Vue приносил мне собеседования.

Это перевод моей статьи, впервые опубликованной на Medium.

А вы видели вакансии на Blazor? Мне правда интересно оказаться неправым в этой части — и заодно узнать, на чём пишут фронтенд в ваших .NET-командах. ?