Max Home IndustryGoogle только что объявил, что Chrome больше не будет поддерживать собственный код в форме PNaCl. Вместо этого он последует примеру других производителей браузеров и будет полагаться на WebAssembly для быстрого кода. Короче говоря, победила WebAssembly.
Собственное приложение — это все, что компилируется в машинный код системы, в которой оно работает, — без виртуальных машин, байтового кода и интерпретаторов. Конечно, это определение очень расплывчато, потому что грань между интерпретатором и своевременным компилятором очень тонкая. Каким бы ни было определение, родное приложение — это приложение, которое работает быстро — максимально быстро — на оборудовании. Браузеры используют JavaScript, скорость которого с годами улучшилась, но он по-прежнему намного медленнее, чем собственный код. Чтобы разрешить Chrome запускать собственные приложения, в 2011 году Google анонсировал NaCl (собственный клиент). Идея заключалась в том, что скомпилированный код можно запускать в песочнице, предоставляемой Chrome. Это позволило нативным программам работать в браузере на полной скорости, и в доказательство этого Google выпустил несколько игр.
Программистам, которым он понравился, он действительно понравился, и поначалу это вызвало большой энтузиазм. Затем стала очевидной одна большая проблема. NaCl был функцией только Chrome, и с течением времени казалось все более маловероятным, что какой-либо другой браузер примет эту технологию. Улучшенная версия NaCl была запущена в 2013 году, PNaCl. При этом использовался переносимый промежуточный код, который позволял нативным приложениям запускаться в браузере, работающем на различном оборудовании.
Даже программисты, которые думали, что PNaCl — это хорошо или хорошая возможность разместить свои программы на C / C ++ в Интернете, не могли избежать вывода, что им придется наклеить наклейку «Работает только в Chrome» на то, что они создавали.
Другие производители браузеров, в частности Mozilla, выразили мнение, что нативный код в браузере — это большая ошибка и старомодное мышление. Будущее за HTML5 и подобными технологиями. Тот факт, что у них не было решения для запуска ресурсоемких веб-приложений в браузере, не стал серьезной проблемой. В результате поддержка PNaCl со стороны программистов стала проигрывать. Затем был asm.js, а затем и WebAssembly — оба были разработаны для ускорения работы JavaScript. В этот момент даже Google, должно быть, начал думать, что PNaCl не такая уж хорошая идея.
В прошлом году команда PNaCl была разогнана, но проект с открытым исходным кодом продолжился. Теперь у нас есть окончательное слово, что PNaCl мертв с точки зрения Google:
Мы прекратим поддержку PNaCl в первом квартале 2018 года везде, кроме приложений и расширений Chrome. Мы считаем, что экосистема вокруг WebAssembly делает его более подходящим для новых и существующих высокопроизводительных веб-приложений, и что использование PNaCl достаточно низкое, чтобы оправдать его отказ.
Так что убила его WebAssembly.
На самом деле сбивает с толку то, что PNaCl по-прежнему будет поддерживаться в ChromeOS. Это потому, что это единственный способ запустить собственный код на Chromebook. Это не лучшая ситуация для Google, и вполне вероятно, что он тоже будет не рекомендуется в недалеком будущем. В конце концов, кто будет тратить время на работу над приложением PNaCl для ChromeOS теперь, когда эта технология не является частью Chrome.
Google подготовил некоторую помощь в переходе на WebAssembly, но, по сути, все, что вам нужно сделать, это перекомпилировать код C / C ++ в WebAssembly после изменения любых вызовов PPAPI на стандартные веб-API. Будут отсутствовать технологии, которые WebAssembly не будет поддерживать какое-то время — если вообще когда-либо. Будут жертвы переезда.
Объявление побуждает программистов перейти на WebAssembly:
С запуском WebAssembly веб-платформа получила основу для нового поколения быстрых и захватывающих веб-приложений, которые работают в любом браузере. Мы очень рады видеть, что разработчики создадут дальше!
Многие отмечают, что переход на любую технологию на основе JavaScript не для них. Некоторые приводят рациональные причины, например, WebAssembly слишком медленный, но в большинстве случаев существует глубокая неприязнь к языку и, следовательно, к чему-либо, основанному на нем. Самая большая проблема заключается в том, что WebAssembly все еще незрелый, и ему потребуется время, чтобы развиться до уровня, равного PNaCl, но теперь, когда Google на борту, мы должны увидеть прогресс в направлении жизнеспособного кросс-браузерного языка, который находится на меньше всего близок к родным скоростям.