Разработчик из команды Mozilla представил (https://hacks.mozilla.org/2018/04/javascript-to-rust-and-bac.../) проект wasm-bindgen (https://github.com/alexcrichton/wasm-bindgen), в рамках которого ведётся разработка прослойки для организации взаимодействия между JavaScript и кодом, скомпилированным в представление WebAssembly. В текущем виде проект сосредоточен на предоставление связки между языками JavaScript и Rust, но в будущем ожидается появление поддержки и других языков, включая C/C++.Wasm-bindgen позволяет из частей на разных языках организовать доступ к строкам, объекткам, классам и прочими структурам. Например, можно импортировать в Rust функциональность JavaScript, такую как манипуляции с DOM, или наоборот экспортировать функциональность Rust в JavaScript, такую как классы и функции, обеспечить совместную работу со сложными типами, такими как строки, классы и объекты, несмотря на то, что спецификация WebAssembly предусматривает манипуляцию только с низкоуровневыми числовыми типами (u32, i32, f32, f64).
URL: https://hacks.mozilla.org/2018/04/javascript-to-rust-and-bac.../
Новость: https://www.opennet.dev/opennews/art.shtml?num=48399
Вместо того чтобы наконец запилить аппаратное ускорение видео надмозги из мозиллы который год занимаются прокрастинацией. Печально.
Вы уверены что данным проектом занимается разработчик что разбирается в аппаратном ускорении видео?
А у них есть разработчик, который разбирается в аппаратном ускорении видео? Как правило, такие разовые задачи ставятся тому разработчику, который есть, а потом уже он разбирается в том, что для этого требуется.
Есть. В Windows и MacOS X же ускорение работает. Просто в линуксе вместо графической подсистемы иксы.
> в линуксе вместо графической подсистемы иксы.а вместо браузера файрфокс, ага.
Вам никто не мешает поставить хр... Яндекс браузер
> Вам никто не мешаетА вам никто не мешает поставить вейланд.
в линуксе вместо графической подсистемы иксы.Были иксы, их выкинули на свалку. А под вейланд они еще сам бройзер не перевели.
Сейчас тендентиция идёт к тому, что во всех плеерах будет использоваться системный плеер с системными декодерами. Пилить что-то своё, а тем более под каждую железку, глупо.
системный это типа MPV или это типа встроенный в браузер в рамках HTML5 <video> ?
А то ещё одной уязвимости в stagefright давно не находили!
Правильно. Давайте ныть об этом на локальном веб-сайте. Это ведь так помогает...
Только я споткнулся глазом о WASM?
Watcom как много в этом слове :)
> Watcom как много в этом слове :)ничего там нет, в слове этом. компилятор(ы) от Watcom были популярны только под МС-ДОС из-за отсутствия нормальной поддержки 32-битного режима в борланд и МС-овских компиляторах, а так же наличия Дос-екстендера в поставке.
> > Watcom как много в этом слове :)
> ничего там нет, в слове этом. компилятор(ы) от Watcom... вроде как оптимизировали гораздо лучше, чем микрософтские (про борланд вообще молчу, у них оптимизации были лишь самые базовые).
А они не хотят таки запилить такую спецификацию WebAssembly, которая бы позволяла обходится без ЖС совсем?
ты думаешь оно будет лучше, надежнее и быстрее? Но ведь оно будет тормознее потому что к дуум придется обращаться костылями и глючнее потому что webassembly сборщика мусора нет.
Так он про это и говорит, чтобы уже наконец сделали апи для сборщика мусора и нормально обращение к дом апи, т.к. сейчас надо это всё делать через JS, то есть через те самые костыли
есть же typescript и 100500 других языков. И webassembly для этого не нужна
TS - компилируется в жс и в рантайме проблемы JS остаются, всё остальное работает очень медленно и потребляет больше ресурсов
TS - это костыль. В конечном итоге, на выходе все равно js. Уж лучше сразу на js писать.
На моей практике, обычный разработчик при переводе проекта на TS сталкивается с немного меньшим количеством попыток обращения к undefined.Но этот вебпак, gulp, tslint и прочие сборочные инструменты на крупных проектах так жестко тупят, что хотелось бы их больше никогда не видеть
Вы просто не умеете их готовить
это java апплеты и флеш, лол. Но тогда браузер превратится в примитивный wget, а на таком денег не попилишь
Oracle в 9 версии отказался от аплетов и даже web start (потому что ему Java не нужна). От flash пока не отказались кажется, но пытаются.
Хотят. В принципе, описанное - один из шагов.
это будет очень весело! сейчас жс-хейтеры ноют о тяжелых сайтах (вот в веб2.0 были времена), а потом как они взвоют от неотключаемых бинарных блобов!
>А они не хотят таки запилить такую спецификацию WebAssembly, которая бы позволяла обходится без ЖС совсем?ХD. Ты видать очень мало знаешь о Rust. Повесишь внутри функции onclick на элемент.. а Раст его по завершению функции почистил))) или попробуй одну и ту же функцию повесить на разные onclick - компилятор скажет что переменная уже заимствована. Да и область видимости у раста.. не видит переменные вне функции..
Не знаю как этом идти в hrml DOM
> Повесишь внутри функции onclick на элемент.. а Раст его по завершению функции почистил"его" -- это кого? Элемент? Каким образом этот элемент попал в функцию? Был создан в ней, и никуда не передан? Да, тогда rust его просто удалит. Или может ты передал его в set_onclick? В этом случае, не удалит. Или ты не создавал элемент, а получил его при помощи get_element_by_id? В этом случае ты получишь ссылку на элемент, и будет удалена ссылка на элемент, а не элемент.
> попробуй одну и ту же функцию повесить на разные onclick - компилятор скажет что переменная уже заимствована.
Не скажет. Ты ведь можешь одну и ту же функцию использовать в rust'е штатно из многих мест? Можешь. Почему же нельзя передать эту функцию во много разных мест?
Если это глобальная функция, то правила работы с ней примерно такие же, как правила работы с глобальными const переменными. Если это замыкание... Ну, тут надо уметь работать с замыканиями. Надо открыть соответствующую главу rust book, и прочитать её вдумчиво. Можно ещё порыться в документации к std::sync::Mutex и std::refcell::RefCell, там AFAIR был где-то пример, как можно создавать _много_ замыканий работающих с одними и теми же объектами. Я думаю, это всё же было в Mutex, там вроде был цикл, который создавал тучу потоков, каждый из которых был замыканием, работающим с одними и теми же объектами -- Mutex тут был бы адекватнее, чем RefCell. Но, всё же, каждое замыкание было отдельным объектом, в том смысле, что для каждого создавалось собственное окружение, которое он захватывал в move-семантике. То есть, функция была одна, а замыкания разные.
Все эти сложности с Mutex, RefCell и Arc может и не нужны, если замыкание работает с const переменными, но помимо того, чтобы быть const, они должны ещё жить не на стеке. Либо статически, либо в куче. Но во втором случае возникнет вопрос "когда освобождать память", и поэтому тебе придётся использовать Arc, и делать clone этого Arc'а на каждое замыкание. Если же переменные живут статически, то тут вообще будет не замыкание, а заурядная функция, объявленная при помощи fn, и проблем возникнуть не должно.
> Не знаю как этом идти в hrml DOM
"Не знаю, как с этим идти в html DOM"? Ты это хотел сказать?
Раст ведь очень много чего позволяет. Чего он не позволяет делать, так это глупостей: если ты меняешь переменную из разных мест асинхронно, то будь добр, сделай это так, чтобы не создавать data race.
Чтобы знать как написать safe API к html DOM, надо учиться. Взять и написать что-нибудь на расте. Надо пойти на github, и почитать чужой код. Надо не стесняться нажимать на кнопочку src, рядом с описанием функций в документации: если ты не понимаешь, как такую функцию написать на rust'е, сходи и посмотри. Rust -- это не жабаскрипт, в нём всё же полезно понимать, что там происходит под капотом. Почитай rustonomicon -- там очень подробно обсасывается грань между safe и unsafe, объясняется когда нужен unsafe, и как им пользоваться так, чтобы создавать safe API, и там же объясняется мотивация почему именно так сделано, а не как-то иначе. Можешь ещё поискать в гугле по слова rust+"too many linked lists", это замечательный гайд, который долго обсирает linked list как структуру данных, мотивируя отказ от linked lists в стандартной библиотеке rust'а, а потом создаёт эти linked list в различных вариантах, чтобы объяснить как это можно делать, если первая демотивирующая часть не отвращает от затеи. Демотиватор можно не читать, а вот всё остальное почитать полезно: LinkedList вынуждает решать множество проблем с data race, так что если ты осилишь LinkedList, то тебе никакое дерево DOM уже не будет страшно.
> А они не хотят таки запилить такую спецификацию WebAssembly, которая бы позволяла
> обходится без ЖС совсем?Может и хотят, но пока рано рыпаться. Надо подождать, когда через все эти wasm-bindgen'ы появятся API для разных языков. Вот тогда можно будет оценить накопленный опыт и подумать о том, чтобы создать единый API, поверх которого будут строится эти. Тогда можно будет не просто скопировать жабаскриптовый API, но сделать лучше.
Помимо этого, с этим API ведь есть ещё проблема, что mozilla не может решать такие проблемы в одиночку. То есть может наверное, но не факт, что гуглы всякие пойдут следом и подхватят. Надо сначала обсудить с гуглом и прочими и придти к консенсусу относительно этого API. А это время, во-первых, а во-вторых, надо иметь аргументы, а чтобы иметь аргументы нужен опыт, и тут мы возвращаемся к тому, что ещё не время. Вот когда будет на github'е десяток пристойных сайтов с активным использованием wasm, чтобы можно было пощупать и внутрь заглянуть, вот тогда можно будет о чём-то говорить.
Используйте ClojureScript
Ребята, может кто в курсе - есть ли движок JS, поставляемый отдельно от всего остального и не требующий для сборки стопицот ненужных вещей (autotools или cmake в самый раз)?
> Ребята, может кто в курсе - есть ли движок JS, поставляемый отдельно
> от всего остального и не требующий для сборки стопицот ненужных вещей
> (autotools или cmake в самый раз)?https://en.wikipedia.org/wiki/JavaScript_engine#Active_projects
JerryScript вроде соответствует.
>> Ребята, может кто в курсе - есть ли движок JS, поставляемый отдельно
>> от всего остального и не требующий для сборки стопицот ненужных вещей
>> (autotools или cmake в самый раз)?
> https://en.wikipedia.org/wiki/JavaScript_engine#Active_projects
> JerryScript вроде соответствует.Ваще ништяк, всё в цвет! То что нужно, беру. :-D Респект. :-)
> Ребята, может кто в курсе - есть ли движок JS, поставляемый отдельно
> от всего остального и не требующий для сборки стопицот ненужных вещей
> (autotools или cmake в самый раз)?duktape
http://duktape.org/
$ gcc -std=c99 -otest test.c duktape.c -lm
$ ./test
1+2=3https://mujs.com/
gcc test.c -lmujs
cat test.c
#include <stdio.h>
#include <mujs.h>int main(int argc, char **argv)
{
char line[256];
js_State *J = js_newstate(NULL, NULL, JS_STRICT);
while (fgets(line, sizeof line, stdin))
js_dostring(J, line);
js_freestate(J);
}
>[оверквотинг удален]
> char line[256];
> js_State *J = js_newstate(NULL,
> NULL, JS_STRICT);
> while (fgets(line, sizeof line,
> stdin))
>
> js_dostring(J, line);
> js_freestate(J);
> }
>
ducktape - не подходит. :-(
muJS - тоже ништяк, тоже беру.
> есть ли движок JS, поставляемый отдельно от всего остальногоА что ты пилишь-то?
Пока только выпиливаю.Видят боги, я был фанатом продуктов Mozilla Foundation со времён основания Mozilla Foundation. Но настала пора прощаться. :-(
Пока в качестве браузера использую links2, в качестве смотрелки youtube - palemoon, ну а дальше - видно будет. WebKitGTK в последней версии что-то тоже становится жирноват, так что вопрос с нормальным браузером для RTK неожиданно открыт. :-)
> Пока только выпиливаю.
> Видят боги, я был фанатом продуктов Mozilla Foundation со времён основания Mozilla
> Foundation. Но настала пора прощаться. :-(
> Пока в качестве браузера использую links2, в качестве смотрелки youtube - palemoon,
> ну а дальше - видно будет. WebKitGTK в последней версии что-то
> тоже становится жирноват, так что вопрос с нормальным браузером для RTK
> неожиданно открыт. :-)Кстати да, проблема с palemoon, не всё там можно делать. Я было подумал на него перейти с firefox, но выяснилось, что он уже протух сто лет в обед. Например он-лайн платежи через яндекс у меня в palemoon идти отказались.
Лучше, чем links2, считаю -- w3m. У него ещё и обёртка в emacs есть. Но вообще это извращение.
Обидно терять Firefox, столько на него было завязано в workflow. Но с тех пор, как они дропнули свои аддоны, делать ничего не остаётся.
А, вот теперь ниша раста стала ясна. Через пару лет раст в 95% проектов будет транслироваться в яваскрипт и выполняться на ноде. Ещё через пару лет об этой прослойке между яваскриптом и программистом все забудут и раст превратится в очередной кофескрипт.
ага, бесполезная трата времени - создавать каждый раз новую х#рь/язык чтобы оно появилось как еще один npm пакет из сотни строк.
а вообще-то у анонимусов короткая память - первый javascript был сделан в Netscape. То-то чуваки подохр#нели во что он теперь превратился ;) Ну и все уже давно знают чем разницу между микрософтом и царем Мидасом - у царя все, к чему он прикасался, превращалось в золото, а у микрософта в г#вно.. Поэтому тут весьма показателен пример рукож#пого г#внософта, который не только не смог его испоганить своим жскриптом этот эту технологию но и феереично похоронил своего осла, тупо из-за врожденной неспособности скопировать дух языка...