люди, которые знакомы с JS и C#(а таких на мой взгляд достаточно много)

Всё очень зависит от личного опыта, я вот за всю свою жизнь ни одного живого C#-разработчика не видел (кроме себя разве что, но я не настоящий сварщик). ¯_(ツ)_/¯
Что конечно же совсем не означает, что их нет или мало.

обычно если выясняется что на новом стэке можно экономить время и деньги, то они не долго тянут с переходом

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

Я же и не спорю с такой точкой зрения. :)
Но тем не менее индустрия весьма инертна, есть много людей, которые вложили свои силы и время в изучение JS (и очень многим из них весьма комфортно с этим языком), много компаний, которые вложили большие деньги в JS (от Google, вложивший огромное количество сил в свой V8, до продуктовых компаний, выстроивших продукт вокруг JS-стека).

В том, что современный JS компилируется в байт-код на старте приложения и дальше JIT-компилируется нативным JS-движком.

А в случае C# добавляется дополнительная прослойка в виде CLR, что "вызывает вопросы касательно производительности".

То есть у нас JIT-компиляция IL внутри CLR, который работает в WebAssembly VM c JIT? :)

А вот это, кстати, любопытно уже с другой стороны. :)
Если Rust-приложения не тянут собой лишний рантайм и GC, то почему они не весят меньше?

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

Имхо — задавит JS фреймворки со временем потому что большинству молодых программистов просто лень учить JS. Вы не представляете себе силу лени.

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

Хотя не уверен, какой смайл здесь более уместен. :(

Ну, самое, опять же, мейнстримовое и разухабистое решение — Redux-Form, ещё 139 kB minified или 26.9 kB minified + gzipped. Безумно много, но суммарно (со всем остальным) даже до половины мегабайта не дотянули.
При этом довольно популярная альтернатива (от тех же авторов, осознавших, какое хтоническое чудовище они породили в виде Redux-Form) — Final-Form, весит всего 14.8 kB minified или 5 kB minified + gzipped.

Понятное дело, что для сильных, смелых и умелых бесконечность никогда не предел, можно на чём угодно сделать приложение любых размеров. Но мы, я надеюсь, говорим о том, насколько хорошо можно сделать, а не о том, насколько плохо? :)

Пока что в сравнении размеров базовой комплектации Blazor очень сильно уступает современным JS-решениям. К тому же, решение с интерпретацией IL на клиенте (см. выше) лично у меня вызывает вопросы касательно производительности выполнения прикладного кода.
Надеюсь, всё это временные проблемы Blazor'а, которые его разработчикам получится преодолеть.

И как-будто всякие Javascript/Typescript/Angular/… библиотеки, которые тащатся сейчас, совсем ничего не весят :)

Берём (для примера) самый мейнстримовый (и при этом весьма раздутый, если по-честному) стек: React (+ ReactDOM) + Redux + Reselect + Redux-Saga.
Суммарно получаем ~139 kB minified или ~46 kB minified + gzipped.
Даже если накинуть ещё столько же на прикладную логику (хотя это будет уже явно не уровень todo-приложения), Blazor'у ещё расти и расти в этом плане.

Я правильно понимаю, что прикладной C#-код в итоге не компилируется в WebAssembly, а прислылается на клиент в IL и уже там исполняется внутри CLR?

Прозвучит для кого-то ужасно, но есть области, где это совершенно неважно.

Типичный пример — разработка внутрикорпоративных решений. Браузер там используется просто как платформа для запуска приложений. Пользователи открывают "сайт" один раз в день (если не раз в неделю) и, как правило, не закрывают.

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

Хорошо это или плохо, но Web очень быстро (и уже давно) растёт и расширяется, так что он давно не ограничивается тем, что мы видим в процессе "веб-сёрфинга". :)

А, точно, C# же managed… Я было думал, что оно полностью компилируется в WebAssembly, без использования CLR в run-time.

Впрочем, если я правильно понимаю, с появлением GC integration в WebAssembly, можно ожидать отказ от CLR и уменьшения размеров сборки. Впрочем, не очень понятно, когда это ещё будет.

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

Хммм, да поправит меня yelbota, но что-то мне это очень сильно напоминает… :)

Если на Vue.js SPA вести 1.7 мегабайт, то точно такое же на Blazor 21 мегабайт.

Кхм, а есть какое-то примерное понимание, откуда там такие размеры-то? Очень хочется пошутить про то, что он тянет с собой весь CLR, но это уж явно не имеет отношения к реальности.

Мне кажется, что в данном случае это скорее субъективное мнение Алан Кея. Насколько этому мнению доверять — каждый решает сам за себя.

1. ToDo это всё же далеко не real-world пример.
2. Не знаю почему, но у меня результаты скачут в несколько раз (сделал несколько прогонов).

В целом, пример на MobX любопытный, спасибо (честно скажу, не смог заставить себя вникнуть в примеры в статье, а в песочнице оно куда нагляднее).

Некоторые соображения:

1. На практике такой сценарий достаточно редкий. Подписываются на store обычно т. н. controller-view (а их ограниченное количество), которые полученные из store данные спускают вниз дочерним pure-компонентам. Соответственно, controller-view сам никакого UI не создаёт и его перерисовка максимально дешёвая.
2. Ошибки подобного класса весьма хорошо выявляются статическим анализом.
3. Если закрыть глаза на пп. 1 и 2, то остаётся reconciliation. Да, это недешёвая операция, но, насколько я понимаю, "реактивная магия" MobX тоже отнюдь не бесплатна. Пожалуй, было интересно увидеть честное real-world сравнение производительности подходов Redux и MobX, но вряд ли мы такое когда-нибудь увидим. :)

А, ну в таком случае, конечно, будет перерисовка — компонент через connect() подписан на обновление state.value, хотя он ему не нужен.

Но это совсем другая история — PureComponent тут тоже никак не поможет и он, опять же, в данном примере совершенно лишний.