Сообщение Re: Blazor. Новая ловушка-тупик? от 06.10.2020 10:45
Изменено 06.10.2020 11:10 Дядюшка Ау
Re: Blazor. Новая ловушка-тупик?
Здравствуйте, 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.
Использовать более низкоуровневые, чем XAF фреймворки IMHO имеет смысл только если у вас большая нагрузка, популярное внешнее public веб приложение, потому что по отзывам XAF не тянет больше сотни одновременных клиентов. Не исключаю, что админ может попытаться оптимизировать это до нескольких сотен, но порядок, наверно остается тот же, по крайне мере пока XAF не позволяет балансировать нагрузку между несколькими микросервисами.
Кстати, а вам не кажется, что использование клиентского Blazor WASM похоже на проги для WinAPI (назовем его NewWinAPI), но для браузера вместо венды,
а использование серверного Blazor похоже на запуск таких NewWinAPI программ на удаленном терминальном сервере в том смысле, что логика отрисовки программы работает на удаленном сервере аналогично RDP, а рендеринг происходит на клиенте, но вместо попиксельных обновлений сервер шлет транзакции изменений DOM модели для браузера.
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.
Использовать более низкоуровневые, чем XAF фреймворки IMHO имеет смысл только если у вас большая нагрузка, популярное внешнее public веб приложение, потому что по отзывам XAF не тянет больше сотни одновременных клиентов. Не исключаю, что админ может попытаться оптимизировать это до нескольких сотен, но порядок, наверно остается тот же, по крайне мере пока XAF не позволяет балансировать нагрузку между несколькими микросервисами.
Кстати, а вам не кажется, что использование клиентского Blazor WASM похоже на проги для WinAPI (назовем его NewWinAPI), но для браузера вместо венды,
а использование серверного Blazor похоже на запуск таких NewWinAPI программ на удаленном терминальном сервере в том смысле, что логика отрисовки программы работает на удаленном сервере аналогично RDP, а рендеринг происходит на клиенте, но вместо попиксельных обновлений сервер шлет транзакции изменений DOM модели для браузера.
Re: Blazor. Новая ловушка-тупик?
Здравствуйте, 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.
Ищу подработку на DevExpress XAF на 2-4 часа/день в вечернее время, 2тр/30Eur/35USD в час
Использовать более низкоуровневые, чем XAF фреймворки IMHO имеет смысл только если у вас большая нагрузка, популярное внешнее public веб приложение, потому что по отзывам XAF не тянет больше сотни одновременных клиентов. Не исключаю, что админ может попытаться оптимизировать это до нескольких сотен, но порядок, наверно остается тот же, по крайне мере пока XAF не позволяет балансировать нагрузку между несколькими микросервисами.
Кстати, а вам не кажется, что использование клиентского Blazor WASM похоже на проги для WinAPI (назовем его NewWinAPI), но для браузера вместо венды,
а использование серверного Blazor похоже на запуск таких NewWinAPI программ на удаленном терминальном сервере в том смысле, что логика отрисовки программы работает на удаленном сервере аналогично RDP, а рендеринг происходит на клиенте, но вместо попиксельных обновлений сервер шлет транзакции изменений DOM модели для браузера.
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.
Ищу подработку на DevExpress XAF на 2-4 часа/день в вечернее время, 2тр/30Eur/35USD в час
дело не в качестве кода и не в масштабе проекта. В этих проектах люди в принципе писали не нужный код. При разработке учетной и/или аналитической системы решаются типовые задачи: разрабатывается модель данных, делаются формочки для работы с данными, делаются разные процедуры преобразования данных (импорт, экспорт, ETL), делается API, интеграция с другими системами, генерация документов и отчетов и т.п. В XAF, по крайней мере, всё что касается пользовательского интерфейса, разграничения прав доступа, простеньких инструментов для аналитики, для генерации документов и т.п. уже реализовано. В тех проектах люди 90% времени тратили на эту бессмысленную рутину, а я 90% времени тратил на модель данных, на нетиповую функциональность. В итоге практически весь код, который они годами писали просто выкидывается. Но это работает не на любом проекте, XAF ускоряет работу раз в 50 только при создании учетных систем (включая CRM, ERP и т.п.).
Использовать более низкоуровневые, чем XAF фреймворки IMHO имеет смысл только если у вас большая нагрузка, популярное внешнее public веб приложение, потому что по отзывам XAF не тянет больше сотни одновременных клиентов. Не исключаю, что админ может попытаться оптимизировать это до нескольких сотен, но порядок, наверно остается тот же, по крайне мере пока XAF не позволяет балансировать нагрузку между несколькими микросервисами.
Кстати, а вам не кажется, что использование клиентского Blazor WASM похоже на проги для WinAPI (назовем его NewWinAPI), но для браузера вместо венды,
а использование серверного Blazor похоже на запуск таких NewWinAPI программ на удаленном терминальном сервере в том смысле, что логика отрисовки программы работает на удаленном сервере аналогично RDP, а рендеринг происходит на клиенте, но вместо попиксельных обновлений сервер шлет транзакции изменений DOM модели для браузера.