Вчера Брендан Айк “взорвал” сообщество веб-разработки: веб получит новый низкоуровневый бинарный компилируемый формат, который будет работать гораздо лучше, чем JavaScript.Google, Microsoft, Mozilla, а также несколько независимых специалистов работают над новым проектом в W3C WebAssembly Community Group, и то, над чем они работают, совсем не маленькая вещь.
WebAssembly — это:
- Улучшение JavaScript: Реализуйте все критичные вещи на wasm (сокращение от WebAssembly — прим. переводчика) и импортируйте его как стандартный JavaScript модуль.
- Новый язык программирования: WebAssembly определяет абстрактное синтаксическое дерево (как и JavaScript) в бинарном формате. Вы можете писать код и чистить его от ошибок в текстовом формате. WebAssembly легко читаем.
- Улучшение для браузеров: Браузеры будут понимать бинарный формат, а это значит, что разработчики смогут компилировать бинарники, которые можно сжать гораздо больше, чем используемые сегодня текстовые файлы с JavaScript. Чем меньше файл, тем быстрее загрузка. В зависимости от возможностей оптимизации времени компиляции, код на WebAssembly может передаваться и запускаться быстрее, чем на JavaScript!
- Целевая компиляций: Возможность другим языкам, получить первоклассную двоичную поддержку через весь стек веб-платформы.
Что это значит для JavaScript?
Прежде, чем ответить на этот вопрос, давайте отмотаем время назад. Вернемся во времена до React, Angular, Backbone и jQuery.
Вот мы и на месте.
Сеть — это набор гипертекстовых документов, отображаемых с помощью систем доставки сообщений, которые, однако, пока еще не связаны между собой. Первый веб-сервер был запущен на компьютере NeXT (см. ниже) в ЦЕРНе…
На дворе 1991 год. Я еще не успел поседеть. Я пытаюсь взломать десятитысячную текстовую игру-квест (я их все не считал).
Я выбрал своеобразный язык программирования для этой цели. На тот момент мне уже успел надоесть и BASIC, и Pascal. Я хотел использовать С, но не мог: я все еще копил на коробочную версию Borland Turbo C++ (они буквально приходят в упакованных коробках с инструкцией и установочным диском). Тогда у меня не было даже простейшего Turbo Assembler.
Я писал на языке ассемблера и “компилировал” в исполняемую программу с помощью командной строки в ДОСе и “debug”. Если это звучит безумно, поверьте мне, так оно и было. Держу пари, что даже те из Вас, которым посчастливилось работать с ДОС, не знают, что можно использовать “debug” для отладки ассемблера и диссасемблеризации (обратный инжиринг) существующего кода.
Звучит круто? Нет. Я ненавидел это. Я не мог дождаться момента, когда смогу сесть за новенький Borland Turbo C++ и программировать по-человечески. В общем, мне его подарили. Ура!
Мне нравился Borland Turbo C++ потому, что на нем был предустановлен Borland Turbo Assembler. Что?! Зачем программировать на языке ассемблера, когда у тебя есть замечательный высокоуровневый, объектно-ориентированный инструмент C++?
Иногда вы хотите работать с голым железом, или близким к нему, без плавления мозга. Кстати, я упоминал что написал много машинного кода до использования C++?
Я сошел с ума.Добиться реальных результатов не так легко, когда пишешь код на языке ассемблера. Тогда зачем же нам нужен WebAssembly?
Мы нуждаемся в WebAssembly потому, что при всей гибкости Javascript, все еще сложно представить много вещей, которые мы бы хотели в нем видеть, и особенности языка, которые нам нужно туда добавить, только усложнят язык, что уже смущает пользователей.
WebAssembly позволяет нам работать с простыми, низкоуровневыми блоками кода, которые можно использовать для программирования чего угодно.
Чем он отличается от JavaScript? Ключевое слово — “низкоуровневый”. Он определяет примитивы, включая ряд типов и операций над этими типами, литералы для них, control-flow, вызовы, кучи и т.д.
Это очень простые примитивы. Ничего сложного. Нет сложной объектной системы (прототипной или какой-то другой). Нет встроенной, автоматической “сборки мусора” следующей за Вами и периодически Вас останавливающей, когда ей нужно собрать мусор.
На самом деле, это будет полезным, чтобы не думать о WebAssembly как о языке вообще. Это больше похоже на машину, немного похожую на машину Тьюринга...
Что же такое WebAssembly?
WebAssembly определяет абстрактное синтаксическое дерево(AST), которое хранится в бинарном формате. Бинарность это здорово, так как позволяет создавать меньшие приложения. Наверняка вы задаетесь вопросом, как можно отлаживать бинарный код.
К счастью, уже сейчас активно идет разработка отладчика, который будет работать в браузерах, а абстрактное синтаксическое дерево будет представлено в (относительно) легко читаемом текстовом формате. Я бы хотел показать примеры, но их пока не особо много. Пожалуй, код на WebAssembly будет все же прочитать сложнее, чем аналогичный код, написанный руками на JavaScript, но, его как минимум будет так же легко читать, как ASM.js. Может даже и легче. Посмотрим.
Для чего будет использоваться WebAssembly?
Среди всего прочего, его можно будет использовать для простой работы с тредами и SIMD (single instruction, multiple data) — проще говоря, с одним потоком команд и несколькими потоками данных. Вы можете поставить в очередь множество блоков данных, а затем прописать одну команду для одновременной работы с ними.
Это значит, что параллельная обработка потокового видео будет обрабатываться процессором. Если вы держите руку на пульсе, то слышали об этом решении в JS, но я всегда считал неудобным решать низкоуровневые вещи посредством JavaScript.
Именно в таких случаях Вам, пожалуй, стоит забыть про объектную систему, “уборщики мусора” и динамическую обработку запросов. Просто поставьте потоки данных в очередь и максимально быстро и эффективно обработайте их.
Как насчет приложений?
На настоящий момент, такие приложения, как Ableton Live (написание музыки) и Adobe Premiere Pro (создание видео), не слишком подходят для портирования в Веб. Замечу, что это возможно, но все же пока затруднительно. Надо решить еще много проблем. Например, надо решить, как лучше синхронизировать данные для real-time приложений.
Кроме того, можно будет разрабатывать приложения, которые будут передавать большие объемы данных через сети обрабатывающих функций. Например, такие, как приложение гитарной педали. Когда люди задумываются о таких вещах, они как правило не думают о JavaScript. Много людей вероятно думают, что это чистое сумасшествие, чтобы даже попытаться.
Но, в любом случае, JavaScript — действительно отличный язык, чтобы построить большую часть приложения, о котором вы только можете мечтать.
WebAssembly органично заполнит пробелы, которые есть в функциональности JavaScript.Пробелы в функциональности JavaScript есть, и это далеко не секрет. Даже самые преданные его фанаты вряд будут спорить с утверждением, что порой язык пытается “проглотить” слишком много, теряя гибкость и эффективность. Еще вчера я думал, что эти пробелы можно устранить, просто добавив больше функциональности в сам JavaScript. Брендан Айк предложил тот же путь на конференции Fluent. Я аплодировал.
Однако, все это время мы упускали один момент: все хотят программировать на языке высокого уровня, но в то же время и иметь возможность “опускаться” до языка ассемблера, когда надо увеличить скорость.
WebAssembly может увеличить скорость JavaScript в разы!Я уверен, что сегодня по всей Сети появятся десятки, если не сотни, статей про WebAssembly. Я более чем уверен, что большая их часть будет посвящена не тому, о чем я писал ранее, а совсем другой особенности этого языка программирования. От нее я, кстати, тоже в восторге.
WebAssembly позволяет использовать больше языков в веб-разработке
Конечно, на самом деле нам не нужен WebAssembly, чтобы использовать в веб-разработке другие языки программирования. Например, у нас уже есть отличные игровые AAA-движки, которые прекрасно работают с компиляцией из JavaScript.
Если вы слышите, что JavaScript работает медленно… Это не так.WebAssembly добавляет вещи, которые большинство JS разработчиков не хотят видеть в JavaScript. Сама функциональность нужна, но вот в JavaScript ей места точно нет. Тем более, что мы можем получить все эти функции с помощью компиляции с других языков программирования.
Фактически, WebAssembly предоставляет нам альтернативный компилятор — созданный специально для этих целей.
Теперь, нам будет гораздо легче портировать код, который сильно зависит от, например, совместно используемых цепочек памяти. Я уверен, что написать компилятор для WebAssembly будет легче, чем написать компилятор для JavaScript, а все потому, что первый гарантирует лучший перенос функций языка в заданное абстрактное синтаксическое дерево.
То, что все старые языки программирования теперь без проблем могут быть использованы в Сети — это хорошо, однако главное не в этом. Дело в том, что:
WebAssembly является отличным основанием для разработчиков начать работу над новыми языками программирования.Сеть ожидает большое будущее. Так что лучше выходить из тени и браться за дело, пока не поздно.
Дополнения + FAQ
В: Что такое wasm?
О: Сокращение от WebAssembly.
В: Почему бы не использовать JVM?
О: Попытки добавить JVM в браузеры с помощью плагинов были и не раз. К сожалению, ничего хорошего из этого не вышло. В JavaScript есть встроенная виртуальная машина, поэтому добавление еще одной приводит к появлению второго набора API подключений, чтобы дать виртуальной машине доступ к DOM, сетям, сенсорам, устройствам ввода и т.п. За это придется кое чем пожертвовать. Например, как будут процессы в виртуальной машине распределять между собой имеющиеся ресурсы? Ответить на этот вопрос сложнее, чем кажется.
Сначала, WebAssembly будет работать как ASM.js полифил, то есть он сможет использовать виртуальную машину JavaScript. Дизайн языка развился исходя именно из этого, и именно поэтому в WebAssembly будет более гладкая интеграция с браузерами, чем могут предложить альтернативные виртуальные машины.
В: Означает ли появление WebAssembly, что в будущем появится много новых языков программирования? Не приведет ли это к фрагментации?
JavaScript в полной безопасности. Его экосистема будет процветать еще много лет. WebAssembly больше касается производительности, разнообразия и движения вперед, а не фрагментации.О: У JavaScript всегда была очень серьезная конкуренция на стороне сервера, а также в программировании для встраиваемых систем, таких как небольшие компьютеры и роботы. Несмотря на наличие большого количества довольно неплохих альтернатив с развитыми экосистемами и профессиональными командами разработчиков, Node продолжает быстрыми темпами наращивать присутствие на серверах стартапов и коммерческих предприятий.
К тому же, JavaScript имеет неплохую поддержку в лице плеяды разработчиков, а также мощной экосистемы. Я люблю добавлять в статьи графики популярности различных модулей. Смотришь на эти кривые и поражаешься.
Обратите внимание на зеленую кривую. Это npm, стандартный репозиторий для JavaScript, который поставляется в связке с Node.
JavaScript все чаще используется в разработке игр, в программировании роботов и IoT устройств. Хотя в этих областях есть значительная конкуренция со стороны C, C++ и Java, на положение JavaScript как для главного языка веб-программирования это никак не влияет. У всех разработчиков есть выбор, и они используют JavaScript не просто так, а потому, что он им нравится.
JavaScript выживет. “Есть только два вида языков программирования: те, на которые люди постоянно жалуются, и те, которые никто не использует”. Бьёрн Страуструп
Полезные материалы
W3C WebAssembly Community Group
Mailing List
IRC: irc://irc.w3.org:6667/#webassembly
GitHub
Who’s involved?
Об авторе
Эрик Эллиот (Eric Elliott) — автор книг “Programming JavaScript Applications” и “Learn JavaScript Universal Development with Node, ES6, & React”. Он участвовал в разработке программных продуктов для Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, а также для таких исполнителей, как Usher, Frank Ocean, Metallica и многих других. Эрик проводит большую часть времени в Кремниевой долине вместе с самой красивой женщиной в мире.
Над переводом работали: greebn9k(Сергей Грибняк), seninrom(Роман Сенин), silmarilion(Андрей Хахарев)
Singree
Комментарии (62)
Flash_X
26.06.2015 14:50Бинарный asm.js?
greebn9k Автор
26.06.2015 15:11Не совсем.
Вот тут объясняют почему создается новый стандарт:
https://github.com/WebAssembly/design/blob/master/FAQ.md#why-create-a-new-standard-when-there-is-already-asmjs
Если вкратце
1. wasm позволяет использовать бенефиты которые нельзя добиться от asm.js. А именно обойти AOT-компиляцию, и отсутствие asm.js оптимизаций.
2. Меньший размер бандла приложения(об этом кстати было в статье).
Аксель Раушмайер сегодня написал что wasm это посути способ доставки бинарного asm.js но ссылок на это я больше нигде не нашел.
Надо следить за развитием стандарта, и там уже будет предельно понятно как asm и wasm друг с другом будут взаимодейтсовать(и будут ли?).
semenyakinVS
26.06.2015 16:01Очень интересно. Не подскажете где можно глянуть подробнее как это работает? Как я понял, это код, который исполняется самим браузером в каком-то низкоуровневом режиме? Или это именно бинарник, стартующий в параллельном с браузером процессе и браузер в нём считает тяжёлые части кода?
helions8
26.06.2015 16:07+1Код выполняется той же самой виртуальной машиной, а в будущем обещают следующее:
When WebAssembly gains the ability to access garbage-collected objects, those objects will be shared with JS, and not live in a walled-off world of their own.
UnknownHero
26.06.2015 17:17Вот наивные, они ещё не поняли, что JavaScript управляет этим миром.
А по делу, есть Roadmap? В сети не нашёл, может упустил что-то.
Gorthauer87
26.06.2015 17:25Это что-то типа более портабельного, чем в llvm, байткода?
mt_
28.06.2015 14:14Кстати, а интересная задумка. КОмпилируй из любого фронт-енда в llvm и будет счастье. Отличная совместимость и куча бонусов.
Но видимо нет, опять не срослось…
forgotten
26.06.2015 17:44-3Моё, например, мнение состоит в том, что WA бесполезен by design.
Узкое место любого веб-приложения — скорость рендеринга. Да, конечно, в силу ограничений языка (некомпилируемый, слабо типизированный) код на JS будет проигрывать коду на asm-е в производительности, да только нет такой задачи в вебе. Никто не занимается тяжёлыми вычислениями на клиенте, кроме майнеров биткойнов да различных проектов полезного использования простаивающих ресурсов.
Любое приближенное к реальности приложение столкнётся в первую очередь с проблемой отображения большого количества данных (читай, дом-элементов) и скорости реакции браузера на действия пользователей. WA в этом поможет примерно никак, потому что тормозит в этом месте не js-код, а сам браузер, обрабатывающий «тяжёлые» страницы.forgotten
26.06.2015 17:47Упреждая вопросы. На десктопе, где пишут на компилируемых статически типизированных языках, эта проблема не решена никак. Если попытаться сделать форму с таким же количеством визуальных компонент, как на обычной веб-странице, она тормозить будет гораздо круче исходной веб-страницы.
Gorthauer87
26.06.2015 21:10Всё это можно оптимизировать, да и из WA можно будет наверняка рендерить напрямую на какой-нибудь egl surface причем предварительно построив граф сцены и сделав так, чтобы долго считающиеся/рендерящиеся данные появлялись на экране по мере готовности, не блокируя основной тред отрисовки.
В общем, я думаю, что в прямых руках можно сделать так, чтобы веб страничка наконец-то работала и отображалась плавно, а не рывками, как сегодня.forgotten
26.06.2015 21:29> Всё это можно оптимизировать, да и из WA можно будет наверняка рендерить напрямую на какой-нибудь egl surface причем предварительно построив граф сцены и сделав так, чтобы долго считающиеся/рендерящиеся данные появлялись на экране по мере готовности, не блокируя основной тред отрисовки.
В общем, я думаю, что в прямых руках можно сделать так, чтобы веб страничка наконец-то работала и отображалась плавно, а не рывками, как сегодня.
Так можно. Но что мешает браузеру это сделать прямо сейчас? Процесс рендеринга в JS не протащен никак от слова совсем, рендеринг полностью на совести браузера. Просто, ха-ха, рендеринг UI — дофига тяжёлая задача, которая в термины графических интерфейсов ложится примерно никак. Собственно, настольные приложения, работающие напрямую с видеокартой (читай, игры) обладают совершенно примитивным и недоразвитым UI, даже rich text в игрушке не встретить.Gorthauer87
26.06.2015 22:56А сложный UI в играх особенно то и не нужен. Но вообще забавно получается, что видеокарта может спокойно обрабатывать миллионы полигонов по 50 раз в секунду, но быть абсолютно бесполезной при рендеринге какого-нибудь сложноразмеченного текста.
Может в языках разметки проблема?forgotten
26.06.2015 22:59+1Нет, проблема в том, что сложная разметка не параллелится. Положение и вид каждого глифа зависит от окружающих его глифов и миллиона сторонних причин, в отличие от видеоигр, где сцену можно описать простым и конечным набором примитивов.
Master_Dante
27.06.2015 11:55Распараллелить можно что угодно, главное иметь желание. В данном случае глифы распределяются между n потоками, сначала рассчитываются габариты, как только все потоки отработали, мы знаем размеры каждого примитива, и дальше можно делать что угодно параллельно. А если все будет делаться с использованием неблокирующих структур данных, так вообще сказка.
forgotten
27.06.2015 15:11Круто. Идите офисные пакеты разрабатывать, озолотитесь.
Master_Dante
27.06.2015 17:57К счастью я уже являюсь разработчиком высокопроизводительных баз данных.
faiwer
26.06.2015 19:10+1Никто не занимается тяжёлыми вычислениями на клиенте
Ну, дык, видимо, теперь будут.
helions8
26.06.2015 19:37+2Ну, так как раз и хотят заниматься тяжелыми приложениями в браузере – в одной из статей говорится даже о риалтайм-приложениях, типа процессоров звуковых эффектов, обработка видео и т.д. С другой стороны, тот же Servo мозиловцы и делают с оглядкой на текущий медленный DOM, который изначально не был рассчитан на то, чтоб его модифицировали. Так что движение к быстрым веб-приложениям идет со всех сторон. Плюс, думаю, очень многих не устраивает медленная скорость обновления стандартов ES (включая доставку в браузеры) и у JS слишком много родовых травм, которые теперь надо оставлять для обратной совместимости.
forgotten
26.06.2015 22:34> Ну, так как раз и хотят заниматься тяжелыми приложениями в браузере – в одной из статей говорится даже о риалтайм-приложениях, типа процессоров звуковых эффектов, обработка видео и т.д.
Процессоры звуковых эффектов давно есть (см. WebAudio, который, опять же, все вычисления скрывает внутри себя, на JS только интерфейсы к созданию фильтров). Обработка видео может быть, но это исчезающий кейс в онлайне.
Веб-приложение — оно, прежде всего, клиент-серверное. И главная проблема в вебе вотпрямщас — огромное количество скрытой под платформой магии типа reflow-repaint, garbage collector-а и прочей головной боли разработчика. Ахиллесова пята веб-платформы — тормоза и отзывчивость UI, вот что нужно ускорять-то. Любое сложное вычисление, если уж сильно хочется, можно на сервер отослать. Или насоздавать воркеров, чтобы компенсировать слабость интерпретируемого языка занятием пары дополнительных ядер.
> у JS слишком много родовых травм, которые теперь надо оставлять для обратной совместимости.
А поподробнее можно с этого места? Какие такие у JS родовые травмы?
forgotten
26.06.2015 22:39Ну и насчёт Серво. Основной его интент — это распараллелить всё что можно: парсинг HTML, применение CSS, вообще всё. Иными словами, Серво не оптимизирует исполнение JS просто потому, что Servo — layout engine, а в качестве JS-движка там внутри SpiderMonkey, и менять его они даже и не собираются (по крайней мере, год назад так говорили).
Итого, Серво демонстрирует ровно обратную мысль к тому, что вы пишете: нет смысла ускорять JS-движок, нужно ускорять браузер.helions8
26.06.2015 23:29+4А я и не говорил, что Servo оптимизирует JS, перечитайте, пожалуйста, мой предыдущий комментарий. Про клиент-серверное приложение это конечно хорошо, только на дворе второе десятилетие 21 века и многим приложениям сервер нужен лишь в качестве хранилища, что уже и сейчас можно делать не только с сервером. Вы как-то не понимаете, что браузер стал сам по себе платформой, и сервер ему может и не нужен вовсе — ну, максимум загрузить код вам в бразуер. По поводу травм — да легко — int64.
ZimM
26.06.2015 22:16+2> Никто не занимается тяжёлыми вычислениями на клиенте, кроме майнеров биткойнов да различных проектов полезного использования простаивающих ресурсов.
Игры на WebGL. Тут вам и тяжелые вычисления, и быстрый рендеринг. Самое очевидное предназначение, как по мне.forgotten
26.06.2015 22:29-3Ну так игры на WebGL и так на WebGL! То бишь шейдеры пишутся на C-подобном языке. Чего там можно ускорить на уровне замены JS другим языком?
ZimM
26.06.2015 22:38+3WebGL и шейдеры это всего лишь рендеринг. При чем тут выполнение непосредственно кода? CPU в современных занимает не менее половины всего времени на кадр. И это на высокопроизводительных языках типа С++.
Один банальный пример — физика, которая по сути куча числодробительного матана, где нужно выжать *всё* из производительности, и, например, написанные вручную ассемблерные SIMD-вставки там не просто так, а уже необходимость. В итоге, на декстопах ни один современный игровой движок не поддерживает процессоры, которые не умеют SSE2. В то время как кодогенерация JS по большей части сейчас плетется где-то на уровне поддержки Intel 486DX. Без возможности использовать SIMD даже вручную (SIMD.js можно уже не учитывать).forgotten
26.06.2015 22:45-2Господи, Хабр, да что с тобой? Когда думать стало немодным?
«Матан» исполняется так: программно задаётся набор объектов и их характеристики, тяжёлые расчёты выполняет спец. библиотека, опираясь на GPU или спец. комманды CPU. Абсолютно наплевать на каком языке задаются параметры — важно, на чём написан сам расчёт. И WebGL демонстрирует то же самое — абсолютно наплевать, на каком языке написана команда «загрузить текстуру в память» — важно, как имплементирована сама загрузка.
И веб-платформа в этом месте логична и проста: JS — управляющий язык. На нём пишутся скриптовые команды, что делать (манипуляция DOM-элементами, WebGL-шейдерами, применение криптографических алгоритмов, etc). А выполнение этих команд — на совести браузера, читай — C++ кода. Если приложение упирается в производительность JS — создаём новое API, в котором типовые задачи реализованы на C++, а в JS просто дырки до управляющих интерфейсов. Так сделано WebAudio, Web Animations, WebCrypto и хренова гора прочих новых спецификаций.ZimM
26.06.2015 22:54+1Понятия не имею, откуда вы взяли идею о использовании JS как управляющего языка. Нет. Я говорю именно про использование JS (или WebAssembly, в данном случае) для произведения самих расчетов. Да-да, вот берем и вычисляем физический матан силами JS-кода. Об этом же и в статье речь идет.
Вы же не станете предлагать все-все библиотеки на свете встраивать в браузер (чтобы они были в нативном коде) и делать к ним JS-интерфейс?forgotten
26.06.2015 22:57+1> Понятия не имею, откуда вы взяли идею о использовании JS как управляющего языка.
Да это как бы не я взял. Веб-платформа в этом направлении и развивается уже довольно долго.
> Вы же не станете предлагать все-все библиотеки мира встраивать в браузер (чтобы они были в нативном коде) и делать к ним JS-интерфейс?
Нет, не предлагаю.
Я только пишу, что WebAssembly типовых проблем веба не порешает. Никак.
Иметь возможность в браузере самому писать алгоритмы, в принципе, полезна. Но практически даром никому не нужна.
aml
26.06.2015 23:06+1Поосторожнее с обобщениями. Вы видели, как работают растеризаторы томограмм в браузере? Там нужно показывать миллионы пикселей на каждом кадре, и выполнять сечения разными плоскостями в реальном времени. В играх есть много сложной математики, специфичной для каждой конкретной игры, которая должна вычисляться на клиенте. Уже сейчас множество приложений, которые до сих пор были возможны только на десктопе, переезжают в браузер. И это только начало.
ZimM
26.06.2015 23:15+7Да, до этого JS действительно был не более чем управляющим языком. Но может, как раз потому, что его производительности заведомо не хватало для чего-то большего?..
Есть реальная задача — сделать производительную реалистичную 3D-физику в браузере. Какие сейчас есть способы это сделать? Верно, сейчас — никаких. Решит ли WebAssembly эту проблему? Да, решит. Я не знаю, как можно утверждать, что это не решает задачу.
«Типовая проблема» — довольно размытое понятие. Да, я совершенно согласен, что 99% веб-страниц WASM не поможет аж никак, и для них более актуально было бы ускорение, скажем, layout-движка. Но тем 1% страниц, которым WASM нужен — он действительно нужен.
megalol
27.06.2015 03:59>Иметь возможность в браузере самому писать алгоритмы, в принципе, полезна. Но практически даром никому не нужна.
Мне нужна. Кому платить?
aml
26.06.2015 22:58Вы описываете каноническое применение скриптового языка. JS с этой задачей отлично справляется. Проблема с доставкой вашей реализации на C++ в браузеры пользователей.
Ждать, когда ваш юзкейс будет реализован в стандартных плагинах и доступен в большинстве установленных браузеров, можно очень долго. Заставлять пользователя устанавливать плагины, которые несут в себе ваш кастомный C++-код, это терять их большую долю. asm.js, как и wasm — это способ безопасно исполнять кастомный код в браузере, при этом с нулевым вовлечением пользователя.forgotten
26.06.2015 23:01И я совершенно с вами согласен!
Я только пытаюсь донести простую мысль, что типовые проблемы веб-разработки НЕ РЕШАТСЯ с помощью WebAssembly. Нетиповые задачи, как майнинг биткойнов — может быть. Ускорение работы и отзывчивости веб-страниц — нет. Нужно оптимизировать нижележащие алгоритмы и/или давать более полное управление из JS.aml
26.06.2015 23:09+5То, что сейчас типовое — это следствие ограничений веб-платформы. Будет меньше ограничений, и сразу то, что сейчас не типовое, полезет в веб.
forgotten
26.06.2015 22:50-1JS — это такой Matlab для веба.
Никому почему-то не приходит в голову писать, что Matlab — плохой, негодный язык. Он же скриптовый! Со слабой типизацией! Некомпилируемый!
Да наплевать. Каждая строчка на Матлабе развернётся в миллион инструкций на asm-е, обрабатывающих гигабайты данных. Накладные расходы на сам язык Матлаб — ничтожны на этом фоне.ZimM
26.06.2015 23:06+1> Накладные расходы на сам язык Матлаб — ничтожны на этом фоне.
Ровно тогда, когда матлабовский скрипт не использует ничего, кроме встроенных функций, которые зачастую действительно реализованы в нативном коде. Как только же вам нужно сделать что-то нетривиальное руками — проще застрелиться, ибо производительность будет в сотни раз меньше, чем у аналогичного кода на С. Матлаб — прекрасная штука, но мне действительно приходилось несколько раз выносить тяжелые куски матлабовского скрипта в нативный код, ибо иначе ожидание становилось просто невыносимым.
Аналогичная проблема и с JS. Вот только в вебе *нет* никакой возможности вынести часть кода в нативную библиотеку. Увы.
Antelle
26.06.2015 23:05Я вот вижу ещё полезное применение WA для написания shared-библиотек: чтобы можно было что-то написать и для веба, и для десктопа, и для мобильных, сейчас нет однозначного вменяемого способа сделать это, кроме разве что asm.js.
> в первую очередь с проблемой отображения большого количества данных
Вопрос очень спорный. Приложения сейчас подключают фреймворки и часто содержат много тяжёлой логики сами по себе. К примеру, вот таймлайн начала загрузки google docs.
Конечно, рендеринг тоже надо оптимизировать, ну так одно другому не мешает.
fogone
26.06.2015 23:35+2Узкое место любого веб-приложения — скорость рендеринга.
Ws не решает проблемы рендеринга, он позволяет выполнять код быстро, когда это необходимо — например, в игре.
Любое приближенное к реальности приложение столкнётся в первую очередь с проблемой отображения большого количества данных
Любое? Мм, нет, например на странице вполне может быть всего один элемент с отображением видео, а вот у него уже на wasm-е написанные кишки.
Мне кажется, вы не совсем правильно понимаете смысла этого стандарта, он в первую очередь создается для того, чтобы в браузере работало то, что сейчас не работает (или работает плохо). А не для того, чтобы страницы быстрее работали.
overmes
26.06.2015 18:52+1Вам не кажется, что web все больше напоминает:
wget google.com | /bin/sh в песочнице
или на приложения для androind || iOS?
Почему сразу не пойти по этому пути?Antelle
26.06.2015 21:55Так и идут по этому пути. Вот сейчас сделают компилируемый код, а чего ещё не хватает в вебе, что есть в приложениях?
RomanPyr
28.06.2015 02:32В итоге каждый браузер будет просто маркетом для сайтов.
Точнее не так, каждый браузер станет менеджером пакетов для приложений-сайтов.Antelle
28.06.2015 21:19+1В идеале, так и должно быть: лёгкие быстрые приложения, которые не требуют сложной установки, не контролируются владельцем аппстора, живут в песочнице, не требуют от разработчика знания UI-фреймворка для каждой платформы или (о, ужас) наличия макбука или виндоусбука. Круто же: понравился сайт, открепил вкладку от браузера, приклеил иконку к доку/таскбару и всё.
Я думаю, вскоромсветломкогда-нибудь будущем, как только веб станет достаточно производительным и будет предоставлять достаточное количество API, теперешние приложения заменятся более портабельными технологиями, а приложениями останутся только системные вещи.
zapolnoch
26.06.2015 18:56-5Улучшение для браузеров: Браузеры будут понимать бинарный формат ...
Ахахахаха!!! Т.е. мяу…
dlap
26.06.2015 19:43+5Держу пари, что даже те из Вас, которым посчастливилось работать с ДОС, не знают, что можно использовать “debug” для отладки ассемблера и диссасемблеризации (обратный инжиринг) существующего кодф
Пари ты проиграл ;)
NeoCode
26.06.2015 23:24+3Очень интересно наблюдать за развития информационных технологий… История таки развивается по спирали, на каждом витке дополняясь чем-то качественно новым.
Сначала были текстовые консольные интерфейсы.
Затем появились графические интерфейсы. Сначала — как вспомогательный режим, который нужно было запустить чтобы посмотреть картинку… после чего они поменялись местами, и теперь консоли — текстовые «окошки» в графическом окружении…
Затем браузеры. Сначала — просто одна из программ графического интерфейса. Со временем они становятся все более значимыми, и постепенно берут на себя функциональность рабочего стола как такового… И вот уже приложения, игры и даже трехмерная графика существует в браузерах, приложения пишутся на html и javascript (хотя еще недавно html — всего лишь язык разметки документов, а javascript — лишь средство создания надоедливых баннеров), появляются целые операционные системы, целиком основанные на браузере и javascript…
Вторая тенденция — виртуализация. В стародавние времена программисты работали напрямую с железом. Затем стали появляться драйверы устройств, API операционной системы, и только единственное устройство — процессор — оставалось доступно для программ напрямую. Но и здесь — Java, .NET, попытки абстрагироваться и от процессора тоже. Собственно, стоило ожидать что с Javascript произойдет что-то подобное, раз этот язык становится новым Си на новом витке развития технологий. Логично, что с помощью WebAssembly перешли от прямой интерпретации текста к виртуальному коду. Придет время — перейдут и к пре-компиляции в машинный код, как Гугл с Dalvik -> ART.
Dicebot
27.06.2015 00:47+1Мечтаю о временах, когда можно будет заниматься веб-разработкой совсем без JavaScript
WebAssembly выглядит хорошим шагом в этом направлении
TheRabbitFlash
27.06.2015 10:21+4Ну ничего себе!? Они придумали ABC из Флеша!
Для тех, кто не в курсе:
Весь программный код у Flash — это ABC (ActionScript Byte Code) блоки, выполняющиеся в виртуальной машине. Она написана на С++.
Вы можете ругать Flash или же оставаться его поклонником, но разными способами и названиями разные компании пытаются повторить то же самое, но на JavaScript и ищут для этого свой формат.
Color
Карл Маркс и Фридрих Энгельс — это не четыре разных человека, а Слава КПСС — вообще не человек…
greebn9k Автор
Не понимаю Вашу иронию. В оригинале так и написано. Более того, над стандартом работают и независимые разработчики.
Color
Просто звучит смешно, вот и вся ирония. Не хотел никого обидеть, даже наоборот :)
greebn9k Автор
Действительно :) Исправили на «независимых специалистов».
mt_
Переводится как «корпорации… и ряд независимых разработчиков», а не то, как вы написали.