.NET und C# ohne Web?
небольшая интерактивность страничек, плюс асинхронные (без перезагрузки страницы) загрузки. А когда стали пытаться сделать из него язык для всего, для сложных приложений, а потом и вообще на десктоп тащить стали, а также в бэкэнд, то джаваскрипт резко превратился в плохой язык
все как раз наоборот, им начали заниматься серьезные фирмы и качество кода и фреймворков заметно подросло, до этого там был полет мыслей, до jQuery и того хуже
Для этого и делали WebForms, там есть Design View, вы точно так-же тянете ASP NET компоненты как в WinForms, а начиная с версии помойму 2012 Visual Studio, там по умолчанию есть jQuery и Bootstrap. Для этого и делали разные CSS и JavaScript фреймворки, чтобы быстро делать веб приложения, и чтобы адаптивный дизайн был. А WPF больше для интерактивных Windows приложений подходит.
сравнивать Webforms с JavaScript это как сравнить английский с саксонским диалектом немецкого ))
Я имел ввиду если ТС не хочет париться с JavaScript, то может использовать WebForms, для этого и делали WebForms чтобы не пилить это на JavaScript.
вы точно так-же тянете ASP NET компоненты как в WinForms
Я только ASP.NET MVC использовал - это без готовых клиентских компонентов, только серверная инфраструктура предоставляется. Все клиенсткие компоненты - со стороны. То, что там в последних версиях (ASP.NET MVC 3-5) есть шаблоны, где можно начать проект сразу с подключенными CSS- и джаваскрипт-фреймворками - это всё всё равно со стороны, а не включено в ASP.NET MVC фреймворк.
Я имел ввиду если ТС не хочет париться с JavaScript, то может использовать WebForms, для этого и делали WebForms чтобы не пилить это на JavaScript.
Насколько я знаю, это давно obsolete и либо очень старые проекты поддерживать, либо вообще никак. Почти все вакансии если и связаны с вебом для дотнета, то там ASP.NET MVC или что там ещё новее у Майкрософта есть. Когда я ASP.NET MVC использовал, то максимум что из джаваскрипта брал - функции некоторых компонентов (типа график нарисовать и прочее) - сам функции и программы на джаваскрипте на клиентской стороне не писал. Просто смотерел тьюториал по джаваскрипт-компоненту и вызывал его функцию с нужными параметрами. Если делать приложения с развитой клиенсткой частью, то там надо и клиентский слой хорошо прорабатывать - это нужен джаваскрипт-специалист, а не такой, как я, который только иногда отдельные функции компонентов дёргать может.
Тут ещё загвоздка в том, насколько в проекте собираются перетянуть одеяло на клиентскую часть, и насколько хотят урезать северную. Если всё в основном на бэкэнде делается, а клиент только представления показывает и обновляет, то достаточно джаваскрипт фреймворков с привязками (байндинги - я использовал KnockoutJS), асинхронных запросов и вызовов функций компонентов - это я делал. А когда на фронтэнде пишут полноценную логику, всякие одностраничные приложения (SPA) и прочее, то тут ASP.NET MVC и вообще сишарп со своей серверной частью отходят сильно на второй план, и я тут умываю руки - я тут не специалист.
Я имел ввиду если ТС не хочет париться с JavaScript, то может использовать WebForms, для этого и делали WebForms чтобы не пилить это на JavaScript.
ТС не хочет на позицию, где нужно будет париться с Javascript.
плюс WebForms не заменяет Javascript и наоборот
Вкратце почитал - они пишут нативно испольняемый код для каждой платформы (считай, нативный фреймворк - код пишется на шарпе, потом компилируется в натив), а вебстек используют просто для рендеринга интерфейса.
Выглядит хреново, что Блазор, что Разор - разметка перемешивается с кодом на шарпе. Такое ощущение, что это всё для небольших поделок. В больших приложениях быстро запутаешься, где тут код, где разметка, и в этой каше разбираться.
Но есть плюс у Блазора - привязка данных (байндинги) работают из коробки, без сторонних фреймворков?
ASP.NET Core Blazor data binding | Microsoft Docs
Для ASP.NET MVC даже с использованием Разор нужно было сторонний фреймворк использовать для привязки (я брал KnockoutJS).
ТС не хочет на позицию, где нужно будет париться с Javascript.
Это несправедливо, что джаваскриптеры и более обще веб-фронтэндеры лезут во все щели с одним своим джаваскриптом (плюс CSS и HTML - это для них один стек) и больше к ним никаких требований не выкатывается. А всем остальным, работающим с вебом, хоть джавистам, хоть дотнетчикам, хоть рубистам, нужно знать ДОПОЛНИТЕЛЬНО весь фронтэнд стек. И когда дотнетчик начинает что-то на фронтэнде для веба делать, то он начинает полностью в его пробелмы погружаться, а бэкэнд как бы уходит на второй план. Потому что веб-фронтэнд настолько проблемный и настолько там всё быстро меняется, что ты волей-неволей переквалифицируешься потихоньку в веб-фронтэндчика-джаваскриптера.
В нормальных и больших компаниях вроде это разделяют - бек и фронт делают разные люди. Но что-то мода пошла всё соединять в одном лице и требовать от кандидатов фуллстек. Потому если проект пишут на ноде, то требуются одни джаваскриптеры, которые делают и фронт и бек. А если на какой гибридной технологии, типа дотнета или джавы на беке, то от джавистов и дотнетчиков требуют ещё и отличное знание фронта (JS-CSS-HTML-Frontend Frameworks) со всеми его заморочками.
Потому у меня дилемма - если погружаться в веб разработку с беком на шарпе и дотнете, то будешь голову забивать фронтом вебовским, и забывать фронт десктоповский и мобильный (WPF, UWP и прочее, что там из GUI у дотнета есть). А я этого не хочу - меня тошнит от заморочек веб фронтэнда. Как зайдёшь на Хабр, почитаешь их кухню, как они костыль на костыль лепят там, где в дотнете всё давно удобно сделано, да ещё друг друга этим нахваливают и сеньорами называются...
где в дотнете всё давно удобно сделано
так если бы дотнет на всех платформах одинаково хорошо летал, то все бы на нем и писали, а так, хоть эпл, хоть линукс возьмите, как там с дотнетом, а в этом сегменте часто кастомеров больше, чем в винде, например, в медицине или химии.
Выглядит хреново,
Для меня очень даже ничего, особенно такую фигню для веба зафигачить 
https://demos.devexpress.com/blazor/RichEdit
https://demos.devexpress.com/blazor/Scheduler
разметка перемешивается с кодом
С вебом особо не работаю, а что есть где не перемешивается?
В больших приложениях быстро запутаешься, где тут код, где разметка
-----
Разумеется. Если следовать образцам даваемым мелкомягкими - обязательно.
Но штука в том, что следовать совсем не обязательно - код выносится в дллки, разметка остается минималистической.
У меня как-то даже требования образовались - не более двух уровней - т..е. for-for, for-if, if...
И как только заставил писать в этом режиме - половина имевшихsя проблем исчезла...
а что есть где не перемешивается?
-----
Не знаю есть ли, но знаю что можно.
Т.е. можно построить байндер, который все заполнит коректно и при этом разметка не будет занать об источниках и наоборот.
И в ASP.NET для этого сделано довольно много. Фактически - все необходимое.
С вебом особо не работаю, а что есть где не перемешивается?
Похоже, что в вебе нет. Это-то и плохо, что веб джаваскриптеры как само собой разумеющееся считают, что перемешивать код и разметку - это нормально. Это только для коротких примеров для краткости пойдёт, как в той же моей ссылке на сайт МСДН.
Не знаю есть ли, но знаю что можно.
Т.е. можно построить байндер, который все заполнит коректно и при этом разметка не будет занать об источниках и наоборот.
И в ASP.NET для этого сделано довольно много. Фактически - все необходимое.
Вот в XAML не перемешивается - там от кода только байндинги к свойствам и методам. В примерах от МС идёт разметка, потом бац кусок шарповского кода, потом снова разметка - что Блазор, что Разор. Вроде, даже в последних версиях XAML позволили сишарповский код писать, а до этого народ свои расширения для этого делал. Ооочень редко это нужно. А то если позволишь, так народ начнёт прямо в разметке развесистые функции писать (те же сложные фильтры данных, вместо того, чтобы сослаться на них во View Model или в code behind).
А ещё иногда в Разор (да и в Блазор, похоже) делают циклами контролы. Т.е. надо из списка слепить ссылки в столбик, например - делают в цикле for или foreach элементы <li> или <a>. Тогда как в нормальных байндингах для этого специальное представление коллекций есть, которое само такие группы элементов делает.
Это несправедливо, что джаваскриптеры и более обще веб-фронтэндеры лезут во все щели с одним своим джаваскриптом (плюс CSS и HTML - это для них один стек) и больше к ним никаких требований не выкатывается.
Ой а я изучал более сложные ЯП чем JavaScript. Такие как LISP, Erlnag, Ada. Сейчас я изучаю COBOL, т.к. я не могу поставить Sap NetWeaver чтобы играться в ABAP, а если и даже смог-бы, то там тестовая версия ограниченна на 28 дней, а COBOL бесплатный. Сейчас покуда занимаюсь робототехникой изучаю ещё Lua, покуда роботы дорогие, а есть бесплатный симулятор, но там на Lua.
Ооочень редко это нужно. А то если позволишь, так народ начнёт прямо в разметке развесистые функции писать (те же сложные фильтры данных, вместо того, чтобы сослаться на них во View Model или в code behind).
а потом получается, что у тебя логика и в code behind и во ViewModel, красота 
WPF мне тоже как-то не зашел
например что напрягает
<TextBox Text="{Binding object.Property}">
для Visual Studio object.property это тупо текст, ни тебе проверки, что ты тут букву пропустил, ни прыжка в класс, где есть проперти, по ф12
ни Find all References
так если бы дотнет на всех платформах одинаково хорошо летал, то все бы на нем и писали, а так, хоть эпл, хоть линукс возьмите, как там с дотнетом, а в этом сегменте часто кастомеров больше, чем в винде, например, в медицине или химии.
так не надо приложения под конкретную платформу разрабатывать, когда есть web
так не надо приложения под конкретную платформу разрабатывать, когда есть web
так я тоже об этом же. А потом удобно дать морду, чтобы кто посмотрел, попользовал как демо, а, если понравилось, то и купил. А если делать на дотнете и иже с ними, то надо для выхода на рынок сразу поддерживать всю эту галиматью в виде маков, винд, линуксов, где у каждого - свои погремушки. Как-то недавно работал с одной фирмой, в которой один фортрановский программист поддерживал бекенд и 28 человек рисовало фронты на все платформы, но начальство кололось, но не лезло на кактус жаваскрипта.