Смотрю, появилась новая технология — 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’а и так же за счет сжатия передаваемых файлов.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Mamut, Вы писали:
S>>Как мы видим на примере размеры загружаемых данных сайта достаточно небольшие 2.4MB M>В какой вселенной это считается «достаточно небольшим» для сайта?
В этой. Это примерно одна загрузка страницы на каком-нибудь новостном сайте, скорее всего даже меньше.
S>В этой. Это примерно одна загрузка страницы на каком-нибудь новостном сайте, скорее всего даже меньше.
Даже в этой вселенной каждый первый говорит и считает, что столько загружать — это ненормально.
Итого:
— технология в preview
— загружает столько, сколько рекомендовано в worst practices
— для комфортной работы требуется еще что-то, чего пока нет, но «появится в будущем»
Здравствуйте, Mamut, Вы писали:
S>>В этой. Это примерно одна загрузка страницы на каком-нибудь новостном сайте, скорее всего даже меньше. M>Даже в этой вселенной каждый первый говорит и считает, что столько загружать — это ненормально.
According to httparchive the average web page size in 2017 was 3 MB. This is a huge increase from the 1.6 MB average of 2014. It is predicted that the average page size will be 4 MB by 2019. According to Pingdom's Average Webpage in 2017 report, an average 819 KB was dedicated to video and 1,818 KB for images.
источник
M>Итого: M>- технология в preview
Да, и что? M>- загружает столько, сколько рекомендовано в worst practices
Врёте M>- для комфортной работы требуется еще что-то, чего пока нет, но «появится в будущем»
Да уже можно использовать.
M>Но «изучать-то стоит». M>На.фи.га? То есть — зачем изучать?
Я не агитирую за изучение. Мне технология понравилась — изучаю и пользуюсь. Если вы не хотите её изучать — ваше дело, мне на это как-то наплевать.
M>>Даже в этой вселенной каждый первый говорит и считает, что столько загружать — это ненормально. S>
According to httparchive the average web page size in 2017 was 3 MB. This is a huge increase from the 1.6 MB average of 2014. It is predicted that the average page size will be 4 MB by 2019. According to Pingdom's Average Webpage in 2017 report, an average 819 KB was dedicated to video and 1,818 KB for images.
Где-то в этом источнике говорится, что это нормально, что это мало, и что к этому нужно стремиться?
M>>Итого: M>>- технология в preview S>Да, и что?
И то. Нафига изучать?
M>>- загружает столько, сколько рекомендовано в worst practices S>Врёте
Обоснованный аргумент, да.
M>>- для комфортной работы требуется еще что-то, чего пока нет, но «появится в будущем» S>Да уже можно использовать.
Ага. Preview, для комфортной работы нужно что-то, чего нет (видимо пока что работа не комфортно)
M>>На.фи.га? То есть — зачем изучать? S>Я не агитирую за изучение. Мне технология понравилась — изучаю и пользуюсь.
Я уже пять раз спросил: зачем ее изучать? Пока что ни одного внятного ответа кроме ссылок на то, что это preview, что она гоняет 3 мегабайта данных только чтобы заработать, и т.п.
Здравствуйте, Somescout, Вы писали:
S>Напомнить кто основной контрибьютор в TypeScript? Что-то пока у закапывальщиков TS лопаты затупились.
Да что-то так себе аргумент, надо на динамику смотреть, а не на единичные проекты. И динамика говорит о том, что связываться с поделиями МС себе дороже
Здравствуйте, vl690001x2, Вы писали:
V>Ну, меня вакансии мало волнуют... Мне просто например скажут — сделай сайт, а я уже сам буду думать на чем делать. Т.к. фриланс. Хотелось бы просто расшириться в сторону веба, наиболее бескровным способом.
А здесь очень простая связь — если технология пригодна для реальных проектов, если в ней есть смысл и перспективы — то софто-девелоперские конторы об этом узнают быстрее вас и будут приглашать людей на эту технологию. Все просто.
Здравствуйте, kaa.python, Вы писали:
S>>Напомнить кто основной контрибьютор в TypeScript? Что-то пока у закапывальщиков TS лопаты затупились.
KP>Да что-то так себе аргумент, надо на динамику смотреть, а не на единичные проекты. И динамика говорит о том, что связываться с поделиями МС себе дороже
Здравствуйте, Mamut, Вы писали:
M>Где-то в этом источнике говорится, что это нормально, что это мало, и что к этому нужно стремиться?
А где вы подтвердили хоть каким-то источником, кроме ИМХО, что это много или worst practice? Не говоря уж о том, что речь о SPA, для которых первоначальная загрузка вообще не критична, потому что в дальнейшем они общаются только с сервисами.
M>>>Итого: M>>>- технология в preview S>>Да, и что? M>И то. Нафига изучать?
Не изучайте.
M>>>- загружает столько, сколько рекомендовано в worst practices S>>Врёте M>Обоснованный аргумент, да.
Вы так и не привели хоть какого-то подтверждения своего утверждения. Так что да, более чем обоснованный.
M>>>- для комфортной работы требуется еще что-то, чего пока нет, но «появится в будущем» S>>Да уже можно использовать. M>Ага. Preview, для комфортной работы нужно что-то, чего нет (видимо пока что работа не комфортно)
Я сейчас не совсем понимаю о чём вы. Конкретизируйте.
M>>>На.фи.га? То есть — зачем изучать? S>>Я не агитирую за изучение. Мне технология понравилась — изучаю и пользуюсь.
M>Я уже пять раз спросил: зачем ее изучать? Пока что ни одного внятного ответа кроме ссылок на то, что это preview, что она гоняет 3 мегабайта данных только чтобы заработать, и т.п.
А я вам уже ответил: я не агитирую за изучение, так что разрешаю вам не изучать.
M>Ответа зачем так и не последовало.
Последовал, просто вы чего-то другого видимо ждёте.
Здравствуйте, vl690001x2, Вы писали:
V>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS.
Это примерно как ORM делают ненужными знание SQL. Ага, конечно.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vl690001x2, Вы писали:
V>>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. C>Это примерно как ORM делают ненужными знание SQL. Ага, конечно.
WebAssembly не транслируется в JavaScript (как например, TypeScript), но где-то сбоку можно прикрутить и JS там. Но именно сбоку.
Высокая средняя скорость передачи данных — от 1 Гб/с
Среднее количество одновременных подключений — 1 млн на км²
Задержка — до 1 мс
да и 4G до 150 Мбит/с.
А для стекловолокна это вообще незаметно. Причем это все кэшируется и при последующих вызовах не скачивается.
А если посмотреть на некоторые сайты, которые отжирают как память так и время процессора и то сколько данных гоняют, то 2мб это совсем немного
и солнце б утром не вставало, когда бы не было меня
Последний релиз был 2 года назад, на официальном сайте никаких новостей/блогов/планов/роадмапов, тренд постепенно уходит в ноль... Дохл?
"Больше 100кмч можно ехать на автобане в любом ряду кроме правого крайнего" (c) pik
"В германии земля в частной собственности" (c) pik
"Закрывать школы, при нулевой смертности среди детей и подростков, это верх глупости" (c) Abalak
Здравствуйте, Аноним931, Вы писали:
vsb>>(GWT)
А>Последний релиз был 2 года назад, на официальном сайте никаких новостей/блогов/планов/роадмапов, тренд постепенно уходит в ноль... Дохл?
Насколько знаю, он используется в гугле в критических продуктах, поэтому умереть в обозримом будущем вряд ли сможет. Я так думаю, просто развился до нужного уровня и всё. А так да, скорей всего будет постепенно уходить в прошлое. Хотя использовать можно.
Здравствуйте, vl690001x2, Вы писали:
V>>>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. C>>Это примерно как ORM делают ненужными знание SQL. Ага, конечно. V>WebAssembly не транслируется в JavaScript (как например, TypeScript), но где-то сбоку можно прикрутить и JS там. Но именно сбоку.
А без разницы. Всё равно JS учить придётся для реального программирования.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, vl690001x2, Вы писали:
V>>>>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. C>>>Это примерно как ORM делают ненужными знание SQL. Ага, конечно. V>>WebAssembly не транслируется в JavaScript (как например, TypeScript), но где-то сбоку можно прикрутить и JS там. Но именно сбоку. C>А без разницы. Всё равно JS учить придётся для реального программирования.
Здравствуйте, Sharov, Вы писали:
V>>>WebAssembly не транслируется в JavaScript (как например, TypeScript), но где-то сбоку можно прикрутить и JS там. Но именно сбоку. C>>А без разницы. Всё равно JS учить придётся для реального программирования. S>typescript же
Один фиг.
По мне так опять тупиковая технология. Умрёт примерно так же как и сильверлайт, по большому счёту не успев родиться.
Несколько месяцев назад пробовал — при первой загрузке страницы шла выкачка чего-то там размером то ли полмега, то ли целого мега. Думается эта особенность, будет сдерживающим фактором в распространении технологии.
Мне кажется подход Netjs гораздо интересней.
Если кратко, парадигма такая: C# -> TS -> JS
Жаль проект не развивается
Здравствуйте, vl690001x2, Вы писали:
V>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется. V>Следует ли на нее внимание обратить или, памятуя о, например, судьбе Windows Phone, лучше все же учить JS/TS?
Здравствуйте, vl690001x2, Вы писали:
V>WebAssembly не транслируется в JavaScript (как например, TypeScript), но где-то сбоку можно прикрутить и JS там. Но именно сбоку.
Нет, но блэйзор это именно компоненты, которые так или иначе используют вызовы(подписка на события html-элементов и т.п.).
wasm нужен для решения сложных вычислительных задач, а тут его использует как часть UI-фреймворк. Это-то и смущает!
Здравствуйте, vl690001x2, Вы писали:
V>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется. V>Следует ли на нее внимание обратить или, памятуя о, например, судьбе Windows Phone, лучше все же учить JS/TS? V>И вообще касаемо WebAssembly, наверное оно все-таки взлетит, может быть есть смысл учить что-то перспективное типа Rust? Ведь наверняка появятся какие-то удобные фреймворки для веба под Rust (а может и уже есть).
А что хорошего в том, что на современных web gui франт end-ах используется много всяких разных не самых удобных и очень быстро меняющихся фреймворков? Мало того, что Blazor позволяет абстрагироваться от всех этих JS библиотек, так еще DevExpress XAF позволяет абстрагироваться от разных Microsoft абстракций в том смысле, что XAF позволяет легко переключаться между рендерингом в WebForms, WinForms и скоро Blazor, особо не вдаваясь в подробности программирования под эти фреймворки (по крайне мере если не планируется писать свои расширения для XAF).
Вместо того, чтобы изучать 100500 JS фреймворков можно изучить один раз DevExpress XAF и потом даже при появлении новой реинкарнации Microsoft Web GUI из эпохи пост Blazor, вы просто переключите используемый движок отображения в XAF, а унифицировать движки и приводить их к общему знаменателю будут проф. разработчики DevExpress. А вы вместо того, чтобы выжигать кодом новой очередной надстройки Microsoft (не говоря уж о многих JS фреймворках) свои глаза можете лишний раз отдохнуть или почитать о новых фичах XAF, которые максимально абстрагированны от реализаций фреймворков, т.е. чтиво будет скорее всего про улучшение бизнес логики, взаимодействия и интеграции различных частей XAF.
С моей точки зрения то, что происходит с развитием разных JS библиотек в целом можно сравнить лишь с хаотичным слабопредсказуемым броуновским движением. Microsoft же поверх в том числе них или с их использованием рождает 1 раз в каждые 5-10 лет свой новый революционный фреймворк после того, как он из состояния research переходит в статус production ready, например: ASP.NET WebForms -> ASP.NET MVC -> ASP.NET Core -> Blazor.
DevExpress XAF в свою очередь позволяет вам вообще расслабиться и плыть по течению, не напрягаясь и не отвлекаясь на все эти изменения.
безусловно он тоже развивается достаточно динамично, но не революционно как новые стэки Microsoft, а эволюционно как бы сглаживая для вас все переходы и неровности, возникающие на вашем пути по вине революционных изобретений Microsoft и в отрасли в целом, вы как бы двигаетесь по прямой в одном и том же направлении без каких либо для вас отклонений и значительных переучиваний, только доучиваете переодические дельты нового причем обычно в управлении бизнес логикой, а не с нуля(самого начала) формошлепство новым способом как в случае MS или еще хуже роя рандомных низкоуровневых JS фреймворков.
дело не в качестве кода и не в масштабе проекта. В этих проектах люди в принципе писали не нужный код. При разработке учетной и/или аналитической системы решаются типовые задачи: разрабатывается модель данных, делаются формочки для работы с данными, делаются разные процедуры преобразования данных (импорт, экспорт, ETL), делается API, интеграция с другими системами, генерация документов и отчетов и т.п. В XAF, по крайней мере, всё что касается пользовательского интерфейса, разграничения прав доступа, простеньких инструментов для аналитики, для генерации документов и т.п. уже реализовано. В тех проектах люди 90% времени тратили на эту бессмысленную рутину, а я 90% времени тратил на модель данных, на нетиповую функциональность. В итоге практически весь код, который они годами писали просто выкидывается. Но это работает не на любом проекте, XAF ускоряет работу раз в 50 только при создании учетных систем (включая CRM, ERP и т.п.).
Использовать более низкоуровневые, чем XAF фреймворки IMHO имеет смысл только если у вас большая нагрузка, популярное внешнее public веб приложение, потому что по отзывам XAF не тянет больше сотни одновременных клиентов. Не исключаю, что админ может попытаться оптимизировать это до нескольких сотен, но порядок, наверно остается тот же, по крайне мере пока XAF не позволяет балансировать нагрузку между несколькими микросервисами.
Кстати, а вам не кажется, что использование клиентского Blazor WASM похоже на проги для WinAPI (назовем его NewWinAPI), но для браузера вместо венды,
а использование серверного Blazor похоже на запуск таких NewWinAPI программ на удаленном терминальном сервере в том смысле, что логика отрисовки программы работает на удаленном сервере аналогично RDP, а рендеринг происходит на клиенте, но вместо попиксельных обновлений сервер шлет транзакции изменений DOM модели для браузера.
V>И вообще касаемо WebAssembly, наверное оно все-таки взлетит
Оно уже давно взлетело в тех нишах, где требуется сложный УЙ. Веб-продукты Аутодеска, или та же Фигма.
KP>Так вроде же автор и основной контрибютор – Майкрософт. Можно сразу закопать
Гитхаб закопал уже? VS Code? TS? Azure?
PS. Я закапывал в своё время Microsoft. Примерно в те времена, когда вышла Win8. В Xcode 4-5 и OS X тех времён было одно удовольствие работать, туда и перепрыгнул. И к чему в итоге пришли? Xcode скатился в такое глюкавое и неповоротливое УГ, что даже Eclipse лучше. Не говоря уже о VS 2019, с которым даже на слабой 32-х битной виртуалке работать комфортнее, чем с современным Xcode на живой macOS. Сам такого не ожидал. VS Code, майкрософтовский же, тоже становится вполне съедобным.
Так что это мнение, по-моему, опоздало в актуальности лет на 8-9.
Здравствуйте, vl690001x2, Вы писали:
V>Смотрю, появилась новая технология — Blazor, которая как бы делает ненужным знание JS. Впрочем, CSS знать все же потребуется. V>Следует ли на нее внимание обратить или, памятуя о, например, судьбе Windows Phone, лучше все же учить JS/TS?
Здравствуйте, kaa.python, Вы писали:
SE>> Azure?
KP>А нахрена если есть AWS и GCP?
Только вот ажуры растут с нехилой скоростью, особенно в период пандемии.
Ажуры сейчас основной драйвер роста для MS.
Кому то и на хрен не нужны AWS и GCP. Конкуренция!
и солнце б утром не вставало, когда бы не было меня
