company_banner

Что не так с WebAssembly?

Автор оригинала: Fernando Doglio
  • Перевод
Современные браузеры могут намного больше, чем рендеринг веб-страниц. Это стало одной из причин появления WebAssembly. Эта технология создана в попытке вывести скорость решения сложных задач на новый уровень, построить мост между JavaScript и машинным кодом.

WebAssembly, в теории, может позволить кому угодно писать низкоуровневый код, выполняющийся в браузере, в безопасном виртуальном окружении. И, что ещё интереснее, технология WASM (сокращение от WebAssembly) была спроектирована как цель компиляции для других языков, позволяя коду, который обычно выполняют в серверной среде (например — коду, написанному на C или на C++), компилироваться в соответствующий формат и выполняться в браузере.



У WASM был огромный потенциал и невероятные перспективы. Что же пошло не так? Почему WASM, через 3 года после релиза, ещё не используется в каждом веб-проекте? Есть ли у WASM будущее в веб-разработке? Поищем ответы на эти вопросы.

В чём заключается цель создания WASM?


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

Никто не собирался создавать новый язык, который предлагалось бы активно использовать веб-разработчикам. Вместо этого технология WASM создавалась как цель компиляции, благодаря которой, скажем, C-разработчик мог бы скомпилировать свой код и запустить его в браузере.

Какая от этого может быть польза?

Хотя JavaScript — это замечательный язык, его разрабатывали, не обращая особого внимания на производительность. И если в веб-среде можно было бы, вместе с JavaScript, применять другие языки, рассчитанные на высокопроизводительные вычисления, это позволило бы пользоваться в браузере всем тем полезным, что есть в JavaScript и в этих языках. Но как это сделать? С помощью некоей промежуточной технологии, некоего моста, которым и стала технология WASM.

▍Какими же создатели WASM видели способы использования этой технологии?


Технология WASM не создавалась как нечто, позволяющее оптимизировать веб-сайты. Она была рассчитана на то, чтобы перевести браузеры (и серверные среды вроде Node.js) на новый уровень производительности при решении некоторых задач. Например — таких:

  • Редактирование видео.
  • Разработка игр.
  • Создание приложений виртуальной реальности.
  • Редактирование и потоковая передача музыки.
  • Эмуляция различных платформ.
  • Шифрование.
  • VPN.
  • Распознавание изображений

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

Кто и для чего реально использует WASM?


Здесь можно найти опенсорсный список проектов, в которых используется WASM.

Но если вам не хочется открывать ещё одну вкладку браузера — вот некоторые наиболее известные проекты из этого списка:

  • TensorFlow.js. Не знали, что WASM используется в TensorFlow.js? Но, на самом деле, так оно и есть. TensorFlow, одна из основных библиотек, давшая JS-разработчикам возможность пользоваться технологиями искусственного интеллекта и машинного обучения, уже давно обзавелась поддержкой WASM-бэкенда. Работа над WASM-реализацией всё новых и новых моделей с тех пор не прекращается. Какая от этого выгода? Разработчики библиотеки заявляют о том, что производительность моделей благодаря WASM выросла, в сравнении с их JS-реализацией, в среднем, в 10 раз.
  • Unity. Это — ещё один известнейший проект. Один из ведущих движков для разработки игр может экспортировать проекты в виде, подходящем для веба. С 2018 года это делается путём компиляции кода в формат WebAssembly. Это — отличный пример того, какую мощь даёт технология WASM тем, кто правильно её применяет. Разработчикам игр не нужно заботиться о создании веб-проектов, или даже о написании JavaScript-кода. Их основная задача — писать код игр, а всё остальное — задача компилятора.
  • Веб-приложение AutoCAD. И здесь используется именно WASM. Правда, веб-приложение Autodesk было переведено на новую технологию лишь частично — старая кодовая база, написанная на C++, была скомпилирована в формат WASM. Это — важный шаг, демонстрирующий возможности WASM в деле повторного использования кода, написанного для платформы, ничего общего не имеющей с вебом, на языке, совершенно не совместимом с браузерами. Теперь этот код спокойно работает в браузерной среде.
  • Google Earth. Вы, возможно, по крайней мере слышали об использовании WASM в этом проекте. Он существует уже более 15 лет, раньше этот проект был представлен настольным приложением. А теперь, благодаря WASM, часть старого кода была перенесена в веб-среду (это очень похоже на то, что было сделано компанией Autodesk). Это — ещё один отличный пример того, чего можно достичь, пользуясь этой технологией.
  • Blazor. Это — среда, использующая возможности ASP.NET для создания интерактивных интерфейсов, работающих в браузере. Благодаря невероятным возможностям WASM .NET-код исполняется прямо в браузере. В результате в руках разработчиков, привыкших писать серверный C#-код, оказывается инструмент для описания веб-интерфейсов.
  • Yew. Думали ли вы когда-нибудь о том, чтобы использовать в своих веб-приложениях Rust? Теперь это, благодаря проекту Yew, совершенно реально. При этом Rust можно применять не только для создания интерфейсов. Yew даёт в распоряжение разработчика среду, поддерживающую многопоточность. Этот проект, правда, пока не готов к продакшн-использованию, но если вы — любитель Rust и хотите пользоваться Yew, но нуждаетесь в помощи, вы всегда можете обратиться за советом к дружелюбной команде этого проекта.

В вышеупомянутом списке более 100 проектов. То, что за некоторыми из них стоят Microsoft, Unity и Google, недвусмысленно указывает на потенциал WebAssembly.

Почему технология WASM не получила достаточно серьёзного распространения?


После чтения вышеприведённого списка проектов, в которых используется WebAssembly, вполне уместно задаться парой вопросов. Во-первых — поинтересоваться тем, что не так с WASM, а во вторых — тем, почему эта технология не получила достаточно серьёзного распространения.

Если об этом поразмыслить, то окажется, что веб изобилует замечательными проектами, не снискавшими особой популярности, так как они не смогли получить достаточной поддержки у своей целевой аудитории. Полагаю, что-то подобное происходит и с WASM.

Бесспорно то, что технология WebAssembly обладает огромным потенциалом, она позволяет делать удивительные вещи и переносить в веб существующие проекты, написанные на языках, не предназначенных для браузеров. Правда, в связи с этим возникает вопрос о том, знают ли об этом разработчики.

Вот вы, например, до чтения этой статьи, уделяли ли некоторое время тому, чтобы найти примеры реального применения WASM? Знаете ли вы о том, как написать WASM-вариант «Hello, World!»? Возникала ли у вас необходимость переноса приложения, написанного для настольной системы, в браузер?

Думаю, что ещё одна ключевая проблема WASM заключается в том, что эта технология нацелена не на веб-разработчиков. Она рассчитана абсолютно на всех, кто хочет перенести некий код в веб-среду. Веб-разработчикам технология WASM не нужна. Они уже знают о том, как пользоваться JavaScript. А учитывая то, сколько сил отнимает даже создание простой WASM-версии «Hello, World!» (вот пример), я вполне понимаю то, что они особо не стремятся освоить эту технологию.

Самая распространённая точка зрения сейчас такова: если речь идёт о создании приложения, выполняющего интенсивные вычисления, то это будет обычное приложение.

Это касается игр, приложений для виртуальной реальности, эмуляторов различных платформ (например — виртуальных машин) и, в целом, всего того, на реализацию чего в браузере рассчитана технология WASM. И, насколько мне известно, для того чтобы поломать тот настрой, который складывался годами, нужны огромные усилия, а большинство компаний просто в этом не заинтересовано.

Станет ли технология WASM чем-то вроде нового стандартного языка для разработки веб-проектов?


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

Стоит помнить о том, что разработчики-то, на самом деле, не пишут WASM-код. Вместо этого ожидается, что они будут писать на C, на Go, или на каком-то другом языке, а потом то, что они написали, будет работать в браузере.

Учитывая это — я не думаю, что WASM вскоре заменит JavaScript. Правда, число тех, кто пользуется WASM, будет расти, так как тенденция перемещения всего в облачные среды помогает изменить то отношение к требовательным проектам, о котором я говорил выше.

Веб-разработчик вы или нет — вы не сможете поспорить с тем, что благодаря тому, как устроена веб-разработка, можно, затратив сравнительно небольшие усилия, взаимодействовать с миллионами пользователей. При этом у веб-разработчика есть весьма гибкие средства, позволяющие менять и обновлять клиентское программное обеспечение. Эта модель скоро станет более привлекательной для компаний, который сейчас имеют полностью нативные (то есть — настольные или мобильные) продукты. Время идёт, а индустрия разработки ПО продолжает движение в сторону облачных технологий.

На самом деле, у технологии WASM есть возможность продлить «срок годности» навыков разработчиков, которые занимаются сейчас тем, что не связано с вебом. Она позволяет таким разработчикам продолжить пользоваться тем, к чему они привыкли, разрабатывая проекты для новой платформы.

Итоги


Технологию WebAssembly создавали люди, ведомые великой целью: устранить разрыв между вебом и всем остальным миром программного обеспечения. Правда, в этой области ещё очень и очень многое предстоит сделать. Но сильные стороны WASM уже вполне хорошо видны в тех проектах, где эта технология используется. Одно только то, что WASM поддерживают 4 ведущих браузера, говорит о том, что эта технология набирает популярность в сфере разработки ПО.

Правда, пока без ответа остаётся вопрос о том, станет ли WASM чем-то большим, чем некий рядовой инструмент, используемый ограниченным контингентом разработчиков. Точного ответа на этот вопрос дать пока нельзя.

А что думаете об этом вы? Полагаете ли вы, что WASM через некоторое время превратиться в ключевую технологию веб-платформы? Видите ли вы формат WASM чем-то таким, что станет, лет через десять-двадцать, стандартным форматом, в который компилируется код, написанный на разных языках программирования? Или, может, вам кажется, что «проект WASM» попросту провалится, и что в сообществе разработчиков не иссякнут разговоры о противостоянии нативных и браузерных приложений?

RUVDS.com
VDS/VPS-хостинг. Скидка 10% по коду HABR

Похожие публикации

Комментарии 163

    +8
    Но у wasm же еще есть такая ниша как embedded vm на стороне сервера. Среда, где можно изолированно выполнять пользовательский, например, код.
      +5
      Почему технология WASM не получила достаточно серьёзного распространения?

      Это как? Unity сейчас торчит почти из каждой гейм-разработки.

      Станет ли технология WASM чем-то вроде нового стандартного языка для разработки веб-проектов?

      javascript — язык очень простой и быстрый в разработке. Зачем его менять на что-то более сложное и непонятное?

      JS и WASM это разные ниши. Как java/С# и C++.
      Они и не должны друг друга замещать.

      Я уверен, что многие фреймворки будут переписывать части потрохов на WASM.
      Наверное даже какие-то CMS, включая WP может переписать какие-то потроха на WASM.

      Но в основной части веб-разработки WASM не требуется — требуются готовые либы, которые, собственно, уже и есть и продолжают появляться.
        0
        Это как? Unity сейчас торчит почти из каждой гейм-разработки.

        Речь же только о сайтах
          0
          веб-разработка сейчас это не только сайты. Браузеры — уже давно полноценная платформа, даже более полноценная, чем некоторые другие.
        +15
        Web разработчик пишет про технологию, которая делает JS ненужным… Ну если он не ждал WebAsm, то я как C# девелопер, который никогда не будет писать на JS, ждал как манну небесную! И теперь наконец-то я могу желать web морды.
          –2

          А разве js в wasm не компилируется? Я думал его как раз для этого и придумали.

            +7

            В wasm нет, и непонятно когда появится gc. Когда туда компилят шарпы, то тащат свой gc и огребают от этого миллион проблем

              +1

              Только шарпы ведь специально в wasm не компилят, а затаскивают реализацию виртуальной машины, которая исполняет обычный байткод дотнета. Из ощутимых проблем — это увеличивает размер бандла, хотя код рантайма отлично кэшируется.

                0

                Обещают aot компиляцию в будущем

                  +2
                  Если посмотреть как компилится юнити, то она компилится а il представление, затем вызывает il2cpp, и потом уже, через emscripten в js или wasm. В итоге живёт это не непрерывном куске памяти. Если уже занято допустим 256, и нужно больше, то нужно выделить 512, скопировать туда эти 256. Т.е. в моменте при переходе с 256 на 257 метров будет выделено 768, двумя огромными кусками, этого может не быть разом даже на машине с 4GB памяти. Короче весьма сомнительное мероприятие.
                +1
                Typescript проект для ознакомления github.com/AssemblyScript/assemblyscript
                  0

                  Интересная штука, только несколько смущает что они всю дорогу сопоставляют себя с Typescript, хотя языки настолько далёкие друг от друга, что лучше бы они себя с условным C# сопоставляли. AS — язык со слабой sound системой типов, с возможностью runtime cast-ов. TS — мета-язык транспилируемый почти без изменений в JS с сильной системой типов и полным отсутствием чего-бы то ни было в runtime.


                  Мне кажется C# и Java имеет с AS больше общего, чем TS.

                    0
                    Не знаю причем тут C# и Java, большая часть проектов WASM написана на C++ или Rust… TS постольку поскольку видел ряд проектов, ну и assemblyscript в том числе. Пример вот вспомнил от Google — github.com/GoogleChromeLabs/squoosh браузерный компрессор для фото, все кодеки на Rust (WASM), веб морда на TS
                      0
                      большая часть проектов WASM написана на C++ или Rust

                      И что? Не увидел в AS никаких синтаксиса для указателей. Плохо искал? Ручное управление памятью? Вроде документация пишет про GC. Также как не увидел в AS ничего из того, чем славен TS.


                      Остальную часть вашего сообщения я, если честно, вообще не понял. Вы комментарием не промахнулись?

                        –1
                        Вторая часть сообщения просто пример проекта на Rust и TS, не более того. По поводу GC, написано же на доступном языке на сайте AS:

                        AssemblyScript implements garbage collection on top of linear memory while the WebAssembly GC (https://github.com/WebAssembly/gc) proposal is still in the works. More precisely it implements multiple runtime variants that are useful for different use cases, with the default being your typical memory manager and GC. The interface of the different variants is always the same, so these are interchangeable, yet differ in their level of sophistication. In case of doubt, starting out with the default is probably just fine.


                        и про память в целом www.assemblyscript.org/memory.html#importing-memory
                          0
                          По поводу GC, написано же на доступном языке на сайте AS

                          Как раз оттуда я и взял то что язык использует GC. Отключать GC можно во многих языках. По ссылке ничего особенно интересного нет. Вот тут (следующая ссылка) уже что-то есть:


                          function __new(size: usize, id: u32): usize
                          function __pin(ptr: usize): usize
                          function __unpin(ptr: usize): void
                          function __collect(): void

                          Получается что синтаксиса нет, но есть что-то вроде макросов\встроенных методов. Т.е. при большом желании можно поиграть в C.

                –4

                Так веб морду вам в любом случае на JS надо будет писать т.к. прямого доступа к DOM у WASM нет.

                  +3
                  В веб-фреймворках под WASM обычно реализованы обертки с интеропом под капотом, чтобы у пользователя не было нужды вылезать из привычной технологии. А тот же Razor для C# вовсе заточен на создание интерфейсов.
                    +1

                    Я не очень в теме, но не окажется ли, что в веб-фреймворках под WASM, собственно, JS больше, чем WASM?

                      +1
                      Почему его должно быть больше? Это же обертки над API и всякие бутстраперы WASM-модулей, а логика делается на чем-то WASM-совместимом.
                      К примеру, у Yew (web_sys) бутстрапер в ~16Кб неминифицированного кода, благодаря чему хэлловорд в сборе выходит меньше размером, чем голый реакт.
                  +2
                  Нам бекендерам эту возможность уже ни раз пытались дать, начиная от WebForms и заканчивая Silverlight. И пока все эти корявые попытки делались, JS стал достаточно зрелым и серьёзным и набрал критическую массу, позволяющую уже даже отжимать нишу на бекенде.
                    0

                    Стремление использовать один язык для всех возможных задач, скорее всего, выйдет вам боком: тулинг будет неудобным, поддержка сообщества — скудной, а ваши "веб-морды" — тяжелыми. Я искренне считаю сишарп одним из лучших современных языков, но он не является серебряной пулей.


                    Писать под веб можно и не касаясь джиеса: typescript, reasonml, purescript...

                      0
                      А тулинг всяких вебпаков легкий.

                      Как человек, который писал на ангуляре 2-7 и который сейчас пишет на Блейзоре могу смело сказать, что писать код и компилить стало в разы быстрее.

                      Тяжесть морды очень относительна. Сам фреймворк кэшируется и не меняется, из бинарей вырезаются неиспользуемые методы, главное рефлексией не баловаться.
                        +1
                        А тулинг всяких вебпаков легкий.
                        Можно использовать Parcel — там практически все из коробки работает. Куда еще легче?
                        Для сравнения — почитайте, как работает отладка блазора.
                        Тяжесть морды очень относительна.
                        Да ничего «относительного» тут нет. Вы сначала заставляете пользователя скачать ~2 мегабайта бинарников, т.е. весь рантайм Mono целиком, а не только то, что фактически используется. Потом он начинает интерпретировать уже непосредственно ваш код — про JIT-компиляцию можете забыть, т.к. она будет работать только на уровне «WASM -> Mono», а на уровне «Mono -> ваш код» это невозможно из соображений безопасности.

                        До тех пор, пока в рантайм WASM не запилят GC и не будет возможности компилировать C# -> WASM напрямую, без промежуточной виртуальной машины, Blazor — не более, чем любопытная игрушка, использовать которую в продакшене можно только на свой страх и риск. А конкретных планов по реализации этой фичи в WASM пока нет, только пропозал…
                          +1

                          https://github.com/dotnet/aspnetcore/issues/5466


                          mkArtakMSFT modified the milestones: Next sprint planning, 6.0.0 11 days ago
                          mkArtakMSFT added this to 6.0 in ASP.NET Core Blazor & MVC 6.0 11 days ago


                          И еще


                          While we do expect significant runtime performance improvements from AoT, our investigations so far have shown that AoT trades of improved runtime performance for increased download size. Code that has been AoT compiled to WebAssembly is generally larger than the equivalent .NET IL (just like how natively compiled .NET images are typically larger than the original .NET assemblies), which impacts startup time. This is why we expect AoT will typically be used in a mixed mode, where some of the app has been optimized for runtime performance using AoT, and the rest has been left as interpreted .NET IL for compactness. Initially we may use AoT to optimize common performance critical code paths in Blazor, like component rendering and JSON parsing, and then make the AoT toolchain available to users to decide how they want to optimize their own code. AoT also does impact the availability of dynamic runtime features, like calling code using reflection.

                          Even with AoT being delayed, we still expect to deliver performance improvements for Blazor WebAssembly in .NET 5. The .NET 5 core libraries are generally more efficient than the Mono ones we're currently using. We are also investigating other performance improvements, like improvements to the GC and the Blazor component rendering algorithm. We are then planning to make previews of AoT support for Blazor WebAssembly available early in the .NET 6 release timeframe (first previews expected in Q1 '21).
                      0
                      Я считаю выбор языков под задачу фикцией. Еще ни разу за мою карьеру никто не выбирал его действительно под задачу. Выбор всегда был или «я это знаю хорошо — давайте на этом и делать» или «я хочу с вот этой штукой побаловаться — давайте на этом и делать». Да собственно угадайте язык по «преимуществам»: простота освоения, простота использования, быстрый старт для типовых задач, динамично развивающийся, обширное комьюнити. Узнали? Знаете что это за язык? Любой!

                      В свете вышесказаного использование одного языка для всего, равно как и «выбор» под задачу — равнозначны.

                      Что качается неповоротливых формочек… Ну поскольку мы и так «выбрали» веб ни о какой «легкости» речь уже не идет. Однако это и не важно! Критерии качества корпоративного софта сильно отличаются от «нормальных». Тут известные баги можно годами не лечить, потому, что известен воркэраунд и главное он известен всем… трем пользоватлям софтины. Тут пользователи по 2 минуты могут ждать отклик веб страницы потому, что альтернатива сделать то-же самое руками за день. И т.д. Я не говорю, что это хорошо, но и не говорю что это однозначно днище и фу фу. Задачи другие. Другие приоритеты.

                      Писать под веб можно и не касаясь джиеса: typescript, reasonml, purescript...


                      А можно, не отходя от станка, на шарпе. Об этом собственно и речь. Это именно «выбор» типа «я это знаю хорошо — давайте на этом и делать». И выбор в данном случае осознанный — морда в данном случае побочный продукт а вовсе не основной. Она не видна наружу. От нее требуется только одно — чтоб она была. У пользователей какой критерий «хорошей» софтины? Да чтоб в Excel выгружало 4 гига отчета! :)
                        0
                        Я считаю выбор языков под задачу фикцией.
                        С одной стороны, я понимаю, что в инженерной практике иногда возникает необходимость забить гвоздь микроскопом. Вот прям позарез надо, а вокруг кроме микроскопа вообще ничего нет, и даже если гвоздь войдет криво, а на микроскопе останется царапина — это не важно. Это к вопросу о том, что «от морды необходимо только то, чтобы она была». Если человек понимает риски и идет на этот выбор осознанно — это вполне допустимо.

                        С другой стороны — отрицание необходимости выбора инструмента под задачу говорит только о вашем уровне компетенции, а то, что никто из вашего круга общения так не делал, вы экстраполируете этот опыт на весь мир и радуетесь, что вам не придется больше иметь дело с этими отвратительными молотками — окончательно авторитет ваших слов на ноль.
                        Знаете что это за язык? Любой!
                        Опять же, совсем не так. Помимо качеств непосредственно языка, которые вы перечислили, есть также экосистема — набор доступных для него библиотек/фреймворков/движков, решающих определенные задачи.

                        Например, сам по себе Python не особо предназначен для всякого дата-саенса. В нем по умолчанию нет ни матриц, ни комплексных чисел, ни символьного вычисления, как в каком-нибудь Wolfram Alpha / Mathcad, да и скорость выполнения для числодробилок не впечатляет. Однако самые популярные библиотеки реализованы именно под него, что делает Python выбором номер 1 при необходимости проанализировать массив данных на наличие корреляции или натренировать нейросеть. Аналогично, PHP все еще довольно популярен, но даже отъявленным фанатам не приходит в голову написать на нем, например, 3D-движок или загрузчик операционной системы.

                        Поэтому писать вы, конечно, вольны на чем угодно. Хоть на сишарпе, хоть на 1С, хоть на батниках — особенно, если этот продукт не нужен никому, кроме трех с половиной человек. Но выдавать в качестве хорошего инженерного решения — увольте.
                          +1
                          Ха! Я в профессии и 90х годов. Работал много где и соответственно языки народ использовал от ассемблера (на самом деле человек программу банкомата в прямо в бинаре правил потому, что исходники потерял :) ) до… ну всего из top 20 + всякая экзотика. И везде вне зависимомти от размера организации, страны и бизнес области четко прослеживалась связь с единственным человеком, который «выбрал под задачу». Само наличие кучи взаимозаменчемых языков подтверждает мои слова.

                          Вы гоаорите инфраструктура определяет годность «под задачу». Соглашусь. Но инфраструктура не язык. причем примеров масса, когда явно не подхлдящий язык используется именно как «стандарт». Давайте посмотрим:
                          • JS подходит для ML? TensorFlow
                          • C# со сборщиком мусора для игр? Unity
                          • Скриптовый Python для data science? Вы сами этот пример привели.
                          • Если уж на то пошло, то JS хорош для UI? Просто выбора нет.

                          И т.д.

                          Если раньше еще можно было говорить что С имеет преимущество перед Ассемблером потому что..., то с современными языками это уже не так. Да объективные преимущества у разных классов языков есть. Но внутри одного класса? Это даже не смешно уже. Что случше Java или C#? Можно холиварить хоть год. А в реальности? Я знаю C# значит от лучше. Кто-то знает Java — да он же прямо создан для это го проекта!

                          И насчет загрузчика на PHP… Но есть-же бекэнд на JS :)
                            0

                            У нас была комичная история. Набрали php-шников и скрам-коуча. И стали выбирать, на каком языке делать новый проект для кассовых аппаратов. И какой же язык лучше всего подошёл под задачу, как вы думаете?)


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

                    –6
                    Главная проблема wasm — бинарность. Непонятно, что код делает, с js хотя-бы теоретически можно что-то контролировать. Ещё больше усугубляется проблема поиска. Сейчас wasm используется тестово, а через время на нём начнут сайты пилить.
                    Потенциально — ящик пандоры, реальность как всегда удивит больше наших фантазий.
                      +7

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

                        0

                        js разминифицировать реально тем более что многие оставляют открытыми map файлы которые позволяют еще и получить исходный код как есть.


                        Тут же мы получим аналог asm для некоторой виртуальной машины — исходный код не поучить. Без хорошего знания ассемблера и LLVM понять что же делает этот маленький пакет на 620кб который визуально ничего не делает — доступно только избранным.

                          +1

                          Там довольно простой ассемблер так-то.


                          image


                          Да и DWARF файлы с исходниками точно так же будут оставлять открытыми.

                      +2
                      Для широкого распространения WASM не хватает сборщика мусора. Как только он будет: Java, C#, Scala, Go и ещё куча языков смогут работать поверх WASM и JS можно будет отправить на свалку истории.
                        0

                        У того же голанга размер пустого бинарника с реализацией сборщика мусора после tinygo — 20кб — вполне вменяемо по сравнению с 1.6мб blazor-а от c#. Т.е реализация managed-управления памятью уже не проблема прямо поверх wasm-а без таковой.

                          0
                          Т.е реализация managed-управления памятью уже не проблема прямо поверх wasm-а без таковой.

                          Безусловно. Но когда у вас таких блобов несколько, и каждый тащит свою реализацию рантайма...

                            0
                            Но blazor не пустой. Там по сути весь рантайм. Да, он большой, но возможностей там ого-го.
                              0

                              Смысл в том, что нет dead code elimination — 1.6Мб — это для пустого проекта практически без пользовательского кода, который никак не использует все это богатство. Если так рассуждать, то 20кб в голанге — это тоже весь богатый рантайм, необходимый для такого же минимального пользовательского кода. Если начать подкидывать своего кода, то размер будет увеличиваться и там и там, просто в одном случае это будет 1.6Мб+, в другом 20кб+.

                            0
                            Для широкого распространения WASM не хватает работы с DOM. И предпосылок к тому, что она появится на данный момент нет. Так что не торопитесь хоронить JS)))
                              0
                              И предпосылок к тому, что она появится на данный момент нет
                              Почему нет? Reference Types proposal почти уже запилили, Typed Functions, Type Import и GC proposal'ы в процессе, а дальше дело будет уже за малым.
                            +6

                            Wasm хорош для специализированных вычислительных задач, или для игр. Обычный фронт вполне шустро работает на js/ts, если конечно не написан совсем криворукими джунами, которые и васм закосячат. Плюс для фронтовых задач есть фреймворки типа реакта или вью, удобный процесс отладки, декларативно-реактивный подход, который не с потолка был взят, а стал итогом многолетней эволюции. Не вижу смысла отказываться от всех этих удобств ради сомнительного пунктика "не использовать js. Тем более по факту промышленным стандартом становится тайпскрипт, который устранил единственный js-ный недостаток — отсутствие типизации. Js не используется в новых проектах:) А что понапишут новоприбывшие фронтендеры на своих "правильных" языках? Спагетти-портянки в стиле jQuery конца нулевых?)))


                            Итого: сишный/плюсовой васм имеет практический смысл, остальное — блажь и йуношеский максимализм, не более.

                              –3
                              Обычный фронт вполне шустро работает на js/ts, если конечно не написан совсем криворукими джунами, которые и васм закосячат.
                              Ой, я надеюсь ты не про mail.ru или не про online.sberbank.ru
                                0

                                Как правило узким местом производительности веб-приложений является CSS и манипуляция DOM, то есть неоптимальное использование браузерного API. WASM + WebGL могут взять на себя отрисовку интерфейса, но это намного трудозатратнее.

                                +2
                                есть фреймворки типа реакта или вью, удобный процесс отладки, декларативно-реактивный подход

                                Blazor и Yew эксплуатируют React-подобный подход с XML-подобным синтаксисом и реактивностью. Первый из коробки отлаживается прямо в девтулзах хрома.

                                тайпскрипт, который устранил единственный js-ный недостаток — отсутствие типизации.

                                В рантайме типов нет, а слабость типизации все так же присутствует.
                                  –3

                                  То что в рантайме типов нет, это преимущество. Представьте, ваш сайт делает запрос ко внешнему API, а формат его ответа поменялся. В слабой типизации, пользователь увидит NaN, но остальная функциональность сайта продолжит работать. А в случае сильной типизации случится рантайм ошибка и сломается вообще всё. Придется в экстренном порядке все бросать и чинить интеграцию с API

                                    +4
                                    А в случае сильной типизации случится рантайм ошибка и сломается вообще всё

                                    Ну нет. Не так. В случае сильной типизации будет ровно то, что вы пропишете. Хотите чтобы приложение кидало ошибку? Тогда после провальной валидации кидайте ошибку. Хотите чтобы в баг-трекер ушло сообщение о проблеме, но пользователь продолжил работу с приложением на удачу? Не вопрос — достройте объект дефолтными значениями.


                                    В случае TS тут скорее играет роль, что типизация игрушечная, и вы можете вообще без какой-либо валидации взять полученное значение "как есть", ибо весь runtime-язык (JS) устроен как "всё есть либо примитив, либо hashmap". Но едва ли это стоит относить к сильной стороне JS. А то что в TS нельзя внятно проверить объект на соответствие типов, потому что runtime информации просто нет — это недостаток. Не на пустом месте берутся все эти io-ts. Но такова уж суть TS, что это мета-язык поверх JS, без своих runtime примитивов.

                                      –3

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

                                        +2

                                        Ну выбор между: неполными провалидированными данными, дополненными значениями по-умолчанию где надо и данными, не соответсвующими схеме, — мне кажется очевиден. Вообще довольно странно радоваться тому что приложение может не упасть когда вместо ожидаемых данных по нему бродит неведомо что. Вам правда нравится ситуация когда в каком-нибудь калькуляторе страховки все поля превращаются в NaN? :-) Или что ещё хуже — НЕ превращаются, просто калькулятор врёт.


                                        Если вы настолько сильно недоверяете своему backend-у, то, имхо, это тем более ещё один повод добавить валидацию.

                                          +1

                                          NaN в калькуляторе страховки мне не понравится. Но вот прочитать статью с NaN лайков я смогу, а если там в процессе загрузки будет TypeError – то уже нет

                                            +3
                                            а если там в процессе загрузки будет TypeError – то уже нет

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


                                            Но мне кажется вы занимаетесь самообманом. Ибо, помимо минорных глюков, это ещё источник и мажорных глюков, далеко не все из которых действительно уронят приложение. По той же самой причине. А учитывая что это "отложенные" баги, как, напримре, запись в произвольную область памяти в C++, то никогда не знаешь где и как оно выстрельнет. А учитывая какую вариативность могут нести такие баги… Вы можете наслаждаться ими вечность (ибо о них даже не знают).


                                            Выбирая между двух зол — я бы выбрал "пусть падает". Это приведёт к:


                                            • разработчики научатся ронять не всё приложение а только лишь часть
                                            • бизнес, зависящий от этого приложения, будет чинить баги. И как минимум знать о них

                                            А вот это вебовское "тяп-ляп, ура, вроде работает", меня самого, как веб-разработчика, — бесит.

                                              +2

                                              Убедили, лучше явная ошибка со стектрейсом, чем невнятный баг репорт от пользователя "что-то работает, но не так". Более строгие TypeError пригодились бы.

                                        0
                                        А то что в TS нельзя внятно проверить объект на соответствие типов, потому что runtime информации просто нет — это недостаток.

                                        А зачем вам проверять его тип в рантайме?
                                          0
                                          • Мета информация доступная в runtime позволяет проводить автоматическую валидацию (пригодится как во фронте, так и на беке)
                                          • Автоматическое построение каких-нибудь моделей (к примеру в ORM)
                                          • Писать гарантированно работающий код вместо guard-ов (которые недалеко от any ушли)

                                          Я думаю если покопаться, то можно много разных кейсов вспомнить. Особенно если спросить шарпистов\джавистов. По сути у нас уже есть instanceof. И многие на это полагаются. Но это работает только с классами. Рефлексия "для бедных".


                                          Кодогенерация из TS типов почти невыполнима. К примеру я недавно игрался с рядом либ которые генерят валидаторы из типов. Решения разделились на 3 группы


                                          • не работает даже в самых тривиальных случаях
                                          • работает только в самых тривиальных случаях и очень плохо
                                          • в целом работает, но генерирует огроооооомные портянки кода и не умеет в переиспользование кода

                                          Основная причина в том, что система типов в TS слиишком сложная, и позволяет генерировать безумно сложные типы. Не зря люди пишут io-ts модели руками.

                                            0
                                            Кодогенерация из TS типов почти невыполнима. К примеру я недавно игрался с рядом либ которые генерят валидаторы из типов.

                                            Лично я не "игрался", а некоторое время назад успешно использовал https://github.com/vedantroy/typecheck.macro
                                            Оно не очень хорошо умеет в сложные типы, но я категорически не вижу смысла в попытках "напрягать" генератор пока он не сломается — на практике нужно ехать (провалидировать результат JSON.parse на входе), а не шашечки. Всё сложное можно заменить на композицию из простого, и отдельно после валидации преобразовывать serialization-ready формат к runtime-ready, если в рантайме таки хочется сложных типов. Валидация же нужна на периметре, а не везде.


                                            А можно и в io-ts модели писать, да (оно всё равно сгенерит типы из моделей). Но я подход с привлечением DSL для описания валидации всё равно считаю "шаг назад, два вперед" — не очень хочется брать какой-то DSL, который полностью заменяют типы TS.

                                              0

                                              На практике всё же надо именно провалидировать JSON: убедиться, что число товаров не является дробным числом, что дата доставки не указывает в прошлое, что в той же дате указан часовой пояс, что номер телефона состоит из цифр и тд. Тут тайпскриптовые типы пасуют. Так что проще не валидатор из типов генерить, а типы из валидатора выводить.

                                                0

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

                                                  0

                                                  А с чего бы мне доверять системе, которую я не контролирую?

                                                    0
                                                    для этого есть отдельный и весьма обширный набор решений

                                                    Вообще не доверяю беку. Подскажите что за решения?

                                                      0

                                                      Всё, что работает с JSON Schema, главным образом.

                                                        0

                                                        А, ок. По сути это тот же класс решений, что и io-ts, только более многословный. Как написана схема и кто её интерпретатор — не так важно, важно что писать её руками. Да, таких решений много.

                                                  0

                                                  Кажется я его тоже пробовал и быстро отбросил. Передо кандидатами стояли задачи:


                                                  • оно должно работать (часть решений работало только в стерильных условиях)
                                                  • оно должно уметь в глобальные типы
                                                  • оно должно уметь в алгебру типов
                                                  • оно должно уметь переиспользовать собственные валидаторы (а то некоторые либы генерируют ТЫСЯЧИ строк кода без переиспользования, там где у io-ts будет строк 10)
                                                  • оно должно использовать либо систему резолвинга путей webpack, либо алиасы из tsConfig. Многие решения использовали что-то своё и даже .tsx файл не могу за-include-ить
                                                  • оно не должно ронять всю сборку если валидатор построить не удалось

                                                  А в идеале оно:


                                                  • должно уметь преобразовывать типы
                                                  • уметь рассматривать отсутствующие значения как присутсвующие undefined значения (тонкости нашего бакенда)
                                                  • уметь тримать лишние поля
                                                  • давать внятные ошибки валидации

                                                  В итоге io-ts подошёл почти идеально. Мало лишнего кода (сама либа довольно мелкая, а конструкторы валидаторов не сильно больше самих типов). Умеет в преобразования и вообще очень гибкая. Очень удобно строить наглядные ошибки. По сути мы столкнулись с 2 проблемами:


                                                  • очень неудобный синтаксис для ?:, к счастью нам оно почти нигде не нужно
                                                  • вместо TS типов приходится писать на суржике. Но это терпимо. Я буквально за 5ч переписал ТОННУ типов автозаменами по регуляркам, множественными курсорами и пр. чёрной магией

                                                  Но я подход с привлечением DSL для описания валидации всё равно считаю "шаг назад, два вперед" — не очень хочется брать какой-то DSL, который полностью заменяют типы TS.

                                                  Я тоже так думал. И убил два дня на эксперименты. Выяснил что ВСЕ существующие решения страшно далеки от поставленных задач и решился на io-ts. Теперь понимаю что изначальная идея о серебрянной пуле была наивной. Такого нет и никогда не будет.


                                                  Кстати есть автоматические конверторы из сваггера в io-ts. К сожалению нам не подошли, так как наш swagger часто показывает погоду на Марсе, т.к. пишется руками.

                                                    0
                                                    оно должно уметь в алгебру типов

                                                    Серьезно? Без алгебры типов не описать приходящее от бека?


                                                    оно должно уметь переиспользовать собственные валидаторы

                                                    Или это можете сделать вы сами, декомпозировав вход на соответствующие блоки. Но конечно, это будет уже не совсем прям полная автоматика.


                                                    оно должно использовать либо систему резолвинга путей webpack, либо алиасы из tsConfig

                                                    Собственно, этот ваш пункт хорошо показывает, в какие грабли постоянно влипают люди, которые стали зачем-то использовать ts-specific или webpack-specific резолвинг :-)


                                                    оно не должно ронять всю сборку если валидатор построить не удалось

                                                    Лично я бы как раз ожидал падения от такого. Но, конечно, в идеале как-то настраиваться бы.


                                                    Но io-ts хороший, да. Пусть он мне и не нравится идеологически, но работает он хорошо.

                                                      0
                                                      Серьезно? Без алгебры типов не описать приходящее от бека?

                                                      Очень много копипасты будет. У нас хватает сущностей почти идентичных (разные версии одного и того же в разрезе времени), но с минимальными отличиями. Где-то полей больше, где-то одно из полей использует более новую модель. И всё это используется одновременно. Так что — да, серьёзно.


                                                      Или это можете сделать вы сами, декомпозировав вход на соответствующие блоки. Но конечно, это будет уже не совсем прям полная автоматика.

                                                      Если мне нужно очень многое писать руками то зачем мне такой инструмент? io-ts при прочих равных даст гораздо больше преимуществ. А писать руками придётся почти всё. У нас ветвистая система серверных типов.


                                                      которые стали зачем-то использовать ts-specific или webpack-specific резолвинг :-)

                                                      Ну да, на дворе 2021 год. Писать ../../../../file/file.txt я не буду. Отказываться от tsx я тоже не буду. И разные, включая кастомные, loader-ы нам тоже сильно упрощают жизнь. Overall это жирный плюс. Впрочем это тема для отдельной дискуссии. Я за продвинутый DX, который экономит время и деньги бизнесу.


                                                      Лично я бы как раз ожидал падения от такого. Но, конечно, в идеале как-то настраиваться бы.

                                                      А зачем вам такое решение? Вам нравится после каждой опечатки минутами ждать пересборки? Не, я пас. TS слишком медленная штука, чтобы её ронять на таких мелочах. Под ронять я имею ввиду совсем ронять. Не ошибку кинуть, а просто тупо убивает процесс.

                                                        0
                                                        Ну да, на дворе 2021 год. Писать ../../../../file/file.txt я не буду. Отказываться от tsx я тоже не буду.

                                                        Ну, tsx должен работать, потому что он не противоречит стандарту импортов никак (ergo, если в каком-то решении не работает — это да, такое себе решение). А вот насчет относительных импортов в 2021 году я бы поспорил: у меня все импорты пишет и рефакторит IDE, руками я "../../.." никогда даже и в прошлом не писал, а уж сейчас и тем более не намерен. Зато вот всяких import * from 'banana', после которых оказывается, что заимпортировалось 100500 сущностей, из которых отношения к бананам имеет штуки две — я навидался до зубовного скрипа.
                                                        А еще я в 2021 году могу просто подвинуть папку в проекте на один уровень вверх или вниз, когда мне код становится надо поудобнее разложить. И никакие импорты от этого не пострадают (IDE их отлично поменяет без моего участия). И три-шейкинг от сторонних магических инструментов мне не нужен, просто потому, что в моем коде ничего лишнего никуда не импортировано, а следить за этим хватает и линтера.


                                                        Но вы правы, это тема для другой дискуссии.

                                                          0
                                                          ergo, если в каком-то решении не работает — это да, такое себе решение

                                                          Все решения у которых отвалился резолвинг — не смогли даже в tsx. Все остальные просто переиспользовали вышестоящий резолвинг (чаще всего это подключение в виде loader-а).


                                                          я бы поспорил

                                                          Т.е. проблемы с code review и git blame вас ни разу не смущают? :)
                                                          btw у меня к vsCode большие вопросы по поддержке рефакторинга и вообще стабильности работы с TS. И даже с git. Возможно vsCode отстой, я не знаю

                                                            0
                                                            Т.е. проблемы с code review и git blame вас ни разу не смущают? :)

                                                            А какие проблемы? Кто что откуда тянет в код — я вижу в коде, а не в импортах. На сами импорты смотреть на ревью — такая себе идея. В крайнем случае можно посмотреть в импорты для уточнений, или что, кому-то мешают ../../.. при чтении?


                                                            btw у меня к vsCode большие вопросы по поддержке рефакторинга и вообще стабильности работы с TS. И даже с git. Возможно vsCode отстой, я не знаю

                                                            Сколько не пользуюсь — не видел никаких проблем. Возможно, у меня не было такого количества TSa. Но проекты со сложными типами на пару мегабайт собственной минифицированной сборки без сторонних зависимостей — были, VS Code работал там всё так же отлично, разве что в отдельных случаях intellisense мог ощутимо подтормаживать, потому что подтормаживал сам TS, крутящийся в language server.


                                                            Для гита я её никогда не использую, но не потому, что нестабильно, а потому, что есть более удобные средства.

                                                              0
                                                              А какие проблемы?

                                                              Огромное количество визуального мусора в diff-ах. Как задетых файлов, так лишних строк в них. Особенно при рефакторинге чего-то сильно обобщённого. Перенёс функцию в другой файл — привет 300 левых файлов в MR. Вам правда это нравится? Gitlab вообще скроет вам половину изменений, т.к. они превысили лимит того, что он может показать единоразово. А если MR сложный и нужно бегать между файлами глазами туда сюда… Не, я решительно не понимаю как кому-нибудь может нравиться когда переименовывание и перенос файлов устраивает из MR атомную войну. Разве что если делать code review по принципу "long read = no read => approve" :)


                                                              В git blame и прочих манипуляциях с историей тоже большое счастье видеть что половина коммитов тупо мусор. А merge conflict-ы… Ужас.


                                                              На сами импорты смотреть на ревью — такая себе идея

                                                              Глаза выколоть? :) Мы, кстати, несмотря на инструмент сортировки импортов смотрим их на code-review. Человек легко может подключить не то, что хотел. Или залезть глубже, чем следует. Или организовать reexport-ы ногами не правильно.


                                                              Мне кажется ../../../ это каменный век. Нам повезло что import-ы и export-ы к нам пришли поздно и сразу в удобном виде, а не как это в большинстве языков работает. С ними же пришли и алиасы. Избегать их из-за сложности с тулингом — мне вас не понять.


                                                              Сколько не пользуюсь — не видел никаких проблем.

                                                              У меня две любимых функции в vsCode — reload window и restart TS server. И целые бубны как реанимировать GIT после частичного stage-инга. Откровенно говоря там тонны багов. Не знаю, как вы их не замечаете.

                                                                0
                                                                Не, я решительно не понимаю как кому-нибудь может нравиться когда переименовывание и перенос файлов устраивает из MR атомную войну.

                                                                Я не вижу ни малейшей причины, по которой переименование/перенос файла не может быть атомарным коммитом. Более того, это один из легчайших атомарных коммитов, которые можно сделать. Точно так же атомарно это идёт в PR/MR.


                                                                В git blame и прочих манипуляциях с историей тоже большое счастье видеть что половина коммитов тупо мусор. А merge conflict-ы… Ужас.

                                                                Но с любой особой уличной системой импортов (на алиасах, сборных реэкспортах, или еще на чем) вы меняете организационные сложности на сложности функционирования кода, когда импорт файлика на одном конце кодовой базы вдруг разносит весь проект в щепки с другого конца, и надо догадаться, что же пошло не так во всех этих алиасах, реэкспортах, и прочем. Ах ну да, это конечно же в гит не пойдет, потому что еще при сборке умрёт. Наверное это круто.
                                                                Но все же на мой взгляд вопросы работы (и даже билда) кода — они всё же сильно важнее вопросов построчного сравнения текстовых файлов (git diff). И если вы принимаете те или иные решения по разработке кода только для того, чтоб у вас файлики исходников "красиво" сравнивались — это чёт вообще ой.


                                                                У меня две любимых функции в vsCode — reload window и restart TS server.

                                                                У меня первая очень любимая (просто потому, что очень много вещей "передернуть" в VS Code можно только ей, но да и работает она мгновенно), а вот второй вообще ни разу в жизни не пользовался.

                                                                  0
                                                                  Я не вижу ни малейшей причины, по которой переименование/перенос файла не может быть атомарным коммитом.

                                                                  • MR проще проводить не покоммитно, а цельно. А то вы ревьювите то, что изменено и\или исправлено в последующих коммитах. Особенно когда там несколько итераций
                                                                  • Это просто тупо неудобно. У вас задето 10 файлов, в них есть ряд изменений. Вам потребовалось переименовать один файл. Что делать? Всё стешить? Или выборочно коммитить? Допустим второе — теперь много ручной работы. А потом она же на MR

                                                                  В общем я регулярно сталкиваюсь с чем-то подобным когда в feature-ветку, живущую больше 5 дней, merge-ится главная ветка, куда контрибьютили ещё 5 человек. Возникает коммит-смерти, который ревьювить бесполезно и бессмысленно. Но теперь нельзя посмотреть diff с предыдущего просмотра. И приходится смотреть покоммитно выборочно. Писать свои issue к коду и потом их удалять, т.к. они уже не актуальны.


                                                                  А вы предлагаете так страдать не только при merge-ах, а даже при переименовываниях?


                                                                  и надо догадаться, что же пошло не так во всех этих алиасах, реэкспортах, и прочем

                                                                  Для этого не нужен PhD.


                                                                  Наверное это круто.

                                                                  Да.


                                                                  И если вы принимаете те или иные решения по разработке кода только для того, чтоб у вас файлики исходников "красиво" сравнивались — это чёт вообще ой.

                                                                  Это не "ой". Это правильная архитектура и забота о деньгах бизнеса. Это экономия кучи денег работодателя и упрощение работы коллег. DX. Далеко не пустой звук. И речь не про красиво, а про результат. Если DX на хорошем уровне то у вас меньше багов, меньше технического долга, короче сроки разработки, меньше когнитивная нагрузка на разработчиков, больше удовольствия от работы и т.д…


                                                                  но да и работает она мгновенно

                                                                  У меня TS и eslint оттупляется за минуты полторы.


                                                                  а вот второй вообще ни разу в жизни не пользовался.

                                                                  Вероятно мы используем разные подмножества TS. У нас бывают зверские сложные типы. И нам не хватает возможностей TS. Каждый серьёзный релиз TS за счастье.


                                                                  А ещё мы линтим TS по-хардкору (линт правила с учётом типов). И пишем свои линт правила

                                                                    0
                                                                    А вы предлагаете так страдать не только при merge-ах, а даже при переименовываниях?

                                                                    Я вообще не понял, почему у вас тут "даже". У вас в проекте переименовывания и переносы файлов идут чаще мержей? Серьезно??


                                                                    Для этого не нужен PhD.

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


                                                                    Это правильная архитектура и забота о деньгах бизнеса.

                                                                    Лично мне видится скорее классическое "создать самому себе проблемы, а потом мужественно их преодолевать". Когда мержи в проекте начинают представлять собой неиллюзорную проблему — стоит заняться скоупом проекта. Например, поделить его на более мелкие части.
                                                                    С TS, собственно, у вас та же история. Если постоянно стремиться к тому, чтоб порвать TS — он у вас таки порвётся. Можно работать с небольшими частями, а можно запилить огромный проект, где типы сплошь выводятся друг из друга, а потом перезапускать langserver, да еще и по полторы минуты.


                                                                    Проекты, которые грузят IDE минут на 20 на холодном старте — я проходил еще во времена, когда на Яве писал. И понял еще тогда, что ничего хорошего в этом нет.

                                                                      0
                                                                      У вас в проекте переименовывания и переносы файлов идут чаще мержей?

                                                                      В большинстве случаев у нас быстроживущие ветки и merge-ы в feature ветку либо не нужны (ибо нет конфликтов), либо очень компактные. Хотя бывает и прорывает.


                                                                      Зависит от того, сколько и каких у вас импортов.

                                                                      Ну обычно нет какого-то резона делать что-то необычайно сложного. Просто иметь возможность обратиться к ближайшему reexport-зонтику от корня. Можно даже просто через ~/. Поэтому PhD не нужен.


                                                                      Я лично видел примеры такого рвения.

                                                                      Думаю они не релевантны к нашему разговору :) С дуру можно много что поломать. Но зачем?


                                                                      Когда мержи в проекте начинают представлять собой неиллюзорную проблему

                                                                      Ну вот в вашем случае они создают. В нашем — нет. Ведь у нас есть alias от корня и мы можем использовать webpack-loader-ы.


                                                                      Например, поделить его на более мелкие части.

                                                                      И это прекрасно, когда я могу делить проект на сколько угодно мелкие части какой угодно вложенности. А не как в примере про MAM. И заметьте я могу переименовывать файлы, дробить их, выносить в поддиректории, много чего делать и… Это никак не скажется на незатронутых файлах. Никакие ../../ нигде не сломаются. Все иморты от "корня до зонтиков" останутся на месте. Файлы не тронуты. Все счастливы.


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

                                                                        0
                                                                        И это прекрасно, когда я могу делить проект на сколько угодно мелкие части какой угодно вложенности. А не как в примере про MAM.

                                                                        Странное противопоставление. В MAM вам тоже никто не мешает всё это делать.

                                                                  0
                                                                  Нам повезло что import-ы и export-ы к нам пришли поздно и сразу в удобном виде, а не как это в большинстве языков работает.

                                                                  В большинстве языков используются неймспейсы, с ними никакие импорты и не нужны.

                                                                    0

                                                                    А как это работает с standalone функциями? Я namespace-ы видел только в PHP. И то это было давно и я с трудом помню как они там работают.


                                                                    Скажем есть у меня код:


                                                                    export const sum = (a: number, b: number): number => a + b;
                                                                    
                                                                    //
                                                                    
                                                                    import { sum } from '~/some`;

                                                                    Как оно будет выглядеть в языке с namespace-ми?


                                                                    
                                                                    const /math/sum = (a: number, b: number): number => a + b;
                                                                    
                                                                    //
                                                                    
                                                                    use /math/{sum}
                                                                    sum(1,2);

                                                                    так?

                                                                      +1

                                                                      Ну вот пример на том же TS:


                                                                      namespace math {
                                                                          export const sum = (a: number, b: number): number => a + b;
                                                                      }

                                                                      namespace main {
                                                                          const sum = math.sum
                                                                          sum(1, 2 )
                                                                      }

                                                                      namespace main {
                                                                          const m = math
                                                                          n.sum(1, 2 )
                                                                      }
                                                                        0

                                                                        Понятно, спасибо за пример. Т.е. это не противовес import/export-ам, а дополнение. В принципе да, удобно когда нет зависимости от имён файлов от слова совсем. Правда получается та же пляска что и с d.ts файлами. Нужно прочитать весь проект. И линтерам, и IDE, и всем-всем-всем тулам, где есть какой-то анализ. Плюс стоит вопрос порядка подключения.

                                                                          0

                                                                          Именно противовес. Неймспейсы обычно мапятся на ФС. Конкретно для JS/TS нужен только сборщик, умеющий подключать файлы по факту использования неймспейса. Например, MAM.

                                                                            0

                                                                            О. Любопытная статья. Спасибо. Вот откуда в $mol $все_эти_ужасные_названия. Пожалуй в таком виде namespace-ы мне даром не сдались.


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

                                              +3
                                              Преимущество в том, что система работает непредсказуемо?)

                                              пользователь увидит NaN

                                              Благо, если NaN только в интерфейсе отобразится, а не пойдет дальше под капотом ломать инварианты и шатать бизнес-логику, суля занимательными часами/днями отладки в поисках причины сломанных данных в системе.

                                              А в случае сильной типизации случится рантайм ошибка и сломается вообще всё.

                                              Скорее отлавливаемое исключение (или аналогичная технология обработки ошибок), позволяющее корректно себя обработать или хотя бы показать милое сообщение об ошибке и отправить лог разработчику. Если восстановление работы возможно (и имеет смысл) или затронута лишь незначительная часть приложения/сайта, никто не мешает продолжить работу. Вместо NaN можно написать что-то более осмысленное, например.
                                                0
                                                не пойдет дальше под капотом ломать инварианты и шатать бизнес-логику

                                                речь про UI, какая там бизнес логика?


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

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

                                                  +1
                                                  речь про UI, какая там бизнес логика?

                                                  У нас тут за окошком 2к21 с SPA и прочими serverless во фронтенде.

                                                  Там же и видно как это реализуется на практике – приложение закрывается целиком, предлагая отправить сообщение об ошибке.

                                                  Вот бы все браузеры падали с сообщением об ошибке, когда пользователь ошибся в домене)
                                                    0
                                                    У нас тут за окошком 2к21 с SPA и прочими serverless во фронтенде.

                                                    Это никак не отменяет необходимость валидации данных между сервером и клиентом. А что там в браузере в локальном стейте поломалось – не так важно, потому что лечится обновлением страницы. Всякие сложные штуки вроде google docs в расчет не берём, это совсем другая лига


                                                    Вот бы все браузеры падали с сообщением об ошибке, когда пользователь ошибся в домене)

                                                    От пользователя всегда приходит строка, ошибся он или нет. Тут скорее речь про всякие "Access violation reading location", которые переодически возникают.

                                                      0
                                                      Это никак не отменяет необходимость валидации данных между сервером и клиентом.

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

                                                      Всякие сложные штуки вроде google docs в расчет не берём, это совсем другая лига

                                                      Веб развивается, клиенты все жирнее. Поэтому игнорировать эту проблему чревато. Собственно, здесь и обсуждается WASM, как способ использовать более надежные технологии.

                                                      речь про всякие «Access violation reading location», которые переодически возникают.

                                                      Если считать это обращением к невалидному/нулевому указателю, то в подобном случае и выполнение JS-скрипта так же отпадает.
                                                        –1

                                                        Непонятно, к чему вы клоните. Представим, завтра в Javascript вводят флаг "use super strict" и типизация становится строгой, как в Python. Как вы думаете, что это нам принесет?


                                                        • Больше качественно работающих вебсайтов
                                                        • Или больше вебсайтов, показывающих белый экран
                                                          +1
                                                          При обращении по невалидной ссылке уже сейчас JS умеет падать с TypeError, почему вдруг ошибка типа в выражении должна устраивать глобальную катастрофу с белым экраном?
                                                          А так — да, это позволило бы повысить качество.
                                                            –1

                                                            Сейчас есть какой-то статус-кво. Вопрос в том, кому будет полезно его изменение в более строгую форму? Что это даст?

                                                              +2
                                                              Сейчас есть гора костылей, любовно наслаиваемых десятками лет, от которых все с радостью бы избавились, если бы не обратная совместимость.
                                                                0

                                                                Какие бы конкретно костыли пропали, если бы сложение массива и строки (или еще чего-то) начало выбрасывать TypeError?

                                                                  +1
                                                                  Контринтуитивные правила приведения типов, баги, которые они вызывают и противостоящий им код (который параноидально явно приводит типы).
                                                                    0

                                                                    Угу. Разработка в стиле "как на войне", когда ты никогда не уверен в том, что приложение хотя бы частично работает как нужно. Когда после каждого релиза так и просится regression test. Когда страшно заниматься хоть сколько-нибудь серьёзным рефакторингом большого приложения, потому что нет уверенности вот прямо ни в чём.

                                                            –3

                                                            Фреймворки, наконец, научатся показывать не белый экран в случае падения одного компонента, а лишь сообщение об ошибке в этом компоненте. Пока что так лишь $mol делает.

                                                      0

                                                      А что такое по вашему "бизнесс логика"?

                                                    +1

                                                    Стандартная путаница слабой/сильной типизации и статической/динамической (хотя я из тех, кто считает, что понятие динамической типизации — оксюморон). А ещё есть такое понятие, как стирание типов (в смысле условного хаскеля, а не джавы), когда компилятор, собственно, в компилтайме гарантирует, что все нужные проверки в рантайме будут сделаны (а ненужные выкидывает), и в рантайме никаких типов нет, но код, нужный вот конкретно в этом месте для валидации жсонов, приходящих от внешнего API, остаётся и корректно обрабатывает ошибки (что, ещё раз, гарантируется компилятором в компилтайме).

                                                      +1

                                                      Вся проблема вашего подхода в том, что если формат ответа поменялся, а ваше приложение продолжает работать — оно продолжает работать некорректно и неизвестно, что именно оно теперь делает. Показывает NaN в калькуляторе? Портит пользовательские данные? Вы не знаете! Более того — вы даже не знаете о самом факте поломки, поэтому не можете починить ее быстро, а узнаете о проблеме уже от конкретных пользователей.


                                                      Такой подход, когда система продолжает работу во что бы то ни стало, называется Garbage in, garbage out. Противоположный ему подход, который применяют во всех системах, где хоть немного дорожат хранимыми данными — Fail fast.

                                                        +2

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

                                                  –1
                                                  Так WASM точно так же как JS работает с DOM, или так же, как десктопное приложение рисуется на канвасе, например?
                                                    +3

                                                    wasm-код работает в песочнице, для взаимодействия с апи браузера и DOM-ом надо выходить наружу через маршалинг/интероп и вот все это. Если злоупотреблять такими вызовами — скорость падает до уровня обычного js, если нет, то есть буст.

                                                      0
                                                      То есть, все эти разговоры о «скомпилил и поехало» это враньё? Значит ускорить можно только что-то безинтерфейсное? Кажется, я что-то слышал про WebGL — оно хотя бы работает как-то напрямую, не тормозит?
                                                        +2

                                                        Если логика максимально долго работает без интеропа с апи браузера (webgl сюда же относится), то получается хороший буст. По поводу webgl — работа с гпу подразумевает редкие вызовы с большим объемом данных, так что падение не должно быть значительным.
                                                        Вот пример ускорения: https://habr.com/ru/company/skillbox/blog/452190/
                                                        Вот не совсем удачный пример ускорения: https://habr.com/ru/company/yandex/blog/475382/
                                                        Вот про DOM: https://habr.com/ru/post/347804/

                                                          +1
                                                          То есть, получается так, что самая важная часть движка браузера (вместе с JS) — разнообразный, максимально стилизирующийся GUI, это не для WASM. И любые тормозные интерфейсы вроде Slack и других веб-мессенджеров, будут так же тормозить. Жаль :(

                                                          П.С.: Я понимаю, что WASM для другого, но есть более насущные проблемы.
                                                            0

                                                            Интерфейс Slack может просто летать но у разработчиков просто руки не от туда ростут… увы толковых frontend девелоперов очень мало. Ну и оишибится с выбором технологии легко, а потом уже размер не будет давать вам все переписать.

                                                              0
                                                              DOM позволяет создать список элементов, и реюзать айтемы при скролле, перезаполняя их данными? Ну как ListView или RecyclerView в Андроиде?
                                                              Если нет, то такой юзкейс всегда будет тормозить :(
                                                                +2

                                                                Для таких вещей используется Virtual Scrolling. Он, вероятно, работает несколько иначе, нежели RecyclerView, но тоже без проблем обеспечивают молниеносную производительность. Нет нужды рисовать тысячи комментариев одновременно. Но это не часть DOM, это уже самописные решения. Со своими недостатками, разумеется. Но оно и правда работает молниеносно.


                                                                Программы вроде Slack тормозят не из-за DOM, а из-за архитектурных проколов, спешки при разработке, неправильно выставленных приоритетов и т.д… Т.е. аналогичная команда с аналогичными установками в ТЗ на другом языке создаст плюс-минус аналогичный продукт. Что там будет использоваться под капотом дело десятое. Воткнут O(n^2) где хватило бы O(n). Не станут кешировать что-нибудь ресурсоёмкое. Не поставят в параллель что-то, что можно поставить в параллель. Ну и т.д..


                                                                Я провёл ряд собеседований на дожность Senior Frontend Developer. Удручающее зрелище. Знаний в области computer science обычно даже зачаточных нет. Понимания используемых технологий тоже. Многие даже своего языка толком не знают.


                                                                Впрочем, насколько я могу судить по своим коллегам с других отделов, подобная петрушка творится и в ObjectiveC/Swift/Kotlin. Ребята жалуются что кандидаты не знают элементарных вещей. Имея 5-7+ лет опыта за плечами.


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

                                                                  +2
                                                                  Я за последние несколько лет провел около сотни собеседований на разные позиции во фронтенд разработке. Были разные кандидаты, от очень знаменитых людей выступающих на holyjs, до просто взрослых людей возрастом 50-60 лет с огромным бекграундом или вчерашних фотографов.

                                                                  После приема на работу я какое то время наблюдаю за теми кого одобрил и выводы получились очень неоднозначные.
                                                                  Были такие люди, которые очень хорошо подкованы в computer science и умели здраво рассуждать, а алгоритмические задачки решали еще до того, как ты успевал рассказать задачу, но при этом локализацию кнопки правили две недели.

                                                                  С другой стороны были вчерашние фотографы, которые приходили на позицию junior developer и закрывали по 6-7 багов в день, причем качество кода было приемлемое.

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

                                                                  Таких разных кейсов было несколько десятков.

                                                                  Исходя из этого, я сделал выводы, что подбор кадров это очень тонкое искусство, нельзя спросить у человека пару алгоритмов, пару типичных задачек и поговорить о какой то теории и сделать вывод плохой или хороший он инженер.
                                                                  Количество лет опыта не имеет никакого значения.
                                                                  Навык проходить собеседования и навык работать, это две разные вещи. Кандидатов нужно подбирать под задачи, которые он будет решать и иметь к каждому человеку свой подход.

                                                                    0
                                                                    что подбор кадров это очень тонкое искусство

                                                                    Всё так. Нужен индивидуальный подход и вообще понимание кого вы ищете, в чём соль позиции. Каков у вас проект и модель бизнеса. И т.д.

                                                                      +6

                                                                      Быстро закрыть баг не сложно. Сложно не открыть при этом ещё парочку рядом.

                                                                0

                                                                Регулярно вижу ругающихся на Slack, при этом я тоже им пользуюсь и проблем не замечаю. Работает отзывчиво, что бы ни запускалось в фоне, неважно сколько приложений, или тяжелой сборки проекта.


                                                                Может тут что-то не со слаком как таковым, а с настройками воркспейса? Может, админы слишком много плагинов/ботов наподключали?

                                                                  +1
                                                                  Нет, просто вы привыкли к лагам. Это нормальное явление.
                                                                    +1

                                                                    Вместе с этим я пользуюсь еще и Telegram, особой разницы между этими приложениями не замечаю. Как же так?


                                                                    А вот что реально лагает, так это страница Хабра, когда число комментариев приближается к сотне. Невозможно просто.

                                                                      +2

                                                                      В Firefox не лагает и на тысячах.

                                                                  0
                                                                  Так для DOM, JS и так будет достаточно быстрым в современных браузерах. А криво написанный код будет тормозить и на wasm.

                                                                  Ускорить веб на клиентской стороне принципиально можно разве что отказавшись от DOM и зажав разработчиков в некие другие рамки, где им будет сложнее реализовать интерфейс через задницу.
                                                                  По этому пути идет flutter, но этот путь имеет и обратную сторону в виде на совсем нативного поведения GUI. Что заметно где-то на уровне «зловещей долины» и потому раздражает.
                                                          0
                                                          Не понимаю, зачем сразу писать на WASM? В нем конечно есть что то вроде ассемблера(хотя в статье пытались писать в бинарном формате, лол), но он — цель для компиляции, и если реализация WASM машины будет намного быстрее JavaScript движков, думаю Js просто переедет на WASM компиляцию, и останется он с нами навсегда. Но жирный плюс — можно писать и на других языках в веб. И т.к цель компиляции одна и та же, то выигрывать будет ЯП с самым лучшим компилятором.
                                                            –1

                                                            Кажется здесь ошибка. Лучший компилятор это человек с асемблером в руках. Но на ассемблер мало пишут. Только критичные части.

                                                              +1
                                                              Это уже лет десять как не так. Лучший ассемблер — это компилятор С с оптимизацией. Все эти выравнивания инструкций и данных плюс оптимизация под бранч предикшн человеку понятна, но недоступна :)
                                                            +1

                                                            JS не надо никуда переезжать, во всех движках он и так компилируется (JIT/AOT). Но из-за его динамики всё скомпилировать нельзя, тут WASM не поможет. Поэтому, кстати, придумали asm.js — подмножество JS, которое хорошо поддается компиляции.

                                                              0
                                                              JS все еще передается и компилируется из высокоуровневой текстовой формы. WASM компактнее и сразу готов к исполнению.

                                                              С поправкой на то, что WASM должен быть готов к исполнению JS (встроена стандартная библиотека, GC и т.п.).
                                                            –1

                                                            Нифига не ясно как такие сайты потом отлаживать, текущий стек веб-технологий сильно зависим от удобных средств отладки и дебага что так же эволюционировало годами.
                                                            ИМХО отладка компилируемого кода веб-приложения это будет больно

                                                                +2

                                                                JS сейчас тоже весь компилированный через webpack и babel. Символы (sourcemap-в) цепляются — и погнали. А бинарный код изумительно дебажится. Еще в turbo под DOS дебаггер работал, как бы не лучше чем сейчас в хроме — там постоянно что-нибудь с source maps глючит.

                                                                  0
                                                                  Символы (sourcemap-в) цепляются — и погнали

                                                                  Регулярно включаю\выключаю sourceMap для JS в devTools. Просто потому что дебаг реального кода и того что там на транспайлилось\засорсмапилось это очень разный debugging. Особенно если во время остановок пользоваться консолью. Полагаю в случае WA всё на порядок хуже.

                                                                    +1

                                                                    Ну а что вы хотели от поделки, которую придумали фронтендеры? https://t.me/dev_browser/462

                                                                    0
                                                                    Удобных средств отладки для JS? Вы не шутите случайно? По сравнению с отладчиком того-же шарпа для JS… просто ничего нет! Хром в виде отладчика? Ну ну.

                                                                    WebAssembly в виде Blazor хороша тем, что можно вообще не отлаживать WebAssembly (ну до определенного уровня разумеется) — пишется server-side Blazor приложение и отлаживается чистый нормальный C# в Visual Studio. Да и удаленныый отладчик для реальных WebAssembly скоро завезут.

                                                                    Ну и чтоб два раза не вставать — тут все говорят про ускорение и вычислительные задачи. Это близко не то, для чего в основном оно будет использоваться. А использоваться оно будет для корпоративных приложений. Есть числодробилка, она конечно и близко не JS. Надо к ней морду. Можно конечно держать отдел фронтэндеров, но зачем если софтиной будет пользоваться человек 10 (но приносить миллионы прибыли), когда можно по быстрому пару формочек написать на том-же шарпе и в прод. А когда надо что-то подправить — опять-же не вылезая из основного языка можно все сделать. Скучно, да. Не cutting edge. Но кровавый энтерпрайз — он такой. Там крутизна и cutting edge в другом.
                                                                      0
                                                                      Как то всё чаще наблюдаю обратную тенденцию, что фронтендеров переименовывают в фулл стек и они лезут на своём JS писать бекенд код. Чаще всего, глядя на результат, кровь идёт из глаз. Но в конечном итоге продукты деливерятся и заказчик считает, что всё сделал правильно.
                                                                        +2

                                                                        Это работает в обе стороны. Результат закономерно печален в обоих случаях.

                                                                        0
                                                                        По сравнению с отладчиком того-же шарпа для JS… просто ничего нет!

                                                                        Не холивара ради, а в чём именно заключается разница? Никогда не дебажил C#.

                                                                      +2
                                                                      Возможно WASM не стал таким быстрым, как ожидалось. Многие ждали от него буста перфоманса, но по тестам С++ на WASM работает примерно так же, как JS в браузере. Какой смысл делать приложение на С++ и WASM, если то же самое будет на JS, но гораздо проще?
                                                                        0
                                                                        Скорее гораздо привычнее и мейнстримнее. Но суть верна
                                                                          0

                                                                          Имею такой же опыт. Один и тот же код написанный на C, в случае WA на моей задаче работает в 10 раз медленнее, чем будучи запущенным как обычный бинарник. Не важно с -03 или без. И это код БЕЗ моста с JS-миром. Т.е. чистая числодробилка почему-то тормозит аж десятикратно. Видимо это целое искусство — добиться от WA большой скорости.

                                                                            +2

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

                                                                              0

                                                                              Вот кстати да. Писал не так давно компилятор некоего DSL в WASM с целью ускорения — предыдущая версия была в J'S — был неприятно удивлен производительностью именно WASM-машины как таковой. Оно просто тупо медленно, хотя казалось бы. Видимо, человеко-столетия, вложенные в оптимизацию как JS-движков, так и нативных тулчейнов, просто так не догнать...

                                                                              0
                                                                              WASM нужен быль только с одной целью что бы можно было использовать уже имеющиеся библиотеки не переписывая их на js. Но и тут WASM сам себе грабли раскладывает. Начнём с установки emscripten.org/docs/getting_started/downloads.html квест (вместо простого инсталлятора). Выполняем скачивается python, nodejs, java, closure, llvm — сразу видно собрано из говна и палок. После чего запускам и оно бодро падает с сообщением «wasm-ld: error: failed to write the output file: permission denied». Опять квест… И это мы еще не дошли до обработки переполнения целых чисел. И других особенностей которые возникают при сборке больших проектов всякими костылями для автоматической сборки…
                                                                              И потом сам по себе webassembly всё равно без js не работает. Ну даже предположи что было бы всё хорошо и взлетело как flash. Получили бы не контролируемый рост потребления использования ресурсов. Дальше ввод всяких заплаток для ограничения майнинга в браузере и т.п. С другой стороны вот нафига например той же apple полноценная виртуальная машина которая позволяет выполнять приложения в обход их политики тотального контроля.
                                                                              Так что светлого будущего у wasm скорее всего не будет.
                                                                                +1
                                                                                у даже предположи что было бы всё хорошо и взлетело как flash. Получили бы не контролируемый рост потребления использования ресурсов. Дальше ввод всяких заплаток для ограничения майнинга в браузере и т.п.

                                                                                А чем принципиально отличается JS от WASM в данном случае?

                                                                                  –1
                                                                                  Принципиально разницы нет. Некоторые компиляторы сразу в js компилируют. С появление wasm должно было стать проще это делать. А по факту нет. Вместо решения проблем только создали новые. И да js так же как и flash может знатно поедать ресурсы не хуже чем когда-то flash со своей рекламой. Что мы и наблюдаем
                                                                                0
                                                                                Ответ содержится в одном из ваших предыдущих переводов

                                                                                Какие выводы мы можем сделать из этих испытаний? А вот какие: вдумчивое написание JS-кода позволяет получать достаточно высокую производительность и не требует перехода на другие языки программирования.


                                                                                Wasm или не Wasm?
                                                                                — https://habr.com/ru/company/ruvds/blog/510904/
                                                                                  +1
                                                                                  Главная проблема WASM в том, что это second class citizen. Там нет никаких API, все надо дергать через js и, как минимум, это очень медленно и неудобно.
                                                                                  Правильный дизайн был бы опустить все API браузера на этот уровень и js тоже компилить в него. Вот тогда — да.
                                                                                  А так — полубесполезная игрушка.
                                                                                    +9

                                                                                    Как автор компилятора, который может перегонять байт-код JVM в WASM могу вставить свои 5 копеек.


                                                                                    1. Нет доступа к стеку. Делали так из благих побуждений — безопасность и простота реализации виртуальной машины. На деле, в C++ вполне обычная ситуация, когда надо вызвать функцию, передав ей указатель на локальную переменную. Честно говоря, что генерируют компиляторы C++ в Wasm, я не смотрел. Да и в Java так делать нельзя. Зато в Java есть GC, у которого roots находятся в стеке. Как я это обошёл? Завёл shadow stack прямо в хипе. Да, я придумал хитрый алгоритм, который вычисляет для каждого call site минимальный объём обновлений shadow stack. Но всё равно это медленно.


                                                                                    2. Нельзя поиграться с memory protection. Есть очень много сценариев использования оного. Самый простой — проверка указателей на null. В реализациях C++ или Java здорового человека принято первую страницу делать недоступной и поэтому при попытке записать или прочитать по адресу 0, CPU бросает исключение, которое можно поймать в виде, например, сигнала unix. В Wasm такие трюки не работают и приходится просто перед каждым dereference (например, чтением поля объекта) вставлять проверку. Кстати, т.к. доступа к стеку нет, то приходится в shadow stack маркировать любой такой доступ, чтобы при выбросе исключения правильно воссоздать stack frame.


                                                                                    3. Казалось бы, нам обещают GC и exception handling в будущих версиях. Но вот я, честно говоря, слабо верю в то, что какая-то прибитая гвоздями спецификация GC сможет учесть разнообразие поведения разных VM в различных экзотических ситуациях, например, с разнообразными weak reference.


                                                                                    4. Ещё одна претензия к черновику GC: приходится дублировать заголовок. Для нужд GC в Wasm необходимо объявлять типы данных и при аллокации объекта (tuple) в управляемом хипе указывается этот тип. Понятное дело, что физически при этом какое-то количество байт будет отведено на указатель на тип данных. Далее, чтобы реализовать виртуальные вызовы, мне так же надо в объекте хранить указатель на virtual table. Получается, у меня двойной заголовок объекта, потребляющий в два раза больше памяти. Это в то время, как у нормальных людей заголовок объекта сразу и vtable описывает и layout объекта для GC.


                                                                                    5. Отсутствует вообще какая-либо стандартная библиотека или хотя бы набор инструкций для некоторых важных операций, вроде копирования участка памяти, обнуления участка памяти, работы с плавающими числами (например, какой-нибудь isNaN) и т.д.


                                                                                    6. Какой-то очень мутный застрявший процесс. Вот вышла несколько лет назад спека 1.0 и дальше комитет только заседает и заседает, генерирует какие-то кривые черновики, а воз и ныне там. Похоже на ситуацию с застрявшей спекой XHTML в своё время.


                                                                                      +2

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

                                                                                        +2
                                                                                        Нет доступа к стеку.
                                                                                        Честно говоря, что генерируют компиляторы C++ в Wasm, я не смотрел.

                                                                                        • В тех примерах, что я смотрел, компиляторы C++ стараются избегать передачи через стек, используя locals
                                                                                        • Если все-таки стек нужен, то считается, что указатель на вершину стека хранится по смещению 4 в памяти

                                                                                        image


                                                                                        Online-компилятор тут. Вроде бы там есть возможность ссылку на код создать, но не понял, как, так что:


                                                                                        Исходный код
                                                                                        extern "C" int sumall(int a[], int size);
                                                                                        
                                                                                        extern "C" int sum(int i, int j){
                                                                                          return i + j;
                                                                                        }
                                                                                        
                                                                                        extern "C"  int call_sum(int v){
                                                                                          return sum(v, v+1);
                                                                                        }
                                                                                        
                                                                                        extern "C" int call_sumall(){
                                                                                          const int SIZE = 100;
                                                                                          int a[SIZE];
                                                                                          a[0] = 3;
                                                                                          a[1] = 4;
                                                                                          return sumall(a, SIZE);
                                                                                        }
                                                                                        
                                                                                        extern "C" int sumall(int a[], int size){
                                                                                          int res = 0;
                                                                                          for (int i = 0; i< size; i++) {
                                                                                            res += a[i];
                                                                                          }
                                                                                          return res;
                                                                                        }
                                                                                          0
                                                                                          В тех примерах, что я смотрел, компиляторы C++ стараются избегать передачи через стек, используя locals

                                                                                          Так это и возможно сделать только если параметр передаётся в виде value. А если в виде ссылки, то единственный сценарий, когда, КМК, это можно оптимизировать — если компилятор решил заинлайнить функцию. Во всех иных ситуациях если вы явно попросите у C++ передать указатель или ссылку на переменную в стеке, то он и передаст указатель или ссылку соответственно. Это не особо возможно оптимизировать.


                                                                                          Если все-таки стек нужен, то считается, что указатель на вершину стека хранится по смещению 4 в памяти

                                                                                          Что по сути и есть тот самый медленный shadow stack взамен быстрого нативного.

                                                                                        0

                                                                                        У нас на проекте одна из основных причин, по которой не используется wasm — поддержка IE

                                                                                          +6

                                                                                          Время от времени заходите на сайт вашего конкурента, используя Internet Explorer 6. Держите их в тонусе!

                                                                                            0

                                                                                            Не будет ли это слишком жестоко?)

                                                                                              +3

                                                                                              Я это к тому, что может это вас так кто-то держит в тонусе?)

                                                                                                0

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

                                                                                          +1

                                                                                          Самая большая проблема, на мой взгляд, это отсутствие поддержки Garbage Collection, что делает бессмыссленным переход многих популярных языков, которые уже умеют транслироваться в эффективный JavaScript. А это огромные кодовые базы Typescript, Java, Scala, Kotlin, Elm…
                                                                                          Возиться с указателями в стиле си, или переучиваться на Rust чтобы писать под веб — это такое себе.

                                                                                            +1

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


                                                                                            А вот для создания админок технология выглядит очень даже интересно.

                                                                                              0
                                                                                              Все кэшируется. А во-вторых, размер так-то сопоставим с ангуляром.
                                                                                              –2
                                                                                              … JavaScript — это замечательный язык…
                                                                                              У меня аж Флеш плеер потёк из браузера. Крайне он специфичный. Поживём увидим, что будет с WASM
                                                                                                –4
                                                                                                WASM поспел к шапочному разбору. Эту технологию нужно было начинать разрабатывать не позднее 2005-го. А сейчас, когда Веб доживает последние годы, WASM попросту не успеет взлететь. Уже к 2030-му в Вебе будут сидеть только старички за 40, а вся молодёжь уйдёт в мессенждеры (даже соцсети сейчас стремительно теряют аудиторию).
                                                                                                Так что тут надо скорее придумывать песочницы для мессенджеров и приложения для них же, ну и в разработку стандартов для ботов вкладываться, если вы действительно смотрите в будущее.
                                                                                                  0

                                                                                                  WASM идеально ложится в стек веб-разработки на Rust. Обе эти технологии положительно связаны друг с другом.

                                                                                                    +2
                                                                                                    Жили долго и счастливо и умерли в один день? =)
                                                                                                      0

                                                                                                      Что, уже бросил попытки выучить Rust?

                                                                                                        +1
                                                                                                        Скорее признал его бесперспективной академической игрушкой для ума.
                                                                                                    +1

                                                                                                    Что я только что прочитал? «Смотрите, технология для решения узкоспециализированных задач. Давайте разберемся, что с ней не так, что она не получила широкого распространения»

                                                                                                      0

                                                                                                      Ну если совсем по теме, то для половины задач из приведенного списка нужен SIMD. Если кто-то хорошо знает WASM, подскажите, в каком состоянии SIMD в нём сейчас? Нужна ли поддержка браузеров, есть ли уже где-то?

                                                                                                        0
                                                                                                        с WASM всё так, он нужен немного для другого — никто не собирается конкурировать с JS.
                                                                                                        WASM нужен для двух вещей. первая — единая кодовая база. я не хочу создавать по 10 алгоритмов на C#, потом на JS, и при изменении какогото из них по пол дня тестировать работают ли они одинаково. WASM позволяет мне писать на C# вобще всё и не заморачиваться с тем как и где оно работает. в больших проектах это очень важно и позволяет избежать лишних специалистов по фронт-енду например. про производительность не знаю, насколько ли это важно — если тензорфлоу сделали значит наверно да, это вторая причина
                                                                                                          +1

                                                                                                          Так если не важно про производительность, вы можете прямо сейчас компилировать c# с js, и это будет работать надежнее, чем WASM.

                                                                                                            0

                                                                                                            подскажите пожалуйста, что это за решение? очень интересно

                                                                                                              0
                                                                                                              В чем ненадежность WASM?
                                                                                                                0
                                                                                                                Вообще wasm сделали что бы фортран в браузере запускать. Потому как переписать то что написано на фортране на javascript слишком дорого. Вот нашли более простой способ. Бинарные вставки ;)
                                                                                                            0
                                                                                                            Ещё и Qt можно собрать в WASM
                                                                                                            Я год назад писал статью

                                                                                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                            Самое читаемое