Comments 46
Это что же, вскоре JS познает что такое настоящая конкуренция? Дожили наконец-то!
А ещё это позволит бэкенд-разработчикам писать что-то для браузера без содрогания и боли =)
В этом интервью об этом есть немного
WebAssembly with Brendan Eich
WebAssembly with Brendan Eich
Да уж познавали, и не раз:
Рынок большой, места хватит всем, найдется и для Blazor.
Нет, это даже близко не конкуренция.
Все подобные решения в прошлом обладали огромными техническими проблемами:
— раздутый бандл на ровном месте (и пока это все еще правда, да);
— медленное исполнение по сравнению с js;
— ужасный дебаг (можно сказать, что почти отсутствующий);
— сложность реализации адекватного транспайлера из сложного языка в js;
— отсутствие возможности хоть как-то управлять памятью;
Но есть еще более важные, не технические проблемы:
— во все давние попытки вкладывали очень мало денег;
— раньше в вебе сложность задач была скажем так не очень большая, чтобы имело смысл городить какую-то сложную инфраструру;
WebAssembly снимает огромную нагрузку с плеч разработчиков подобных языков. А сложность задач растет
Все подобные решения в прошлом обладали огромными техническими проблемами:
— раздутый бандл на ровном месте (и пока это все еще правда, да);
— медленное исполнение по сравнению с js;
— ужасный дебаг (можно сказать, что почти отсутствующий);
— сложность реализации адекватного транспайлера из сложного языка в js;
— отсутствие возможности хоть как-то управлять памятью;
Но есть еще более важные, не технические проблемы:
— во все давние попытки вкладывали очень мало денег;
— раньше в вебе сложность задач была скажем так не очень большая, чтобы имело смысл городить какую-то сложную инфраструру;
WebAssembly снимает огромную нагрузку с плеч разработчиков подобных языков. А сложность задач растет
Недавно как раз перевод статьи опубликовал: Возможно, вам не нужен Rust, чтобы ускорить ваш JS.
Сейчас слишком много спекуляций на теме WebAssembly и его производительности. Реальные цифры не показывают существенного прироста. И это было в задачах на обработку чисел и сортировку массивов.
В UI-логике и работе с DOM API особого преимущества тем более ждать не стоит.
Статья хорошая. Но как пример микрооптимизаций.
Давайте начистоту: то, что WebAssembly вообще показывает хоть какие-то реальные цифры это есмь случайность. Технология сырая, молодая, никому пока не нужная (в прикладном бизнесе). Пытаться сравнивать по перфомансу WebAssembly и JS сродни сравнению интеллектуальных способностей ребенка и подростка.
По сравнению с чистым JS технологии построенные поверх WebAssembly будут обладать следующими фичами:
— возможность агресивной оптимизации во время компиляции (практически отсутствует в JS благодаря его интерпретируемости);
— zero-cost абстракции;
— более адекватная работа с расположением объектов в памяти, а не «надеемся, что V8 как-то все разрулит»;
— меньше затрачиваемой памяти (что оказывает влияет на быстродействие системы);
И да, во многих приложениях это все окажется несущественным. Но в то же время полноценные приложения смогут жрать меньше в 2-4 раза памяти, цпу, батареии.
Давайте начистоту: то, что WebAssembly вообще показывает хоть какие-то реальные цифры это есмь случайность. Технология сырая, молодая, никому пока не нужная (в прикладном бизнесе). Пытаться сравнивать по перфомансу WebAssembly и JS сродни сравнению интеллектуальных способностей ребенка и подростка.
По сравнению с чистым JS технологии построенные поверх WebAssembly будут обладать следующими фичами:
— возможность агресивной оптимизации во время компиляции (практически отсутствует в JS благодаря его интерпретируемости);
— zero-cost абстракции;
— более адекватная работа с расположением объектов в памяти, а не «надеемся, что V8 как-то все разрулит»;
— меньше затрачиваемой памяти (что оказывает влияет на быстродействие системы);
И да, во многих приложениях это все окажется несущественным. Но в то же время полноценные приложения смогут жрать меньше в 2-4 раза памяти, цпу, батареии.
Вах какой новост!!!
Будет интересно когда другие платформы вступят в гонку. Не удевлюсь если React как ViewEngine на .NET появится, а «back-end в front-end»-е ASP.NET Core оставят :) Или можно ещё помечтать и WPF во всей красе увидеть. А если приглядеться ещё к этой новости Welcoming Progressive Web Apps to Microsoft Edge and Windows 10, то могут наверное чудеса произойти.
Будет интересно когда другие платформы вступят в гонку. Не удевлюсь если React как ViewEngine на .NET появится, а «back-end в front-end»-е ASP.NET Core оставят :) Или можно ещё помечтать и WPF во всей красе увидеть. А если приглядеться ещё к этой новости Welcoming Progressive Web Apps to Microsoft Edge and Windows 10, то могут наверное чудеса произойти.
Если WPF сможет трансформироваться в корректный DOM — почему нет? Главное понимать, что какой бы магией это не казалось, запускается оно всё в браузере и должно жить по его правилам.
React как способ порождения View для .NET уже давно существует — https://reactjs.net/. Тот факт, что он не оформлен в виде ViewEngine ещё не мешает за 15 минут написать метод, возвращающий ActionResult, использующий для рендеринга только реакт.
Не во всей красе и не WPF, но XAML https://github.com/praeclarum/Ooui/wiki/Xamarin.Forms-with-Web-Assembly
.Net платформа решила всю инфраструктуру под себя взять?:)
Microsoft понимает, что они нехило так профукали рынки мобильных, кроссплатформенных и веб приложений. Вот и пытаются навёрстывать. Xamarin, .NET Core, TypeScript, а теперь вот и Blazor. Довольно приятно видеть, что в нынешнем Microsoft даже такой just-for-fun проект как Blazor можете получить поддержку и ресурсы для дальнейшего развития.
Silverlight второе пришествие :-)
Отличная новость! Искренне буду рад если .NET займёт часть данного рынка.
Чтобы работать с чужими JavaScript библиотеками мы исследуем возможность использования определений типов TypeScript в C# коде с полным intellisense. Это сделает около 1000 самых популярных JS-библиотек очень простыми для интеграции.
Это, просто, потрясающе. Я не могу подобрать слов.
Опять теже грабли, проходили же уже GWT.
Но это ведь не совсем GWT. GWT компилировал Java в JavaScript, что накладывает свои ограничения. А если учесть каким был JavaScript ещё лет 5 назад, то трансляция джавы кажется ещё более ужасной идеей. WebAssembly же этой некий байт-код, на который отлично ложится компиляция того же дотнета или джавы, которые итак в собственный байт-код собираются. Ну и это открытый стандарт, который развивается силами разных компаний. Думаю в данном случае мы получим совсем другой результат. По крайне мере хочется в это верить.
Если scalajs, kotlin js и аналоги таргетились в Js, то теперь таргетинг — WebAssembly. Это вроде и здорово, но как только вспоминаешь, что с DOM особо не поработать, то появляются вопросы, надо ли это всё.
Это в теории звучит прекрасно. А на практике есть демо страница: https://blazor-demo.github.io/ (тут исходники)
На ней грузится 1,5 мегабайта WASM файлов, чтобы показать нам "Hello world". Проект еще на ранней стадии и это понятно, но все равно каких-то киллер фич не видно. Да и WebAssembly там используется скорее ради хайпа, чем какой-то реальной выгоды в скорости.
Еще можно почитать статью по теме: WebAssembly и манипуляции DOM, где анализируется производимый байткод разных компиляторов.
Если уж на то пошло, то хеллоу ворлд на ангуларе будет не сильно меньше весить =) Как они сами говорят, у них есть реализация Mono на asm.js, но она гораздо медленее wasm-версии, так что выгода в скорости заявляется. Киллер-фича тут в том, что можно прям в браузере юзать библиотеки, авторы которых никогда и не думали, что кто-то их будет так запускать.
Все это имеет смысл, только если производительность покажется на приемлимом уровне. Пока нет тестов производительности и сравнения с другими технологиями, сложно о чем-то говорить.
Вполне может оказаться, что решение транслировать код в чистый JS без WASM окажется быстрее, потому что делать вызовы WASM и обратно — это дорогая операция.
А GWT вполне себе живой и с версии 2.8 где есть новый jsinterop, я не вижу принципиальных отличий от TypeScript (кроме языка :-))
www.webtoolkit.eu/wt — вот вам еще одна попытка сотворить невозможное, но уже на базе С++ :)
Я уже путаюсь во всяческих реализациях .NET
- .NET Framework, .NET Core — понятно.
- Mono — оно сейчас развивается независимо от .NET Core/.NET Framework и имеет независимую кодовую базу, реализующую все то же самое? Или нет?
- Xamarin — это на основе Mono
- UWP, WinPhone и прочая плеяда
мертворожденныхтехнологий — по-идее их базируется на .NET Framework?
Или я что-то не понимаю?
А новость очень крутая. Я джва года Я давно ждал чего-то подобного.
Mono — это альтернативная, кроссплатформенная реализация .NET Framework. На момент покупки майкрософтом, был почти полностью реализован .NET 4.5 (с некоторыми исключениями, вроде асинхронности и платформенно-зависимых частей).
Именно благодаря Моно появился Xamarin.
.NET Core — это переписанный «с нуля» .NET Framework, более легкий и кросс-платформенный.
Именно благодаря Моно появился Xamarin.
.NET Core — это переписанный «с нуля» .NET Framework, более легкий и кросс-платформенный.
UFO just landed and posted this here
Я, конечно, в Microsoft не работаю, поэтому о таких планах не осведомлён. Однако, насколько я понимаю позиционирование, то Mono уже практически никак не отделяется от Xamarin и будет развиваться именно для присутствия на мобилках и в играх. Ну и вот, видимо в браузере.
.NET Core это кроссплатформа для бэкенда.
.NET Framework это виндовс-приложения.
UWP это такой .NET Core для приложений в сторе с мордой на WPF. Так как WPF стандартизовали, то возможно со временем они UWP и превратят в надстройку над .NET Core.
Простой ASP.NET всё ещё поддерживается, но есть ощущение, что это теперь Legacy, который никак развиваться не будет. Как только они более-менее догонят его по фичам в ASP.NET Core, то начнут совсем активно продвигать миграцию и минимизировать усилия по поддержке.
Но это лишь мои мысли и догадки. Нынешний Microsoft, конечно, неплох, но если вспомнить чехарду с ASP.NET 5, Core, DNX, DNVM и этим всем — чёрт его знает, что они ещё могут выкинуть =)
.NET Core это кроссплатформа для бэкенда.
.NET Framework это виндовс-приложения.
UWP это такой .NET Core для приложений в сторе с мордой на WPF. Так как WPF стандартизовали, то возможно со временем они UWP и превратят в надстройку над .NET Core.
Простой ASP.NET всё ещё поддерживается, но есть ощущение, что это теперь Legacy, который никак развиваться не будет. Как только они более-менее догонят его по фичам в ASP.NET Core, то начнут совсем активно продвигать миграцию и минимизировать усилия по поддержке.
Но это лишь мои мысли и догадки. Нынешний Microsoft, конечно, неплох, но если вспомнить чехарду с ASP.NET 5, Core, DNX, DNVM и этим всем — чёрт его знает, что они ещё могут выкинуть =)
UFO just landed and posted this here
И одновременно с вашими предположениями MS шлет привет и мочит, например, новую структуру проектов на базе json, которая пришла вместе с Core. Что не добавляет уверенности относительно их планов на Core.
Я, в общем, про это в конце и написал.
Смысл Mono при наличии Core тоже не понятен. Вроде бы это была открытая реализация .Net. А теперь у нас их две и обе у MS: Mono и Core.
Всё-таки Mono умеет работать там, где не умеет Core, плюс имеет гуёвый и мобильный стэк построенный поверх себя. Быстро перенести Xamarin на Core видимо не получится, поэтому пока что Mono будет жить.
Ну а ASP.Net только ленивый не пинал: каждый, абсолютно каждый релиз — это на самом деле новый продукт, просто называние похоже.
1.1, 2.0, 2.1 — с точки зрения ASP.NET Core разработчика это не особо крупные обновления. Они хорошие, полезные, но это не разные продукты. Миграция с 1.1 на 2.0 занимала иногда считанные минуты. Заменить project.json на csproj это не катастрофа. Вот между бетами и релиз-кандидатами — там да, были сильные изменения.
Но от компании (а не от кучки ночных красноглазиков) требуется именно разбор завалов и очень четкая стратегия. А ее нет.
С другой стороны большая компания может себе позволить одновременно развивать много направлений и обмениваться успешными наработками.
И акции их продам. Что и всем остальным советую.
Начали за здравие, закончили за упокой.
UFO just landed and posted this here
UFO just landed and posted this here
ASP.NET Core 2.0 — это фикс к какому «уже существующем проекту»? Удовлетворит ли он главному критерию фикса — полная обратная совместимость?
Если бы совместимость не ломалась — его бы 1.2, а не 2.0. Разный продукт и потеря совместимости это разные вещи.
Как этот новый очень быстрый продукт соотносится с продуктом ASP.NET (по названии вроде бы почти одно и то же).
Это развите идей ASP.NET. Но это не новая версия. А ещё Java и JavaScript тоже похоже называются =)
А ещё моё любимое: как там в новом проекте с базовой внутренней библиотекой Owin? Если у меня код пользуется Owin во всю, я смогу его использовать в ASP.NET Core 2.0?
Вроде как вполне — www.nuget.org/packages/Microsoft.AspNetCore.Owin
UFO just landed and posted this here
Какой критерий по которому можно отнести 1.2 и 2.0 к одному продукту? Название? Есть где-то официальный список обратных несовместимостей — вроде сломалось — A, B, С? (Как это делают все нормальные команды и компании)
Общий код? Общий API с частичной несовместимостью? Что вам ещё нужно? Список несовместимостей очевидно есть, вместе с гайдом по миграции — docs.microsoft.com/en-us/aspnet/core/migration/1x-to-2x
Правильно ли я вас понимаю, что разработка в ASP.NET (не Core — да-да, мы так должны всегда оговариваться из-за того, что бардак, который вы не хотите признать) — это не развитие идей ASP.NET? Если там есть развитие идей, то каких? Если это развитие идей ASP.NET — то получается целых два проекта для развития одних и тех же идей? Ну и на сладкое: вот этот вот Blazer вкрутили в какой из продуктов (ASP.NET не Core как я понимаю)? Он будет везде или только кое-где? Какая логика в этом? «Здесь — читать, здесь — не читать, а здесь мы рыбу заворачивали.»
ASP.NET вроде как и не развивается. Там только баги какие-то фиксят. Вся работа идёт только над Core. Blazor пока никто никуда не вкрутил, это сторонний, к тому же экспериментальный, проект. Как и было написано в статье — есть планы предоставить удобную интеграцию для ASP.NET Core проектов. Но для самого Blazor никакой ASP.NET Core не нужен.
Ага, гуглить я умею. Повторю вопрос: Если у меня код пользуется Owin во всю, я смогу его использовать в ASP.NET Core 2.0? Как Microsoft.AspNet.WebApi.Owin связан с Microsoft.AspNetCore.Owin? Как там с портированием кода при переходе с одной библиотеки на другую? Список несовместимостей? Или это тоже разные продукты? Ну вроде как просто называются Owin?
Owin это стандарт, есть реализация его поддержки в ASP.NET Core. Вот можете тут почитать — docs.microsoft.com/en-us/aspnet/core/fundamentals/owin. У меня owin нет, с его миграцией я не сталкивался.
Вы бы еще спросили как ASP.NET Core 2.0 соотносится с ASP, и как там дела с совместимостью :-)
Sign up to leave a comment.
Blazor: Техническое введение