Комментарии 64
Но, помимо вышеперечисленного, у Blazor есть и другие интересные возможности:
Из абцаза выше процитированного текста можно предполагать, что сравнение всё еще идёт с JS. Ну окей:
Для обеспечения работы Blazor не нужны браузерные плагины.
Для JS они тоже (чудеса, правда?) не нужны.
При разработке для Blazor можно выполнять полноценную отладку .NET-кода.
При разработке на JS можно выполнять полноценную отладку JS. Опять же, чудо чудное, да?
Фреймворк использует новейшие возможности браузеров.
А еще он отлично работает в IE11. Или нет. В любом случае, JS, внезапно, тоже использует новейшие возможности браузеров.
Фреймворк отличается хорошей браузерной поддержкой.
Ну да, работает везде, кроме тех браузеров, где не работает ;-)
Использование Blazor позволяет организовать совместное использование кода между клиентскими и серверными частями приложений.
Ну прям как c Node.js несколько лет назад, ага.
Отличное сравнение. Впрочем, чего еще ожидать от пустой маркетинговой статьи.
Для JS они тоже (чудеса, правда?) не нужны.
Только вот уровень языков очень разный. Даже TypeScript не сможет соревноваться с платформой .NET. В данном случае C# из коробки работает полноценно с модулями, и не требуется уписываться import'ами, чуть более что-то серьёзное и десятки и более строк импортов с кучей функций и компонентов. Опять же шикарная строгая типизация. Да и колосальный фреймворк, а не тот ад, что творится в JS, тысячи библиотек в зависимостях. Одну обновили и добавили баг и потом можно неделями искать эту проблему.
При разработке на JS можно выполнять полноценную отладку JS. Опять же, чудо чудное, да?
Как? Имея кучу гемороя с сорсмапами, когда одни работают в одних условиях, другие в других, при этом скорость компиляции знатно начинает страдать.
Ну да, работает везде, кроме тех браузеров, где не работает ;-)
В общем как и JS. Внедрение новых возможностей до сих пор хромает, приходится использовать постоянно колосальное кол-во полифилов, чтобы работало в старых бразуерах, эх, мечта, иметь новые возможности, а пользоваться только старыми.
Ну прям как c Node.js несколько лет назад, ага.
Вот не стоит путать возможности и инфраструктуру Node.js с .NET, тут опять же не требуется этот колосальный ад из тысяч бибилиотек, чтобы всё работало.
А чего так просто забыли процитировать внедрение зависимостей? Или просто сказать нечего? В том же Angular увы это костыль, а ни как не полноценное внедрение зависимостей. И это то, чего мне не хватает в JS, очень сложно построить внятную архитектуру приложения на JS. Вплоть до того, что не так давно сделал некую альтернативу для нашего проекта, да, стало проще, но всё не получается реализовать все возможности в рамках JS.
Я конечно понимаю, вы фанат JS, но не стоит плевать со своей колокольни, если на другой никогда не были.
Я работал и с .NET и с JS и могу сказать одно, я терпеть не могу JS из-за его низкого порога вхождения, это приводит к появлению кучи низкокачественного кода, им завалено всё, ад из мелких библиотек. Если смотреть на фреймворки типа Angular, даже они крайне слабы в сравнении с платформой .NET, да, я не буду отрицать, что Blazor в начале пути и пока что он не подойдёт для полноценных проектов, но потенциала у него куда больше чем у JS.
В данном случае C# из коробки работает полноценно с модулями, и не требуется уписываться import'ами, чуть более что-то серьёзное и десятки и более строк импортов с кучей функций и компонентов.
И вы, конечно, почему-то считаете это чем-то плохим. Непонятно только, почему.
Опять же шикарная строгая типизация.
В TS не хуже. Я бы вообще сказал, что «лучше», но это вкусовщина, поэтому не буду.
Да и колосальный фреймворк, а не тот ад, что творится в JS, тысячи библиотек в зависимостях. Одну обновили и добавили баг и потом можно неделями искать эту проблему.
Когда вы сами себе злобный буратина, и не имеете тестов, но зато имеете отличную привычку обновлять версии ваших зависимостей просто потому, что вам так захотелось? Конечно.
Вы еще давайте расскажите, как в C# нельзя выстрелить себе в ногу, чтоб мы тут дружно почитали и посмеялись.
Как? Имея кучу гемороя с сорсмапами, когда одни работают в одних условиях, другие в других, при этом скорость компиляции знатно начинает страдать.
Если вы не умеете создавать сорсмапы — честное слово, это не проблема сорсмапов. Это настолько не rocket science, что утверждать, что там всё плохо — это ну очень грустно.
В общем как и JS.
Да нет, не «как». Большинство новых фич языка полифиллится, то есть, таки в итоге работает в старых браузерах. С web assembly всё просто: нет браузерной поддержки? Идите лесом, точка.
А чего так просто забыли процитировать внедрение зависимостей?
Да, пропустил и не заметил. Хвалиться «внедрением зависимостей» — это что-то из серии «а в нашем крутом инструменте можно сделать цикл со счётчиком!». DI тривиально делается в любом приличном языке (и нетривиально, но всё равно делается — в любом тьюринг-полном).
В том же Angular увы это костыль, а ни как не полноценное внедрение зависимостей.
В том же ангуляре это тяжелое наследие, которое изначально было довольно убого реализовано, а теперь так и тянется. Ничего удивительного.
И это то, чего мне не хватает в JS, очень сложно построить внятную архитектуру приложения на JS.
Вот давайте предметно: что такого вы архитектурно можете реализовать на C#, и не можете на JS?
Я конечно понимаю, вы фанат JS, но не стоит плевать со своей колокольни, если на другой никогда не были.
Нет, я не фанат JS. Я просто на нем (да и даже не на нем, а на TS) пишу, и поэтому к высасываемым из пальца аргументам «за Blazor» отношусь очень пренебрежительно. Потому что реальный аргумент тут ровно один: «вы можете сбацать SPA, не вылезая из уютного C#». И после этого следует долгий разговор о цене, которую вы за это заплатите, например, о том, что весь ваш код будет результироваться в немаленькие блобы, которые любой заходящий на вашу страницу будет обязан полностью выгрузить прежде чем у него вообще начнёт хоть что-то работать. И что работать оно всё будет примерно с такой же скоростью, как и на JS.
TS хорош, чертовски хорош, и система типов в нём крутейшая. Проблема у него только одна — JS. Пишешь крутейший типизированный код, а потом как лбом об асфальт врезаешься в какую-нибудь простейшую вещь, которую сделать нельзя, или в какое-то совершенно неочевидное поведение, потому что JS.
В этом смысле C# выигрывает в плане стабильности — да, не так круто, зато гораздо меньше таких вот сюрпризов.
В этом смысле C# выигрывает в плане стабильности — да, не так круто, зато гораздо меньше таких вот сюрпризов.
Пишешь крутейший типизированный код, а потом как лбом об асфальт врезаешься в какую-нибудь простейшую вещь, которую сделать нельзя, или в какое-то совершенно неочевидное поведение, потому что JS.
Давайте я и у вас попрошу конкретики: что такого «простейшего» вы не смогли сделать?
Легко. Вот прямо вчера пример: есть тип discriminated union по строкам, ну например:
type mytype = 'string1' | 'string2' | ...Дальше, имеется строка, полученная с вебсервиса в рантайме. Как проверить, что строка принадлежит этому типу? Быстрое гугление показало, что проще всего сделать массив со всеми валидными строками для типа и использовать его как основу для типа, а проверять через массив. К сожалению, определение типа я изменить не могу, так как он не мой, так что этот способ мне не подходит. Ну и даже этот способ, честно говоря, выглядит костылём.
Как проверить, что строка принадлежит этому типу?
Если вспомнить, что TS и его типов в рантайме не существует — то становится совершенно очевидно, что никак. Вы пытаетесь использовать инструмент не по назначению. Переход от «типов» к «коду в рантайме» силами TS принципиально не возможен.
А если вам просто не хочется писать руками тайпгарды, а хочется, чтоб они «сами» возникали — пользуйтесь автоматикой, типа такой github.com/rhys-vdw/ts-auto-guard. Генерация кода по типам в компайл-тайм — конечно же очень возможна.
Так я и пишу про преимущества/недостатки инструмента.
Действительно, микроскоп имеет тот небольшой недостаток, что гвозди им забивать не очень удобно.
Поясните, где здесь забивание гвоздей микроскопом? Хотите сказать, что TS не предполагает работы с типами? Или работа с типами в рантайме — это какая-то плохая идея? Я лично всегда считал, что это попросту недостаток выбранной реализации (транспиляции в JS).
Хочу сказать, что любая реализация RTTI небесплатна, а RTTI сам по себе практически никогда не является необходимой абстракцией, это скорее «решение для бедных», покрывающее проблемы системы типов конкретного языка, и открывающее бекдоры вида «если нельзя, но очень хочется — тогда таки сделаем».
Типы в рантайме в общем случае просто не нужны. А если имеется некоторый частный случай, в котором просто страсть как хочется — для этого нужно брать соответствующие частные же решения.
Типы в рантайме в общем случае просто не нужны. А если имеется некоторый частный случай, в котором просто страсть как хочется — для этого нужно брать соответствующие частные же решения.
Ну вот у Typescript и есть эти самые проблемы, но нет даже "решения для бедных" в виде RTTI.
RTTI сам по себе практически никогда не является необходимой абстракцией, это скорее «решение для бедных», покрывающее проблемы системы типов конкретного языкаА можете вот это пояснить на моём примере выше? Как бы вы эту задачу решали на языке с хорошей системой типов, но без RTTI?
И что работать оно всё будет примерно с такой же скоростью, как и на JS.
… и даже медленнее, потому что WebAssembly пока что не умеет в прямую интеракцию с DOM, и там будут постоянные пробросы команд WA -> JS -> DOM и обратно.
Ну хорошо, подробнее.
Циклические зависимости, такой беды как это в JS, C, C++ и т.д. тут нет, если в C и C++ это можно решить, то в JS это даже решить адекватно нельзя, ну никак. Вторым пунктом тут идёт снижение объёмов бойлерплейт кода.
Я бы сказал, что хуже. В TS стогая типизация, но если хочется, то будет не строгая. В C# так сделать нельзя, да, там есть тип dynamic, но он не лежит в основе языка, при этом же код даже под dynamic идёт довольно строг. Опять же к системе типов, в JS в общем примерно как и в Java value-type идут только для примитивных типов и никак иначе, в C# этим можно управлять.
Тесты, окей. В JS и даже TS нет адекватной реализации DI и IoC, если в TS хоть какой-то костыль есть, то тут всё плохо, а в содружестве с отсутствием модулей, приходится мокать не просто передаваемые объекты внутрь кода, а приходится мокать импорты, приходится мокать хуки и т.д., что по факту убивает идею юнит-тестов и тестирования чёрного ящика, ибо надо знать внутреннюю реализацию тестируемого кода.
А обновление зависимостей временами требуется как бы, новый функционал, фиксы багов, которых обычно ой как не мало. И что уж делать, если я на пршлой неделе сделал новый проект используя create-react-app и получил десятки ворнингов несоответствия версий. В C# за весь мой опыт такого отстойного отношения к коду я ещё не видел.
Не отрицаю, в C# есть ад зависимостей, но не настолько гигантский как в JS, в .net core при этом ад стал ещё меньше.
Ага, не хочешь по 5-10 минут собирать проект, делаешь послабше сорсмапы, ах да, тут дебаггер не может трейсить код, переключаешься опять на дотошные сорсмапы, ах да, тут понадобилось подрубить css, ой, все стильники в index.js, идёшь, опять меняешь сорсмап и т.д. Это типа всё окей?
Web Assembly — этот как бы что-то похожее на ассемблер. Я не говорил про поддержку DOM, новых стандартов CSS, я тупо говорил про какие-нить функции для работы с данными. startsWith, includes и т.д.
Ну давайте покажите пример тестов вашего кода. И мы уже оценим, реально ли это в рамках JS или не особо. Особенно в условиях, когда JS сейчас тупой и процедурный и даже его крайне костыльные объектная-ориентированность не используется кучей разработчиков, чего стоят хуки реакта. Я уж лучше сделаю сервис, который мне будет IoC контейнер подсовывать сам и я не буду париться, а в тестах я сделаю простой мок. А не буду париться с попытками мокнуть импорт в Jest с кучей проблем.
Ну давайте. React+Redux+Deox+Saga и это только самый базовый набор библиотек. Все подразумевают работу в своём уникальном стиле, у всех сайд эффекты поддерживаются по своему, этим пользоваться можно, но искать код, который нужен в большом проекте задачка уже становится совсем нетривиальной. Приходится использовать кучу разных механизмов, вместо одного.
Ну тут видны консервативные взгляды, тут ключевой момент не C#, а Web Assembly, родная технология для браузеров и вам грустно становится от того, что теперь на C#, который скомпилится в Web Assembly, можно писать родной код для браузеров. И вам обидно, прям как фанатам PS, когда их эксклюзивы уходят на ПК.
И вы, конечно, почему-то считаете это чем-то плохим. Непонятно только, почему.
Циклические зависимости, такой беды как это в JS, C, C++ и т.д. тут нет, если в C и C++ это можно решить, то в JS это даже решить адекватно нельзя, ну никак. Вторым пунктом тут идёт снижение объёмов бойлерплейт кода.
В TS не хуже. Я бы вообще сказал, что «лучше», но это вкусовщина, поэтому не буду.
Я бы сказал, что хуже. В TS стогая типизация, но если хочется, то будет не строгая. В C# так сделать нельзя, да, там есть тип dynamic, но он не лежит в основе языка, при этом же код даже под dynamic идёт довольно строг. Опять же к системе типов, в JS в общем примерно как и в Java value-type идут только для примитивных типов и никак иначе, в C# этим можно управлять.
Когда вы сами себе злобный буратина, и не имеете тестов, но зато имеете отличную привычку обновлять версии ваших зависимостей просто потому, что вам так захотелось?
Тесты, окей. В JS и даже TS нет адекватной реализации DI и IoC, если в TS хоть какой-то костыль есть, то тут всё плохо, а в содружестве с отсутствием модулей, приходится мокать не просто передаваемые объекты внутрь кода, а приходится мокать импорты, приходится мокать хуки и т.д., что по факту убивает идею юнит-тестов и тестирования чёрного ящика, ибо надо знать внутреннюю реализацию тестируемого кода.
А обновление зависимостей временами требуется как бы, новый функционал, фиксы багов, которых обычно ой как не мало. И что уж делать, если я на пршлой неделе сделал новый проект используя create-react-app и получил десятки ворнингов несоответствия версий. В C# за весь мой опыт такого отстойного отношения к коду я ещё не видел.
Вы еще давайте расскажите, как в C# нельзя выстрелить себе в ногу, чтоб мы тут дружно почитали и посмеялись.
Не отрицаю, в C# есть ад зависимостей, но не настолько гигантский как в JS, в .net core при этом ад стал ещё меньше.
Если вы не умеете создавать сорсмапы — честное слово, это не проблема сорсмапов. Это настолько не rocket science, что утверждать, что там всё плохо — это ну очень грустно.
Ага, не хочешь по 5-10 минут собирать проект, делаешь послабше сорсмапы, ах да, тут дебаггер не может трейсить код, переключаешься опять на дотошные сорсмапы, ах да, тут понадобилось подрубить css, ой, все стильники в index.js, идёшь, опять меняешь сорсмап и т.д. Это типа всё окей?
Да нет, не «как». Большинство новых фич языка полифиллится, то есть, таки в итоге работает в старых браузерах. С web assembly всё просто: нет браузерной поддержки? Идите лесом, точка.
Web Assembly — этот как бы что-то похожее на ассемблер. Я не говорил про поддержку DOM, новых стандартов CSS, я тупо говорил про какие-нить функции для работы с данными. startsWith, includes и т.д.
Да, пропустил и не заметил. Хвалиться «внедрением зависимостей» — это что-то из серии «а в нашем крутом инструменте можно сделать цикл со счётчиком!». DI тривиально делается в любом приличном языке (и нетривиально, но всё равно делается — в любом тьюринг-полном).
Ну давайте покажите пример тестов вашего кода. И мы уже оценим, реально ли это в рамках JS или не особо. Особенно в условиях, когда JS сейчас тупой и процедурный и даже его крайне костыльные объектная-ориентированность не используется кучей разработчиков, чего стоят хуки реакта. Я уж лучше сделаю сервис, который мне будет IoC контейнер подсовывать сам и я не буду париться, а в тестах я сделаю простой мок. А не буду париться с попытками мокнуть импорт в Jest с кучей проблем.
Вот давайте предметно: что такого вы архитектурно можете реализовать на C#, и не можете на JS?
Ну давайте. React+Redux+Deox+Saga и это только самый базовый набор библиотек. Все подразумевают работу в своём уникальном стиле, у всех сайд эффекты поддерживаются по своему, этим пользоваться можно, но искать код, который нужен в большом проекте задачка уже становится совсем нетривиальной. Приходится использовать кучу разных механизмов, вместо одного.
Нет, я не фанат JS. Я просто на нем (да и даже не на нем, а на TS) пишу, и поэтому к высасываемым из пальца аргументам «за Blazor» отношусь очень пренебрежительно. Потому что реальный аргумент тут ровно один: «вы можете сбацать SPA, не вылезая из уютного C#».
Ну тут видны консервативные взгляды, тут ключевой момент не C#, а Web Assembly, родная технология для браузеров и вам грустно становится от того, что теперь на C#, который скомпилится в Web Assembly, можно писать родной код для браузеров. И вам обидно, прям как фанатам PS, когда их эксклюзивы уходят на ПК.
Циклические зависимости
Разбиение кода на множество блоков и множество же импортов — никак не равно «циклические зависимости» и даже не способствует им.
Вторым пунктом тут идёт снижение объёмов бойлерплейт кода.
Тот неловкий момент, когда модули называют «бойлерплейтом». А лучше вообще просто фигачить всё в один исполняемый файл, сразу в машинных кодах, а то понапридумывают этого вашего бойлерплейта, а нам писать его.
В TS стогая типизация, но если хочется, то будет не строгая. В C# так сделать нельзя, да, там есть тип dynamic, но он не лежит в основе языка, при этом же код даже под dynamic идёт довольно строг.
Простите, но это пустопорожняя риторика. Я вам точно так же вашими же словами скажу, что «тип any не лежит в основе языка». Про «строгость с dynamic» вообще смешно. Какая «строгость», если компайл-тайм проверки типов к dynamic просто не применяются?
В JS и даже TS нет адекватной реализации DI и IoC
Вы вообще о чём сейчас? Вы говорите о языке с first-class functions, где IoC выражается просто передачей функции в качестве параметра. Рюшечки сверх этого можно навернуть какие угодно самостоятельно или взять готовые. Вы всерьез что ли думаете, что в экосистеме нет решений по IoC с каким угодно произвольным числом наворотов? Есть.
что по факту убивает идею юнит-тестов и тестирования чёрного ящика, ибо надо знать внутреннюю реализацию тестируемого кода
Я уже в который раз замечаю, что вы пишете так, как будто вы недавно узнали много разных баззвордов, но не удосужились узнать их значение. Юнит-тесты по определению основаны на знании внутренней реализации «юнитов» (чем бы они у вас не были).
И что уж делать, если я на пршлой неделе сделал новый проект используя create-react-app и получил десятки ворнингов несоответствия версий.
Create-react-app — не эталон прекрасного кода, а средство для бедных, которые не могут разобраться с тем, что там с чем соединить, чтоб у них проект получился. Не пользуйтесь плохими сторонними решениями, что я вам могу сказать.
React+Redux+Deox+Saga и это только самый базовый набор библиотек.
Это не «базовый набор», а жуткая сборная солянка, которую вы сами же себе устроили, а теперь говорите, что не можете с ней справиться. Не можете — так и не берите. Есть вещи даже проще голого реакта, что уж говорить про попытке собрать стейт-менеджер из всего, что только под руку попало.
И этот же человек выше говорит про «бойлерплейт», а сам пытается писать со стеком, с которым без множества вождений руками вокруг навязываемых архитектур ничего не пишется.
Ну тут видны консервативные взгляды, тут ключевой момент не C#, а Web Assembly, родная технология для браузеров
Вы не удосужились ознакомиться с дорожной картой реализации WA. Там нет «сделаем так, чтоб было удобно сбацать сайтик на C#, C++, Rust, итд», это всего лишь побочный эффект.
WA реализован как механизм подключения в JS числодробилок, и именно в этом плане он работает максимально хорошо. Использование WA в других контекстах — связано с солидным объемом проблем. В первую очередь с большими блобами, которые к тому же не дают никакого преимущества по скорости работы страницы.
Я вообще нахожу очень забавным, что всё те же самые люди, которые при случае всегда любят пнуть JS за «сайты стали толстыми, надо грузить мегабайты JSа» — в разговорах о web assembly всегда помалкивают о том, сколько там юзеру придётся грузить скомпилированного кода.
Не можете — так и не берите. Есть вещи даже проще голого реакта, что уж говорить про попытке собрать стейт-менеджер из всего, что только под руку попало.
Ээээ, тут только одна State-magament либа и это Redux. А всё остальное, это лишь необходимость для исправления архитектурных проблем этого самого Redux. Ну и контексты реакта, спасибо, не надо, для калькулятора хватит, а вот посерьёзнее проект не переживёт, особенно если хочется к примеру Redu/Undo добавить.
Вы не удосужились ознакомиться с дорожной картой реализации WA.
Я в курсе что такое WA и как оно работает. И WA так или иначе родная для браузеров технология, тут уже какое-то словоблудие начинается.
Использование WA в других контекстах — связано с солидным объемом проблем. В первую очередь с большими блобами, которые к тому же не дают никакого преимущества по скорости работы страницы.
Как бы часто неподконтрольные перерисовки, а и часто ненужные перерисовки со стороны React как бы не даёт никакого преимущества по скорости работы.
Ну и хватит кормить тролля. Уже все ваши доводы скатились до уровня Страуструпа, когда он был против тех или иных пропосалов в новые стандарты C++. «А это ведь можно вот так сделать» и выдаёт раз в 5-10 больше кода. Да, можно, но зачем? Если можно сделать проще, если можно не заботиться о проблемах, если уже есть готовые решения. Зачем страдать? Но вот все ваши доводы уже скатились до уровня: Можно ведь и пострадать. Развитие ЯП сводится не к удовлетворению вашего эго, а к снижению трудозатрат. И blazor это может дать. А если уж у разработчиков не хватит ума-разума, чтобы это понять, это не вина платформы, увы.
А всё остальное, это лишь необходимость для исправления архитектурных проблем этого самого Redux.
Ну так и что вам мешает не брать редакс, раз он такой плохой?
Как бы часто неподконтрольные перерисовки, а и часто ненужные перерисовки со стороны React как бы не даёт никакого преимущества по скорости работы.
Если вы не в состоянии совладать с «неподконтрольными» перерисовками в реакте, почему стоит ожидать, что у вас в blazor будет всё лучше?
Можно ведь и пострадать.
А, изучение подходящих инструментов у вас теперь называется «можно пострадать». Ну, бывает. А не страдать — это, видимо, пользоваться как можно большим количеством текущих абстракций, и все протечки молча игнорировать. Блобы большие? Ну так это не наша проблема, у нас всё скомпилировалось же и работает. Пускай либы сишарпа в сам браузер положат, авось поменьше станут ;-) Работает небыстро? Пускай делают нативный доступ к DOM из WA, а потом это в каком-нибудь blazor реализовывают, а мы тут не при чём ;-)
НЛО прилетело и опубликовало эту надпись здесь
А если вы знали js то само собой для вас ничего не поменяется и blazor вам не нужен и преимуществ нет никаких
Вы, собственно, сами выложили единственное преимущество, которое тут есть. «Не надо учить этот ваш мерсссский JS».
НЛО прилетело и опубликовало эту надпись здесь
Вообщем суть Blazor в том что бэкендеру на C# будет проще работать с фронтом не изучая JS
НЛО прилетело и опубликовало эту надпись здесь
Программисты: "любой уважающий себя разработчик должен разбираться в платформе, а не просто быть тупо писателем на фреймворке"
Те же программисты когда речь заходит о Web UI: "не хочу разбираться с JS/HTML/CSS, хочу собирать из готовых компонентиков"
P.S. это адресовано не вам напрямую, Kanut79, просто мысли на тему.
НЛО прилетело и опубликовало эту надпись здесь
Вообще-то с Blazor идет довольно толстый Javascript-рантайм для обертки DOM API, поэтому без Javascript все-таки не обойтись, просто в данной ситуации он написан не вами.
НЛО прилетело и опубликовало эту надпись здесь
И на мой взгляд чтобы например на TypeScript'e писать, в JS разбираться тоже совсем не обязательно надо.
Учитывая, что TS представляет собой JS с типами — ну да, конечно, совсем не надо.
Никак. Любой человек, привыкший к типизированным языкам, очень быстро столкнется с тем фактом, что при запуске все типы TS исчезают и приходится иметь дело с JS.
НЛО прилетело и опубликовало эту надпись здесь
Если речь про C#, там для объектов сохраняются метаданные, и в рантайме можно получить тип объекта.
НЛО прилетело и опубликовало эту надпись здесь
Ровно до тех пор, пока вы в рантайме не попытаетесь получить тип какого-нибудь объекта и получите Object вместо имени класса.
Это кстати важный вопрос итогового размера приложения.
Может Вам известно, сколько занимает рантайм? И есть ли в инструментарии что-то вроде tree-shaking?
Вот есть такой пример, вроде более-менее популярный: https://blazorboilerplate.com/
Там загружается 700 Кб JS, 1.9 Мб WASM и 7.7 Мб dll-ок (то есть больше 10 Мб в сумме).
И судя по этому тикету, это считается нормой и Tree-shaking не предусмотрен. Хотя, я не настоящий сварщик, может что-то и поменялось с момента создания тикета.
первая картинка полностью показывает что делает любой инструмент с блэйзером
Ещё у Blazor клиент-серверное взаимодействие построено на WebSocket, с соответствующими ограничениями. Например аплоад файлов тоже через вебсокеты, и оказывается медленнее, потому что надо пилить файл на части, которые пролезут через буферы вебсокета. Ну либо завести параллельный Blazor’у механизм аплоада
Это если используется Blazor Server. А в Blazor Wasm нет особо ограничений на connectivity. Хоть json'ы на бэк гоняйте, хоть большие файлы.
Да вообще-то никто не запрещает использовать другие механизмы. Ыыыы, откуда вообще это взяли-то? Вообще-то есть IHTTPClient, что использует Fetch API.
Вот отсюда взял. Автор пишет:
It’s entirely expected that <InputFile> takes ~30% longer than native HTTP uploads, because it has to base64 encode the data since IJSRuntime only allows JSON responses.
Там речь о plain-blazor аплоаде без внешних сервисов. Как выше отметили, это для Blazor Server, для Blazor Wasm ситуация может быть иной. Но я когда я смотрел Blazor я смотрел на Blazor Server, а не Wasm.
В Блейзор-сервер размер буфера настраиваемый. И скачиваю и загружаю файлы по 200 мгб (зип) и скорость, в моем случае в 2.7 раза выше по стравнению с http.
Кажется с Google Web Toolkit мы уже это проходили
Очень бестолковая статья. Заявленного в заголовке сравнения по сути нет, в основном вода.
НЛО прилетело и опубликовало эту надпись здесь
потому что все использую vue + .net webapi =)
Есть точно такое же по качеству сравнение с Vue.js:
www.telerik.com/blogs/blazor-vs-vue-web-developers
Игнорируют большинство классных фишек Vue — SFC, динамическая загрузка компонентов и вьюх, Composition API.
Имхо, на Blazor имеет смысл смотреть только если вы .NET разработчик которому внезапно нужно делать фронтенд для внутреннего продукта, или что-то еще что с реальным интернетом не пересекается. Где не важен пользовательский опыт, SEO и энергопотребление.
www.telerik.com/blogs/blazor-vs-vue-web-developers
Игнорируют большинство классных фишек Vue — SFC, динамическая загрузка компонентов и вьюх, Composition API.
Имхо, на Blazor имеет смысл смотреть только если вы .NET разработчик которому внезапно нужно делать фронтенд для внутреннего продукта, или что-то еще что с реальным интернетом не пересекается. Где не важен пользовательский опыт, SEO и энергопотребление.
Система обнадеживающая, и в перспективе можно свести работу с js к минимуму, но на данный момент система компонентов из коробки довольно бедна, часть стандартного браузерного js api пропущена и приходится писать отсутсвующий функционал на js и через IJSRuntime дергать это.
Теоретически популярность Blazor облегчит жизнь тем .NET разработчикам, которых компания заставляет быть фулстеками и им приходится кроме довольно объемной экосистемы .NET также держать в голове не менее объемную экосистему JS. Это утомляет)
Теоретически популярность Blazor облегчит жизнь тем .NET разработчикам, которых компания заставляет быть фулстеками и им приходится кроме довольно объемной экосистемы .NET также держать в голове не менее объемную экосистему JS. Это утомляет)
Тема Blazor-а мне довольно интересна, но соглашусь с тем, что статья ни о чём.
Во-первых, почему-то не проставлены хабы Net или C#, читателям которых Blazor как раз должен быть наиболее интересен.
Во-вторых, не увидел нормального сравнения по возможностям. Пробежался по статье пару раз и даже не могу нормально удерживать в голове, о чём в ней идёт речь. Нужны таблички со списком фич и пометками имеет/не имеет эту фичу конкретный фреймворк.
В-третьих, ну и выкладки про замену, как по мне, немного бредовы. Заменить js-фреймворки Blazor может только для net-программистов.
Для меня лично, как делающего на фронте всякую стандартную работу с табличка плюс украшательства, радует, что можно будет нормально отлаживать сразу весь проект в Студии, не мучаясь с отладчиком в браузере. Точки остановки, переменные вот этот вот всё. Ну и совместимость типов, когда не нужно будет страдать с тем, что JS криво парсит DateTime. А волнует прежде всего насколько это всё будет быстро работать.
Во-первых, почему-то не проставлены хабы Net или C#, читателям которых Blazor как раз должен быть наиболее интересен.
Во-вторых, не увидел нормального сравнения по возможностям. Пробежался по статье пару раз и даже не могу нормально удерживать в голове, о чём в ней идёт речь. Нужны таблички со списком фич и пометками имеет/не имеет эту фичу конкретный фреймворк.
В-третьих, ну и выкладки про замену, как по мне, немного бредовы. Заменить js-фреймворки Blazor может только для net-программистов.
Для меня лично, как делающего на фронте всякую стандартную работу с табличка плюс украшательства, радует, что можно будет нормально отлаживать сразу весь проект в Студии, не мучаясь с отладчиком в браузере. Точки остановки, переменные вот этот вот всё. Ну и совместимость типов, когда не нужно будет страдать с тем, что JS криво парсит DateTime. А волнует прежде всего насколько это всё будет быстро работать.
НЛО прилетело и опубликовало эту надпись здесь
Blazor позволяет использовать модели и логику их валидаций с прямо из класса, используемом на сервер. Это помогает не получать ошибки в стиле «на сервере принимается число, а клиент отправляет строку»
Эти ошибки и на Ангуляре получать не обязательно, есть же swagger. Бонусом на бэк идёт веб-клиент, позволяющий "прокликать" API до передачи на фронт.
Вот какие ошибки действительно устраняются таким образом — так это ошибки несогласованности бизнес-логики в доменных объектах.
Соглашусь со многими, что практически бесполезная статья (пожалуй, кроме комментов к ней) — содержит самые поверхностные начальные сведения, которые и так практически везде куда не ткни по blazor.
Как c# программисту, который не хочет/ленится изучать react/angular/vue… искал в этой статье такие сведения:
Если кто в курсе, то буду признателен за инфу.
Как c# программисту, который не хочет/ленится изучать react/angular/vue… искал в этой статье такие сведения:
- Как сравнение сколько весят на клиенте js фреймворки, а сколько blazor (для последнего, с одной стороны, мельком слыхал, что очень много, а с другой, что можно сильно оптимизировать).
- Как поддержка многопоточности у blazor (мелькала инфа, что с этим вроде есть какие-то проблемы).
Если кто в курсе, то буду признателен за инфу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сравнение Blazor и JavaScript-инструментов