Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 93
> можно писать Frontend на Go
> Звучит многообещающе
Не соглашусь. Вы можете зайти в интерфейс Google Doubleclick for Publishers, чтобы увидеть, что получится. Там используется Dart-код, который скомпилирован в огромные JS файлы, размером по моему порядка 2-3 Мб. Причем виджет «What's new» идет как отдельный файл такого же размера — похоже, что компилятор заново приинклудил туда все стандартные библиотеки. Грузится это адски медленно и при работе тормозит.
Так что я не хочу фронтенд на Го. Давайте лучше фронтенд на HTML5 и CSS 2.1 делать.
> Звучит многообещающе
Не соглашусь. Вы можете зайти в интерфейс Google Doubleclick for Publishers, чтобы увидеть, что получится. Там используется Dart-код, который скомпилирован в огромные JS файлы, размером по моему порядка 2-3 Мб. Причем виджет «What's new» идет как отдельный файл такого же размера — похоже, что компилятор заново приинклудил туда все стандартные библиотеки. Грузится это адски медленно и при работе тормозит.
Так что я не хочу фронтенд на Го. Давайте лучше фронтенд на HTML5 и CSS 2.1 делать.
Frontend на Go
Там используется Dart-код
Но… это же абсолютно разные вещи?
Если альтернатива — устанавливать что-то на компьютер, то почему бы и нет. Wasm кешируется в скомпилированном виде и работает сразу. Для desktop пара мегабайт не считается чем-то значимым.
Вот можно зайти и поиграть в quake, оригинальный код, скомпилированный в wasm. Работает очень гладко, грузится быстро, действий от пользовалеля, кроме перехода по ссылке, не требует.
Вот можно зайти и поиграть в quake, оригинальный код, скомпилированный в wasm. Работает очень гладко, грузится быстро, действий от пользовалеля, кроме перехода по ссылке, не требует.
Скомпилированный wasm сейчас кешируется только в firefox, остальные браузеры отключили эту возможность из-за безопасности. Firefox это где-то 12% всех браузеров.
QuakeJS is a port of ioquake3 to JavaScript with the help of Emscripten.
Насколько я понимаю, там всё же не wasm, а asm.js
Согласен. Хотя всё равно как бинарник выглядит, если в середину промотать.
Хм, получается, что wasm ещё быстрее работать будет?
Хм, получается, что wasm ещё быстрее работать будет?
Пару моментов:
- Трансляция чего-либо в JS — это совсем не то же, что и трансляция этого же чего-либо в WebAssembly
- Кто сказал, что на Go нужно писать весь фронтэнд? Вполне можно из JS-а вынести «тяжелые» расчёты (криптографию, например)
Во-первых, низкоуровневый язык (wasm) будет требовать больше байт памяти, чем высокоуровневый. Потому маленьким объем не будет. Плюс, люди любят использовать разные библиотеки, и они будут еще сильнее увеличивать объем. Плюс, у языка может быть рантайм, который сам по себе потребует место.
Почему тормозит код гугла на дарт — я не знаю. Может из-за того, что там используется Material Design с анимациями, может из-за этого. Но получился по моему мнению, отвратительного качества продукт. Это он в Хроме тормозит, а в Фаерфоксе или ИЕ вообще страшно туда даже заходить.
Почему тормозит код гугла на дарт — я не знаю. Может из-за того, что там используется Material Design с анимациями, может из-за этого. Но получился по моему мнению, отвратительного качества продукт. Это он в Хроме тормозит, а в Фаерфоксе или ИЕ вообще страшно туда даже заходить.
Я зашел, только вот там интерфейс на ангуляре 1.5 написан., да и собственно кода ангуляровского там от силы 100кб, остальное — тонна аналитики и прочего говна.
А у вас специально в коде местами
i (ай) заменена на l (эл)?func maln, let prlntMessage, #prlntMessageButtonВ оригинале код был в виде картинок. i/l — погрешность оптического распознавания. Просмотрел ещё раз, исправил.
dell
А для чего это нужно на практике? Есть же ангуляр, ву, рекат и вот это всё. Теперь предлагается написать еще один фреймворк только уже на го?
WebAssembly это не очередной фреймворк, это возможность исполнения более низкоуровневого байткода браузером. А это открывает возможность писать фронтенд на языках отличных от JavaScript, вот тут на Go. Интересно пойдет ли это в массы и что будет с JavaScript, когда у него не останется монополии в поддержке браузерами.
Вообще, заменить JS на Go может быть не лучшей идеей. У Го довольно тяжелый рантайм, свой сборщик мусора, ему нужны системные вызовы (+ еще объем для их эмуляции), он там создает кучу потоков. Плюс, если вы хотите взаимодейстовать с DOM, вам придется постоянно выходить из wasm среды в JS интерпретатор и это тоже наверно повлечет расходы.
Компилировать в wasm имеет смысл код для каких-то тяжелых задач — обработка картинок, видео, аудио, генерация PDF и так далее. Для работы с DOM выгоднее использовать JS наверно.
Компилировать в wasm имеет смысл код для каких-то тяжелых задач — обработка картинок, видео, аудио, генерация PDF и так далее. Для работы с DOM выгоднее использовать JS наверно.
Вообще, заменить JS на Go может быть не лучшей идеей
Если вы отвечали мне, то я не говорил что это лучшая идея. Я говорил о равных условиях для всех языков при написания фронтенда. Go это будет или C# или еще что-то — это дело вкуса.
если вы хотите взаимодейстовать с DOM
да, это пока самая большая проблема с wasm, пока они это не решат, технология не зайдет в массы.
У JS тоже довольно тяжёлый рантайм. Другое дело, что, как я понимаю, рантайм любых языков (включая JS, кстати) доставляется для каждой WebAssembly сборки вместе с самой сборкой, статическая линковка, разделяемых библиотек нет в текущих реализациях.
Есть модули. Они могут использоваться в качестве динамически линкуемых библиотек. Другое дело, что пока нет CDN с нужным кодом, который бы использовался совмесно несколькими проектами, но это скорее, вопрос времени.
Ничего не будет, ни один проект не будет делать фронт на Go, если это не сайт для кота конечно. 1) Это не быстро. 2) Это требует штат программистов на go. 3) Это сырая технология которой угнаться за современным вебом будет трудно. 4) Отсутствие хоть какого то здравого смысла. Зачем писать на go если js это стандарт который вырабатывался десятилетиями? Сори, но кроме как баловством это ни как не назвать.
Вы тоже не поняли моего посыла, я не про Го. Я о том, что технология потенциально позволяет писать на чем угодно. Но из ваших аргументов, я могу согласится только с 3), это пока очень и очень сыро.
Во всем остальном совсем не убедительно.
Если посмотреть, что творится в js с кучей webpack, babel, TypeScript и прочих постпроцессоров, то сомневаешься, что это быстро.
Написание на js требует штат программистов на js
Зачем писать на js, если будет новый стандарт, который не обязывает этого делать?
Во всем остальном совсем не убедительно.
1) Это не быстро.
Если посмотреть, что творится в js с кучей webpack, babel, TypeScript и прочих постпроцессоров, то сомневаешься, что это быстро.
2) Это требует штат программистов на go
Написание на js требует штат программистов на js
Зачем писать на go если js это стандарт который вырабатывался десятилетиями
Зачем писать на js, если будет новый стандарт, который не обязывает этого делать?
1) Все эти webpack, babel, TypeScript ставятся одной командой. Да и речь идёт о производительности а не сборе проекта.
2) Штат front-end программистов найти гораздо легче, это проще для бизнеса. Да и не каждый программист на go согласиться заниматься front-end'ом. В добавок ко всему нужно знать не только язык, но и особенности браузера и много чего ещё, т.е. вы должны найти go разработчика который ещё и front-end'ер сам по себе.
4) Браузеры не просто так поддерживают js, по этому это и есть стандарт. Если бы браузеры по умолчанию поддерживали go то он был бы стандартом, а так это всего лишь сомнительная возможность при помощи хаков.
2) Штат front-end программистов найти гораздо легче, это проще для бизнеса. Да и не каждый программист на go согласиться заниматься front-end'ом. В добавок ко всему нужно знать не только язык, но и особенности браузера и много чего ещё, т.е. вы должны найти go разработчика который ещё и front-end'ер сам по себе.
4) Браузеры не просто так поддерживают js, по этому это и есть стандарт. Если бы браузеры по умолчанию поддерживали go то он был бы стандартом, а так это всего лишь сомнительная возможность при помощи хаков.
1) Байт код будет однозначно быстрее
2) Не надо искать именно на Го, надо искать на любом языке, который будет с поддержкой wasm
3) Речь же не про поддержку браузерами Го, а про поддержку браузерами (более) абстрактного байт кода, без привязки к js. Примерно так сделаны JVM и CLR
2) Не надо искать именно на Го, надо искать на любом языке, который будет с поддержкой wasm
3) Речь же не про поддержку браузерами Го, а про поддержку браузерами (более) абстрактного байт кода, без привязки к js. Примерно так сделаны JVM и CLR
Байт код проще парсить. Производительность зависит от конкретной реализации в браузере.
1) Это от задачи зависит, на фронте 90% задач это вывод какой то простых данных с сервера, использовать wasm для решений подобных задачь это всё равно что стрелять из пушки по воробьям. Другое дело конечно как выше уже писали «Doom в браузере».
2) А разница? На других языках точно так же будет не просто найти такого специалиста.
3) Пишется всё равно на go
2) А разница? На других языках точно так же будет не просто найти такого специалиста.
3) Пишется всё равно на go
Ну да, не меняются 
Нужно быть достаточно далёким от веба человеком, что бы утверждать, что он не развивается. GraphQL ещё вспомните если для вас развитие веба упирается во взаимодействие сервера и клиента.
Не до конца понял, что вы имеете ввиду под «кардинальными» изменениями, новый язык разметки, стилей, логики? Таких не будет, они в принципе не возможны, что бы это понять нужно понять как работает веб. Даже простые изменения внедряются аккуратно, чтобы ничего не сломать. И да, данное изменение не «кардинальное» т.к. это по сути хак, который при том работает не стабильно.
Там в имеющихся технологиях хватает изменений, только успевай изучать.
GraphQL, WebGL. Это только чуть капнув. В самом js постоянные изменения. Да и к слову про фреймворки, если это для вас основное что есть во фронте, они меняются, постоянно выходят новые версии, в пристройку к ним идёт куча всего, и новый фреймворк хоть и не обязательно узучать, ознакомиться всегда не помешает.
Например: в HTML нельзя создать в форме несколько кнопок с разными HTTP-методами. До сих пор невозможно создать кнопки в форме с методом UPDATE или DELETE. До сих пор стандартный тег невозможно стилизовать.
да хоть тот же самый display:flex; хорошо подвинул float & inline-block
Кардинальные изменения:
CSS
JS и DOM (aka Dynamic HTML)
XHR и прочий AJAX
WebSockets
*storages
Это только то, что на моей памяти отложилось, что лично меня сильно затронуло как бэкенд-разработчика прежде всего. То есть эти технологии в браузере заставляли меня менять серверные технологии.
CSS
JS и DOM (aka Dynamic HTML)
XHR и прочий AJAX
WebSockets
*storages
Это только то, что на моей памяти отложилось, что лично меня сильно затронуло как бэкенд-разработчика прежде всего. То есть эти технологии в браузере заставляли меня менять серверные технологии.
А если бэкенд написан на Go, а текущий фронт на JS на 80% дублирует его? Одним из главных плюсов NodeJS на бэкенде в вебе считается возможность переиспользования части его кода на фронте и в целом меньший порог входа для фуллстэкеров. wasm в том числе с go поможет обеспечить единую экосистему без (почти) JS.
Наверное, пока основная задача — разделять код логики сервера с клиентом. Ещё wasm показывает себя с лучшей стороны, когда делает что-то, под что не оптимизирован js. Например, потоковая обработка видео. А работать с DOM деревом wasm действительно не умеет — всё через API JS.
А теперь давайте сравним размеры итогового wasm файла условного нетривиального Hello World написанного на Go с примерно такой же программой написанной на Rust/C++. (про текущую производительность график в статье и так достаточно нагляден) Плюс о каких преимуществах Go может идти речь в сугубо однопоточной среде WebAssembly? Без этого Go превращается в непримечательное подобие C со сборщиком мусора. Понятно что хочется тоже запрыгнуть на хайп-трейн, но лично я к Go скомпилированному в WebAssembly весьма скептично.
Потоки будут. + go проще, те же факторы, что и при разработке backend.
Хотелось бы знать, как это будет выглядеть через пару лет.
Хотелось бы знать, как это будет выглядеть через пару лет.
Да какая разница, какой язык :)? Главное, что это язык с нормальной типизацией и фазой компиляции, и на нем не лежит весь груз обратной совместимости со старым кодом.
Как уже выше писали, основная проблема в толстом рантайме. Возможно эту проблему и получится частично решить более продвинутой линковкой и кешированием (что бы, например, рантайм Go был отдельным wasm файлом и расшаривался между сайтами), а так же интеграцией с браузерным сборщиком мусора, но это дело точно не ближайшего будущего. По этим причинами, на мой взгляд, для wasm больше всего подходят C, C++ и Rust, ну может быть D с его Better C (хотя новостей о нём в области wasm я особо не слышал). Причём Rust весьма активно инвестирует в данную область.
Все постигается в сравнении. Без бенчмарков говорить про тольстый рантайм рановато. Unity3D штука не легкая, но вполне можно поиграть в Dead Trigger 2 из браузера.
о пока в wasm не запилят сборщик мусора, с которым можно было бы связать D-шный сборщик, код на таком D будет не очень D-образным, с ручной аллокацией-деаллокацией.
Не будет. То что нет GC в wasm, не значит что GC не может быть на уровне языка, как часть его runtime.
В том то и дело что уже давно есть Typescript с поддрежкой типизации, дженериков, нормальных классов с инкапсуляцией. Переводить весь фронт на го или раст нет никакого смысла, особенно экономического. Вынести что-то тяжеловесно еможет быть и да. Или портировать готвовую кодовую базу. Но не более.
Ну в общем-то, переводить весь фронт на go никто и не предлагает. Тут суть немножко в другом. Вот скажем, реальный пример — есть такая штука, как graphviz, некая тулза для показа графов. Написана на C, в какой-то степени кроссплатформенно. Консольная утилита. Ну так вот, ее при помощи emscripten кажется, затащили в браузер.
Т.е. изначально была некая полезная функциональность, которую не переписывая затащили в веб. go тут может быть полезен ровно для тех же целей, на мой взгляд.
Т.е. изначально была некая полезная функциональность, которую не переписывая затащили в веб. go тут может быть полезен ровно для тех же целей, на мой взгляд.
вот и Go подтянулся… до этого пробоаал blazor (c#) — прикольно, уже можно что-то начать делать…
С одной стороны бета (даже скорее альфа) версия, с другой — уровень production ready зачастую можем определить и самостоятельно. Это просто риск :)
Для небольших поделок, когда к какому-то сервису прикрутить простенький GUI пойдет. На большее — оно пока в альфа было… Может что и поменяется в API.
Да, видел байдинги к DevExtreme. Не успел разобраться ещё, но думаю попробовать что-то сбацать…
Для небольших поделок, когда к какому-то сервису прикрутить простенький GUI пойдет. На большее — оно пока в альфа было… Может что и поменяется в API.
Да, видел байдинги к DevExtreme. Не успел разобраться ещё, но думаю попробовать что-то сбацать…
Да, следует упомянуть поддержку в последней версии Visual Studio. Да, еще есть такой туториал www.codeproject.com/Articles/1251603/ASP-NET-Core-Blazor-Master-Detail-CRUD-with-Filter
А воообще запускать скомпилированный бинарный код в браузере… это же не безопасно, мы разве к этому идем? у Java не получилось
В том-то и отличие, что безопасно. Бинарный код заперт в песочнице конкретного размера, и уничтожается, при попытке обратится за её пределы. Также, там нет системных вызовов, всё делается только через JS API, которое считается безопасным.
JVM и WASM серьёзно отличаются друг от друга.
WASM вписывается в существующую архитектуру web, не пытается тащить свои виджеты.
WASM добавлен в движок JS, стандарт является открытым.
WASM не привязан к какому-либо языку.
Есть более подробное обсуждение.
JVM и WASM серьёзно отличаются друг от друга.
WASM вписывается в существующую архитектуру web, не пытается тащить свои виджеты.
WASM добавлен в движок JS, стандарт является открытым.
WASM не привязан к какому-либо языку.
Есть более подробное обсуждение.
>JVM и WASM серьёзно отличаются друг от друга.
Неубедительно.
>WASM вписывается в существующую архитектуру web, не пытается тащить свои
виджеты.
Аплеты — это далеко не про виджеты, и их проблемы безопасности тоже лежат совсем не в области виджетов.
>WASM добавлен в движок JS, стандарт является открытым.
Байткод JVM тоже стандартный и хорошо описан. «wasm добавлен в движок JS» — по-моему это совершенно разные движки.
>WASM не привязан к какому-либо языку.
JVM тоже.
И?
JVM (да и flash кажется) тоже в песочнице. Но все дело в том, что как только вы пытаетесь этому коду что-то полезное разрешить, вам нужно песочнице предоставить API, скажем для доступа к геолокации, или к bluetooth, или еще к чему-то, даже к DOM например, или доступ к JS, и который вы совершенно напрасно считаете безопасным. Большое число CVE в JS движках тому подтверждение.
Принципиальная разница может быть только в одном случае — если вы научитесь статически валидировать байткод wasm (для байткода JVM это невозможно, для flash насколько я знаю — тоже), а возможность валидации для wasm по-моему никто не показал. Так что в текущем виде это все теории.
Неубедительно.
>WASM вписывается в существующую архитектуру web, не пытается тащить свои
виджеты.
Аплеты — это далеко не про виджеты, и их проблемы безопасности тоже лежат совсем не в области виджетов.
>WASM добавлен в движок JS, стандарт является открытым.
Байткод JVM тоже стандартный и хорошо описан. «wasm добавлен в движок JS» — по-моему это совершенно разные движки.
>WASM не привязан к какому-либо языку.
JVM тоже.
И?
JVM (да и flash кажется) тоже в песочнице. Но все дело в том, что как только вы пытаетесь этому коду что-то полезное разрешить, вам нужно песочнице предоставить API, скажем для доступа к геолокации, или к bluetooth, или еще к чему-то, даже к DOM например, или доступ к JS, и который вы совершенно напрасно считаете безопасным. Большое число CVE в JS движках тому подтверждение.
Принципиальная разница может быть только в одном случае — если вы научитесь статически валидировать байткод wasm (для байткода JVM это невозможно, для flash насколько я знаю — тоже), а возможность валидации для wasm по-моему никто не показал. Так что в текущем виде это все теории.
Какую валидацию ожидаете? Обратились за пределы выделенной памяти, получаете ошибку выполнения. Допустили переполнения целых чисел, получаете ошибку выполнения.
То что вы перечисляете — это вообще не статическая валидация. Такого, простите, полно и в JVM.
И это не спасает от выхода за пределы песочницы, потому что большая часть дыр в безопасности JVM в случае апплетов (да и вообще) выглядела примерно так: вы вызываете некий метод API, который потом дергает ваш callback, но делает это в контексте с повышенными привилегиями.
Более того, переполнение чисел и в JS контроллируется. Ниче, что уязвимости типа spectre можно прямо из браузера эксплуатировать?
И это не спасает от выхода за пределы песочницы, потому что большая часть дыр в безопасности JVM в случае апплетов (да и вообще) выглядела примерно так: вы вызываете некий метод API, который потом дергает ваш callback, но делает это в контексте с повышенными привилегиями.
Более того, переполнение чисел и в JS контроллируется. Ниче, что уязвимости типа spectre можно прямо из браузера эксплуатировать?
Вопрос был, что вы ожидаете от статической валидации? Если небезопасный код приводит к ошибке выполнения, то нужна ли статическая валидация, или достаточно проверок во время выполнения.
>Вопрос был, что вы ожидаете от статической валидации
Доказательства безопасности.
Да, во многих случаях есть возможность эксплуатации дыр более низкого уровня, вплоть до железа. Я не думаю и не рассчитываю, что wasm обеспечит некую невозможность эксплуатации spectre, условно говоря. Это было бы слишком строго. Хорошо если своих дыр не будет.
Но проверки времени выполнения — это ровно то, что есть и было в JVM. Там есть эти проверки, что не мешало регулярно находить в них дырки в безопасности, потому что авторы этих проверок — обычные люди, потому что пишутся они на обычном языке (java, например, или C++), и им свойственно ошибаться.
Я готов в принципе поверить, что более простая виртуальная машина wasm окажется в итоге надежнее и лучше — это нормальный довод, но это не 100% доказательство.
Доказательства безопасности.
Да, во многих случаях есть возможность эксплуатации дыр более низкого уровня, вплоть до железа. Я не думаю и не рассчитываю, что wasm обеспечит некую невозможность эксплуатации spectre, условно говоря. Это было бы слишком строго. Хорошо если своих дыр не будет.
Но проверки времени выполнения — это ровно то, что есть и было в JVM. Там есть эти проверки, что не мешало регулярно находить в них дырки в безопасности, потому что авторы этих проверок — обычные люди, потому что пишутся они на обычном языке (java, например, или C++), и им свойственно ошибаться.
Я готов в принципе поверить, что более простая виртуальная машина wasm окажется в итоге надежнее и лучше — это нормальный довод, но это не 100% доказательство.
Доказательства безопасности.
Это не является доказательством безопасности. Статический анализ не защитит от обращения в память другого процесса.
Я не думаю и не рассчитываю, что wasm обеспечит некую невозможность эксплуатации spectre, условно говоря. Это было бы слишком строго.
Wasm это инструкции, для абстрактного процессора, поэтому по определению он не может служить источником эксплуатации spectre. Спецификации довольно строки. C++ который успешно выполнялся в Asm.js, стал падать в wasm, undefined behavior из C++ выстрелил нам в ногу.
виртуальная машина wasm окажется в итоге надежнее и лучше
Скажу по секрету, её нет. Все выполняется тем же движком, что и JS.
>Статический анализ не защитит от обращения в память другого процесса.
Для некоторого класса программ — может защитить. Я видел работы по статической верификации IL — и насколько я понимаю, wasm существенно проще. Во всяком случае другие широко известные методы — все хуже.
>Wasm это инструкции, для абстрактного процессора, поэтому по определению он не может служить источником эксплуатации spectre.
Я не буду настаивать, но по-моему вы ошибаетесь. Не конкретно насчет spectre, но насчет чуть более широкого класса уязвимостей — скорее всего. Все что связано с таймингом — не требует какого-то специального набора инструкций для эксплуатации.
Для некоторого класса программ — может защитить. Я видел работы по статической верификации IL — и насколько я понимаю, wasm существенно проще. Во всяком случае другие широко известные методы — все хуже.
>Wasm это инструкции, для абстрактного процессора, поэтому по определению он не может служить источником эксплуатации spectre.
Я не буду настаивать, но по-моему вы ошибаетесь. Не конкретно насчет spectre, но насчет чуть более широкого класса уязвимостей — скорее всего. Все что связано с таймингом — не требует какого-то специального набора инструкций для эксплуатации.
Да, заметьте — spectre chrome POC использует только sharedarraybuffer, и воркеры. И ничего больше.
Заметьте, что это не имеет отношения в байт коду.
Прямого не имеет. Это был ответ на вашу фразу:
>wasm это инструкции, для абстрактного процессора, поэтому по определению он не может служить источником эксплуатации spectre.
Для эксплуатации варианта spectre из javascript оказалось достаточно SharedArrayBuffer (фактически — массив), и воркеров (фактически — параллельные потоки). Ничего такого уж специального тут нет. Я не говорю, что на wasm ровно такое же возможно — я говорю, что атаки такого типа на абстрактный процессор вполне возможно себе вообразить.
>приведите пример этих классов.
Ну я же вроде писал уже — для CLR я видел такую работу. Это было исследование от MS, на тему статического доказательства безопасности IL. То есть такой класс программ — почти все программы на C#, например.
>wasm это инструкции, для абстрактного процессора, поэтому по определению он не может служить источником эксплуатации spectre.
Для эксплуатации варианта spectre из javascript оказалось достаточно SharedArrayBuffer (фактически — массив), и воркеров (фактически — параллельные потоки). Ничего такого уж специального тут нет. Я не говорю, что на wasm ровно такое же возможно — я говорю, что атаки такого типа на абстрактный процессор вполне возможно себе вообразить.
>приведите пример этих классов.
Ну я же вроде писал уже — для CLR я видел такую работу. Это было исследование от MS, на тему статического доказательства безопасности IL. То есть такой класс программ — почти все программы на C#, например.
Отсюда следует, что вы видели, но содержимого не знаете. Отлично.
У каждого свои недостатки (с). Я даже найти ту статью не смогу, потому что это совершенно не мой профиль.
Мне вполне достаточно было практического вывода — что некие доказательства правильности вполне возможны для языка такой сложности, как IL, изначально не задуманного специально для такой цели, чтобы доказывать про него теоремы.
Мне вполне достаточно было практического вывода — что некие доказательства правильности вполне возможны для языка такой сложности, как IL, изначально не задуманного специально для такой цели, чтобы доказывать про него теоремы.
У Java другой подход. Интерпретатор байт-кода — внешний бинарник по отношению к браузеру, напрямую взаимодействующий с ОС. И, насколько я знаю, никто не писал чисто браузерные JVM, брали стандартную и прикручивали бридж к браузеру. Здесь же VM часть браузера, такая же как интерпретатор JS с теми же рисками безопасности. Или даже обособленная часть интерпретатора JS.
>c теми же рисками безопасности
Ну да. Так это и выглядит на посторонний взгляд.
Если все, кроме «числомолотилки» делается через JS API — но это, простите, означает, что безопасность wasm для этих случаев будет такой же, как в JS. С чего бы ей быть лучше — непонятно.
Ну да. Так это и выглядит на посторонний взгляд.
Если все, кроме «числомолотилки» делается через JS API — но это, простите, означает, что безопасность wasm для этих случаев будет такой же, как в JS. С чего бы ей быть лучше — непонятно.
А кто-то где-то утверждал, что у wasm будет с безопасностью лучше чем у js? Насколько я знаю, утверждения были, что будет лучше чем у java апплетов и прочих бриджей из браузерной песочницы во внешний мир.
Ну вот же: habr.com/post/417563/?reply_to=18914011#comment_18898205
Тут прямо написано — безопасно. Я на это и ответил изначально.
Тут прямо написано — безопасно. Я на это и ответил изначально.
Безопасней чем Java-аплеты и такая же безопасность как у «исходников» JavaScript. То есть от компиляции в бинарный код безопасность не уменьшается, а вроде даже увеличивается, поскольку песочница wasm лишь часть песочницы JS. Да, могут быть уязвимости в реализациях, но концептуально это самый безопасный способ исполнять код в браузере из имеющихся.
>Да, могут быть уязвимости в реализациях
Я ни разу не спорю, что реализация wasm должна быть надежнее. Все рассчитано на то, что уязвимостей в ней будет меньше, потому что язык проще. И это в общем правда — но это в тоже время и не гарантия.
И пока/поскольку песочница wasm многие вещи делает через js api, то все уязвимости последней должны быть также доступны из первой. Может я чего не вижу, но почему нет-то, где тот механизм, который помешает вызвать нехороший js код?
Я ни разу не спорю, что реализация wasm должна быть надежнее. Все рассчитано на то, что уязвимостей в ней будет меньше, потому что язык проще. И это в общем правда — но это в тоже время и не гарантия.
И пока/поскольку песочница wasm многие вещи делает через js api, то все уязвимости последней должны быть также доступны из первой. Может я чего не вижу, но почему нет-то, где тот механизм, который помешает вызвать нехороший js код?
А используя emscripten уже можно тензорфлоу запускать на джаваскрипт в браузере. И что? Что за мания пихать все что можно во все что не нужно.
Возможно wasm станет в какой-то степени альтернативой умершему флешу.
И наверное отлично подойдет для создания каких нибудь сложных калькулятор с 3D моделями. Что-то вроде констурктора кухонь, где можно двигать элементы в 3D пространстве, менять их размеры и т.д.
Т.е. каких-то очень проприетарных приложений.
На JS и сегодняшних инструментах такие вещи получаются очень сложными и тяжелыми для браузере.
А обычные веб-приложения, где есть активное и типичное взаимодействие с DOM скорее всего будут не для него, слишком неудобен он для них.
И наверное отлично подойдет для создания каких нибудь сложных калькулятор с 3D моделями. Что-то вроде констурктора кухонь, где можно двигать элементы в 3D пространстве, менять их размеры и т.д.
Т.е. каких-то очень проприетарных приложений.
На JS и сегодняшних инструментах такие вещи получаются очень сложными и тяжелыми для браузере.
А обычные веб-приложения, где есть активное и типичное взаимодействие с DOM скорее всего будут не для него, слишком неудобен он для них.
Есть суперсложный пример, завоевывающий сейчас рынок дизайн инструментов — Figma. Это пример того как можно делать сложные Online приложение, а также показатель стабильности wasm
DOM и прочее вщаимодействие с внешним миром можно оставить JS, а с помощью wasm избавиться от дублирования логики на разных языках на фронте и бэке. Банальная валидация, например.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Благодаря WebAssembly можно писать Frontend на Go