_>Ну и да, пока что в силу ограничений WebAssembly говорить о нормальном взаимодействие с DOM как-то смешно... Т.е. там или свой рендеринг в canvas или же тупо вызов js кода для работы с DOM. Поэтому и у Blazor пока что не может быть речи об исключение JS из проекта с рисованием в HTML.
А это и не нужно. Суть блазора это генерация HTML с использованием .Net вместо (вместе) с JS/TS
Здравствуйте, takTak, Вы писали:
IT>>По секрету — сейчас время работы программиста стоит дороже, чем даже двукратная разница в скорости между платформами. Значительно дороже, а главные критерии в разработки — это тестируемость, поддерживаемость и читаемость, а вовсе не скорость.
T>+1
T>поддерживать C# на порядки проще, чем любую ерунду на яваскрипте
Кому как.
Поддерживал код на С# и на ExtJS. На С# конечно писать проще, но не в разы
Re[6]: А нахрен нужен .NET и весь этот C# в принципе нормальному человеку?
IT>>>По секрету — сейчас время работы программиста стоит дороже, чем даже двукратная разница в скорости между платформами. Значительно дороже, а главные критерии в разработки — это тестируемость, поддерживаемость и читаемость, а вовсе не скорость.
T>>+1
T>>поддерживать C# на порядки проще, чем любую ерунду на яваскрипте
П>Кому как. П>Поддерживал код на С# и на ExtJS. На С# конечно писать проще, но не в разы
сколько времени ты в ExtJS въезжал? сравнимо ли конечное качество?
Re[4]: А нахрен нужен .NET и весь этот C# в принципе нормальному человеку?
Здравствуйте, Программизд, Вы писали:
П>Здравствуйте, T4r4sB, Вы писали:
TB>>Здравствуйте, alexzzzz, Вы писали:
A>>>Есть ощущение, что в последнее время тема ненужности Window/Net/C# специально форсится. Подозреваю, что это как-то связано с грядущими выборами, но не понимаю как.
TB>>Надоел C#? Хватит это терпеть! Голосуй за Жириновского!
П>Какая связь между C# и Жириновским?
Интуитивно подозреваю, что связь есть, но пока не понимаю, какая.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Re[5]: А нахрен нужен .NET и весь этот C# в принципе нормальному человеку?
Здравствуйте, Тёмчик, Вы писали:
Тё>Здравствуйте, Serginio1, Вы писали:
S>> Угу так прощелкал, что ажуры тянут акции MS вверх. Да в ажурах используются докеры под линукс где используется .Net Core. Тё>Где используется ажур? Откуда на ажуре линух? Ведь ажур- прямое свидетельство, как сильно MS прощелкал сервера.
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, alexzzzz, Вы писали:
pkl>>>>Или как язык C# принёс в мир какие-то особо ниипические парадигмы и доселе мир не знал таких инновационных компьютеро-лингвистических эстетств?
vsb>>>Насколько я знаю, в C# есть встроенный язык запросов (LINQ), аналогов я ни в одном ЯВУ не видел. Впрочем в новых ЯВУ таких аналогов тоже не появляется, что наводит на подозрения, что эксперимент оказался неудачным (как в Java с проверяемыми исключениями). Но на C# я не пишу, поэтому не буду утверждать однозначно.
A>>У LINQ есть свои недостатки, но в общем и целом фича удобная и зашла отлично, люди пользуются.
vsb>Для чего пользуются? Для запроса по коллекциям или для БД?
И для коллекций и для БД
Re[9]: А нахрен нужен .NET и весь этот C# в принципе нормальному человеку?
Здравствуйте, alex_public, Вы писали:
_>Хаха, а когда я писал тоже самое несколько лет назад (в обсуждение WebAssembly), у тебя было прямо противоположное мнение.
Ты плохо понял о чем я писал. То было не мое мнение, а мои ожидания от деятельности комитета, которые были похожи на саботаж.
Я вчера вскольз пообщался с автором Блейзора по поводу внутренностей — там скорее не благодаря, а вопреки. Жуткие JS стабы и логика по типу реакта, просто чтобы управлять DOM. И при этом более легковесные и тонкие решения недоступны, так как блейзор генерит текст, а не DOM, а собственно DOM строит уже blazor.js
_>Поэтому и у Blazor пока что не может быть речи об исключение JS из проекта с рисованием в HTML.
В текущем понимании у Blazor никакого JS в прикладном коде не надо.
Re[10]: А нахрен нужен .NET и весь этот C# в принципе нормаль
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>> По сути WebAssembly играет роль замены CEF
НС>По факту все существенно сложнее.
Ну если совмещать Angular — CEF — .Net то достаточно близко.
Можно еще вспомнить Ionic.
Помните, на данный момент Blazor — эксперимент для команды ASP.NET. Нам потребуется несколько месяцев чтобы понять сможем ли мы сделать из него полноценный, поддерживаемый продукт. Мы ещё ничего не обещаем, поэтому не надо строить свои бизнес-планы вокруг Blazor!
Мне блазор очень понравился. Надеюсь на взлет.
и солнце б утром не вставало, когда бы не было меня
Re[6]: А нахрен нужен .NET и весь этот C# в принципе нормальному человеку?
Здравствуйте, Программист2013, Вы писали:
T>>поддерживать C# на порядки проще, чем любую ерунду на яваскрипте П>Кому как. П>Поддерживал код на С# и на ExtJS. На С# конечно писать проще, но не в разы
В разы приходит с опытом.
Re[11]: А нахрен нужен .NET и весь этот C# в принципе нормаль
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Serginio1, Вы писали:
S>> По сути WebAssembly играет роль замены CEF
НС>По факту все существенно сложнее.
Я так понимаю, что в Ангуларе за генерацию HTML, события, сервисы отвечает JS упакованный через WebPack
В Blaxor за это отвечает .Net Код упакованный через Компоновщик (linker) .NET IL
Ну а дальше запускается двумя способами
Интерпретация
В режиме интерпретации рантайм Mono компилируется в WebAssembly, но ваши .NET сборки — нет. Браузер загружает и запускает рантайм, который в свою очередь может загружать и исполнять стандартные .NET сборки (обычные .NET .dll файлы), собранные обычным .NET тулчейном.
Это похоже на то, как для обычной CLR основное ядро распространяется скомпилированным в нативный код, который затем загружает и исполняет .NET сборки. Единственное ключевое различие в том, что десктопная CLR активно использует JIT-компиляцию для ускорения исполнения, в то время как Mono на WebAssembly работает ближе к классической модели интерпретации.
Ahead-of-time (AOT) компиляция
В AOT режиме ваше .NET приложение превращается в чистые WebAssembly бинарники сразу при сборке. В рантайме не происходит никакой интерпретации — ваш код выполняется как обычный WebAssembly-код. Этот режим всё ещё требует загрузки некоторой части рантайма Mono (таких низкоуровневых .NET сервисов как, например, сборка мусора), но позволяет отказаться от таких компонентов как парсер .NET файлов.
Это похоже на то, как с незапамятных времён утилита ngen позволяет AOT-компиляцию .NET сборок в нативный машинный код, или на недавно появившийся полноценный нативный AOT .NET рантайм — CoreRT.
Режим интерпретации против AOT
Какой режим лучше? Мы пока что не знаем.
Однако мы знаем, что режим интерпретации даёт гораздо более быстрый процесс разработки, чем AOT. После изменения кода вы можете пересобрать его обычным .NET-компилятором и получить обновлённое приложение в браузере в считанные секунды. AOT-компиляция, в свою очередь, может занимать минуты.
Очевидная мысль — режим интерпретации будет основным для разработки, а AOT — для продакшена.
Но всё это может оказаться совсем не так, потому что режим интерпретации, к удивлению, гораздо быстрее, чем вы могли бы подумать. И мы слышали от ребят из Xamarin, которые используют .NET для нативных мобильных приложений, что обычные (не AOT) .NET сборки очень маленькие и хорошо поддаются компрессии, в отличие от AOT-сборок. Мы будем рассматривать оба варианта пока у нас не появится возможность объективно оценить разницу.
и солнце б утром не вставало, когда бы не было меня
Re[7]: А нахрен нужен .NET и весь этот C# в принципе нормальному человеку?
Здравствуйте, takTak, Вы писали:
IT>>>>По секрету — сейчас время работы программиста стоит дороже, чем даже двукратная разница в скорости между платформами. Значительно дороже, а главные критерии в разработки — это тестируемость, поддерживаемость и читаемость, а вовсе не скорость.
T>>>+1
T>>>поддерживать C# на порядки проще, чем любую ерунду на яваскрипте
П>>Кому как. П>>Поддерживал код на С# и на ExtJS. На С# конечно писать проще, но не в разы
T>сколько времени ты в ExtJS въезжал? сравнимо ли конечное качество?
В ExtJS въезжал 1-2 года (верстал веб формы), на C# писал серв. часть (расчеты, вызов ф-ции сохр-я в БД, компилил это все в dll)
На Js писал расчеты на клиенте
Re[10]: А нахрен нужен .NET и весь этот C# в принципе нормаль
Здравствуйте, Serginio1, Вы писали:
_>>Ну и да, пока что в силу ограничений WebAssembly говорить о нормальном взаимодействие с DOM как-то смешно... Т.е. там или свой рендеринг в canvas или же тупо вызов js кода для работы с DOM. Поэтому и у Blazor пока что не может быть речи об исключение JS из проекта с рисованием в HTML. S>А это и не нужно. Суть блазора это генерация HTML с использованием .Net вместо (вместе) с JS/TS S>Blazor: Техническое введение
Вот только не надо МНЕ рассказывать про устройство Blazor. Я прямо на этом форуме описывал это устройство задолго до того, как авторы Blazor написали первую строчку своего кода!
И пока что (при текущей ситуации с webassembly) не очень понятно какие преимущества сможет привнести Blazor по сравнению с различными компиляторам C#/Java/C++ и т.п. в JS. Ну или если говорить не про компиляторы (которые лежат в основе таких продуктов), а про фреймворки, то например в сравнение с GWT.
P.S. Я в своих прогнозах говорил о языках типа Питона — для них всё будет совсем по другому. Но опять же только после доработки webassembly до возможности прямого доступа к DOM (это у них есть в планах, но не в первую очередь).
Re[6]: А нахрен нужен .NET и весь этот C# в принципе нормальному человеку?
Здравствуйте, Ночной Смотрящий, Вы писали:
_>>Хаха, а когда я писал тоже самое несколько лет назад (в обсуждение WebAssembly), у тебя было прямо противоположное мнение. НС>Ты плохо понял о чем я писал. То было не мое мнение, а мои ожидания от деятельности комитета, которые были похожи на саботаж. НС>Я вчера вскольз пообщался с автором Блейзора по поводу внутренностей — там скорее не благодаря, а вопреки. Жуткие JS стабы и логика по типу реакта, просто чтобы управлять DOM. И при этом более легковесные и тонкие решения недоступны, так как блейзор генерит текст, а не DOM, а собственно DOM строит уже blazor.js
Да, по другому сейчас нельзя. Ну точнее текст — это конечно же перебор (зачем, когда нормальное api легко строится?), но без работы через JS безусловно не обойтись.
_>>Поэтому и у Blazor пока что не может быть речи об исключение JS из проекта с рисованием в HTML. НС>В текущем понимании у Blazor никакого JS в прикладном коде не надо.
Ха, в прикладном коде. Такое же уже было... Возьми например какой-нибудь GWT — почему по твоему он ещё не захватил мир? ) Да, и если что, для C# компиляторов в JS тоже полно существует.
Кстати, в этом смысле забавно выглядит компилятор emscripten для C++, у которого есть две целевые платформы для одного и того же кода: wasm32 и asm.js. Разница в компиляции под них только в не сильном (ну во всяком случае пока в wasm не добавили поддержку SIMD) увеличение производительности.
Re[11]: А нахрен нужен .NET и весь этот C# в принципе нормаль
_>И пока что (при текущей ситуации с webassembly) не очень понятно какие преимущества сможет привнести Blazor по сравнению с различными компиляторам C#/Java/C++ и т.п. в JS. Ну или если говорить не про компиляторы (которые лежат в основе таких продуктов), а про фреймворки, то например в сравнение с GWT.
_>P.S. Я в своих прогнозах говорил о языках типа Питона — для них всё будет совсем по другому. Но опять же только после доработки webassembly до возможности прямого доступа к DOM (это у них есть в планах, но не в первую очередь).
речь не про техническое приемущество а про приемущество, состоящее в удобности работы с кодом, меня вот динамические языки отталкивают: в них, как в болоте...шаг вправо и ты уже утонул, так этого и не заметив
понятно, что если какое-либо техническое приемущество появится, то это станет важным фактором
Re[12]: А нахрен нужен .NET и весь этот C# в принципе нормаль
Здравствуйте, takTak, Вы писали:
_>>И пока что (при текущей ситуации с webassembly) не очень понятно какие преимущества сможет привнести Blazor по сравнению с различными компиляторам C#/Java/C++ и т.п. в JS. Ну или если говорить не про компиляторы (которые лежат в основе таких продуктов), а про фреймворки, то например в сравнение с GWT. _>>P.S. Я в своих прогнозах говорил о языках типа Питона — для них всё будет совсем по другому. Но опять же только после доработки webassembly до возможности прямого доступа к DOM (это у них есть в планах, но не в первую очередь). T>речь не про техническое приемущество а про приемущество, состоящее в удобности работы с кодом, меня вот динамические языки отталкивают: в них, как в болоте...шаг вправо и ты уже утонул, так этого и не заметив T>понятно, что если какое-либо техническое приемущество появится, то это станет важным фактором
Так в GWT использовалась как раз статически типизированная Java. )
Re[11]: А нахрен нужен .NET и весь этот C# в принципе нормаль
Здравствуйте, alex_public, Вы писали:
_>Здравствуйте, Serginio1, Вы писали:
_>>>Ну и да, пока что в силу ограничений WebAssembly говорить о нормальном взаимодействие с DOM как-то смешно... Т.е. там или свой рендеринг в canvas или же тупо вызов js кода для работы с DOM. Поэтому и у Blazor пока что не может быть речи об исключение JS из проекта с рисованием в HTML. S>>А это и не нужно. Суть блазора это генерация HTML с использованием .Net вместо (вместе) с JS/TS S>>Blazor: Техническое введение
_>Вот только не надо МНЕ рассказывать про устройство Blazor. Я прямо на этом форуме описывал это устройство задолго до того, как авторы Blazor написали первую строчку своего кода!
F cnjb _>И пока что (при текущей ситуации с webassembly) не очень понятно какие преимущества сможет привнести Blazor по сравнению с различными компиляторам C#/Java/C++ и т.п. в JS. Ну или если говорить не про компиляторы (которые лежат в основе таких продуктов), а про фреймворки, то например в сравнение с GWT.
_>P.S. Я в своих прогнозах говорил о языках типа Питона — для них всё будет совсем по другому. Но опять же только после доработки webassembly до возможности прямого доступа к DOM (это у них есть в планах, но не в первую очередь).
Ну вот, а говоришь читал.
Так как же он позволяет нам запускать .NET? Всё благодаря тому, что команда Mono добавила поддержку WebAssembly в свой проект. Если вы пропустили новости, то проект Mono стал частью Microsoft в 2016 году. Mono это официальный .NET рантайм для клиентских платформ (таких как нативные мобильные приложения и игры). WebAssembly это просто ещё одна клиентская платформа, поэтому вполне разумно, что Mono должно на ней работать.
Моно может запускаться на WebAssembly в двух режимах: режиме интерпретации и AOT.
Интерпретация
В режиме интерпретации рантайм Mono компилируется в WebAssembly, но ваши .NET сборки — нет. Браузер загружает и запускает рантайм, который в свою очередь может загружать и исполнять стандартные .NET сборки (обычные .NET .dll файлы), собранные обычным .NET тулчейном.
Это похоже на то, как для обычной CLR основное ядро распространяется скомпилированным в нативный код, который затем загружает и исполняет .NET сборки. Единственное ключевое различие в том, что десктопная CLR активно использует JIT-компиляцию для ускорения исполнения, в то время как Mono на WebAssembly работает ближе к классической модели интерпретации.
Ahead-of-time (AOT) компиляция
В AOT режиме ваше .NET приложение превращается в чистые WebAssembly бинарники сразу при сборке. В рантайме не происходит никакой интерпретации — ваш код выполняется как обычный WebAssembly-код. Этот режим всё ещё требует загрузки некоторой части рантайма Mono (таких низкоуровневых .NET сервисов как, например, сборка мусора), но позволяет отказаться от таких компонентов как парсер .NET файлов.
Это похоже на то, как с незапамятных времён утилита ngen позволяет AOT-компиляцию .NET сборок в нативный машинный код, или на недавно появившийся полноценный нативный AOT .NET рантайм — CoreRT.
Режим интерпретации против AOT
Какой режим лучше? Мы пока что не знаем.
Однако мы знаем, что режим интерпретации даёт гораздо более быстрый процесс разработки, чем AOT. После изменения кода вы можете пересобрать его обычным .NET-компилятором и получить обновлённое приложение в браузере в считанные секунды. AOT-компиляция, в свою очередь, может занимать минуты.
Очевидная мысль — режим интерпретации будет основным для разработки, а AOT — для продакшена.
Но всё это может оказаться совсем не так, потому что режим интерпретации, к удивлению, гораздо быстрее, чем вы могли бы подумать. И мы слышали от ребят из Xamarin, которые используют .NET для нативных мобильных приложений, что обычные (не AOT) .NET сборки очень маленькие и хорошо поддаются компрессии, в отличие от AOT-сборок. Мы будем рассматривать оба варианта пока у нас не появится возможность объективно оценить разницу.
То есть можно вызвать метод .Net из моно получить текст HTML и через JS вставить его в DOM.
Есть два пути
1. Получить Текст из .Net
2. Вызвать JS функцию передав в неё текст.
Это очень похоже на использование хромиум
тобы работать с чужими JavaScript библиотеками мы исследуем возможность использования определений типов TypeScript в C# коде с полным intellisense. Это сделает около 1000 самых популярных JS-библиотек очень простыми для интеграции.
Текущий подход для вызова чужих библиотек или вашего JS/TS кода из .NET это регистрация именованной функции в JS/TS файле. Например:
// Это JavaScript
Blazor.registerFunction('doPrompt', message => {
return prompt(message);
});
… и затем создаём обёртку для вызова из .NET:
// Это C#
public static bool DoPrompt(string message)
{
return RegisteredFunction.Invoke<bool>("doPrompt", message);
}
Вот тебе и прямой доступ к DOM
и солнце б утром не вставало, когда бы не было меня
Re[12]: А нахрен нужен .NET и весь этот C# в принципе нормаль
Здравствуйте, Serginio1, Вы писали:
S>Текущий подход для вызова чужих библиотек или вашего JS/TS кода из .NET это регистрация именованной функции в JS/TS файле. Например: S>[/q] S>
Это не прямой доступ к DOM, а прямой доступ к JS, который есть у любого WebAssembly приложения от рождения. Именно так работает этот http://rsdn.org/forum/flame.comp/6729734.1
мой тест. А вот прямого доступа к DOM у WebAssembly приложений пока нет, потому как для этого надо ещё разработать и внедрить в браузер новое низкоуровневое API. Это есть в плане развития WebAssembly, но далеко не в первой очереди. Сейчас у них за основное считается улучшение инфраструктуры, добавление работы с многопоточностью и SIMD. И я в принципе согласен с такими приоритетами, т.к. без этого преимущество в производительности над JS кодом уж слишком небольшое, в сравнение с теми усилиями, которые нужны для работы с WebAssembly в данный момент.
Re[13]: А нахрен нужен .NET и весь этот C# в принципе нормаль
T>>речь не про техническое приемущество а про приемущество, состоящее в удобности работы с кодом, меня вот динамические языки отталкивают: в них, как в болоте...шаг вправо и ты уже утонул, так этого и не заметив T>>понятно, что если какое-либо техническое приемущество появится, то это станет важным фактором
_>Так в GWT использовалась как раз статически типизированная Java. )
ну и что? кто-то то, что оттуда появлялось, мог для чего-то использовать ?
