С точки зрения производительности во время выполнения меня интересуют

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

Я проводил эксперименты с ядром Three.js + WASM.

https://github.com/takahirox/three.wasm-experimental
https://twitter.com/superhoge/status/1071132448426262529

В результате экспериментов я понял, что перенос всего ядра на WASM может улучшить производительность времени выполнения, в 1,5 раза быстрее в моем примере, в то время как частичный перенос небольших частей, например, только математических кодов (Vector3, Matrix4, ...), не дает никаких преимуществ, потому что больших накладных расходов JS-WASM.

Но я не думал, что будет хорошей идеей переписывать все ядро ​​Three.js на C ++ или Rust для участников из-за сложности обслуживания, поэтому я искал альтернативные пути. Меня интересует, работает ли TypeScript + AssemblyScript для Three.js.

Как начать? Должны ли мы начинать сначала только с файлов d.ts или полностью переходить к TypeScript?

Мы будем отправлять PR, который добавляет файлы * .d.ts в Three.JS, в основном на основе @ types / three (таким образом, повторно используя эту работу). Это отличная отправная точка и позволяет нам пока продолжить работу с JS. Это также можно делать постепенно.

@takahirox хорошая работа :-) Меня всегда восхищало, как много инноваций происходит вокруг Three.js. Жалко, что этим доказательствам концепции уделяется так мало внимания. Я также считаю, что переписывать все на C ++ или Rust - это не вариант. Может быть, AssemblyScript и есть, но я не пробовал AssemblyScript, поэтому могу просто рассказать о том, что я читал об AssemblyScript. Но, возможно, нам также следует рассмотреть AssemblyScript, потому что, насколько я понимаю, это более или менее подмножество TypeScript.

@bhouston Я не уверен, имеет ли d.ts из @types/three в репозиторий three . Тем более, что эти файлы d.ts могут быть сгенерированы из файлов TypeScript, и тогда они всегда синхронизируются. Есть ли способ обеспечить автоматическую синхронизацию файлов d.ts с js-файлами? Если да , то я думаю , поставив d.ts файлы в three репо может быть полезным. Также я думаю, что это зависит от решения сопровождающих. Если они не хотят использовать TypeScript, также можно использовать файлы d.ts . Также, если они решат добавить TypeScript через несколько лет, мы могли бы на этот раз d.ts файлы

@bhouston Я не уверен, имеет ли смысл перемещение файлов d.ts из @ types / three в репозиторий three. Тем более, что эти файлы d.ts могут быть сгенерированы из файлов TypeScript, и тогда они всегда синхронизируются.

Если мы перейдем непосредственно к TypeScript, файлы * .d.ts не понадобятся. Проблема в том, что в настоящее время проект @ types / three всегда немного устарел с Three.JS, потому что он поддерживается отдельно. Кроме того, он отражает встроенную структуру three.js, а не отдельных файлов, и, следовательно, не может поддерживать встряхивание дерева и другие формы оптимизации. Таким образом, добавление файлов * .d.ts значительно улучшает текущее состояние проекта, но это не так хорошо, как переход к файлам * .ts напрямую.

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

Я понимаю, что Three.JS любит делать вещи постепенно, поэтому это был дополнительный вариант, а не большой взрыв.

@bhouston Полностью согласен с вами. И я также считаю, что переписывание «большого взрыва» невозможно, поэтому нам нужно внедрять его постепенно. Но если я читаю документацию по TypeScript, кажется, что у нас могут быть файлы ts и js рядом. Таким образом, мы могли начать преобразование отдельных файлов в формат ts. Для получения дополнительной информации вы можете прочитать это сообщение в блоге: https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html

Но как подойти к TypeScript должен решить один из сопровождающих. Я думаю, что оба варианта (файлы d.ts или смешивание файлов ts и js) возможны. И это более-менее вопрос личных предпочтений и стиля.

@tschoartschi Я хотел бы продвинуть этот вопрос вперед. @mrdoob одобрил параллельные файлы * .d.ts. Я хотел бы пойти туда, потому что это не заставляет людей сразу же использовать TypeScript, и мы можем отказаться от него, не переписывая все дополнения на этапе * .ts. И затем мы все еще можем преобразовывать файлы * .js в файлы * .ts постепенно, в основном я объединяю их с расположенными рядом файлами * .d.ts.

Я думаю, что размещение файлов * .d.ts рядом друг с другом - это действительно хороший первый шаг, и это легко сделать. Я бы предпочел не позволять «совершенству» удерживать нас от постепенного прогресса.

@bhouston круто 😎 Я тоже мог бы помочь. Думаю, было бы разумно, если бы вы начали, а затем я мог бы присоединиться к вам. Возможно, мы могли бы также поговорить с сопровождающими @types/three . Должны ли мы создать канал Slack в рабочем пространстве Three.js? Так мы сможем быстрее согласоваться и не засорять эту проблему разговорами в чате. Тем не менее, я бы подождал, пока

Я готов посвятить время порту, как только он получит благословение от @mrdoob.

Пока браузеры не поддерживают TypeScript изначально, я предпочитаю сосредоточиться на JavaScript ES6.

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

https://github.com/mrdoob/three.js/blob/dev/examples/webgl2_sandbox.html#L37 -L48

Добавление файлов * .d.ts рядом друг с другом - это хорошо, но для этого понадобится кто-то, кто будет владеть ими и поддерживать их в актуальном состоянии.

@mrdoob Я не думаю, что можно ждать, пока браузеры поддержат TypeScript. Я не слышал о намерениях какого-либо поставщика браузеров внедрять TypeScript. Но я вижу ваши опасения, особенно с примерами. Я не смотрел новые примеры. Замечательно, что в примерах можно просто импортировать исходные файлы.

Я не уверен, что было бы лучшим решением для создания библиотеки на TypeScript и сохранения возможности импортировать JavaScript из src. Конечно, мы могли бы транспилировать файлы TypeScript, а затем разместить соответствующий файл JavaScript рядом (что является стандартной настройкой компилятора TypeScript), но это может усложнить такие вещи, как управление версиями кода и т. Д. Структура папок может выглядеть так:

three/
├── src/
    ├── cameras
        ├── PerspectiveCamera.ts // authored code
        ├── PerspectiveCamera.js // generated code by TS compiler

Тем не менее, мне это кажется немного неудобным, поскольку перенесенный код должен находиться где-то в папке dist , build или bin . Но это всего лишь мнение, а не факт. Может быть, есть какие-нибудь фанаты TypeScript, которые знают более хорошее решение.

Другой вариант - это файл d.ts предложенный @bhouston. Но, как упомянул @mrdoob, может быть сложно поддерживать файлы d.ts в актуальном состоянии. Особенно в долгосрочной перспективе. Действительно ли возможно поддерживать их в актуальном состоянии в ближайшие годы? Я мог бы помочь с настройкой файлов d.ts но не могу гарантировать, что буду участвовать в их постоянном обновлении. Для меня гораздо сложнее постоянно фиксировать время, чем блокировать одноразовый интервал и делать некоторые вещи. Я все еще не уверен, что лучше: поддержать проект @types/three или добавить файлы d.ts непосредственно в проект three . Проект @types/three уже работает и обслуживает те же потребности, что и подход d.ts . У него также есть аналогичные проблемы. Который в основном держит вещи в актуальном состоянии.

Итак, я пришел к выводу, что в среднесрочной перспективе он выглядит не слишком хорошо для TypeScript в Three.js. Для меня это нормально, хотя я хотел бы видеть больше внедрения TypeScript.

Еще одно предложение:
Фреймворк игры Phaser использует свои комментарии для автоматического создания определений типов. Я думаю, что это инструмент с открытым кодом. Таким образом, определения TS могут быть сгенерированы правильным добавлением / ** комментариев * / над функциями.

Фреймворк игры Phaser использует свои комментарии для автоматической генерации определений типов ...

См. Https://github.com/mrdoob/three.js/issues/11550 и https://github.com/mrdoob/three.js/issues/4725#issuecomment -41833647.

Хотя создание документации из комментариев в файлах *.d.ts может быть интересным. 🤔

Добавление файлов * .d.ts рядом друг с другом - это хорошо, но для этого понадобится кто-то, кто будет владеть ими и поддерживать их в актуальном состоянии.

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

Также есть этот проект https://github.com/semleti/three.ts
Возможно, стоит взглянуть и довести его до версии 100, а не начинать новую?
Потому что я не вижу, чтобы Three.js переписывался в TypeScript, если только не очевидно, насколько лучше работать с типами для такого огромного проекта ... И я прекрасно понимаю, почему этого может никогда не случиться, поскольку он будет полагаться на язык это нестандартно внутри браузера.

@schoening Я начал это обсуждение, потому что существуют некоторые @flyover (https://github.com/flyover/three.ts, https://github.com/mrdoob/three.js/issues/11552#issuecomment-367026821) . Основная проблема с разветвленной версией Three.ts заключается в том, чтобы оставаться в актуальном состоянии. Все репозитории отстают от некоторых версий, и я думаю, что это произойдет со всеми проектами, которые не поддерживаются «основной» командой. Если проект Three.js не будет поддерживать TypeScript, я думаю, что лучше всего помочь проекту @ types / three оставаться в синхронизации. Думаю, нам следует объединить усилия там.

Если Three.js будет поддерживать TypeScript в какой-то момент в далеком будущем, было бы здорово подумать, как такой переход может быть успешным. Как упоминал @donmccurdy, существует несколько подходов для достижения лучшей совместимости с TypeScript. Я думаю, что JSDoc может быть жизнеспособным подходом. Меня все еще не убеждают файлы *.d.ts так как я думаю, что поддерживать их в актуальном состоянии даже труднее, чем комментарии JSDoc. Также я не думаю, что есть способ программно проверить исходный код с помощью файлов *.d.ts . Но, возможно, @bhouston смог бы обрисовать свой подход, особенно

На данный момент лучший опыт для меня - это vscode + d.ts + JSDoc, все в одном проекте, так что легко оставаться в синхронизации.

В последней версии vscode улучшена поддержка checkJs (может быть включена в tsconfig.json ), которая в основном представляет собой компилятор TypeScript, проверяющий файлы JavaScript с использованием типов из JSDoc плюс слияние объявления из d.ts для более «продвинутых» типов, что было бы некрасиво в синтаксисе JSDoc.

Поскольку vscode может наследовать все типы, он также может обнаруживать все виды ошибок типов, поэтому всякий раз, когда выполняется рефакторинг, легко увидеть и отредактировать "ошибочные / старые" типы из d.ts , поэтому он продолжает синхронизироваться. .

Хуже всего в TypeScript - это дополнительный шаг транспиляции, который может занимать несколько секунд для каждого отдельного изменения кода. Короче говоря, JSDoc + d.ts в vscode обладает всеми преимуществами типов, но не недостатком сверхмедленного шага транспиляции.

Единственная проблема - добавить 100% правильный тип JSDoc ко всему, чтобы vscode мог полагаться на него (например, @constructor , <strong i="16">@enum</strong> {number} , <strong i="18">@param</strong> {number} n Number of steps )

Я также хотел добавить сюда, что @bhouston и @LuWangThreekit создали PR для файлов *.d.ts . Для получения дополнительной информации ознакомьтесь с их примечанием: https://github.com/mrdoob/three.js/issues/11552#issuecomment -454881060 и / или их PR https://github.com/mrdoob/three.js/pull/ 15597

Примечание: TypeScript в браузерах может быть не за горами, если Deno (интерпретатор TypeScript, построенный на V8 и Rust с 32000 звезд на GitHub) окажется достойным.

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

Для всех, кто интересуется TypeScript ...

Эта библиотека, вдохновленная Three.js, над которой работает

https://threeify.org/

Threeify от @bhouston кажется отличным проектом: в нем есть SemVer и используется семантический релиз. Он построен на основе TypeScript, и его основными ценностями кажутся такие вещи, как Tree Shaking, Small Build Files и т. Д. Все, что многие из нас хотели бы видеть и в Three.js. Так что я очень ценю работу, которая вложена в

@bhouston @mrdoob Но действительно ли нужно создавать новый проект? Есть ли смысл раскалывать комьюнити? Многим крупным интерфейсным фреймворкам удалось осуществить переход на такие вещи, как SemVer, TypeScript, Tree Shaking и т. Д., Без разветвления своего кода и сообщества.

Я думаю, что @pailhead написал интересную статью о работе с Three.js, я думаю, что это была следующая: Работа с разными версиями three.js . Поэтому я думаю, что в сообществе есть люди, которые хотели бы помочь перенять некоторые вещи, которые Threeify пытается реализовать. Думаю, было бы здорово объединить усилия и улучшить Three.js вместо создания новой библиотеки.

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

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

У нас очень похожий опыт, как у @pailhead, я не думаю, что его рабочий процесс является нишевым. Я думаю, что его рабочий процесс очень типичен для разработчиков, работающих с современными интерфейсными фреймворками, такими как Vue , Ember , React , Svelte , Angular ...

Может быть, нам стоит посмотреть, как Vue это делает. У него есть база пользователей, начиная от программистов PHP, которые просто хотят улучшить свой веб-сайт, до людей, которые разрабатывают сложные веб-приложения. Это очень хорошо меняет кривую между этими разными типами пользователей.

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

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

Когда вы просматриваете эту ветку, уже есть два разных проекта, Three.ts и Threeify, и, вероятно, их гораздо больше. Я искренне верю, что для всего сообщества Three.js будет огромная выгода, если мы будем работать вместе, а не создавать форки и отдельные инициативы.

@mrdoob , как насчет опроса для сбора данных? использование машинописного текста - это одно, и я уверен, что есть и другие качественные переменные, которые мы могли бы попытаться оценить.

@ roomle-build вы можете перечислить недостатки преобразования библиотеки в TypeScript?

Я не вижу реальных недостатков в постепенном внедрении TypeScript в библиотеку. Напротив, я думаю, что это принесет много пользы (вот почему многие проекты конвертируются в TypeScript). Тем не менее, конечно, есть некоторые проблемы, например:

• как мы можем обеспечить приятный опыт для пользователей, не использующих TS?
• как пользователи без встроенного шага могут использовать библиотеку
• и, конечно же, обо всем остальном, о чем я не думал

Но, как я уже сказал, эти вопросы решаются и в других проектах, и мы можем скопировать эти решения оттуда (например, Vue или Ember ).

Но главное, что я хотел отметить, это то, что я думаю, что это опасно, если сообщество расколется, и у нас будет несколько разных проектов и вилка вилки или вилки. Я не фанат фрагментации и считаю, что лучше работать вместе, чем друг против друга. Конечно, есть и другие люди, которые будут утверждать, что конкуренция - это здорово и что это будет способствовать развитию инноваций также в проекте Three.js, но я больше верю в сотрудничество 🙂

Я думаю, что одним из самых больших преимуществ three.js является его доступность. Пункты, перечисленные в @ roomle-build, ухудшат простоту использования движка (особенно для новичков). Я голосую за продолжение использования JavaScript, если в браузерах не поддерживается изначально альтернативный язык программирования.

Я не фанат фрагментации и считаю, что лучше работать вместе, чем друг против друга.

Наличие большего количества 3D-движков в сети не означает, что разработчики работают друг против друга. Иногда действительно лучше, если разные проекты сосредоточены на разных вещах.

Я думаю, что одним из самых больших преимуществ three.js является его доступность. Пункты, перечисленные в @ roomle-build, ухудшат простоту использования движка (особенно для новичков).

Я так не вижу, потому что другие проекты пишут свой код на TypeScript без какого-либо влияния на доступность. В качестве примеров я уже упоминал Vue и Ember. Может быть, имеет смысл пересмотреть позицию в отношении TypeScript? Нам не нужно было бы изобретать что-то, нам нужно было бы только скопировать успешные подходы из других проектов. Кроме того, я думаю, что TypeScript будет иметь то преимущество, что three.js будет более доступным для участников, потому что IDE может помочь им быстрее получить обзор всего проекта.

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

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

Думаю, мы четко изложили свою позицию.