WebAssembly - встречайте на арене цирка

8 тем ниже, ага?

Иными словами все более-менее адекватные разработчики будут использовать этот webassembly как аналог cffi. Скомпилят нужную либу, к проекту подключат, а проект будет по прежнему на js или одной из его разновидностей. Всё лучше, чем преодолевать кучу проблем у разных браузеров при попытке подсоединить что-то нативное для скорости. А тут даже права как у расширений не нужны.

Бедные пердаки тех, кто мечтал, чтобы веб разработчики либо перешли на С++ либо ушли из профессии.

Его автор у меня в игноре, потому не увидел :)

Ну надо понимать, что размер таких бинарников все равно будет приличным. Это конечно не такой звиздец как asmjs после ecmascripten, но все равно до фига. Хотя многих это не остановит.

Мне больше понравилось, что все смогли договориться в фантастически короткие сроки.

Ура, можно будет писать клиентсайд на пхп!

Обломись бабка, на похапе пока можно только площадь ильича считать. Маршалинг объектов еще не привернули.

Размер точно не остановит, теперь страницы, которые ничего не делают, но на старте тянут по крайней мере 5 мегабайт уже норма и вполне прилично отрабатываются даже на мобильниках. Сразу народ тянуть вещи вроде ffmpeg не будут, но по мелочи, zlib, expat, ffmpeg частями - за милую душу:)

А договорится смогли потому что это как бы заход с боку. Ничего не ломается и ни с чем не конфликтует. Плюс не особо сложно в реализации, это немаловажно. Плюс огромному числу разработчиков как раз и надо втянуть в веб привычные компоненты.

А смысл? Всё равно будешь дёргать серверный php, который будет дёргать mysql и так только пупок будет развязываться от сложности. php хорош тем, что просто и удобен.

С другой стороны теперь будет проще писать чисто js приложения, которые будут использовать только amazon для хранения всего. А разные компоненты, которые будут декодировать бинарное говно(медиа, сжатые данные и просто бинарные структуры для компактности) сохранённое на amazon - будут тащить из C++, компилять в WebAssembly и тут уже можно передавать привет тем, кто кричал про конец Javascript:)

Его автор у меня в игноре, потому не увидел :)

Спасибо, пометил.

Сколько гигабайт ОЗУ надо?

А вот это кстати, при грамотном использовании, наоборот может полегчать. Но по факту - вряд ли. То есть если народ будет тянуть только нужные либы для ускорения чего-нибудь, то те тормозные дубликаты, что сейчас есть на js испарятся(например браузерный клиент какого-нибудь spice будет большей частью на С и работать будет почти как нативный). Но народ потянет не только мелкие либы, он потянет всё что сможет потянуть. Причём каждый сайт! Поэтому скоро появится новая проблема, как бы так то что сайты тянут скомпилированное как-нибудь кешировать или вообще подгружать прямо в браузер из npm. Но это только ещё дальше развяжет руки.

Так уж сложилось, веб жиреет, и не важно с webassembly или без него.

Вангую, что будет жрать больше чем js при большем же количестве дыр.

Думаю да, лет 5, пока не подточат под нужды.

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

Понимаю, зачем оно им надо, но энтузиазма, как минималист, не испытываю. Для моих нужд и JS - через глаза, а тут ещё одна сущность, для того самого.

Сомневаюсь. ЖС жрет под неэпические оптимизации динамики, которой тут просто нет. Она осталась на более высоких уровнях, которые выпилили за ненадобностью.

Другой вопрос, надо ли было изобретать новый общий формат байткода, но это трансцендентная область.

Дыр больше не станет, исполняторы байткода те же.

Так вот в лоб это вряд ли будет работать. По крайней мере все крупные сайты будут апдейтить свои бинарники пару раз в день, приписывая версию, примерно как сейчас с js происходит. Но да, можно замутить браузерный npm и все зависимости проекта выносить туда. Примерно так и будут в конечном счёте делать, поможет ли - поживём увидим.

Тебе повезло. А мне вот надо было ресайзер картинок делать. И все было хорошо, пока не захотел unsharp mask ввернуть через HSL.

Как js на сервере, только наоборот. Один язык для всего.

Зачем куча тем?

Вот же обсуждение есть: Бинарный интернет опять на пороге

Опенсорс же. Каждый пилит свою тему.

А мне вот надо было ресайзер картинок делать

Если не секрет, зачем понадобилось это прямо у клиента делать, а не на сервере заранее подготовить нужные картинки? Что этот сайт делает?

Так не получится, потому что этот php надо будет приклеить ко всем частям браузера как сейчас приклеен js, а это не факт что webassembly так будет сделан. Планы есть, но насколько эти планы будут реализованы в полном объёме и насколько то что будет реализовано можно будет удобно использовать. Скажем можно ли будет из php клиентского в конечном счёте сделать так: element->style[«color»] = «black» или придётся как-то так: element->getProperty(«style»)->setValue(«color», «black»); element->applyChanges(); Но даже если и будет удобно, не уж-то будет удобнее js? То есть тут вот какое дело. Js на клиенте удобен + js на сервере, дающий простейший rest интерфейс тоже удобен, в сочетании с клиентским angular or whatever шаблонированием.

Допустим всё зашибись и php удобен, не уж-то будете использовать <?php ?> шаблоны на клиенте? И что, тогда в php ещё засунут работу с virtual dom, чтобы эти шаблоны котировались на фоне angular и прочих?

Теперь не тормозит?

Намана, похапе для логики, джаваскрипт как шаблонизатор!)

https://github.com/nodeca/pica#pica---high-quality-image-resize-in-browser развлекайсо

Юзеры пытаются закачивать котиков в овердохрена мегапикселей. Им это долго, потому что большие файлы. Серверу это долго когда много больших картинок. Выгоднее мегапиксели на клиенте предварительно свести к вменяемому размеру. А на сервере уже только мелкие превьюшки достроить.

Теперь будут думать как со всей этой хренодельней взлететь :)

Юзеры пытаются закачивать котиков в овердохрена мегапикселей

Ааа, понятно. :)

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

Т.е. испортить пользовательские данные? Отлично, отлично.

http://jsil.org/

Ты совсем позеленел, даже забыл предложить белорусский рубль.

В WebAssembly не требуется применение сборщика мусора, так как применяется явное управление памятью

нет gc --- это теперь плюс? :)

PHP в принципе сомнительная штука, однако ж пользуются. А уж если пойдёт, то и синтаксического сахара туда будет насыпано, и работу с чем угодно добавят.

Пользуются потому что легаси. Старое говнище суппортить как-то надо, а новое на нем делать уже смысла нет.

Ещё как делают, причём с нуля часто используя относительно свежие фреймворки. Вот прямо сейчас в таком проекте участвую. Но сдаётся мне, это всё таки просто пехепешники доросли до высшего менеджмента и консультантов и пропихивают такие решения:)

а при чем тут белорусский рубль?

нет gc --- это теперь плюс? :)

Конечно. Кому надо, тот сделает поверх свой GC с бдж и ш.

Проприетарщики с копирастами нервно потирают потные рученки и что-то шепчут про drm.

А если серьезно, то это выгодно в первую очередь гуюглу с его Хромосом и облачными сервисами.

Я не говорил, что на пыхе новое не делают или невозможно сделать. Я сказал что это бессмысленно.

Просто есть остаточные явления. Например бизнес перекидывает человеческие ресурсы с пыховского легаси. Или кому-то нравится пых и он хочет на нем писать.

Не совсем, хотя и в большей степени будет ими использоваться просто потому, что они теперь и делают всё что люди используют:)

Тут дело в том, что веб теперь это инструмент не только и не столько для сайтов, сколько для приложений. И как следствие и появились новые задачи(которые пока можно решить только если ваше приложение это расширение браузера, то есть например подгрузить нужную либу для конвертирования изображения или что-нибудь подобное) и в веб приехали обычные разработчики, которые не привыкли к тонне ограничений. Им нужны привычные инструменты. При этом писать на js они могут без проблем, но он просто не позволяет писать всякие числодробилки и использовать уже готовые числодробилки. Хреново работает с бинарными форматами и тд. Поэтом выгодно будет не только гуглу, а всем кто пишет кросс-платформенный софт в виде веб приложений.

Проприетарщики с копирастами нервно потирают потные рученки

Ну так это видно невооружённым глазом. Главное ведь, чтобы каждый сверчок знал свой шесток.

это выгодно в первую очередь гуюглу с его Хромосом и облачными сервисами

ChromeOS и с PNaCl себя вполне неплохо чувствует.

И привиделось мне страшное...те макаки, что сейчас ваяют на electron+node.js+chromium десктопные приложения, будут их ваять на electron+node.js*+wasm**...вот это будет лютый overhead...
___
*судя по названию опции в ff этот самый wasm неотрывно с ним связан\
**с каким-нибудь gtk3/qt5 для отрисовки интерфейса

Вангую «нэйтивный» typescript и таки закапывание всех уродств js.

А разумный для сохранения размер canvas оставить не достаточно качественно?

Там даже демка есть. Открой и посмотри.

PNaCl - это какая-то локальная разработка гугла, которую никто особо не подхватил. А тут будет универсальное решение для всех браузеров, следовательно и web-приложений будет гораздо больше, а учитывая дурную тенденцию переносить все в web хромобуки внезапно превратятся из дешевых и бесполезный в дешевые и функциональные устройства.

Кошмар какой. Проще сказать пользователю: «утебя слишком большая картинка дурень», если ему _действительно_ необходимо что-то залить, то он найдет способ уменьшить, а если очередная «еда для whoreграмма», то и фиг-бы с ней.

Не получится. Они начнут плакать и лезть в техподдежку с тупыми вопросами. В итоге всем плохо и все теряют время. Это плохое решение.