Открыть список
Как стать автором
Обновить

Комментарии 46

Это что же, вскоре JS познает что такое настоящая конкуренция? Дожили наконец-то!

А ещё это позволит бэкенд-разработчикам писать что-то для браузера без содрогания и боли =)
Нет, это даже близко не конкуренция.
Все подобные решения в прошлом обладали огромными техническими проблемами:
— раздутый бандл на ровном месте (и пока это все еще правда, да);
— медленное исполнение по сравнению с js;
— ужасный дебаг (можно сказать, что почти отсутствующий);
— сложность реализации адекватного транспайлера из сложного языка в js;
— отсутствие возможности хоть как-то управлять памятью;

Но есть еще более важные, не технические проблемы:
— во все давние попытки вкладывали очень мало денег;
— раньше в вебе сложность задач была скажем так не очень большая, чтобы имело смысл городить какую-то сложную инфраструру;

WebAssembly снимает огромную нагрузку с плеч разработчиков подобных языков. А сложность задач растет

Недавно как раз перевод статьи опубликовал: Возможно, вам не нужен Rust, чтобы ускорить ваш JS.


Сейчас слишком много спекуляций на теме WebAssembly и его производительности. Реальные цифры не показывают существенного прироста. И это было в задачах на обработку чисел и сортировку массивов.


В UI-логике и работе с DOM API особого преимущества тем более ждать не стоит.

Статья хорошая. Но как пример микрооптимизаций.
Давайте начистоту: то, что 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, то могут наверное чудеса произойти.
Если WPF сможет трансформироваться в корректный DOM — почему нет? Главное понимать, что какой бы магией это не казалось, запускается оно всё в браузере и должно жить по его правилам.
Вы не путайте понятия XAML и WPF. XAML можно трансформировать в HTML. Но вот графический стэк WPF трансформировать в Web не только сложно, но и вредно. Графика WPF с retained mode для веба хуже значительно, чем immediate mode от (Web)OpenGL.

React как способ порождения View для .NET уже давно существует — https://reactjs.net/. Тот факт, что он не оформлен в виде ViewEngine ещё не мешает за 15 минут написать метод, возвращающий ActionResult, использующий для рендеринга только реакт.

Да это уже давно, я имел в виду что сам реакт на шарфе напишут. Идея виртуального дума очень прикольная, иммутабельностьб компоненты и всё такое. Скоро запилят API чтоби с WASM c DOM-ом общаться или что то в этом направлении. Помнию читал где то статеику про такое.
.Net платформа решила всю инфраструктуру под себя взять?:)
Microsoft понимает, что они нехило так профукали рынки мобильных, кроссплатформенных и веб приложений. Вот и пытаются навёрстывать. Xamarin, .NET Core, TypeScript, а теперь вот и Blazor. Довольно приятно видеть, что в нынешнем Microsoft даже такой just-for-fun проект как Blazor можете получить поддержку и ресурсы для дальнейшего развития.
Ну я в целом рад такому подходу. Один язык и масса ему применений. От веба до игр(Unity).
Язык даже и не один. Подойдёт любой язык CLR-семейства.
+ Подойдёт любой язык DLR-семейства… IrpnRuby, IronPython, Iron%WhatEver%.
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, более легкий и кросс-платформенный.
НЛО прилетело и опубликовало эту надпись здесь
Я, конечно, в 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 и этим всем — чёрт его знает, что они ещё могут выкинуть =)

НЛО прилетело и опубликовало эту надпись здесь
И одновременно с вашими предположениями 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 это не катастрофа. Вот между бетами и релиз-кандидатами — там да, были сильные изменения.

Но от компании (а не от кучки ночных красноглазиков) требуется именно разбор завалов и очень четкая стратегия. А ее нет.

С другой стороны большая компания может себе позволить одновременно развивать много направлений и обмениваться успешными наработками.

И акции их продам. Что и всем остальным советую.

Начали за здравие, закончили за упокой.

Вы по-моему пишете из криокамеры, потому что в последнее время в том же аспнете ничего кардинально не меняется. Включаются новые библиотеки, фиксятся баги в уже существующих проектах.

НЛО прилетело и опубликовало эту надпись здесь
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
НЛО прилетело и опубликовало эту надпись здесь
Какой критерий по которому можно отнести 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, и как там дела с совместимостью :-)
НЛО прилетело и опубликовало эту надпись здесь
Mono… Ну и вот, видимо в браузере.
А еще есть CoreRT и среди архитектур там упоминается WASM. И там же есть пример c MonoGame, а какая связь между Mono и .NET Core runtime мне пока не ясно.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.