런타임 성능의 관점에서 나는 관심이 있습니다.

또한 AssemblyScript와 같은 실험적 도구는 소스 코드의 특정 성능 비판적 부분에 대한 옵션이 될 수 있습니다.

Three.js 코어 + WASM 실험을 해왔습니다.

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

실험을 통해 전체 코어를 WASM으로 이식하면 런타임 성능을 1.5배 더 빠르게 개선할 수 있다는 것을 깨달았습니다. 반면 작은 부분(예: Math 코드(Vector3, Matrix4, ...))만 부분적으로 이식하는 것은 이점이 없기 때문에 큰 JS-WASM 오버헤드.

하지만 유지 관리의 어려움 때문에 기여자를 위해 전체 Three.js 코어를 C++ 또는 Rust로 다시 작성하는 것은 좋지 않다고 생각하여 다른 방법을 찾고 있었습니다. TypeScript + AssemblyScript가 Three.js에서 제대로 작동하는지 궁금합니다.

시작하는 방법? 처음에는 d.ts 파일로만 시작해야 합니까, 아니면 완전히 TypeScript로 건너뛰어야 합니까?

우리는 주로 @types/three를 기반으로 하는 *.d.ts 파일을 Three.JS에 추가하는 PR을 제출할 것입니다. 점진적으로 수행할 수도 있습니다.

@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 repo로 옮기는 것이 많은 의미가 있는지 잘 모르겠습니다. 특히 이러한 d.ts 파일은 TypeScript 파일에서 생성될 수 있으며 항상 동기화되어 있기 때문입니다.

TypeScript로 직접 이동하면 *.d.ts 파일이 필요하지 않습니다. 문제는 현재 @types/three 프로젝트가 별도로 유지 관리되기 때문에 Three.JS에서 항상 약간 구식이라는 것입니다. 또한 개별 파일이 아닌 three.js의 빌드 구조를 미러링하므로 트리 쉐이킹 및 기타 형태의 최적화를 지원할 수 없습니다. 따라서 *.d.ts 파일을 추가하면 현재 상태에서 프로젝트가 크게 향상되지만 *.ts 파일로 직접 이동하는 것만큼 좋지는 않습니다.

*.ts 파일로 직접 이동할 수 있다면 그것이 더 나은 선택입니다. 이에 대한 지원이 있는지 확신할 수 없었습니다.

나는 Three.JS가 일을 점진적으로 하는 것을 좋아한다는 것을 이해합니다. 따라서 이것은 빅뱅이 아니라 증분 옵션이었습니다.

@bhouston 전적으로 동의합니다. 그리고 빅뱅 재작성은 불가능해서 점진적으로 도입해야 한다고 생각합니다. 그러나 TypeScript 문서를 읽으면 ts 및 js 파일을 나란히 가질 수 있는 것처럼 보입니다. 그래서 우리는 단일 파일을 ts로 변환하기 시작할 수 있습니다. 자세한 내용은 다음 블로그 게시물을 참조하세요 .

그러나 TypeScript에 접근하는 방법은 관리자 중 한 사람이 결정해야 합니다. 두 가지 옵션( d.ts 파일 또는 ts 및 js 파일 혼합)이 모두 가능하다고 생각합니다. 그리고 그것은 개인의 취향과 스타일에 관한 어느 정도의 문제입니다.

@tchoartschi 이 문제를 진행하고 싶습니다. @mrdoob 이(가) 나란히 *.d.ts 파일을 승인했습니다. TypeScript를 사람들에게 즉시 강요하지 않고 *.t 단계 동안 모든 기여를 다시 작성하지 않고도 철회할 수 있기 때문에 거기에 가고 싶습니다. 그런 다음 우리는 여전히 *.js 파일을 *.ts 파일로 점진적으로 변환할 수 있습니다. 대부분은 병렬 *.d.ts 파일과 병합합니다.

병렬 *.d.ts 파일은 정말 좋은 첫 번째 단계이며 수행하기 쉽다고 생각합니다. 나는 "완벽함"이 점진적인 발전을 가로막는 것을 허용하지 않는 것을 선호합니다.

@bhouston 멋져요 😎 저도 도와드리겠습니다. 나는 당신이 시작하고 다른 사람들과 내가 참여할 수 있다고 생각합니다. 어쩌면 우리는 @types/three 의 유지 관리자와 이야기할 수도 있습니다. Three.js 작업 공간에서 Slack 채널을 만들어야 하나요? 따라서 우리는 더 빨리 조정할 수 있고 채팅과 같은 대화로 이 문제를 더럽히지 않습니다. 그럼에도 불구하고 @mrdoob이 자신의 관점을 추가할 때까지 겠습니다 . 그가 TypeScript에 반대한다면 시간을 투자해서는 안 된다고 생각하기 때문입니다.

@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에서 라이브러리를 작성하고 src에서 JavaScript를 가져올 가능성을 계속 유지하는 가장 좋은 솔루션이 무엇인지 잘 모르겠습니다. 물론 TypeScript 파일을 변환한 다음 해당 JavaScript 파일을 나란히 가질 수 있지만(TypeScript 컴파일러의 표준 설정임) 이는 코드 버전 관리 등을 복잡하게 할 수 있습니다. 폴더 구조는 다음과 같을 수 있습니다.

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

그럼에도 불구하고 트랜스파일된 코드는 dist , build 또는 bin 폴더 어딘가에 있어야 하기 때문에 이것은 나에게 조금 어색해 보입니다. 그러나 그것은 단지 의견일 뿐이며 확실한 사실은 아닙니다. 아마도 더 나은 솔루션을 알고 있는 TypeScript 괴짜가 있을 것입니다.

다른 옵션은 @bhouston이 제안한 d.ts 파일입니다. 그러나 @mrdoob이 언급했듯이 d.ts 파일을 최신 상태로 유지하는 것은 까다로울 수 있습니다. 특히 장기적인 관점에서. 다음 몇 년 동안 최신 상태로 유지하는 것이 정말 관리 가능한가요? d.ts 파일을 설정하는 데 도움을 줄 수는 있지만 항상 업데이트하는 데 관여할 것이라고 보장할 수는 없습니다. 저에게는 일회성 슬롯을 차단하고 몇 가지 작업을 완료하는 것보다 지속적으로 시간을 투자하는 것이 훨씬 어렵습니다. @types/three 프로젝트를 지원하는 것이 더 나은지 아니면 three 프로젝트에 직접 d.ts 파일을 추가하는 것이 더 나은지 아직 확실하지 않습니다. @types/three 프로젝트는 이미 작동 중이며 d.ts 접근 방식과 동일한 요구 사항을 충족합니다. 비슷한 과제도 있습니다. 기본적으로 최신 정보를 유지하는 것입니다.

그래서 제 결론은 중기적으로 Three.js의 TypeScript가 그다지 좋아 보이지 않는다는 것입니다. 더 많은 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
새로 시작하는 것보다 살펴보고 v100으로 가져올 가치가 있습니까?
TypeScript에서 Three.js가 재작성되는 것을 볼 수 없기 때문에 그러한 거대한 프로젝트를 위한 유형으로 작업하는 것이 얼마나 더 좋은지 분명하지 않은 한... 그리고 언어에 의존하기 때문에 발생하지 않을 수 있는 이유를 충분히 이해합니다. 그것은 브라우저 내부의 표준이 아닙니다.

@schoening 이 토론을 시작한 이유는 Three.js의 개념 증명 TypeScript 버전이 있기 때문입니다. 링크한 리포지토리 또는 리포지토리입니다 (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이 실행 가능한 접근 방식이 될 수 있다고 생각합니다. JSDoc 주석보다 파일을 최신 상태로 유지하는 것이 훨씬 더 어렵다고 생각하기 때문에 *.d.ts 파일에 대해서는 아직 확신이 서지 않습니다. 또한 *.d.ts 파일을 사용하여 프로그래밍 방식으로 소스에 대해 확인할 방법이 없다고 생각합니다. 그러나 @bhouston 은 그의 접근 방식, 특히 최신 상태를 유지하는 것에 대한 우려를 간략하게 설명할 수 있습니다. 아마도 이 문제에 대한 현명한 해결책이 있을 것입니다.

지금까지 나에게 가장 좋은 경험은 vscode + d.ts + JSDoc이며 모두 동일한 프로젝트에 있으므로 동기화를 유지하기 쉽습니다.

최신 vscode 버전은 d.ts 에서 병합된 선언과 JSDoc의 유형을 사용하여 기본적으로 JavaScript 파일을 검사하는 TypeScript 컴파일러인 checkJs 지원을 개선했습니다( tsconfig.json 에서 활성화 가능). JSDoc 구문에서 보기 흉한 "고급" 유형의 경우.

vscode는 모든 유형을 파생시킬 수 있으므로 모든 유형의 오류도 감지할 수 있으므로 리팩토링이 완료될 때마다 d.ts 에서 "버그/이전" 유형을 쉽게 보고 편집할 수 있으므로 계속 동기화됩니다. .

TypeScript의 가장 나쁜 점은 추가 트랜스파일 단계로, 모든 단일 코드 변경에 몇 초가 걸릴 수 있습니다. 요컨대, vscode의 JSDoc + d.ts 는 유형의 모든 장점을 가지고 있지만 추가로 느린 트랜스파일 단계의 단점은 아닙니다.

유일한 문제는 모든 것에 100% 적절한 JSDoc 유형을 추가하는 것이므로 vscode가 이에 의존할 수 있습니다( @constructor , <strong i="16">@enum</strong> {number} , <strong i="18">@param</strong> {number} n Number of steps )

나는 또한 @bhouston 과 @LuWangThreekit 이 *.d.ts 파일에 대한 PR을 만들었다는 것을 여기에 추가하고 싶었 습니다. 자세한 내용은 https://github.com/mrdoob/three.js/issues/11552#issuecomment -454881060 및/또는 PR https://github.com/mrdoob/three.js/pull/에서 확인하세요. 15597

참고: 브라우저의 TypeScript는 Deno (GitHub에서 32,000개의 별을 가진 Rust와 V8 기반 TypeScript 인터프리터)가 가치가 있는 것으로 판명되면 그리 멀지 않을 수 있습니다.

코어 및 예제 모듈에 대한 유형 선언 파일을 추가했으므로 지금은 문제를 닫는 것이 좋습니다. TS 사용자를 위한 개발 경험은 확실히 작년보다 나아질 것입니다.

TypeScript에 관심이 있는 모든 사람을 위해...

@bhouston 이 작업하고 있는 이 Three.js에서 영감을 받은 라이브러리가 여러분이 찾고 있는 것일 수 있습니다.

https://threeify.org/

@bhouston 의 Threeify 는 훌륭한 프로젝트인 것 같습니다 🤩 SemVer가 있고 의미론적 릴리스를 사용합니다. TypeScript 위에 구축되었으며 핵심 가치는 Tree Shaking, Small Build Files 등과 같은 것 같습니다. 우리 중 많은 사람들이 Three.js에서도 보고 싶어하는 모든 것입니다. 그래서 저는 Threeify에 들어가는 작업을 정말 소중하게 생각합니다👍

@bhouston @mrdoob 하지만 새 프로젝트를 만드는 것이 정말 필요한가요? 커뮤니티를 나누는 것이 의미가 있습니까? 많은 대형 프론트엔드 프레임워크가 코드와 커뮤니티의 포크 없이 SemVer, TypeScript, Tree Shaking 등과 같은 것으로 전환할 수 있었습니다.

@pailhead 가 Three.js로 작업하는 것에 대한 흥미로운 기사를 작성했다고 생각합니다. 제 생각에는 다음과 같았습니다: 다른 three.js 버전으로 작업하기 . 그래서 커뮤니티에 Threeify 가 구현하려고 하는 것들을 채택하는 데 도움을 주고 싶은 사람들이 있다고 생각합니다. 새 라이브러리를 만드는 것보다 힘을 합쳐 Three.js를 개선하면 좋을 것 같아요.

인터넷의 많은 기사와 마찬가지로 Pailhead의 기사는 편향되어 있습니다. 라이브러리의 다른 용도는 고려하지 않습니다.

서로의 개발 워크플로를 방해하지 않고 모든 유형의 js 개발자를 수용하는 라이브러리를 만드는 것은 불가능하다고 생각합니다.

우리는 @pailhead 와 매우 유사한 경험을 Vue , Ember , React , Svelte , Angular 와 같은 최신 프론트 엔드 프레임워크로 작업하는 개발자에게 매우 일반적이라고 생각합니다.

Vue 가 어떻게 하는지 살펴봐야 할 것 같습니다. 웹사이트를 향상시키려는 PHP 프로그래머부터 정교한 웹 앱을 개발하는 사람들에 이르기까지 다양한 사용자 기반을 보유하고 있습니다. 다양한 유형의 사용자 간의 곡선을 매우 멋지게 구부립니다.

또한 모든 사람의 경험을 손상시키지 않고 기존 코드 기반을 업그레이드하는 방법에 대한 훌륭한 예가 있습니다. Ember 가 어떻게 웹 커뮤니티와 업계 표준과 함께 지속적으로 성장할 수 있었는지 살펴볼 수 있습니다.

최신 웹 개발을 실행하는 것이 불가능하다고 생각하지 않습니다. 하지만 많은 노력이 필요하고 그런 부분에 대해 많은 생각을 해야 한다는 데 전적으로 동의합니다. 이것이 여러 개의 새로운 프로젝트를 만드는 것보다 현대적인 경험을 만들기 위해 함께 일하는 것이 더 낫다고 생각하는 이유입니다.

이 스레드를 살펴보면 이미 Three.ts와 Threeify라는 두 개의 다른 프로젝트가 있으며 아마도 더 많은 프로젝트가 있을 것입니다. 포크와 별도의 이니셔티브를 만드는 대신 함께 작업한다면 전체 Three.js 커뮤니티에 엄청난 이점이 있을 것이라고 진심으로 믿습니다.

@mrdoob , 데이터를 수집하기 위한 설문조사는 어떻습니까? typescript의 사용은 한 가지이며 추정치를 얻을 수 있는 다른 질적 변수가 있다고 확신합니다.

@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는 IDE가 전체 프로젝트의 개요를 더 빨리 얻을 수 있도록 도와주기 때문에 기여자가 three.js 더 쉽게 액세스할 수 있다는 이점이 있다고 생각합니다.

대체 프로그래밍 언어가 브라우저에서 기본적으로 지원되지 않는 한 JavaScript를 계속 사용하는 것에 투표합니다.

가까운 미래에는 이런 일이 일어나지 않을 것이므로 TypeScript에 대해 보다 실용적인 관점을 가져야 한다고 생각합니다. 위에서 썼듯이 프로젝트와 리포지토리가 구성되는 방식의 문제일 뿐이며 사용 편의성과 개발 경험 간의 절충점이 아니라고 생각합니다.

나는 우리가 우리의 입장을 분명히 했다고 생각한다.