Comments 89
Добро пожаловать в мир JavaScript. Вы просто испорчены C#. C# - один из лучших прикладных языков сейчас. Посмотрите Kotlin Multiplatform. Bleeding Age, но может вам зайдёт, если есть желание писать на хорошем языке и иметь возможность дергать JS-код
Котлин уже научился не тянуть с собой 2 мегабайта рантайма?
Blazor тянет не меньше, но клиентов автора это устраивало, насколько я понял
Я написал интернет-магазин для магазинов мяса на Blazor Server. Там фактически нет фронта, есть только бекенд. Всё события и изменения в DOM-дереве передаются на сервер через WebSocket и сервер генерирует новый html и шлет обратно.
Это не blazor webassebly - другая технология
А там уже исправили ситуацию, что один сервер может поддерживать всего несколько десятков пользователей одновременно, из за того что для каждого пользователя надо его контекст на сервере держать?
Это вопрос к @arthurlomakin - он же на нем что-то делает. Я только теоретически интересуюсь
At this point, we have actually hit a limitation. With the Azure SignalR Service. As of this post, the max number of SingleR connections a service can have is 100,000 concurrent connections.
Thus there is a limit of 100,000 concurrent users to a Blazor Server Side application.
Не интересовался, но оказывается много. Но это на мощном сервере.
Scale vertically means adding more compute and/or memory to the machine.
In our example, Microsoft has stated that a 1 core, 3.5 GB memory machine can scale to 5000 concurrent users.
Note this says for concurrent users, not total users. So if you have a system with 10,000 users, but you have only 1000 on at any given time, you are fine with the machine listed above. By the way, you should know how many concurrent users you have using your system over any given day.
Upgrade your Azure machine to the P2V3, 4 Core, 16 GB memory, and you can support up to 20,000 concurrent users.
For a single Azure app service, your application can support up to 20,000 concurrent users. That seems fairly decent.
~250 KB. У меня Blazor Server, а не Blazor WebAssembly, там намного больше, как вы и говорите.
По-моему еще нет. Просто как вариант "и волки сыты, и овцы целы" для автора. В Kotlin Multiplatform ИМХО проще до JS дотянуться, чем из Blazor и сам язык на C# похож, а местами даже интереснее сделан.
Если я испорчен C#, это плохо или хорошо?
Надо было мол брать, а не реакт
Blazer это же васм. Так можно людей и из геймдева сайты научить писать. Просто в e-commerce все плохо, либо самопис либо ... Битрикс))))
Вообще, когда вы что то долго ищите и не можете найти там, где сфера разработки огромна, типа поиск орм за 1 месяц, это звоночек, что вы пытаетесь использовать свой прошлый опыт в другой области. Что то тут не так и это что то может потом вылезти.
Вы пришли из Шарпа и плюетесь на то что все не такое как Шарп) Уэлкам, избалованным корпоративным софтом разработчикам. !
Заходим в документацию TypeORM, смотрим раздел "Working with Repository":
import {getRepository} from "typeorm";
import {User} from "./entity/User";
const userRepository = getRepository(User); // you can also get it via getConnection().getRepository() or getManager().getRepository()
const user = await userRepository.findOne(1);А если ещё и инициализировать все репозитории где-то в одном месте, и прокидывать их в сервисы по мере необходимости, то ваш код превратится в одну строчку:
const user = await userRepository.findOne({ where: { name: 'Вася' } });Сходили бы, доку почитали бы ради разнообразия, что ли.
Претензии, конечно, так себе, но в итоге выбор в пользу MikroORM был сделан абсолютно верно.
Если автор ORM прямо в readme заявляет, что «Your models in your app are your database tables» — очевидно, он не понимает, что вообще такое ORM, и делает что-то странное. Дальше можно даже не смотреть.
А что делает ORM? В Entity Framework таблицы базы описывалось C# классами и запросы тоже с ними работали.
Согласен, что не все претензии весомые. Но добавилась весомая проблема независимости миграций в ORM. Дописал в статье.
ORM - это такая штука, которая а) не всегда нужна, б) иногда вылазит боком.
Ну и, в целом, стремление переписать фронт на React.JS понять еще можно. Зачем при этом на беке на ноду переползать - вообще не понятно.
В общем, Blazor вас испортил. Мухи отдельно, котлеты отдельно Фронт связан с беком на уровне API, тчк.
del
но проблемы js все равно не ушли, а ты точно уверен что name там есть?)) а может name это массив байтов?
Я это смотрел. Все равно, если я напишу вместо name nam, то будет все ОК. Хотя я хотел добиться, чтобы IDE мне сообщило об ошибке. Я правда уже нашёл способ. Дописал в статье. Но все равно миграций нормальных нет нигде в JS.
А что такое "нормальные миграции"?
Дописал в статье. Независимость от базы при создании новой миграции.
А что скажете про такие миграции? Они норм или нет?
Независимость от базы при создании новой миграции
... как правило, фикция.
Классика же, 10 лет назад вместо Vue просто jQuery был.
А таки почему JS, а не TS? Тем более что и второй, и особенно третий Вью его хорошо поддерживают.
web api + vue = идеально , другого не нужно
Когда начинаешь писать на новом для себя фреймворке, языке всегда времени тратится больше на разработку, так как приходится многое изучать. Вы приплюсуйте время на изучение C# и Blazor.
Язык/фреймворк - инструменты. Под каждую задачу/проект - свой набор, не стоит тут зацикливаться на какой-то одной экосистеме. Иногда набросать небольшой сервер на nodejs быстрее, чем C# городить (хотя в последнее время они значительно сократили бойлерплейт и в принципе приблизились к той же nodejs). Плюс иногда есть хорошие либы, вокруг которых легче строить приложение. Например, бота для телеграмма мне удобнее писать на telegraf+node, а систему авторизации на .NET Identity.
Для бэкэнда на ноде есть удобный фреймворк nestjs, в нем и IoC, ORM, Eventbus. Он довольно близок по идеалогии к .NET.
Да и почему бы фронт не писать на JS , а бэк на C#. Есть разные связки и они хорошо подходят под разные сферы.Зачастую над проектом трудятся несколько разработчиков: фронэндер, бэкэндер. Как правило фронтэндер пишет на js/typescript. Разбирать страницы Razor на смеси C#+JS куда сложнее.
На React, а особенно на React+Redux разработка действительно идёт крайне медленно. Это свойство самой технологии - низкоуровневость решения, большие объёмы бойлерплейта и обилие подводных камней, которые становятся видны лишь со временем.
Опыта до Blazor у меня было тоже +- 2 месяца, я писал приложение на WPF. И это все.
Зачастую над проектом трудятся несколько разработчиков: фронэндер, бэкэндер.Тем не менее, это далеко не всегда так. Фронт в том же энтерпрайзе зачастую не настолько заморочен, чтобы был смысл в отдельных специалистах.
Разбирать страницы Razor на смеси C#+JS куда сложнее.«Смесь» должна быть скрыта под врапперами с интеропом, «прикладной» код должен быть только на C#.
Давно не было статьи "у меня большой опыт C#/Java, решил разобраться с фронтендом, а у тут все устроено не так, как я привык, и мне это не нравится". Спасибо, ваше мнение важно для нас! /s
На самом деле, есть в статье интересные моменты:
нужно сделать колесо фортуны, на JS готовое решение есть, а для Blazor нет
Так может потому и нет, потому что на Blazor сложные UI штуки не реализовываются? Что сама технология задумана для более-менее прямолинейных CRUD, и как-только начинаются шаги в сторону, технология уже не справляется.
Сразу заметно, что код React в 1.5 раза больше.
А ничего что в React у вас 3 компонента, а Blazor все соединено в один? Сами написали больше кода, и жалуетесь теперь.
React же все построено вокруг паттернов CQRS, Event Sourcing, на бекенде эти паттерны используют только в сложных проектах, поскольку для простого проекта это принесет только вред
Откуда такая уверенность, что работающее хорошо в бекенде априори будет работать хорошо везде? Большинство бекендов как правило stateless, поэтому там можно обойтись прямолинейными паттернами. Фронтенд же (и любой UI в принципе) хранит в себе состояние, и без его грамотной огранизации даже то самое колесо фортуны реализовать не получится.
Вывод такой – если уж взялись изучать новую экосистему, то нужно сначала понять её базовые парадигмы и паттерны, и почему они используются. А не натягивать свой прошлый опыт, потому что так привычнее.
Есть еще Modx, но если я не ошибаюсь, это тот же Redux, только с сахаром в виде ООП да и сейчас Redux - де-факто стандарт.
MobX - совсем не Redux, даже не близко. Рекомендую всё же к нему присмотреться, если собираетесь оставаться на React.
Redux же не стандарт совсем. Его какое-то время много хайпили, пока проекты не выросли. После этого даже до самых глупых дошло, что это какая-то тормозная ерунда, в которой концы с концами не сведёшь, а рефакторить адски больно. Теперь же потихоньку Redux-легаси переписывают кто на MobX, кто на хуки.
Я 3 месяца назад искал работу. К сожалению, вакансий c react + redux было гораздо больше чем с react + все остальное. Смотришь, хорошая вакансия, но redux все портит и нет особого желания всерьёз рассматривать позицию в проекте с ним. Да и на курсах штампуют новых поклонников Абрамова и redux-а. Эх, испортил Абрамов реакт основательно и надолго.
<sarcasm>Судя по кол-ву опечаток, вообще удивительно что удалось написать хоть что-то рабочее</sarcasm>.
А если серьезно, то сам сталкивался с подобным эффектом когда менял стек. Переходил с PHP на Java и пытался применить старый опыт в новой среде - получал кучу ошибок и потенциальных дыр. Переходил с Java на JS - аналогично: привычные подходы и паттерны перестают работать. В 2019м полез во Flutter и тоже не мог долго вкурить как тут делать привычные мне штуки. Но как только в мозгах перестраиваешь парадигму мышления и начинаешь понимать что другой стек = другие паттерны - все начинает идти как по маслу.
Скажу так, нет ни одного шаблонизатора(я туда отношу и JSX), который хоть немного сравнится по удобству с Razor(шаблонизатором для Blazor).
Я тут рассказывал недавно, почему шаблонизация - это устаревшая концепция. Для примера, могу продемонстрировать, как ваше приложение пишется на $mol.
Cмотрите, это не шаблон, это статически типизированное декларативное описание композиции компонент:
$my_app $mol_list
tasks?val /$my_task
rows /
<= Task_list $mol_list rows <= task_list /$mol_view
<= Add $mol_row sub /$mol_view
<= Add_descr $mol_textarea value?val <=> add_descr?val \
<= Add_submit $mol_button_major
title @ \Add
click?event <=> add_submit?event null
Task!id $mol_row sub /$mol_view
<= Task_descr!id $mol_text text <= task_descr!id \
<= Task_remove!id $mol_button_minor
title @ \Remove
click?event <=> task_remove!id?event nullТут мы видим из чего состоит приложение и как компоненты связаны друг с другом разносторонними связями.
А вся логика описывается уже отдельно кодом:
namespace $.$$ {
export class $my_app extends $.$my_app {
task_list() {
return this.tasks().map( ( _, i )=> this.Task( i ) )
}
task_descr( id: number ) {
return this.tasks()[ id ].descr
}
task_remove( id: number ) {
const tasks = this.tasks().slice()
tasks.splice( id, 1 )
this.tasks( tasks )
}
add_submit() {
const task = { descr: this.add_descr() }
this.tasks([ ... this.tasks(), task ])
this.add_descr( '' )
}
}
}Тут мы видим откуда берутся данные и что делают кнопки.
Как видите, кода получилось примерно столько же, как и на Blazor, но:
Тут уже есть поддержка локализации. Английские тексты при сборке автоматически выносятся в отдельный JSON, а в коде они заменяются на человекопонятные глобально уникальные ключи.
У каждого элемента есть все необходимые человекопонятные классы для стилизации. Это что-то типа автоматического БЭМ, только круче. Более того, можно писать статически типизированные стили.
Тут есть куча точек расширения. Каждое имя после стрелочки - такая точка. Фактически это просто методы в классе, которые можно в дальнейшем переопределять.
Описания задач поддерживают маркдаун, а форма - подсветку синтаксиса.
Рендеринг приложения автоматически виртуализируется. Даже если вы в описание каждой из тысяч задач засунете килотонны текста - больше 1000 DOM-элементов у вас на странице не будет.
И весит это всё меньше, чем один только голый Реакт. Грузится, соответственно, тоже гораздо быстрее.
$Не?/ну<=>это<=ад \
$.$$$какой@то? null
return <абсолютно .{.. props} c={<><вами>согласен</вами>{' '}<в>этом</в></>} {/*или*/} className={'irony ' + нет()}/>
В принципе любой, кто значет html и js сможет понять, что тут написано.
Что же означает это нагромождение из !$$$@@/\ <= понять очень трудно.
Во что это превращается в html?
return <абсолютно
{/*Не знал, что тут можно комментарии писать, хех*/}
className={'irony ' + нет()}
c={<><вами>согласен</вами> <в>этом</в></>}
{... props}
/>
let root model dispatch =
let pageHtml =
function
| Page.About -> Info.View.root
| Counter -> Counter.View.root model.counter (CounterMsg >> dispatch)
| Home -> Home.View.root model.home (HomeMsg >> dispatch)
div
[]
[ div
[ ClassName "navbar-bg" ]
[ div
[ ClassName "container" ]
[ Navbar.View.root ] ]
div
[ ClassName "section" ]
[ div
[ ClassName "container" ]
[ div
[ ClassName "columns" ]
[ div
[ ClassName "column is-3" ]
[ menu model.currentPage ]
div
[ ClassName "column" ]
[ pageHtml model.currentPage ] ] ] ] ]
Вот норм вариант:
let root model dispatch =
let pageHtml =
function
| Page.About -> Info.View.root
| Counter -> Counter.View.root model.counter (CounterMsg >> dispatch)
| Home -> Home.View.root model.home (HomeMsg >> dispatch)
div
[]
[ div
[ ClassName "navbar-bg" ]
[ div
[ ClassName "container" ]
[ Navbar.View.root ] ]
div
[ ClassName "section" ]
[ div
[ ClassName "container" ]
[ div
[ ClassName "columns" ]
[ div
[ ClassName "column is-3" ]
[ menu model.currentPage ]
div
[ ClassName "column" ]
[ pageHtml model.currentPage ] ] ] ] ]Если уж совсем топить за справедливость, то код на view.tree вообще невозможно отформатировать ненормально. И он не превращается в html, он превращается в дерево компонент. А компоненты уже могут создавать dom элементы, рисовать на canvas, а могут вообще не иметь никакой визуализации.
Ого, новая версия brainfuck. Теперь с $
В TypeScript нужно впилить расширение для компилируемых шаблонов, как это сделали для JSX. На React пишу с 2014, но в 2021 видеть его почти стандартом уже странновато.
Типа вот такого?
@* Эта кнопка вызывает функцию DeleteTodoItem и передает ей TodoItem агрумент *@ <button @onclick="(() => DeleteTodoItem(TodoItem))">Удалить</button>
Шел 2021 год... Программистам все еще продолжали платить за строчки кода с комментариями...
Перед тем, как писать критику, стоило бы изучить те инструменты, которые вы выбрали. Про репозиторий в TypeORM вам писали, можно проще и лучше. Про миграции, всё есть в документации: указываем откуда, как и куда генерировать их через конфиг или энвы. Если не нравится через JS их генерировать и применять, есть ts-node, жизнь чутка проще становится. Прежде чем жаловаться, неплохо было бы изучить, как эти инструменты работают, чтобы потом не кричать, почему ничего не работает или не получается.
Еще есть Angular и Vue, но там шаблонизаторы тоже не такие мощные, краткие и понятные как Razor
Если вам нужен был просто рендеринг и ничего больше, есть куча самых обычных шаблонизаторов, например, EJS вам, наверное, даже понравится.
В Blazor можно легко сделать DI контейнер (в Angular тоже), в React же все построено вокруг паттернов CQRS, Event Sourcing
Если мы берём React, тут немного просто другие парадигмы используются. Вам в компонентно-ориентированном программировании зачем DI? Дочерние компоненты добавляются лёгким импортом и небольшим JSX. Если вы про запросы к API, то в React есть Hooks, делаете свой хук с привязкой к API.
CQRS и Event Sourcing нужны для контроля над состоянием, вокруг которого и построен React.
почему мне рекламируют их, если они неудобные, непрактичные, или ну ооочень многословные?
А почему доля того же blazor намного меньше, чем react+redux? Может всё же они немного для других задач? Может потому что они хорошо решают СВОИ задачи?
Я люблю C#, ненавижу зоопарк в JS, но если вы не поняли или вам просто не понравилось, это не означает, что это плохие и ужасные технологии.
Учитесь и не спешите с выводами. В любом случае, вы молодец, что поддерживаете хоть как-то кругозор.
Я как раз использовал ts-node.
Про репозиторий в TypeORM вам писали, можно проще и лучше.
Я это тоже использовал. Но оно же все равно не подскажет, если я опечатался, а это и было целью
А почему доля того же blazor намного меньше, чем react+redux? Может всё же они немного для других задач? Может потому что они хорошо решают СВОИ задачи?
Учитесь и не спешите с выводами.
Ну, на мой взгляд, вывод автор сделал правильный)
Точно не потому что хорошо решают) JS тоже самый популярный язык, но это не делает его лучшим. Он популярен из-за того, что веб-разработка очень распространена, а браузеры не поддерживают другие языки.
Возвращаясь к react+redux. Помню, как в тем времена одновременно появилось много новых технологий. ES6, webpack, react + менеджеры состояний к нему и прочее. Народ не успевал во всем этом разобраться и большинство выбирали технологии по количеству лайков в github. В это время Абрамов показал зрелищный доклад на конференции, на которой были разработчики из facebook, которые и наняли его. Из-за этого события он обрел популярность и начали ошибочно полагать, что он очень сильный разработчик и сделал крутую вещь.
Ещё такой момент: redux стал реализацией flux - модного тогда подхода к стейт-манагерству. Потому воспринялся как истинный путь.
Абрамов на самом деле как разработчик весьма неплох, сейчас пилит сложные крутые штуки, его жизнь далека от формоклёпства. В редуксе он давно разочаровался. Фейсбук не использует редукс.
Я не говорю что он плох. Но он известней любого, гораздо более опытного фронтенд разработчика. Тогда он явно не был разработчиком, к которому стоило прислушиваться всему react сообществу, особенно в плане архитектуры. Я не работал с ним и не слежу за ним, поэтому не знаю в чем и насколько он хорош, но думаю, когда его нанимали, он был на уровне обычного миддла. Ну и поработав несколько лет в Фейсбук, он конечно стал гораздо более хорошим разработчиком, чем раньше.
Всё события и изменения в DOM-дереве передаются на сервер через WebSocket и сервер генерирует новый html и шлет обратно.И насколько хорошо работает такая технология на мобильном интернете с низкой скоростью, непредсказуемыми задержками и периодическими обрывами?
вот после таких статей (про орфографические ошибки я вообще молчу) начинающие разработчики думают, что проблема в языке программирования (ЯП), а не в человеке, который неправильно использует этот ЯП
как можно делать такие выводы, учитывая, что у Вас нет никакого нормального опыта на js
А почему бы не попробовать Сделать React + NodeJs + Laravel?
Вообще статья выглядит как "Не разобрался, да и хуй с ним, пойду на шарпе писать и всем расскажу что ЖыэС говно"
Комментарии норм разбежались)
Скромно напомню про Vaadin. Входные языки Java или Kotlin, фронт отдельно писать не нужно совсем. Всем хорош, за исключением двух вещей: а) даже в 2021 даже опытные разработчики склонны писать бизнес-логику в onClick, и б) хрен на него найдёшь разработчиков в 2021 / RU. Вот печально думаем, куда переезжать - React или Vue :(
"Всё события и изменения в DOM-дереве передаются на сервер через WebSocket и сервер генерирует новый html и шлет обратно. То есть onclick можно обработать прямо из C# и там же скачать, к примеру данные из базы. Это очень удобно"
То есть то, что должно происходить на клиенте передается на сервер? А смысл? Чтобы сделать материал для этой статьи?
"Это очень удобно". Это шутка?
"То есть onclick можно обработать прямо из C#". Спасибо не надо.
Почему я ненавижу JS или как я в 15 лет переписывал свой интернет-магазин