Комментарии 136
Проблема эта — быстро исполнять код в браузере
Васм решает множество проблем, и эта не то что бы самая главная. Так же:
mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html
www.reddit.com/r/programming/comments/djl3h9/free_pascal_has_now_a_webassembly_backend
Главная проблема "убить JS" (помимо тонны написанного кода) — сложность переноса рантайма и сборщика мусора, который есть у многих языков как C#, Java, Python и прочие. Поэтому жизнеспособными в WASM оказываются только такие языки как C++ или Rust, которым не надо тащить сборщики мусора и жирные рантаймы.А остальным языкам по сути необходимо носить всё этот в бинарнике WASM. Недавно Майкрософт выпустила "ужатую" VM C# для WASM, но это такой себе вариант, когда в браузере уже есть рантайм и GC для JS. Как один из возможных вариантов — портировать языки для работы с движком браузера напрямую, но кому это нужно? Да и смысл WASM теряется. Ну а писать весь сайт на C+++ или Rust не каждый сможет.
Но чтобы это реализовать, нужно пройти ещё несколько важных шагов по упрощению JS/Wasm interop.
Проверено, меньше 100Мб. Не забывайте про brotli
Прототип чата вышел в 20Мб, brotli уменьшает до 5мб.
К проблемам уже зарепорченым staticlab я добавлю еще несколько
- Выделение текста мышью не работает. Причем не только в сообщениях, но и в текстовом инпуте
- Инвертированный скролл с очень дерганой ненативной анимацией
- Tab-клавиша не работает как надо, не получается перейти в адресную строку браузера
- Плюс всякие мелкие недостатки, вроде отсутствия скролла вниз чата при отправке нового сообщения.
Если именно такие кривые интерфейсы нас ждут с массовым приходом WebAssembly, то Javascript внезапно окажется еще и более предпочтительным вариантом.
Я тестировал поддержку WebAssembly в Qt когда он был в Technical Preview. Но мы в IQ Option пишем свой freamework на C++ и в нем всё вами перечисленное работает.
для старых браузеров будет polyfill — возможность преобразования Wasm в asm.js
Для C++ можно сразу получить wasm и asm.js код. И это нужно не только для IE 11, но и на случай когда производитель сломает поддержку wasm в браузере. Из недавнего Safari на iOS 13-13.1.3.
это бинарный формат, запускаемый в браузере
Wasm всегда загружается и вызывается ТОЛЬКО из JavaScript
Две больших неправды. WASM вполне себе можно запускать и вне браузера (см. wasmer), а то и
ну и загрузку модулей через обертку в других языках тоже никто не отменял.
С формальной точки зрения WASM выглядит похожим на аплеты.
внутри него работает ActionScript, по сути, тот же JavaScript
Во флеше работал байткод. Это как раз то, ради чего webasm задуман.
PS: не смог пройти мимо и не вступиться за покойничка.
А вот время и стоимость разработки увеличатся в разы если писать их на плюсах или Яве.
Плюс такие вещи, как React, навряд ли кто станет воспроизводить на других языках.
Минусы без обоснования, предполагаю, от секты хейтеров JS:)
По удобству и скорости разработки с JS может соревноваться только Python
Как "хейтер JS" не могу не прокомментировать :) Кроме времени на разработку есть ещё и время на отладку + поддержку. Чтобы что-то спрототипировать, конечно, скриптовые языки с динамической типизацией удобны. А вот с гарантиями, что через неделю что-нибудь где-нибудь не отвалится в самый неожиданный момент — тут уже сложнее.
Может, это прозвучит странно, но я бы не рискнул написать что-то большое на Python, да и на счёт C бы задумался — я банально не настолько в себе уверен. :) Мне намного комфортнее на Scala. Просто квалификация — понятие векторное: у кого-то чёткая дисциплина, позволяющая с бешеной скоростью писать на языках со статически-слабой проверкой типов, а кого-то не напрягает формулировать типы (не пишу "указывать", поскольку в Scala это далеко не везде обязательно, в отличие от старых версий Java), но при этом спокойнее, когда компилятор страхует, где только можно. Про Haskell вон вообще шутки ходят, мол, если скомпилировалось, то почти наверняка работает, как надо.
Будете смеяться, но насколько я помню, когда-то в Селектеле, грубо говоря, переписывали скрипты с Python на Haskell — ну, такой мелкий рефакторинг устроили, ага… Итог был, что даже с учётом отладки всё-таки медленнее, но тем не менее провалом, вроде, это не посчитали.
К тому же ладно, если я один пишу. А если команда в течение пяти лет? А если это открытый проект с априори неизвестной квалификацией контрибьютеров. Вон, в Mozilla, говорят, стали спать спокойнее, когда перешли на Rust для некоторых многопоточных библиотек (или их вообще не решались сделать многопоточными до этого — точно не помню...).
В общем, всё-таки выбор языка зависит от задачи, и кроме времени разработки есть ещё и время отладки/поддержки и вероятность, что что-то может сломаться внезапно. JS — это ещё один вариант в trade-off (для меня вряд ли приемлемый), но едва ли серебряная пуля, как его некоторые пытаются выставить в последнее время (а другие с OpenNet их называют нехорошими словами. Впрочем, фанатам Раста и всего, что не C, там тоже часто достаётся).
PS: получилось довольно по-капитански, знаю...
Как «хейтер JS» не могу не прокомментировать :) Кроме времени на разработку есть ещё и время на отладку + поддержку. Чтобы что-то спрототипировать, конечно, скриптовые языки с динамической типизацией удобны. А вот с гарантиями, что через неделю что-нибудь где-нибудь не отвалится в самый неожиданный момент — тут уже сложнее.
99,9% фронтэнда написано JS, всё работает и не отваливается:)
Может быть секрет в автоматизации тестирования кода, если вы про него слышали.
На беке Node в качестве API Node выбирают такие компании, как Яндекс(видел вакансии), Гугл, ВК и многие другие. Знакомый лидом работает в высоконагруженном проекте там все сервисы на Node и тоже всё работает.
Может, это прозвучит странно, но я бы не рискнул написать что-то большое на Python, да и на счёт C бы задумался — я банально не настолько в себе уверен. :)
Действительно странно, учитывая, что на Python написаны такие «совсем простые и не нагруженные сервисы, как YouTube и Instgram.
Мне намного комфортнее на Scala. Просто квалификация — понятие векторное: у кого-то чёткая дисциплина, позволяющая с бешеной скоростью писать на языках со статически-слабой проверкой типов, а кого-то не напрягает формулировать типы (не пишу „указывать“, поскольку в Scala это далеко не везде обязательно, в отличие от старых версий Java), но при этом спокойнее, когда компилятор страхует, где только можно.
Указание типов это только 20% тормозов. То что в JS пишется в одну строчку на других языках может занять 10+.
Про Haskell вон вообще шутки ходят, мол, если скомпилировалось, то почти наверняка работает, как надо.
Будете смеяться, но насколько я помню, когда-то в Селектеле, грубо говоря, переписывали скрипты с Python на Haskell — ну, такой мелкий рефакторинг устроили, ага… Итог был, что даже с учётом отладки всё-таки медленнее, но тем не менее провалом, вроде, это не посчитали.
Про Hascel ничего не знаю, кроме того, что вакансий по нему почти нет. Может там и правда удобно.
К тому же ладно, если я один пишу. А если команда в течение пяти лет? А если это открытый проект с априори неизвестной квалификацией контрибьютеров. Вон, в Mozilla, говорят, стали спать спокойнее, когда перешли на Rust для некоторых многопоточных библиотек (или их вообще не решались сделать многопоточными до этого — точно не помню...).
В общем, всё-таки выбор языка зависит от задачи, и кроме времени разработки есть ещё и время отладки/поддержки и вероятность, что что-то может сломаться внезапно.
В данной ситуации ясно о чём речь. JS на браузере — он же фронтэнд. Если вам уровень мышления позволяет без проблем проанализировать консоль и понять откуда что прилетело, то JS, если нет то TS, WebAsembly и т.п. вам больше подойдут.
99,9% фронтэнда написано JS, всё работает и не отваливается:)
Я в курсе :)
Может быть секрет в автоматизации тестирования кода, если вы про него слышали.
А есть ещё и статический анализ — до какой-то степени тоже тесты, но которые ещё и писать не нужно. Не знаю, как с ними в JS — наверное, тоже приемлемо, всё-таки язык мягко говоря распространённый, но вот сами анализаторы писать, наверное, жуть.
Указание типов это только 20% тормозов. То что в JS пишется в одну строчку на других языках может занять 10+.
Про Hascel ничего не знаю, кроме того, что вакансий по нему почти нет. Может там и правда удобно.
Когда-то, когда я только становился Scala-программистом, мне её рекламировали, как язык, на котором разработка почти столь же быстрая, как на ну грубо говоря Python (там был другой язык с динамической типизацией), но при этом с шикарной системой типов. Так вот прикол конкретно Scala в том, что она изначально задумывалась как, в том числе, язык для создания DSL, ну и традиционные вещи в ФП типа filter, map, flatMap и т. д. там во весь рост. При этом "под капотом" там местами какая-то лютая система типов, но ровно для того, чтобы для пользователя это был очень простой DSL, притом статически проверяемый. В общем, извините за излишнюю рекламу Scala — она здесь как пример, что статическая типизация — это не всегда синоним "неудобно писать код" — иногда да, но в целом нет. Так что, если вдруг ради интереса решите посмотреть в сторону Haskell — лучше гляньте на Scala. Она, скорее всего, покажется намного более понятной, да и используется "в дикой природе" намного чаще.
В данной ситуации ясно о чём речь. JS на браузере — он же фронтэнд. Если вам уровень мышления позволяет без проблем проанализировать консоль и понять откуда что прилетело, то JS, если нет то TS, WebAsembly и т.п. вам больше подойдут.
Так ведь некоторые и десктопные приложения в Electron пихают. И да, Scala тоже не полностью устраняет необходимость аккуратного кодинга.
Когда-то, когда я только становился Scala-программистом, мне её рекламировали, как язык, на котором разработка почти столь же быстрая, как на ну грубо говоря Python (там был другой язык с динамической типизацией), но при этом с шикарной системой типов. Так вот прикол конкретно Scala в том, что она изначально задумывалась как, в том числе, язык для создания DSL, ну и традиционные вещи в ФП типа filter, map, flatMap и т. д. там во весь рост. При этом «под капотом» там местами какая-то лютая система типов, но ровно для того, чтобы для пользователя это был очень простой DSL, притом статически проверяемый. В общем, извините за излишнюю рекламу Scala — она здесь как пример, что статическая типизация — это не всегда синоним «неудобно писать код» — иногда да, но в целом нет. Так что, если вдруг ради интереса решите посмотреть в сторону Haskell — лучше гляньте на Scala. Она, скорее всего, покажется намного более понятной, да и используется «в дикой природе» намного чаще.
Когда выбирал второй язык ( Python разбирал только пол месяца, поэтому его не считаю), посмотрел в сторону Scala, но в эту сторону и идут, как правило, последователи мира Java, поэтому выбрал Go.
Map, filter и т.п. — это ещё ES5 синтаксис для JS. Основное развитие пошло с ES6+ стандартов. Если взгляните, то увидите, сколько «сахара» сейчас предлагает JS.
Когда переходил на Scala, делал это с осторожностью, поскольку против Java испытывал некоторые предрассудки. В итоге на Scala особо "паттерны ради паттернов" не использовал. И здесь расчёт был как раз на то, что "надо будет — спрошу у Идеи все места использования, поправлю, проверю что всё компилируется — и после этого буду достаточно спокоен". Вот здесь как раз и помогала развесистая статическая типизация.
Map, filter и т.п. — это ещё ES5 синтаксис для JS. Основное развитие пошло с ES6+ стандартов. Если взгляните, то увидите, сколько «сахара» сейчас предлагает JS.
Это да, сейчас, кстати, и в Java всякие stream API появились — к счастью, языки заимствуют хорошие особенности друг у друга. Вот только когда я последний раз читал документацию по Python (довольно давно), там эти filter и т.д. по непонятной для меня причине были помечены как нежелательные к использованию.
Ох… С "философией" и классификацией у меня вечные проблемы… Видимо, да. Скорее, может, как переосмысление идей ООП и ФП (ну и статической типизации, но с каждым по отдельности она и так отлично совмещается) внутри одного языка, преимущественно нацеленное на JVM (но также на компиляцию в JS и нативный код). Кстати, насколько мне известно, часть бекенда в Twitter как раз на Scala.
Значит ваша специализация корпоративный «серьёзный софт», только и всего.
Конечно вы можете попытаться изобрести фронтэнд фраемворк или заняться машинным обучением на Scala, но зачем если есть инструменты, которые дают лучшее соотношение цена/качество?
На самом деле, тоже не вполне понимаю, зачем писать на JS на Scala — скорее, к слову пришлось. Ну, то есть, это в каком-то смысле уже не та разрекламированная Scala, опирающаяся на всю экосистему библиотек на JVM, а просто язык с прикольной системой типов и некоторыми библиотеками, поддерживающими Scala.JS.
Впрочем "современная Java" — это, скорее Kotlin. Насколько мне известно, совместить ООП и ФП вместе со статической типизацией в одном языке — это был гигантский труд. В этом плане Scala — это скорее "новый язык, опирающийся на экосистему JVM".
Кстати, на Scala даже пишут продвинутые генераторы процессоров. Хотя, справедливости ради, на чём сейчас железо только не пишут (в качестве DSL) — на Haskell, Python, разве что, не на ассемблере.
Насколько мне известно, совместить ООП и ФП вместе со статической типизацией в одном языке — это был гигантский труд.
То есть к ограничениям ООП, Kotlin добавляет ещё и ограничения ФП?))) Воинстину брейнфак.
Кстати, на Scala даже пишут продвинутые генераторы процессоров. Хотя, справедливости ради, на чём сейчас железо только не пишут (в качестве DSL) — на Haskell, Python, разве что, не на ассемблере.
Вы сначала определитесь, что хотите писать, а потом уже выбирайте язык под эти цели.
То есть к ограничениям ООП, Kotlin добавляет ещё и ограничения ФП?))) Воинстину брейнфак.
Не Kotlin, а Scala и не ограничения, а возможности. :) Можно писать как на упрощённой Java с удобным автоматическим выводом типов и лаконичными конструкциями, имея при этом доступ ко всему наследию Java. Можно (но не обязательно) и как на ФП (правда, как раз-таки без ограничений на сайд-эффекты, например).
Kotlin, как я понимаю, это попытка упростить синтаксис Java и обуздать некоторые опасные вещи вроде null, который в Java может выскочить практически, где угодно. Но врать не буду — про Kotlin я лишь слышал чужие рассказы.
Вы сначала определитесь, что хотите писать, а потом уже выбирайте язык под эти цели.
Это само собой. Просто забавно, что язык подходит сразу для многого, и при этом удобным образом (потому что одно из предназначений по задумке — DSL).
Мда… Как-то мы умудрились затеять развесистое обсуждение Scala в треде про WASM, в который она даже и не факт, что компилируется...
Мда… Как-то мы умудрились затеять развесистое обсуждение Scala в треде про WASM, в который она даже и не факт, что компилируется...
Всё же в сравнении становиться плохим или хорошим. Когда то и ассемблер был прорывом:)
Так что, если вдруг ради интереса решите посмотреть в сторону Haskell — лучше гляньте на Scala
На правах нуба и чайника, замечу что лучше наверное сначала всё-таки в сторону Хаскеля. Скала типичный язык для продакшена, позволяющий делать что угодно и как угодно. В том числе вещи совсем не идиоматичные для ФП. И если человек никогда не писал в функциональном стиле, на Скале он в нём писать никогда и не научится. А вот сначала сломать мозг Хаскелем, который просто НЕ ПОЗВОЛИТ писать не идиоматично, а потом перейти на Скалу по-моему идея гораздо более здравая. Хотя всё конечно зависит от цели.
Наверное, вы правы — и сам я именно в таком порядке знакомился — но на момент написания комментария DMP7 мне казался "JS-хейтерохейтером" и я в порыве обсуждения предложил ему что-то менее вызывающее отторжение у человека, у которого нет жгучего желания узнать, что же это за ФП, а просто интересующегося. Scala — она и в плане синтаксиса меньше мозг выносит, и используется сильно больше где. Впрочем, и сам я и близко не "чистый функциональщик".
С другой стороны, напротив, вариант "полностью сломать мозг Хаскелем и нести ФП в родной JS" (а JS, насколько я понимаю, вполне позволяет использовать некоторые подобные вещи) тоже имеет право на жизнь.
Лично я JS не отношу ни к тем не тем, т.к. он по сути не накладывает никаких ограничений, кроме здравомыслия( повторяющийся код по функция, отступы и т.п.)
На беке Node в качестве API Node выбирают такие компании, как Яндекс(видел вакансии), Гугл, ВК и многие другие.
Только код теперь пишут на Typescript, а не голом JS. Все-таки фронтенд-девелоперы (в том числе и писатели для Node.js) поняли полезность статической типизации, когда большое количество ошибок удобнее ловить на этапе компиляции, а не в рантайме.
Конкретно в Яндекс упоминание TS не такое частое. Возможно из-за того, что туда берут людей с довольно высоким интеллектом и проанализировать лог для них намного проще чем писать много лишнего кода.
Если код без искусственных накруток( когда и так компактный js пытаются сделать ещё компактнее ) хорошо оформлен, где надо комменты — то никаких проблем.
Другое дело, что программеры любят делать себя незаменимыми и придумывают «фишки», вот за такое лид должен сразу наказывать.
При миграции с js на ts с каждым шагом потихоньку включаешь все больше проверок компилятора, пока не переведешь проект в такое состояние, что он соберется с strict-type-checking. А затем в линтере объявляешь все any вне закона (и только в тех местах, где без него не обойтись (даже с помощью дженериков и/или type unions) втыкаешь коммент с отключением линтера). Компилятор, кстати, на ошибки с типами предсказуемо ругается, там магии и подводных камней нет.
Не отваливается — понятие растяжимое.
Если вам уровень мышления позволяет без проблем проанализировать консоль и понять откуда что прилетело, то JS, если нет то TS, WebAsembly и т.п. вам больше подойдут.
Эк вы мощно — звучит как "Если мозгов хватает, пиши на JS" :) (извините, если неправильно понял) Я вообще-то про другое: для "более строгих" языков тоже мозги нужны, и не меньше — просто требуются другие сильные и прощаются другие слабые стороны. Вообще, в идеале для некоторых задач (не уверен, что фронтенд к ним относится) было бы удобно, чтобы "мозгов хватило — написал хорошо, не хватило — не написал никак". В этом плане впечатляют рассказы про Rust (который я мечтаю когда-нибудь изучить) от людей, пол-часа бившихся с компилятором, выполнявших его подсказки, и в итоге таки написавших безопасный многопоточный код. В то же время компилятор C++ согласился бы почти сразу, и оно почти всегда бы работало — это-то и страшно...
RUST создавался для системного программирования, а это сложнее и ответственнее веба(самолёты и ракеты должны летать так как задумано). Писать на нём фронтэнд — это всё равно, что беспилотник сбивать ракетой за млн. $
А вот с этим соглашусь! Только один нюанс: неверный тип в Scala/Rust (в TS, наверное, тоже) прилетит при компиляции, и вы его неспешно изучите и поправите, а вот undefined is not a function — в рантайме, и поправить может понадобиться срочно. Извините за приступ графоманства :) Просто сейчас у некоторых людей есть мода выставлять JS серебряной пулей вообще для всего. Вот против этого, а не написания фронтенда на JS, в моём представлении выступают JS-хейтеры.
Я не так давно в программировании, хотя образование профильное ( жизнь помотала много где ), но о слове runtime впервые услышал в Go — такие ругательства в js не используются:)
Да без разницы что прилетит — выйдет ошибка в консоли, можно поставить точки останови или логи и посмотреть, что и откуда прилетело. Весь вопрос в том насколько это для вас сложный процесс.
У каждого языка своя специализация и ниши. По мере развития или появления новых технологий. какой то язык может занимать ниши другого — это эволюция.
Упс, прошу прощения за неточность формулировки: под run-time в данном случае я подразумевал "во время выполнения" (например, у клиента в браузере) в противовес compile-time (которое у вас на рабочем месте или на сборочном сервере).
Ну прилетит и что случиться? Самолёт упадёт или город без электричества останется? Нет, он нажмёт кнопку обновить браузер и дальше будет заниматься своими веб-делами:)
Так и живем, что сказать. И это банк, не котики какие-то. И, да, писал баг-репорты, с нулевым эффектом конечно же.
Кого их?
Не Явой единой с плюсами. Есть тот же Котлин, Скала, Груви, если речь о jvm.
Не Явой единой с плюсами. Есть тот же Котлин, Скала, Груви, если речь о jvm.
То что на JS вы напишите за день на этих языках за 2-3, при условии одинаковой квалификации программистов.
Вы сравнивали с тем же Котлином или чисто теоретически рассуждаете?
Если сравнивали — какие критерии одинаковой квалификации вы выбрали между js и jvm-based?
Под квалификацией имел ввиду программистов одинаково уверенно знающих свой инструмент.
Ну то есть вы считаете, что условный сеньор на Котлин пишет в 2-3 раза медленнее чем JS?
А вы попробуйте пересесть полностью на язык с динамической типизацией лет на 5. Когда вернетесь обратно — мыслить будете уже немного по другому. Но чем дальше — тем меньше будет чувствоваться отпечаток. Это не хорошо или плохо — это естественно. Когда общаетесь на английском — тоже мыслите по другому. Потому-что язык это не только фонетика и грамматика — это целое окружение.
И вот тут мне кажется JS очень сильно проигрывает. Был уже опыт.
Но как верно отметил Aingis, ошибки ловят тесты и грамотно выстроенная система автоматического тестирования — это 90% гарантия спокойной жизни.
Когда в языке есть несколько видов неопределенных значений, например, null, undefined, NaN, которые возвращаются случайным образом, а результаты их сравнения (==) еще более случайны, это весьма затрудняет понимание кода и поиск ошибок.
Каждое из этих значений появляется в определённых ситуациях) Для знающего человека — это облегчения анализа, а не усложнение.
В JS добавляют продвинутые возможности, но ради сохранения совместимости остается весь этот бардак, который был там с первой версии.
Бардак в старом коде, новый пишется исключительно под ES6+
Только не на фронтенде. Хочешь писать для Web: изволь использовать ровно один язык. И ладно бы язык был хорош. Людей, которые его не любят, и зачастую обоснованно, намного больше чем тех, кто его любит.
У вас будет возможность понять почему именно JS выбрали языком для фронта:)
Интересно, кем и как это гарантируется? По моему многолетнему опыту, если язык или библиотека позволяют выстрелить себе в ногу, то, увы, всегда найдется непустое множество людей, которые будут ежедневно стрелять себе в ногу.
Это гарантируется требованиями работадателей. Везде требуют ES6+. То что вы в вашем сознании ассоциируется с js уже давно умерло:)
Для таких людей создаются тесты, которые отлавливают эти выстрелы.
Да и в принципе веб программирование слишком простая отрасль, что бы такие выстрелы были частыми.
В том-то и дело, что никто не выбирал и выбора никогда не было. Потому и используется.
Давайте рассуждать логически. Если был язык, который мог бы решать эту задачу на порядок лучше, то его бы уже давно внедрили в браузеры.
У вас предвзятое отношение к языку, в котором вы не разбирались. В такой ситуации все мои аргументы бесполезны — вы всё равно будете приводить притянутые за уши примеры, которыми уже давно никто не пользуется.
LOL. Вы это говорите сейчас человеку, который имеет дело с Javascript с момента его создания.
В том и проблема, что тот язык, который жив в вашей памяти уже давно не используется, а операторы вроде "==" используют либо застрявшие в прошлом динозавры, либо хейтеры)
В общем, все, как я и полагал. В частности, что ни с чем, кроме JS, вы дела не имели. Поживите, посмотрите, через несколько лет поговорим.
Пишу ещё на Go, тоже хороший язык для определённых целей.
операторы вроде "==" используют
По назначению. Там, где нужен именно этот тип сравнения.
и использовали бенчмарки SPEC для оценки производительности Wasm по сравнению с теми же тестами на asm.js и на родном коде
Интересно, за счёт чего 429.mcf wasm обогнал нативную версию…
Так бывает, например, на сравнении JS и Wasm, когда алгоритм вроде бы одинаков, но в JS используется Number = 64-разрядный float, а в Wasm используется i32 или i64 — результаты различаются во много раз.
Будет ли wasm быстрее сервера go?
Можно нубский вопрос?
Какой инструментарий мне стоит использовать, чтобы разрабатывать модули WASM? Но только чтобы не пришлось скачивать дцать гигов фреймворков от майкрософт?
Язык я готов для этого изучить любой, я даже текстовый WASM не обломаюсь в ручную писать. Только скажите чем компилировать.
Как вариант: Emscripten позволяет транслировать большое количество кода на C в JS, но при этом он часто не прощает Undefined Behavior, на который ПОКА забивают многие другие компиляторы (UB — это всегда плохо, так что это не баг). Emscripten — это фактически backend для LLVM + run-time, изображающий из себя API системных вызовов чего-то POSIX'ного для musl libc. Также он может использоваться для C++, вроде бы для Rust, да и много ещё, наверное, для чего.
Также есть родственный ему проект Binaryen — своего рода binutils для WASM. Можно хоть из JS генерировать WASM на ходу (если собрать Binaryen в JS или WASM с помощью Emscripten), но помни, Золушка после приблизительно тысячного WASM-модуля вкладка Chrome превращается в тыкву.
На правах рекламы: вот здесь можно почитать, как я портировал QEMU для выполнения в браузере — там и Emscripten, и Binaryen, и JIT...
Emscripten в последних версиях уже использует LLVM для wasm.
Ну, для пользователя разница, видимо, будет не сильно заметной, своя у них поддержка или из upstream LLVM (всё равно всё работало через LLVM с давних времён). Скорее, это важно для остальной экосистемы LLVM и его frontend'ов.
UPD: говорят, компилируется значительно быстрее. Надо бы посмотреть...
Правда, они либо ещё не обновили документацию, либо не переключились по умолчанию на использование upstream backend:
Emscripten can currently (July 2019) use 2 backends to generate WebAssembly: fastcomp (the asm.js backend, together with asm2wasm) and the upstream LLVM wasm backend.
Fastcomp is currently the default, but we hope to switch the default soon to the upstream backend.
Как бы пользователи компиляторов, это разработчики. Разная скорость компиляции и разного качества выходные бинарники. fastcomp это набор скриптов на python и nodejs.
To install/activate it, use one of:
latest [default (llvm) backend]
latest-fastcomp [legacy (fastcomp) backend]
Those are equivalent to installing/activating the following:
1.39.3
1.39.3-fastcompНу, на качество выходных бинарников ещё не смотрел. А вот со скоростью по прошлым впечатлением, действительно, было куда расти. Особенно неприятно было на относительно слабом ноутбуке (Core i3-380M и 8Gb оперативки, ага) заметить ошибку, поправить один файл и минуту ждать линковки. Если новый backend это устраняет, то это очень радует!
Также можно попробовать Rust.
Если вам ближе TypeScript, то AssemblyScript.
Можно. Например, с помощью Binaryen можно собрать из "ассемблерного листинга", а можно генерировать на ходу программно. Во втором случае поддерживается не только высокоуровневый control flow (if / while / switch или что там), но и низкоуровневые передачи управления между basic block'ами, а он уже сам сделает relooping (т.е. сведёт к первому случаю, как требуется в wasm) — это пригодится, если у вас уже некое промежуточное представление, а не человекочитаемый код, который вы вручную пишете.
в идеале настолько быстро, насколько позволяет имеющийся у нас процессор.
виртуальная машина, байт-код
Миссия провалена.
Байт-код приводит к затратам на старте, но не замедляет последующее выполнение.
Если нужна макс. производительность — используйте JIT-компиляцию. Но тогда теряется безопасность, если код выполняется в адресном пространстве браузера или производительность — если в отдельном.
Вы все равно никак не получите макс. безопасность, переносимость и производительность одновременно. Чем-то придется жертвовать, в случае браузеров — это однозначно производительность.
Любой байт-код интерпретируется виртуальной машиной.
Кроме того, который можно при получении сразу скомпилировать в нативный код. Насколько я помню, с WebAssembly дело обстоит именно так. Что-то вроде "write once, compile everywhere", только компиляция делается непосредственно перед запуском, но не для каждой функции отдельно (как в случае JIT-компилятора), а для всего полученного байт-кода сразу.
WebAssembly: что и как