Ось уже тиждень західна айтішной преса і форуми не можуть заспокоїтися, обговорюючи цікаву новинку під назвою WebAssembly. І «гудуть» не так через перспектив, скільки через неможливість прийти до спільної думки - що ж це насправді таке і як повинно бути побудовано. Масла у вогонь підливає склад учасників розробки, що включає Mozilla, Google, Microsoft і Apple. Так що сумнівів в тому, що штука вийде потужна, немає. Складнощі тому, що Мережа такої технології ще не знала. Були спроби реалізувати щось подібне, але всі вони або занедбані або обмежилися вузькими нішами, тобто універсальними не стали. А універсальність тут абсолютно необхідна. Втім, досить загадок, давайте розберемося що ж це за звір.
Якщо окинути думкою історію браузерів як класу, стане очевидна проста річ: це не стільки хаотичний вибух технологій, скільки спроба уподібнити веб-оглядач класичної обчислювальній машині. Спочатку інтуїтивно, пізніше усвідомлено, розробники браузерів вчили свої дітища виконувати програми та працювати з інформацією так само, як це робить будь-яка офлайнова комп'ютерна програма. Звідси потреба в мові програмування, який став би фундаментом для додатків Веб. Java, Adobe Flash, Silverlight, Javascript, NaCl - все це, в загальному, одного поля ягоди. Але ніхто з них завдання в повному обсязі не вирішив.
Недоліки відомі. Щось вимагає підключення плагінів і виконує веб-додаток поза периметром безпеки браузера. Щось невільно, тобто за визначенням обмежена рамками однієї операційної системи. Щось вимагає внесення серйозних змін в браузерну архітектуру. На цьому тлі, звичайно, виділяється Javascript - максимально наблизився до ідеального рішенням. Він всіма визнаний і всіма підтримується. Але і він не без гріха.
Справа в тому, що вимоги до браузерних мови з часом змінилися: уже в нульові веб-дизайнерам стало недостатньо тільки мати свою мову програмування, їм знадобився мову-посередник, на який можна «переводити» більш складні додатки, написані на класичних мовах зразок C ++ . Javascript у міру сил і можливостей роль такого посередника виконує, його навіть модифікували, щоб у нього це виходило краще (див. конструктор asm.js ). Однак спочатку він для такого посередництва не був призначений - і це проявляється в роботі: парсинг (читання, розшифровка JS-програми) на мобільних пристроях забирає чимало часу і енергії.
А уявіть, як здорово було б отримати абсолютно універсальна мова-посередник для веб-додатків! Вимоги до нього, втім, здаються нездійсненними. По-перше, це має бути не просто ще одна мова програмування, а такий, на який легко переводити програми з будь-яких інших мов - хоч з C, хоч з Python, хоч з того ж Javascript. По-друге, призначатися в першу чергу він повинен не для людини, а для машини, а тому записувати не текстом, а байт-кодом (компактней, швидше читається комп'ютером і легше транслюється в машинний код для виконання). Нарешті, по-третє, він повинен розумітися будь-яким браузером на будь-якій платформі. Інакше кажучи, необхідно змусити розробників всіх браузерів працювати спільно - і це здається мало не найскладнішим!
І тим не менше, такий універсальний браузерні мову-посередник - «асемблер для Веб» - вже існує: це, власне, і є WebAssembly (або, коротко, wasm). Поки, правда, немає ні специфікацій, ні тим більше стандарту - лише грубі начерки, призначення яких людині з боку не так-то просто пояснити. Однак крига скресла і це найголовніше.
Умовляти вендорів не знадобилося: вони самі прийшли до розуміння необхідності спільної праці - рухомі нуждою, бо Javascript вже явно недостатній. На даний момент wasm перетинається тільки з одним мовою, а саме все з тим же Javascript (це полегшить впровадження підтримки wasm на початковому етапі), але в перспективі, як замислюється, перевести на нього можна буде програму з будь-якої мови. Головна його перевага перед яваскрипт - в швидкості: wasm-програма швидше передається по мережі (адже вона коротше: байт-код!), В десятки разів швидше читається і перетворюється в машинний код, а крім того, можливо, буде і швидше виконуватися (wasm адже не обмежений застарілими конструкціями, як Javascript, він ближче до асемблеру, ніж до мов високого рівня).
У той же час wasm покликаний не замінити Javascript, а позбавити його від завдань, для вирішення яких той не призначався. Батько яваскрипт Брендан Айк - незважаючи на недавні пам'ятні події (див. « помста геїв »), Він якимось дивом в розробці WebAssembly бере участь - так ось Айк впевнений , Що яваскрипт не зникне. Просто кожна мова піде своїм шляхом. Javascript візьме на себе завдання, які не потребують великих обчислювальних витрат, а wasm стане саме посередником: писати на ньому не будуть, в нього будуть переводити складні програми з інших високорівневих мов. В результаті стане практично можливим писати ефективні веб-додатки на будь-якій мові програмування, а середньостатистична продуктивність таких додатків виросте.
Безжурний Брендан Айк як і раніше рекомендує в будь-який незрозумілій ситуації ставити на Javascript!
Робота над WebAssembly сконцентрована зараз у відкритій групі при W3C, підключитися до якої може кожен бажаючий (до речі, приємний сюрприз: там багато російських імен). Природно, ні про яку стандартизації поки навіть не йдеться, все зшито на живу нитку (є сирої FAQ ). Але чи вдасться взагалі довести wasm до стадії стандарту? Адже вендори неминуче стануть тягнути ковдру кожен на себе, як робили це завжди. Втім, озираючись на успіхи Javascript - який так-сяк, не без застережень, все-таки універсальний - можна сподіватися, що і wasm досягне принаймні того ж рівня сумісності.
Як багато часу це займе? Айк вважає, що через кілька років все топові браузери обзаведуться підтримкою WebAssembly. І вже зараз радить робити ставку не тільки на Javascript (його звичайний рада останні років п'ятнадцять), але і на wasm. Имхо, варто прислухатися.
PS У статті використані ілюстрації Charis Tsevis , Дмитра Барановського , ModernWeb2015 .
Але чи вдасться взагалі довести wasm до стадії стандарту?Як багато часу це займе?
