Сегодня великий день! JavaScript стал на шаг ближе к смерти!
В этот памятный день зарелизился .Net Core 3.0, который привносит в мир веб возможность писать на чистом C# с помощью фреймворка с открытым исходным кодом Blazor, компилируя исходные коды в WASM, который является открытым стандартом и поддерживается на уровне браузера, что исключает повторение судьбы SilverLight. А там, где не поддерживается WASM если возможность эмуляции и передачи готового с сервера прямо клиенту.
Сам по себе Blazor похож на Angular. Да, может быть какие-то фичи отсутствуют, но в ближайших релизах их добавят.
Покайтесь JavaScript'еры, ибо грядет судный день!
Еще на тему
А тут прямо простор открыли для других языков.
Угу, особенно хорошо это видно на примере какого-нибудь Си
С#
Java
New-wave tried to destroy the metal, but the metal had its way
Grunge then tried to dethrone the metal, but metal was in the way
Punk-rock tried to destroy the metal, but metal was much too strong
Techno tried to defile the metal, but techno was proven wrong
Metal!
It comes from hell!
это прям вот точно про javascript
JS как голем из говна, ты его рубишь а у него больше говна отрастает, так он еще и тебя пачкает.
Глядишь и еще какие-нибудь игроки подтянутся.
Например, у Google есть Dart, который пока компилится в JavaScript, но если у майков получится завоевать популярность, то будет круто.
В текущем варианте Blazor можно использовать JS для доступа к апи браузера, но через год все обрастет либами и высокоуровневыми обертками.
Ты просто робот, имитация жизниИмитация ООП. Ну, джава то еще говно, тут да. Но против C++/C#/Kotlin - говнище. Я писал немного и ой как мне не хватило хотя бы сраной перегрузки операторов. Писать векторные-матричные операции через add(), mult() и так далее не очень удобно.точно ли сразу в WASM?
емнип, в WASM скомпилирована Mono Runtime, а сам Blazor компилируется в EXE. (да да, виртуальная машина в виртульной машине)
емнип(2), компиляция напрямую в WASM была намечена в .net5
Следите за руками. WASM - low-level виртуальная машина, исполняющая некий байткод. Поверх этой виртуальной машины запущен адаптированный рантайм .NET (грубо говоря, они взяли рантайм .NET и скомпилировали его не в машинный код какого-нибудь x86, а в байт-код WASM), со всеми его jit-компиляторами, сборщиками мусора и прочим говном. И уже поверх крутится ваше приложение. Мы добавили вам виртуальную машину в виртуальную машину, осталось прихуярить монитор.
И это пиздец, скажу я вам. Это отличное проявление эволюционного развития ПО. Зачастую новое рождается на основе существующего, не изменяя сути вещей, а добавляя еще один ебаный слой абстракции поверх. WASM - хорошая штука, если вам нужно запустить какой-нибудь C/C++/Rust/etc, т.е. нативный код в браузере, чтобы получить перфоманс. Нахуя вам перфоманс в браузере, я, конечно, не знаю. 3д игры, блеать? Матан считать? Фотошопы? И все же, WASM - тот еще костыль. А VM поверх VM - это пиздец.
Но и это еще не все. Стандарт WASI: запуск WebAssembly за пределами веба. Еще раз. Специальная хуета, сделанная, чтобы обойти ограничения веба (один сраный JS, песочница итп итд) тащится в обычные ОС! Теперь ты можешь запускать .NET/Python/etc в гребанном WASM в винде/линуксе/итп. Да-да, ровно в то же время, как ты можешь запускать все то же самое на своей сраной ОС непосредственно! Особенно забавно, если речь идет не о каком-нибудь С/С++/итп, которые надо перекомпилировать, а о питоне, шарпе или джаве!
докинь WebGPU к WASM и дотка в браузере уже не будет казаться чем-то нереализуемым
ну и справедливости ради - реализацию "VM поверх VM" обещали ликвидировать к .NET5. Под айфоны же как-то (Mono+LLVM) компилируется сразу бинарь. Плюс у Unity есть такая тулза как IL2CPP - возможно смогут прикрутить её как временное решение
- работа там, где установка невозможна или затруднена (xbox, ipad, итд)
- Нулевая стоимость поддержки не-x86 (ты же понимаешь, что для ARM и MIPS нет никаких проблем выпустить CPU на 5ггц?)
- нулевая стоимось поддержки различных ОС (кто сказал Linux?)
и далее по списку.
А поддержка не-х86 легко доступна везде, где есть gcc :)
Вообще, это все к той теме, которую я поднял, об эволюционном развитии ПО.
Не, кросс-платформенность и прочее дерьмо, безусловно, хорошо.
У нас есть ОС, есть графическая подсистема (встроенная ли, как в винде/айосях/андроиде итп) или отдельная (x window server), которая умеет нативно рисовать всякие кнопочки (привет GDI+ и прочие). Затем, значит, мы шлем все это дерьмо нахер, говорим, что от ОС нам нужен фреймбуфер (точнее, контекст DirectX/OpenGL, ведь щас все аппаратно ускорено), а мы уж сами отрисуем все кнопочки-менюшки своими силами, с большим количеством графона и настроек (привет, WPF). Но все это говно все еще запускается в ОС, так или иначе пользуется ее API для работы с файлами, процессами итп итд. Мы идем еще дальше, мы делаем браузер, который берет фреймбуфер и херачит там страничку, берет всякий WASM и рисует опять-таки все наши кнопочки-менюшки. Возникает, закономерный вопрос. Нахуя нам вся ОС (я не про ядро, драйвера и прочее) с ее ГУИ, API и прочей хуйней, которая висит мертвым грузом и служит, лишь чтобы сраный браузер запустить? Вспоминаются всякие Chrome OS. Но ведь можно дальше пойти. Все, что нам нужно от ОС (кроме ядра, дров, ФС и прочего): композитный менеджер окон, предоставляющий приложениям фреймбуферы и стандартная виртуальная машина. И какой-то АПИ. У нас есть веб-стандарты, почему не может быть стандартов для ОС, описывающих вышеназванное? Но и тут идем дальше. Если у нас стандартное поведение ОС, и предоставляют они некий минимальный функционал, то нахуя нам вообще разные ОС? Дальше лень.
исходники только доступны не везде и не всегда (привет Adobe)
>Если у нас стандартное поведение ОС, и предоставляют они некий минимальный функционал, то нахуя нам вообще разные ОС?
Не взлетит. У нас уже есть POSIX, но он описывает далеко не всё. Но даже если бы описывал:
1)также у нас есть некрософт с хаченным перехаченным win32, который находится за всеми этими вашими gdi и wpf и никуда смываться не планирует
2) у нас есть Яббл с think different головного мозга
3) у нас есть ворох разных юниксов, чьи стоны всё еще слышны из-за спины Тукса
вот поэтому на браузеры и возложили миссию быть кроссплатформенной прослойкой, которая возьмёт на себя всю боль и тяжесть поддержки разных ОС
WASM не поможет, ведь нет исходников, не скомпилировать под WASM-байткод. Это все равно, что скомпилировать под MIPS/ARM/etc. И я более, чем уверен, что у тех же сраных адобов там лютое дрочево, которое не получится легко потрануть простой кросс-компиляцией. Типо SIMD.
Кстати об SIMD. Что насчет поддержки SIMD в WASM? И как это будет, если нам нужно дохуя кросс-платформенно, но у нас есть SSE на старом дерьме, AVX/AVX2/AVX512 на новом дерьме, NEON на ARM итп? .NET типо выкатил какую-то ограниченную поддержку, но там не очень вписывается в то, что WASM - минимальная и легкая "тупая" машина.
> Не взлетит. У нас уже есть POSIX, но он описывает далеко не всё. Но даже если бы описывал:
Тот же WASM помимо собственно ВМ имеет некое подмножество POSIX, какие-то системные вызовы, которые должны быть реализованы WASM-машиной. Например, работа с файлами. Ты дергаешь эти сисколы, а песочница проверяет твои права доступа (ой, а ведь у нас есть ОС, занятые примерно этим).
> также у нас есть некрософт с хаченным перехаченным win32, который находится за всеми этими вашими gdi и wpf и никуда смываться не планирует
И опять WASM идет нахуй как спаситель человечества, потому что если даже под x86 Wine работает через жопу...
> вот поэтому на браузеры и возложили миссию быть кроссплатформенной прослойкой, которая возьмёт на себя всю боль и тяжесть поддержки разных ОС
О чем я и говорю, у нас дохуя старого легаси-говна, и имплементация чего-то нового заключается в нашлеповании новой лепешки поверх легаси говна. Я тут не говорю о каких-то конкретнных способах разрешения всей этой хуйни, я и так понимаю, что сложно, дорого и бизнес, я тут больше за жизнь и о высоких материях пизжу.
а зачем нам исходники WASM? сам WASM отлично скомпилируется под все нужные платформы и без исходников
>Типо SIMD
SIMD-инструкции были доступны даже в JS и доступны в WASM :) И возвращаясь к WebGPU - GPGPU там тоже планируется
>Например, работа с файлами. Ты дергаешь эти сисколы, а песочница проверяет твои права доступа
тут тебе не дырявый Flash, прозрачного доступа к ФС нет, не было и не будет. Есть чернивик File API, к которому будут биндинги.
>И опять WASM идет нахуй как спаситель человечества, потому что если даже под x86 Wine работает через жопу...
srsly? //_- с чего ты взял, что WASM будет дёргать winapi напрямую, если говорилось про браузер как универсальную прослойку?
Когда вы затронули тему софта без исходников, костыльных винапи и прочего говна, я подумал, что вы ведете речь о переносе существующего софта на кроссплатформ с помощью WASM. Мол, взяли "некрософт с хаченным-перехаченным Win32 API" и какой-то магией кросс-платформенно его гоняем.
А WASM - это one more платформа для кроссплатформенного софта, как я это вижу. .NET, JVM, только сбоку и более низкоуровнево.
Я не говорил про прозарчный доступ к ФС, я как раз сказал, что песочница.
да, Blazor пока работает не оптимально, но есть же С/С++, Rust, Go, Swift и даже Kotlin, которые компилируются в WASM напрямую и работают в разы быстрее JS
Тот же V8 - невероятно сложная штука со своими лексическим анализатором, песочницами, многоуровневой jit-оптимазацией и вообще.
Разве не будет прекрасно если вместо этого монстра на ТВОЕЙ машине будет работать легковесная VM, от которой требуется только AOT-компилятор и проверка прав доступа в runtime?
Flash был плагином, который поддерживали Adobe и на сколько я помню, патчили они тоже только они.
WASM- это открытый стандарт и реализация ложится целиком на браузер=> браузеры могут активно сами фиксить уязвимости, а различные проблемы безопасности - это косяки конкретного браузера.
да и сам JS в strict режиме тоже наверняка нормально компилируется в WASM
нет
- строгая типизация на уровне vm (а не транслятора)
- нормальное ООП, а не обвёртка над прототипами
- отсутствие callback hell по умолчанию, а не через promise-костыль
- нормальная многопоточность, а не "нити" одного потока
итд.
нет, серьёзно - список косяков js можно продолжать почти бесконечно, а венчать его всегда будет скорость выполнения
- чем не устраивает ооп на прототипах. Какая разница как оно там внутри сделано? Просто хачу?
- есть воркеры.
А что не так со скоростью выполнения? Собрался риалтайм на джсе кодить? Не выйдет. ИМХО современный js особенно ts приятен и годен к употреблению в своей сфере. Для веба лучшего пока не придумали.
в смысле? как раз устроила бы, если бы была
>Иногда она просто не нужна. Особенно когда обрабатываешь респонс как ни странно.
почему?
>чем не устраивает ооп на прототипах. Какая разница как оно там внутри сделано?
тем, что это неполноценный кастрат. в теле класса даже свойства нельзя определить, lol
>А что не так со скоростью выполнения?
всё с ней не так - и медленная (в разы медленнее даже тех же java и c#), и ресурсоёмкая: быстрая (по меркам js) vm для js просто не может не ЖРАТЬ ресурсы
>Для веба лучшего пока не придумали
уже придумали - прямо сейчас ты комментируешь пост уже даже не про hello world на с++ для wasm, а про полноразмерный framework для SPA-приложений, написанный на высокоуровневом языке
>класса даже свойства нельзя определить, lol
Лол вот беру и определяю. Законом не запрещено.
>полноразмерный framework для SPA
Хуйня. Посмотрю где этот ваш framework будет через 2 года.
Хз, вот некогда не понимал этого. Разве, когда ты работаешь с конкретным REST API тебе заранее, что он тебе вернет?
В чем проблема написать классы?
А то получается, что ты не будешь падать, даже если произойдут какие-то изменения в API и ты не будешь знать о проблеме.
а нам похуй, что тебе похуй, сорян. Нужна проверка типов в runtime, чтобы не ловить потом плавающие баги
>При оброботке сложных и запутанных ответов /запрсов
в том же c# (и не только в нём) можно использовать nullable-типы. А еще, если прям уж очень сильно хочется говна навернуть, есть тип dynamic
>Лол вот беру и определяю. Законом не запрещено.
в ts или в js? речь всё еще про js, если что.
>Хуйня. Посмотрю где этот ваш framework будет через 2 года.
через 2 года в framework завезут компиляцию напрямую в wasm, что резко подтянет производительность и ресурсоёмкость
воркеры - не потоки. предлогаешь eval'ить код переданный текстовым сообщением из основного скрипта?