.js에서 .mjs로 확장자를 바꿨다는 점을 주목해줬으면 하는 바람, 사실 어느 확장자를 쓰든 문제에 부딪히는 현실에 대한 체감형 공감, dojo부터 CommonJS, AMD, ESM, webpack, esbuild, rollup 등 다양한 모듈 시스템을 써 왔던 입장에서 이 말에 정말 공감 100%라는 느낌
commonjs에서 esm으로의 전환이 마치 python2에서 python3로 넘어갈 때처럼 엄청난 변환이었지만, 기대에 비해 얻는 이점은 적고 번거로움만 가중된 인상, 많은 라이브러리들이 esm만 지원하는 경우가 많아져서 요즘은 npm의 'versions' 탭에서 최근 한 달 가장 다운로드 많이 된 버전을 골라 그게 마지막 commonjs 버전일 가능성이 높다는 현실, 분명 esm이 진보된 모듈 시스템이라 할 만하지만 tc39가 거의 의도적으로 commonjs와 호환이 안 되게(top-level await 등) 만든 부분은 정말 이해불가라는 솔직한 의견
js에서 모듈의 역사가 그야말로 트라우마에 가깝다는 생각, 이제 브라우저에 import maps까지 도입되어 앞으로 또 무슨 재미있는(?) 문제들이 생길지 궁금한 마음
최근에 Function 객체가 런타임에 아무 JS 코드나 컴파일할 수 있음을 알게 되어서, 'import'도 쓸 수 없는 내 환경에서 일종의 생명줄 역할로 매우 유용하게 활용 중, JS 생태계에선 별로 필요 없을 수도 있지만 내겐 큰 도움이 됨을 강조
그래서 모두가 bun.sh를 써야 한다는 주장
.esm.js도 쓸 수 있지 않느냐는 질문
이 글에서 장기적으로 문제를 일으킬 수 있는 부분을 더 지적하자면, var 키워드 대신 let이나 const를 쓸 것을 추천, var는 여전히 동작하지만 요즘 JS 개발자들은 대부분 linter로 var 사용을 금지하는 분위기, var는 함수 스코프만 지원해서 대부분의 타 언어 개발자들이 언젠가 혼란을 겪는 포인트임, 네이티브앱 포팅 이슈로는 컴파일 타임에 Ctrl-C, Ctrl-V로 복사/붙여넣기를 하드코딩해서 리눅스, 윈도우에선 되지만 맥에서는 먹히지 않는 예시를 언급, 웹에서는 copy, paste 이벤트를 감지하는 식으로 처리해야 하며 Unity 같은 프레임워크도 하드코딩된 키 때문에 맥에서는 복붙이 안 되는 것을 목격, 대부분 게임에선 필요 없지만 복붙이 필요한 기능을 웹으로 내보낼 때는 꼭 문제가 되는 사례
웹/NodeJS에서 멀티스레딩 너무 싫다는 푸념, mutex나 rwlock 같은 동기화 프리미티브로 값 자체를 context간(예:v8 isolates) 전송 가능하게 만드는 게 아니라, 실제론 거의 쓸 데 없는 SharedArrayBuffer만 도입된 점이 아쉬움, 스레드간 동기화는 결국 thunking과 데이터 복사를 RPC 레이어를 통해 하게 되는 구조, 우리 회사 프로덕션 앱은 70~100GB RAM을 쓰는 대형 앱(내가 만들기 전부터 그랬음)이라서, 네이티브코드 기반으로 메모리 페이지와 커스텀 데이터 구조를 직접 관리하면서 직렬화/해제 최소화하는 희한한 해결책을 찾고 있는데, v8은 문자열 인코딩이 utf16이라 네이티브 레이어에서 JS 값 다루기가 비쌈
100GB RAM을 쓰는 이 앱이 진짜 웹앱이어야만 했는지 궁금, C# 같은 언어로 작성된 내부 툴이어야만 할 이유가 있는 것처럼 들리는 의문
이 생태계가 혼돈에 가까워서 차라리 '마조히스트' 소리도 더 정상적으로 느껴지는 현실
이미 혼돈이 내포돼 있다고 봐도 된다는 한 마디
글 자체가 잘 쓰여진 점, 더군다나 어렵고 복잡한 루트로 시작한 선택에 놀라움, 프로젝트 세팅이 가장 힘든 부분임을 실감, 바로 보안/헤더 문제에 부딪힌 걸 칭찬하지만 종종 예상되는 문제는 CORS라는 의견, 우리 회사에서도 emscripten/C++으로 빌드 중이며 WebGPU/셰이더와 WebAudio까지 추가해 앞으로 더 빡센 여정이 예상
예전엔 브라우저에서 코드 컴파일은 '느릴 것'이라 막연히 생각했지만 OP가 그렇지 않음을 잘 설명, Emscripten 프로젝트도 "LLVM, Emscripten, Binaryen, WebAssembly의 조합 덕분에 출력물이 작고 거의 네이티브와 같은 속도로 동작"한다고 강조 (emscripten.org)
오늘 나에겐 '옐로우버스 증후군'같은 하루, 지난 주까지만 해도 Emscripten을 몰랐는데, 프로젝트에 SDL을 붙이며 CMake에 APPLE, MSVC, EMSCRIPTEN 타겟이란 주석을 만났고, 바로 오늘 hn에서 Emscripten 이야기를 또 마주쳐서, 이제는 본격적으로 시간 내서 깊이 파봐야 할 시점이라는 다짐
"거의 네이티브 속도"라는 표현이 상당히 주관적이라는 의문, 실제로 얼마나 빠른 건지 문서에서 수치 데이터를 못 찾음
글이 유익했으며 본인도 C로 작성된 컴파일러를 웹어셈블리로 컴파일해 웹플레이그라운드로 만들고 싶다는 계획, 참고로 최신 브라우저는 자바스크립트를 통해 SQLite를 사용할 수 있는데, 이게 wasm에서도 가능한지 궁금, 만약 emscripten이 C 코드의 sqlite API 호출을 브라우저 sqlite db로 다리 연결해주면 너무 이상적일 것 같아 더 알아볼 가치가 있음
SSL에 왜 48번 포트를 썼는지 궁금, 특별한 이유가 있는지 질문
H48이라는 이름에서 따와 무작위로 정한 포트라는 답변, 이 웹앱은 추가 HTTP 헤더가 필요해서 사이트 전체에 영향 없이 구현하려고 간단히 다른 포트를 쓴 것이 원인, https://h48.tronto.net로 리다이렉트도 되고, 나중에 OpenBSD의 httpd와 relayd 세팅을 더 개선하거나 아예 별도의 도메인으로 옮기는 방안도 고민 중이라는 설명
Hacker News 의견