Web-assemby (браузерная технология)

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

Думаю, если будет реализована эта технология и будет доступ к API браузера (хотя бы DOM), то:

1. PHP вытеснит JS c клиентской части для обычных сайтов. Дешевле будет использовать один язык (PHP) вместо двух.

2. Аудитория nodejs с падением популярности js на клиенте намного уменьшится.

3. Клиент-серверные приложения (не сайты) получат возможность распространения с помощью браузера.

4. Для web-assembly будет построен генератор исходников. Дальше придумают обфускаторы как с net/java, но особо интересующихся это не остановит.

5. Web-assembly существенно уменьшит прирост ассортимента магазинов приложений. Разработчики будут продавать приложения и игры со своих сайтов.

?

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

...
6. «Столица автоматически переходит в Васюки...»

Одна глупая истина: продаётся не то что полезнее, а то что лучше рекламируется. Гугл, Фейсбук, etc разродятся очередным **як**як.js, и продакшен на следующий год-два будет писать на этом. Независимо от степени абсурдности или дырявости фреймворка.

Якщо хтось і вб’є JS, то це буде не PHP.

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
1. PHP вытеснит JS c клиентской части для обычных сайтов. Дешевле будет использовать один язык (PHP) вместо двух.

ну во-первых, не PHP, а Go (согласно прогнозам Валялкина). :-)

не знаю такого, а как прогнозы раньше сбывались?

ну я как бы про этого => dou.ua/...​ers/aliaksandr-valialkin товарища)
А насчет его прогнозов... хм... ну не знаю — может какие-то из его прогнозов уже сбылись)))

так забавно наблюдать эту возню в песочнице: «моя лопатка круче твоего совочка!»

Немного почитал и хотел услышать аргументирванные коментарии

Вот видно, что немного. И причем тут php? Компилировать говно в конфетку не выйдет.

WebAssembly is a low-level assembly-like language with a compact binary format that runs with near-native performance and provides languages with low-level memory models such as C++ and Rust a compilation target so that they can run on the web. (Note that WebAssembly has the high-level goal of supporting languages with garbage-collected memory models in the future.)

WebAssembly Concepts

Где в выражении low-level и performance присутствует php? Смысл же ассембли в производительности, работа с памятью и типами. А не просто компилить какой либо язык. Получается что идея в замене шила на мыло.

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

1.

в выражении low-level

йде мова безпосередньо про WebAssembly, чи не так?
2. WebAssembly опирається на LLVM.
3. Говорити про PHP та інші мови з

garbage-collected memory models

поки що рано, так як це ще не реалізовано.

От як реалізують п.3, тоді і побачимо: переганяти AST-інструкції LLVM якось вже навчився; питання, чи буде можливість представити PHP код як дерево AST-інструкцій. Я правильно розумію?

А що буде коли це трапиться? Адже саме для цих ідей я і створив цей топік. (:

Та нічого не трапиться: в людей просто буде можливість завернути код на одній (C, Java, Go etc) мові в іншу (WebAssembly). І, як тут вже писали, ніхто нікого вбивати не буде.

LLVM сколько слов в этом сокращении...

Я одобряю. Нормальные языки вроде Java и C можно будет компилировать в WebAssembly. Javascript уйдет в прошлое так же как и наколенные поделки поверх него типа CoffeeScript/TypeScript.

GWT уже делал это — позволял компилировать Java в JavaScript, оказалось, что этого мало:
1) В вебе очень много CSS, а этот вопрос никак не улучшили, если не сказать наоборот.
2) Java хороша своим набором библиотек, которые тянут другие библиотеки, а скорость загрузки для веба критична. 5Mb jar’ников и никто не будет пользоваться вашим сайтом. А без библиотек Java не так хороша как кажется.
3) Интеграция с уже готовыми библиотеками на JS.

IMHO: WebAssembly — это как 4-х ядерный процессор в мире однопроцессорных программ — еще долго никому не понадобится.

5Mb jar’ников и никто не будет пользоваться вашим сайтом

Посмотрите сколько сегодня весит один SPA вебсайт и удивитесь

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

Точно! А я то думал, почему весь веб тормозит! А он просто джунами писан!

Прикинь. Джунами писано больше чем ты думаешь %)

Некоторые и по 10 лет из джунов не выходят.

да тут на DOU больше половины джунов с личками Senior ))

Посмотрел размер js в линкедине. 1.2 Mb. Вся страница 2.5 Mb. Впечатлило. Но ходит слух, что они там с эмбером здорово похимичили, чтобы производительность поднять.

в любом случае бинарный формат более эффективный в плане размера чем текстовый — все остальное идентично и можно нормально реализовать при желании. Скоимпилированый flash весил очень мало

Ну gzip творит чудеса, а вот парсить таки в разы быстрее

Якщо хтось і вб’є JS, то це буде не PHP.

Поржал про пхп. Хотя, говорят, там теперь даже спецификация языка есть, даже 30 лет не прошло.
Сорву покровы — пхп компилить в джаваскрипт и сейчас можно (благо что только в него не компилится), в гугле даже результаты на эту тему есть. Даже ждать не надо, прямо сегодня бери и тащи пхп на клиент.
Сорву еще немножко покровов — «WebAssembly» уже был 10 лет назад, часть стандарта EcmaScript 4.0. Не взлетело. Впрочем, стандарт утащили в Flash 9, но даже там кросс-компиляция с плюсов (или других языков) особого распостранения не получила (самое интересное с того что я помню — движок Unreal, плюс Unity где еще и .NET скрипты компилились).
Что там у нас еще под покровом? Ах, да, JavaScript, впринципе, и так не особо медленный — в его оптимизацию вложено невероятное количество человеко-столетий. Есть определенные врожденные уродства типа однопоточности и полного отсутсвия типизации (как следствие JIT там полон эвристики), но, в целом, на одном потоке добиться, скажем, 10ти кратного ускорения не так и просто. WebAssembly будет где-то посередине в плане производительности, разве что многопоточность прикрутят нормальную.
А еще «не сайты» тоже можно было ставить аки приложения (по крайней мере гугловские приблуды в хроме) но особо не распостранилось.
А еще пока что тенденция обратная — из сайтов делают мобильные приложения, банально потому что у веба есть определенные фундаментальные ограничения (например отсутствие доступа к нативным API).

В общем — у автора какое-то очень интересное мировоззрение в центре которого PHP. Необходимо оглянуться вокруг, посмотреть статистику, например:
insights.stackoverflow.com/...​rends?tags=php,javascript
и понять что PHP не центр вселенной — JS стабильно растет, а вот PHP падает с 2014го.
А WebAssembly скорее подстегнет популярность JS — можно будет делать высокопроизводительные модули типа игровых движков, более того, это прекрасно вписывается в нынешнюю моду на SPA — бекенд становится все тоньше а клиент все толще.

Кисилев итт, развернутая статистика по СО, а с аналитики на уровне «даже в гугле результаты есть» — вообще поржал.

Ну, SO, конечно, не есть последняя инстанция (может у PHPшников есть какие-то свои сайты), но задуматься стоит. Лично я и JavaScript не особо люблю, если он сдохнет — я только обрадуюсь. Но увы, этого ожидать не приходится.
Ну вот например из гугла по «из пхп в жс»: phpjs.hertzen.com
Но смысла добавлять какую-то более аналитичную аналитику чем «в гугле оно есть» я не вижу — это коммент а не статья, я в PHP не то что не эксперт а даже прикасаться брезгую. Если кому интересна развернутая аналитика от эксперта — велкам ту гугл, хули. Мне лично не интересно, автор вон вопрошал «можно ли будет» — на самом деле ответ «уже можно».

Это твои выдумки, я не «вопрошал». Ну подставь вместо php свой C# - получишь что-то типа аля silverlight/moonlight, разве не будет удобней на нем разрабатывать? Вот так и с php — многим будет просто лень учить 2 языка вместо одного. И компиляция из php существующего кода в js не отменяет ковыряние в том что получилось.

Да ну мужик, ты гонишь чушь ! И действительно подставить C# вместо JS’a можно (хоть и не нужно), но ущербный php недоязык для домохозяек — нельзя !

К счастью C# не мой — я к нему цепью не прикован. Лично мне и EcmaScript 4 нравился очень (светлая ему память), и на сях я с радостью код пишу, и на джаваскрипте (хоть и с мыслями на тему «кто эту херню придумал») — даже на node.js что-то писал, и хардварными разработками балуюсь. Сейчас буду писать апликуху на JS со всеми этими ангулярами и реактами — посмотрим что там водится. Так что я голову в сишарпном песке не держу — есть вещи которые мне нравятся, есть такие которые мне не нравятся, не более того. Работать можно со всем (кроме PHP конечно же).
Если уж совсем честно то был момент когда я C# не то чтоб начал закапывать но место для могилки присматривать точно начал. К счастью Майкрософт вытащил голову из задницы и за последний год в .NET больше нововведений чем за предыдущие лет этак 5 — посмотрим сможет ли это развернуть тренд.

1. PHP вытеснит JS c клиентской части для обычных сайтов. Дешевле будет использовать один язык (PHP) вместо двух.

lol nodejs > php

да, да, так и будет, похапе убьет жабасрипт и будет править, как только, так сразу))0))
ору как птеродактиль

...
6. «Столица автоматически переходит в Васюки...»

Я просто скопирую от туда сюда главнейшую мысль (на память):

Единственный момент где он выигрывает — это то, что больше не нужно парсить текстовое представление с кучей сложных правил синтаксиса.

и развитие этой главнейшей мысли тоже

  • Суть WebAssembly — не замена JS. Об этом говорят и сами разработчики WA, но почему-то девелоперы их не особо желают слушать.
  • WebAssembly — это следующий шаг в развитии таких штук как asm.js. На данный момент он и *есть* 1-в-1 отображением фич asm.js.
  • Единственный момент где он выигрывает — это то, что больше не нужно парсить текстовое представление с кучей сложных правил синтаксиса.
  • Вместо этого, используется бинарное представление синтаксического дерева (AST).
  • Таким образом, достигается выигрыш в скорости парсинга до 20 раз. (Слишком многие, кстати, путают это со скоростью выполнения кода)
  • Последнее совершенно неверно. Так как сами правила выполнения остаются те же от asm.js, а в случае V8 — даже виртуальная машина та же.
  • Ну а причины выигрыша по скорости самого asm.js те же — ручное управление памятью, чистая математика с определенными типами. Никакой магии.
  • Надеюсь, понятно, что пытаться туда же засунуть бизнес-логику и манипуляции с DOM бессмысленно. Вы не получите никакого профита.

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

не поменялись, но wasm точно не убъет js — единственный вариант смерти js — сам web должен умереть и родится новый

Эпичность этого будет сродни лекарству от рака, чесслово ))) Надеюсь я доживу до этого ))).

все что имеет начало — рано или поздно закончится

Спасибо за надежду! ))

Надеюсь я доживу до этого )

Чьи цели и приоритеты? Создателей WASM? Они опубликованы и не являются тайной. Если что, это официальный репо, объективней некуда.
github.com/...​/master/HighLevelGoals.md
github.com/...​design/blob/master/FAQ.md
github.com/...​n/blob/master/UseCases.md

Одна глупая истина: продаётся не то что полезнее, а то что лучше рекламируется. Гугл, Фейсбук, etc разродятся очередным **як**як.js, и продакшен на следующий год-два будет писать на этом. Независимо от степени абсурдности или дырявости фреймворка.

Оппа, цензура. На dou. А потом удивляются откуда Роскомнадзоры берутся. Так благими намерениями ж!

Тот случай, когда не поленился: п.2.8 VS п.3.4

Вы вовремя проснулись? Доукомнадзор давно втихаря подчищает форум в угоду сами-знаете-кого (ваши ссылки на правила вызывают смех). Привыкайте, мы живем в Украине 2017 года, такие вещи стали нормой.

Я просто констатирую факт, что внутри сравнительно небольшого сообщества внезапно (на самом деле предсказуемо) поднимаются нормы, не свойственные онлайну, но очень близкие деградировавшему государству.

Критиковать это естественно никто не будет, админ прав и нисовершаетполовогоакта. Лишь наблюдение. ДОУ стареет вместе с нами.

Кстати, когда ДОУ запретят, тоже не буду удивляться. Думаю, вероятность близка к единице. Причина любая, например юридическое соглашение не на мове писано.

На самом деле так даже лучше — что имелось ввиду все равно прекрасно понятно, зато выглядит более культурно :)

Пардон, но это похоже на влажные мечты php-шника :)
Основной профит от технологии это модули для js, написанные на низкоуровневом ЯП для оптимизации узких мест, т.е более навороченный аналог native c++ модулей под nodejs. Все приложение лепить на с++ вряд ли кто будет. Каким боком тут php- это загадка. Может будут конкуренты и у js всякие там Go, как основного языка для бизнес логики, но это точно не php, вообще страшно предположить как php должен быть натянут на браузер с event-асинхронной моделью и зачем вообще делать троллейбус с буханки хлеба.

PHP вытеснит JS c клиентской части для обычных сайтов. Дешевле будет использовать один язык (PHP) вместо двух.

Забавно. Как бы наоборот, что сейчас и происходит. JS вытесняет PHP ибо дешевле и производительнее будет использовать один язык (JS) вместо двух. Но все ровно у PHP есть и будет ниша в классике.

2. Аудитория nodejs с падением популярности js на клиенте намного уменьшится.

Ничего оно не уменьшится, просто разрабы на js будут вольны использовать модули помимо js и или выносить критические участки в них, что позитивно скажется на производительности в целом. Скорее тут будет еще и наплыв js разрабов, ведь бекенд/фроненд/мобайл для всего можно будет писать еще более производительные приложения на js (хотя на ноде то и так можно), что привлечет разрабов мобайл разработки, которые ранее делали выбор на native платформы в угоду быстроты работы приложения. Логично, что для бизнеса будет выгоднее держать js разраба, которого можно достаточно быстро перенести с фронта в бек, или на мобайл.

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

кому-то переиспользование серверного кода.

сервер, кто гнался за быстродействием/количеством запросов в сек и переиспользованием серверного кода, уже давно написан на js под nodejs. Поезд этот давно ушел. Это если даже закрыть глаза, что php ну никак не ложится в идеологию асинхронности. Если уж как то попытаться это сделать, то это будет сплошной костыль, тогда вопрос в чем суть?

модули для js, написанные на низкоуровневом ЯП для оптимизации узких мест

Эта история почти никогда не сработает, просто потому что разница между «низкоуровневым» и «высокоуровневым» ЯПами не настолько существенна, чтобы содержать две тимы, а уж тем более городить костыли-скотчи.

Эта история почти никогда не сработает
чтобы содержать две тимы

Ну во-первых большинство кода проекта это third-party modules, соответственно чтобы их юзать c js кода, знать с++ не нужно, во-вторых ничто не мешает взять c++ разраба, для крупного проекта, где и нужна тонкая оптимизация собственных фич, целая тима тут не нужна, ибо с++ кода относительно немного будет, собственно несложные вещи на с++ может осилить и js разраб, ведь многие и его учили/юзали или все еще юзают для хобби.

а уж тем более городить костыли-скотчи.

Чем отличается в парадигме костылей то, что сейчас все модули в проекте на js, а потом можно будет портировать горячие под c++? Например, что плохого если тот же React портируют на c++, и некоторые свои абстракции тоже будут оформлены в c++ модуле? Многие языки позволяют подгружать и юзать из кода DLL под виндой, написанных на разных языках, или вообще ассемблерные вставки, почему это плохо? Это просто адаптация этой концепции для web.

собственно несложные вещи на с++ может осилить и js разраб

В этом собственно и основная проблема. И вместо

тонкая оптимизация собственных фич

получается куча говнокода на плюсах написанная по остаточному либо чуваками, которые плюсы в последний раз видели лет 10 назад, либо июнями. Т.е. ни о какой собственно оптимизации речи уже не идет, а идет речь о каких-то системозависимых вещах.

которые плюсы в последний раз видели лет 10 назад, либо июнями

Есть шанс, что на большом проекте, которому понадобится серьезная оптимизация через Си, кроме июней будет хоть пара мидлов. Да и вряд ли там будут сверхсложные алгоритмы... так сразу и не представишь, что там может особо в ступор ввести, кроме как сам отвечай за память и у тебя есть потоки. Весь хардкор, где нужен реальный скилл, как и сейчас, будет писаться третьими лицами в opensource.

А есть мануал как собрать компилятор (gcc, clang) для wasm?

На оф странице гляньте emscripten compiler помойму назывался

emscripten же вроде в js компилит?

в asm.js но есть вариант скомпилить в wasm

Думаю так и будет в первое время. Есть несколько причин использовать один язык даже для standalone-приложений:

— труд узкопрофильного специалиста стоит дешевле чем многопрофильного
— библиотеки связывания под js не всем нравятся, придумают альтернативы под свой язык

JS прост, и его знают почти все — боль фронтенды это браузеры, а не язык

Но даже на этом форуме столько тем, о том что JS говно. Даже от тебя видел комментарии что js это говно, а ts это сорт типизированнго говна (:

То было несколько утрировано, просто его есть за что критиковать, но обычно критикуют в стиле «я хотел чтобы было как я хотел, оказывается там другие правила потому говно». Насчет wasm и быстродействия — у вас должны быть жирные операция с целыми числами чтобы увидеть отличия в производительности по сравнению с джс, а это в реальности редкость.

Когда появится полноценный выбор между языками на клиенте — разве «новый» человек будет осознанно выбирать JS? Возможно фанатически настроенные разработчики + мастера своего своего дела будут дальше его использовать. В общем случае доля js во фронт-энде должна уменьшаться.

еще и как будет, люди осознано выбирают для микросервисов node.js хотя пишут только бекенд

потому что руки чешутся или реклама?

Потому что удобно и подходит

ты своей фанатской любовью php пихаешь, а js это для фанатически настроенных разработчиков, lol

Чем фанатство PHP хуже фанатства ноды? Кроме того, что в СНГ PHP считается нехипстерским и не модным?

а я не сказал что хуже, как по мне любое фанатство — это непонимание того, что каждый инструмент под свои задачи. Я лишь подчеркнул то что, автор фанатический php-шник. Но может и нет. Он просил держать все в тайне.

— труд узкопрофильного специалиста стоит дешевле чем многопрофильного

это только когда они оба инвалиды умственного труда, иначе узкопрофильный дороже стоит, а многопрофильный просто быстрее работу находит на меньшие деньги

Это ответ с потерей контекста. Специалисты, которые будут разбираться в своем языке + js будут стоить дороже.

Нифига подобного, фронтенд или бекенд обычно получает больше фуллстека, за исключением не девелоперских позиций

Ну тут противоречие явно. Зачем тогда работать фулстеком вообще, если можно по отдельности дороже. Получаешь реально столько, за сколько сумеешь продать.

не совсем — но большинство фуллстеков слабые в каждой специализации, а развиватся они особо часто не хотят — конечно это не относится ко всем

расскажи это Qt/QML гикам

И что, много проектов на Qt/QML есть? Поделитесь может?

omg, dou its not the whole world
к тому же. вы вибираете технологии по количеству вакансий? ах да, это же доу

Qt/QML делался под нокиевские мобилки. Нокию убили. Теперь нет такого насыщенного рынка для этой технологии, увы. Разве что свою мобилку делать.

шо, серьезно? ничего, что в тиер1 там андроид и иос?

ничего, что в тиер1 там андроид и иос?

И шо? Когда надо писать под андроид, пишут на джаве; когда под айос — на обжце/свифте. А делать что-то кроссплатформенное вообще никто не хочет.

не хотят потому что формошлепы

Не хотят заказчики.

нашла, чем гордиться ©

у меня 2 проекта и оба с Qt. еще раз мир не огранисиаается доу, а технологии жабаскрипом

Я не опенсоурс.

Последний Qt/QML у меня был в 2012ом году

Для меня обещания скорого прихода WebAssembly и последующей неизбежной смерти JS (вот уже скоро, ща-ща-ща, подождите еще немного!) примерно так же звучат, как «25 декабря 1928 года земля налетит на небесную ось!».

Ну или сколько лет уже Java хоронят. «Хоронили Java — порвали два JS» :)

Підписатись на коментарі