넷팩

이번 게시물은 짧은 게시물이겠지만... 후속 게시물이 더 길어지기를 바랍니다.

겨울방학 동안 시간을 ​​내어 한 가지 실험을 했습니다.

C#/.NET을 사용하여 작성된 웹 도구가 Rust / Go / Zig ...와 비슷한 성능을 낼 수 있습니까?

그래서 코딩을 좀 했습니다...(GitHub에서 찾을 수 있음)

프로세스

저는 조악한 번들러 논리로 시작했습니다.

• 파일 열기
• 콘텐츠 읽기
• 정규 표현식을 사용하여 JS 파일의 import 문 등을 감지하세요.
• 링크된 모듈 해결
• 해결된/기존 package.json 파일을 열어 모듈 경로 식별

결과는 간단했습니다. AoT(사전 컴파일) .NET을 사용하면 확실히 고성능 웹 프로젝트에 사용될 수 있습니다.

그래서 저는 실험을 조금 계속했습니다. 정규식을 실제 코드 이해로 대체합니다.

TLDR; 결과

답은: 그렇습니다! ?

번들러는 현재 기능이 불완전하지만 첫 번째 결과는 상당히 강력합니다. README에 표시된 벤치마크는 성능이 확실히 다른 도구와 동일한 수준임을 나타냅니다. 충분히 빠릅니다.

자세한 내용

개인적으로는 C#/.NET이 Rust보다 훨씬 덜 복잡하고 Go보다 강력하다고 생각합니다. 몇 가지 단점도 있습니다. 거짓말을 할 수 없습니다.

C#/.NET이 해당 분야에서 실행 가능한 주된 이유는 AoT입니다. AoT가 없으면 시작 성능(런타임 요구 사항은 물론)이 전체 아이디어를 죽이는 것입니다.

반면에 AoT에는 몇 가지 과제가 있습니다. 일부 라이브러리는 사용할 수 없거나 통합하려면 일부 작업이 필요합니다. 따라서 .NET의 유연성 중 일부를 사용할 수 없습니다.

rspack과 같은 도구에서도 사용되는 가장 큰 테스트 프로젝트의 경우 다음과 같은 결과를 얻습니다.

번들러도 기능이 불완전하므로 프로젝트에서 유효한 결과를 생성할 만큼 충분히 제작되었습니다. 따라서 현재로서는 모든 결과가 예비적이지만 적어도 어느 정도 타당성은 있습니다.

그렇습니다. 넷팩은 이미 경쟁사를 능가하고 있으며 더 나은 성능을 발휘할 가능성도 있습니다. 추가로 최적화할 수 있지만 소스 맵이나 트리 흔들기 등이 도입되면 일부 성능이 저하될 수도 있습니다. 지금은 잠재적인 최적화(예: JS AST 생성 스트리밍)로 인해 전체적으로 지금과 거의 동일해야 한다고 확신합니다.

현재 가장 큰 장애물은 JS(X)만 지원한다는 것입니다. 아직 TypeScript는 지원하지 않습니다(이러한 파일을 구문 분석하려고 시도하지만 유형을 사용하면 실패합니다). 지원하기가 "상당히" 쉬울 수 있지만 이를 위해서는 Acornima를 포크해야 하며 이는 프로젝트에 대한 소문이 충분히 있을 때만 수행할 작업입니다.

시야

여기에 들어가면 더 좋은 것들이 많이 있습니다. 하지만 먼저 몇 가지 기본 사항을 정리해야 합니다. 소스맵, TypeScript 지원 또는 구성 시스템 등이 있으면 좋을 것 같습니다.

이 실험에는 다른 번들러가 하지 않는 몇 가지 기능이 있습니다. 예를 들어 HTML 진입점에 importmap이 있는 경우 importmap의 항목은 자동으로 외부 항목으로 간주됩니다. 마찬가지로 특정 종속성을 공유로 설정할 수 있습니다. 이 경우 결과 HTML에 자동으로 importmap 항목/importmap이 생성됩니다. 꽤 깔끔해요.

향후 번들러는 SASS, CSS 모듈, CSS-in-JS는 물론 모듈 페더레이션 및 네이티브 페더레이션에 대한 기본(즉, 즉시 사용 가능) 지원을 제공할 예정입니다.

당신의 생각은 무엇입니까? 이것이 실행 가능한 아이디어라고 생각하시나요, 아니면 그냥 쓰레기라고 생각하시나요? 합리적인 기본값을 갖춘 빠른 ​​.NET 기반 번들러가 우리에게 필요한가요?

위 내용은 넷팩의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!