Комментарии 25
Смысл писать веб на компилируемом языке? Чем это лучше Laravel Livewire?
Много веб-сервисов пишется на стеке C#/.NET. И компании не то чтобы хотят тратиться на найм фронтендера для всего этого. Для них и будет блейзор.
Так же много сервисов создается для внутреннего использования внутри компаний. И в этом случае блейзор будет вообще отличным вариантом.
А приведенный тобой Laravel тут вообще никаким боком, поскольку php и .NET вообще никак не пересекаются и не конкурируют. Это разные стеки для разных задач.
Почему это не пересекаются?
Потому что .NET используется там, где php попросту не вытянет. Это как сказать, что премиальный мерседес конкурирует с хундай солярис.
Так же и в обратную сторону работает: Обратилась ко мне однажды мадам, у которой пара павильонов в городе есть, чтобы сделать ей сайт-магазин. На что ей был дан такой же ответ, что это будет как стрелять из базуки по воробьям, и была отправлена к php-фрилансерам.
Каждый язык решает свою задачу.
А какое преимущество в вебе дает интерпретация?
Чем это лучше Laravel Livewire?
WebSocket против HTTP и полноценный WASM-режим с возможностью делать полноценные PWA.
Холиворный вопрос. Как адепт C# и компилируемых языков, скажу: всем лучше. Очевидно, что для адепта PHP будет другой ответ, и он тоже будет прав.
Blazor - офигенная штука! Можно писать фронт так, будто пишешь бэк. Все боли фронтендеров фактически отсутствуют, при особом желании можно даже совсем без JS обойтись. Имеются разные варианты использования Blazor:
С постоянным подключением к серверу - довольно медленное решение, но можно быстро написать всё в одном. Можно писать запросы к БД хоть прямо со страницы.
Только фронт с отдельным API (на чём угодно). Очень быстро работает, максимально простое решение, рендеринг на клиенте. Можно получить данные при инициализации страницы. Фактически не отличается от MVC, если API на C#.
Связка фронта и API с возможностью рендеринга на сервере. Тут надо сначала поразбираться, данные можно получать в разных местах в зависимости от выбранного режима рендеринга. Самое сложное решение, но при этом самое гибкое, с кучей возможностей. Не требует постоянного соединения с сервером.
Я использовал все три подхода. В новом проекте собираюсь использовать третий. Для меня даже нет варианта выбора другого фреймворка. Blazor почти идеален.
А ещё там встроены страницы управления аккаунтом. Так что можно с ходу иметь сайт с возможностью регистрации пользователей, не тратя на это кучу времени. Остаётся лишь настроить под себя.
Я бы не сказал, что server-версия «довольно медленное решение». Для проверки я находил сайты, созданные на Blazor Server, которые хостятся в сша. И могу сказать, что я каких-либо лагов не почувствовал. Даже с телефона на мобильном интернете они работали нормально.
Один из своих сайтов я сначала таким образом написал. Он работал существенно медленнее переделанной версии и при потере подключения приходилось перезагружать страницу. Особенно неудобно было пользоваться с телефона.
А wasm вариант в blazor уже научили первый раз открываться хотя бы через 2 секунды, а не через 30?
По dial-up соединению любой сайт будет открываться пол часа (:
А если серьёзно, то нужно понимать область применеия Blazor - корпоративные приложения. А в этот сорфт работают с компа по проводному интернету и хорошо, если пользователи закрывают браузер и выключают компуктер раз в неделю, а не дожидаясь очередного обнолвнеия и неизбежной перезагрузки. Поэтому, размер приложения может быть как и 15МБ так 500Кб - пользователь разницы не заметит.
В современном dotnet есть еще interactive режим работы
Это когда при первых запросах условно работает как blazor server, а при последующих - blazor wasm.
Кроме того, можно гибко конфигурации страницы - одна например только в режиме server , другие в режиме wasm
Сложно понять насколько ASP.Net MVC ещё используется в разработке? Судя по публикациям микросервисы полностью заняли его нишу разработки.
На MVC в том числе делают микросервисы. Кроме того, сейчас MS ативно форсит более аскетичный Minimal API для этих целей, но этот подход еще не победил.
Может ты хотел сказать ASP?
ASP, еще до дотнета который? Нет, речь идет об актуальном ASP.NET Core MVC, хотя автор в посте по почему-то отбросил слово "Core", но из контекста понятно, что речь идет не про оригинальный ASP.NET MVC под .NET Framework.
Нет.
1) Что значит "до дотнета"? Дотнет был всегда, просто раньше он назывался .NET Framework, а сейчас просто .NET
2) У актуального дотнета уже несколько лет нет слова Core в названии, начиная с версии .NET 5
3) Объясни, как пишутся микросервисы на ASP.NET MVC? MVC - это шаблон проектирования Model-View-Controller, и я затрудняюсь представить, кто и как пишет с его помощью микросервисы. Поэтому я и спросил, что быть может ты имел ввиду сам фреймворк ASP.NET, а не шаблон?
Что значит "до дотнета"?
Это значит, что ASP и ASP.NET - разные технологии. Ссылку я привел выше.
У актуального дотнета уже несколько лет нет слова Core в названии
У дотнета - уже нет, а у библиотек и фреймворков - так и осталось. ASP.NET Core, EF Core и т.п.
У MS всю дорогу проблемы с неймингом =3
MVC - это шаблон проектирования Model-View-Controller, и я затрудняюсь представить, кто и как пишет с его помощью микросервисы.
В чем именно тут затруднение? Микросервисы накладывают ограничения на архитектурные паттерны? Или что "View" может быть не только куском готового HTML, но и JSON-моделькой?
Или что "View" может быть не только куском готового HTML, но и JSON-моделькой?
Наверное будет правильно так описать различия:
1) для приложения с визуальным интерфейсом "View" это "View Template" в который помещены данные "View model" и такой контент web-сервер отдаёт для прорисовки в броузере;
2) для веб-сервиса JSON-модель это data transfer object.
Впервые слышу такое, что json может быть view. Мы точно об одном и том же говорим?
Да и в комментарии выше правильно подмечено, что json - это dto.
Конкретно в ASP.NET MVC, View - это визуальная часть.
View в MVC - это презентационный слой для данных, визуальным он может быть, но не обязан. REST API своему клиенту могут презентовать данные в виде JSON - фронтенду или другому (микро)сервису. Визуализируются они дальше или нет - не важно.
В ASP.NET Core средства создания REST API лежат в сборке Microsoft.AspNetCore.Mvc.Core, поэтому логично было бы считать их частью ASP.NET Core MVC-сабфреймворка. Раньше этому у MS было отдельное название - Web API, а сейчас в документации скупое Controller-based APIs.
ASP.NET MVC — это супермощная вещь, но она имеет ряд недостатков по сравнению с альтернативами.
Интерактив на странице реализовывать куда менее удобно, чем, например, в Next.js. Да, у вас доступна вся мощь ванильного JavaScript, HTMX, Bootstrap — и добавить на страницу карусели, модальные окна или простые формы вполне реально. Этого достаточно для части задач, например при рендеринге простых сайтов. Однако создать полноценный интерактивный мультифункциональный портал для клиента — вроде банковского — будет значительно сложнее (хотя и возможно: как-то же раньше справлялись, хотя современные фреймворки как раз и пришли на смену этому «как-то»).
Выбор UI-китов крайне ограничен, и большинство из них постепенно устаревают. В современном мире UI-киты чаще всего выпускаются под конкретные фреймворки. Да, бывают версии с «чистым» HTML, но их немного — и у них возникают серьёзные вопросы по объёму «копипасты»: чтобы создать модальное окно или форму с валидацией, приходится вставлять в 2–3 раза больше кода, чем в случае с компонентами.
С другой стороны, это же и плюс: работа на самом низком уровне с HTML, CSS и ванильным JavaScript заставляет искать максимально простые и прямолинейные решения там, где это возможно.
Если же рассмотреть Blazor, он тоже оказывается довольно компромиссным решением:
Да, интерактивность реализовывать проще, и удобно переиспользовать код между сервером и клиентом. Однако всё это присутствует и в Next.js — причём в куда более продвинутом виде и нативно, на «родных» веб-технологиях, а не через WebAssembly и JS Interop.
А сам JS Interop — это головная боль. Да, можно использовать JS-библиотеки, но там, где TypeScript подсвечивает синтаксис и проверяет типобезопасность на этапе компиляции, в Blazor все проверки смещаются в рантайм (включая тесты).
В целом экосистема Blazor развита слабо: под React сотни UI-китов и библиотек, а в Blazor основную работу ведут энтузиасты.
Поэтому каждый раз, когда я думаю запускать новый SaaS-пилот и пишу бэкенд на .NET, руки тянутся «ускорить» разработку, взяв ASP.NET Core или Blazor. Но, трезво взглянув на реальность, я понимаю: гораздо быстрее написать весь фронт на Next.js — там уже есть нужный UI-кит, удобные компоненты, сборка через Vite, минимизация, оптимизация, сжатие изображений — всё настроено «из коробки». Так что на ASP.NET MVC я уже смотрю с лёгкой ностальгией, хотя и пишу API на .NET.
P.S. При этом Next.js и вся Node.js-экосистема, конечно, дико кривые. Не далее как сегодня я узнал, что в Node.js HTTP-сервере жёстко задан таймаут запроса — 5 минут. Его можно переопределить, но только глобально: установка таймаута для отдельных запросов не работает. А багу этому уже за 100 лет в обед, и никаких движений по её исправлению. Ладно, это ещё можно обойти. Но Next.js не позволяет переопределять этот таймаут через свои настройки — только патчингом исходников. Ишью на GitHub по этому поводу висит уже несколько лет. И таких «подводных камней», на которых можно зависнуть на целый день, хватает — стоит лишь выйти за рамки простого рендеринга. Но всё равно, как ни странно, получается быстрее, чем на ванильном стеке, за счёт универсальности серверного и клиентского рендеринга.
JS Interop — это головная боль. Да, можно использовать JS-библиотеки, но там, где TypeScript подсвечивает синтаксис и проверяет типобезопасность на этапе компиляции, в Blazor все проверки смещаются в рантайм
Если говорить именно про библиотеки на JS, то TS будет полагаться на декларации контрактов (*.d.ts), которые в рантайме так же могут разъехаться с реализацией. При том TS, как известно, не силен рантаймовыми проверками, в отличие от.
ASP.Net MVC vs Blazor: чья возьмет?