Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется.
Следует ли на нее внимание обратить или, памятуя о, например, судьбе Windows Phone, лучше все же учить JS/TS?
И вообще касаемо WebAssembly, наверное оно все-таки взлетит, может быть есть смысл учить что-то перспективное типа Rust? Ведь наверняка появятся какие-то удобные фреймворки для веба под Rust (а может и уже есть).
Здравствуйте, vl690001x2, Вы писали:
V>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется.
Так вроде же автор и основной контрибютор – Майкрософт. Можно сразу закопать
Здравствуйте, Shmj, Вы писали:
S>Никто не знает. WebAssembly уже давно ждем, но что-то пока не видно множества вакансий по нему, что как бы намекает...
Ну, меня вакансии мало волнуют... Мне просто например скажут — сделай сайт, а я уже сам буду думать на чем делать. Т.к. фриланс. Хотелось бы просто расшириться в сторону веба, наиболее бескровным способом.
Здравствуйте, kaa.python, Вы писали:
V>>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется.
KP>Так вроде же автор и основной контрибютор – Майкрософт. Можно сразу закопать
Напомнить кто основной контрибьютор в TypeScript? Что-то пока у закапывальщиков TS лопаты затупились.
Здравствуйте, vl690001x2, Вы писали:
V>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется.
Ошибаетесь: Blazor позволяет убрать JS из логики приложения. Совсем без него обойтись... можно, если используешь готовые компоненты. Если же нужно дописать что-то своё, то где-то что-то может всплыть. У меня пока две задачи для JS возникли — перехват нажатий клавиш со всего документа (body onkeydown) и фокусировка ввода на элементах. То есть вобщем-то минимум, но представление в js иметь всё-же стоит.
V>Следует ли на нее внимание обратить или, памятуя о, например, судьбе Windows Phone, лучше все же учить JS/TS?
У меня в целом ощущение, что Blazor пока для интранет-приложений, причём что в виде WebAssembly, что в сервеном. Для общедоступных приложений нужно точно представлять что ты хочешь получить и зачем для этого использовать именно WA.
Но вот программировать на Blazor, особенно в серверном варианте — просто удовольствие.
Здравствуйте, Somescout, Вы писали:
S>Здравствуйте, vl690001x2, Вы писали:
V>>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется. S>Ошибаетесь: Blazor позволяет убрать JS из логики приложения. Совсем без него обойтись...
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Но вот программировать на Blazor, особенно в серверном варианте — просто удовольствие.
НС>А зачем в серверном варианте WebAsm?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>>>А зачем в серверном варианте WebAsm? S>>А он там и не используется. НС>Отож. Поэтому когда технология, которая изначально создавалась для WebAsm, лучше выглядит без WebAsm — это много говорит про полезность WebAsm.
Там не в полезности WebAsm дело — в серверном варианте Blazor работает совсем в другом режиме, получается что-то вроде веб-терминала, например вам нужно при отрисовке страницы сделать запрос к базе — просто делаете запрос к базе (var result = await dbContext.SomeTable.Where(...).ToListAsync()). Нужно постучаться в AD — без проблем. Нужно подписаться на RabbitMQ — да вперёд и с песней. Не нужно строить никаких API, нет даже потенциальных проблем с безопасностью (все данные, весь контент сессии существует только на сервере, клиент получает только то, что он должен отобразить) — просто и удобно. То есть удобство серверного Блазора именно в том, что он серверный, а не в отсутствии/наличии WebAsm.
Здравствуйте, Somescout, Вы писали:
S>Там не в полезности WebAsm дело — в серверном варианте Blazor работает совсем в другом режиме, получается что-то вроде веб-терминала, например вам нужно при отрисовке страницы сделать запрос к базе — просто делаете запрос к базе (var result = await dbContext.SomeTable.Where(...).ToListAsync()).
Я в курсе. Этой идее сто лет в обед, оно еще в вебформсах присутствовало. Но топик то больше про WebAsm.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Somescout, Вы писали:
S>>Там не в полезности WebAsm дело — в серверном варианте Blazor работает совсем в другом режиме, получается что-то вроде веб-терминала, например вам нужно при отрисовке страницы сделать запрос к базе — просто делаете запрос к базе (var result = await dbContext.SomeTable.Where(...).ToListAsync()).
НС>Я в курсе. Этой идее сто лет в обед, оно еще в вебформсах присутствовало. Но топик то больше про WebAsm.
А какой смысл тогда был в заявлении "...это много говорит про полезность WebAsm"? Я не заявлял о его бесполезности, просто упомянул что программировать в серверном варианте очень приятно.
V>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется. V>Следует ли на нее внимание обратить
Не стоит. Потому что для того, чтобы работать, он сначала загружает в браузер половину .net рантайма, а потом только начинает работать. Такие проекты хороши для очень узких сфер применения. Например, какие-нибудь корпоративные интранеты.
V> И вообще касаемо WebAssembly, наверное оно все-таки взлетит, может быть есть смысл учить что-то перспективное типа Rust? Ведь наверняка появятся какие-то удобные фреймворки для веба под Rust (а может и уже есть).
Учить можно все, что угодно. К WebAsm'у это имеет ортогональное отношение. Потому что WebAsm в текущей его реализации и в ближайшем будущем ничего тебе не даст.
Здравствуйте, Mamut, Вы писали:
V>>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется. V>>Следует ли на нее внимание обратить
M>Не стоит. Потому что для того, чтобы работать, он сначала загружает в браузер половину .net рантайма, а потом только начинает работать.
Там весело: они просто взяли из моно интерпретатор байткода, и этот интерпретатор, скомпиленный в васм, загружают. Получается в 50 раз медленнее обычного дотнета. Над нормальной AOT компиляцией из дотнета прямо в васм вроде работают, но как обычно ожидаемо уперлись в GC, пока работает лишь пример с рендерингом картинки, где с памятью работать и освобождать не надо.
M>Не стоит. Потому что для того, чтобы работать, он сначала загружает в браузер половину .net рантайма, а потом только начинает работать. Такие проекты хороши для очень узких сфер применения. Например, какие-нибудь корпоративные интранеты.
V>> И вообще касаемо WebAssembly, наверное оно все-таки взлетит, может быть есть смысл учить что-то перспективное типа Rust? Ведь наверняка появятся какие-то удобные фреймворки для веба под Rust (а может и уже есть).
M>Учить можно все, что угодно. К WebAsm'у это имеет ортогональное отношение. Потому что WebAsm в текущей его реализации и в ближайшем будущем ничего тебе не даст. https://habr.com/ru/company/microsoft/blog/473172/
Ну рассматриваются разные сценарии и неизвестно, что будет когда выйдет
Blazor WebAssembly пока находится в превью и еще не готов к использованию. Если вы ищете готовое к работе решение, то мы рекомендуем Blazor Server.
После выпуска Blazor WebAssembly (май 2020 г.) он позволит запускать компоненты Razor и код .NET в браузере на устройстве пользователя.
Q: Wouldn't the app download size be huge if it also includes a .NET runtime?
Not necessarily. .NET runtimes come in all shapes in sizes. Early Blazor prototypes used a compact .NET runtime (including assembly execution, garbage collection, threading) that compiled to a mere 60KB of WebAssembly. Blazor now runs on Mono, which is currently significantly larger, but opportunities for size optimization abound, including merging and trimming the runtime and application binaries. Other potential download size mitigations include caching and using a CDN.
Что дальше с Blazor?
После выпуска Blazor WebAssembly мы планируем расширить Blazor для поддержки не только веб-приложений, но и Progressive Web Apps (PWA), гибридных приложений и даже полностью нативных приложений.
Blazor PWA: PWA — это веб-приложения, использующие новейшие веб-стандарты для обеспечения более нативного взаимодействия. PWA могут поддерживать автономные сценарии, push-уведомления и интеграции с ОС, такие как поддержка закрепления приложения на главном экране или в меню «Пуск» Windows.
Blazor Hybrid: гибридные приложения — это встроенные приложения, использующие веб-технологии для пользовательского интерфейса. Примеры включают приложения Electron и мобильные приложения, которые отображаются в веб-представлении. Гибридные приложения Blazor не запускаются на WebAssembly, а вместо этого используют собственную среду выполнения .NET, например .NET Core или Xamarin. Вы можете найти экспериментальный образец использования Blazor с Electron на GitHub.
Blazor Native: приложения Blazor сегодня рендерят HTML, но вместо этого средство рендеринга можно заменить на отображение нативных элементов управления. Приложение Blazor Native изначально запускается на устройствах и использует общую абстракцию пользовательского интерфейса для визуализации нативных элементов управления для этого устройства. Это очень похоже на то, как сегодня работают фреймворки, такие как Xamarin Forms или React Native.
Эти три новинки в настоящее время являются экспериментальными. Мы ожидаем официального анонса поддержки приложений Blazor PWA и Blazor Hybrid с использованием Electron в период .NET 5 (ноябрь 2020 г.). Пока еще нет дорожной карты для поддержки Blazor Native, но это область, которую мы активно исследуем.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, vl690001x2, Вы писали:
V>Следует ли на нее внимание обратить или, памятуя о, например, судьбе Windows Phone, лучше все же учить JS/TS?
Если цель — работу работать, то лучше JS/TS. Если цель — знакомиться с новинками, можно и покопаться. Ключевой вопрос — чем это лучше текущих вариантов? Например Java компилируется в JavaScript уже лет 10, если не больше (GWT).
V>И вообще касаемо WebAssembly, наверное оно все-таки взлетит, может быть есть смысл учить что-то перспективное типа Rust? Ведь наверняка появятся какие-то удобные фреймворки для веба под Rust (а может и уже есть).
Этого никогда не будет. Rust всегда будет менее удобен, чем другие ЯП из-за отсутствия GC. Поэтому, если только у тебя не очень необычные задачи, для веб-разработки не советую туда лезть.
Хотя язык очень крутой и выучить его стоит.
Если хочешь что-то выучить, обрати внимание на Flutter. Фиг его знает, взлетит или нет, но технология очень многообещающая и уже набрала большую популярность.
Здравствуйте, Mamut, Вы писали:
S>> Ну рассматриваются разные сценарии и неизвестно, что будет когда выйдет
M>Именно. Preview Blazor'а, который работает в MVP WebAssembly, и кто-то всерьез хочет задаться вопросом «стоит ли изучать»?
Изучать то стоит. Тот же серверный вариант уже работает, а переключиться на WebAssembly там изменить настройки https://docs.microsoft.com/ru-ru/aspnet/core/blazor/hosting-models?view=aspnetcore-3.0
Для комфортной работы с blazor для интернет проектов требуется LazyLoading. Который обещают добавить в ближайшем будущем
V Размеры файлов и linker
Как мы видим на примере размеры загружаемых данных сайта достаточно небольшие 2.4MB (после распаковки на клиенте 5.4MB). При первой загрузке сайта происходит загрузка требуемых DLL для работы сайта (пример как загрузка JS библиотек), в последствии они повторно не перезагружаются, а используются из кеша браузера.
Так же следует обратить внимание на то что используется linker. Это позволяет уменьшить размер итоговых dll файлов, то есть из файлов автоматически вырезаются неиспользуемые коде функции.
Например, System.Text.Json.dll из 288КБ стал размером 114 КБ, а System.Memory.dll из 146КБ стал 58.5КБ. Это обеспечивается и за счет работы linker’а и так же за счет сжатия передаваемых файлов.
и солнце б утром не вставало, когда бы не было меня