[📚정보] 자바스크립트 엔진중에도 좋은게 있는건 사실 맞음. 다만

[익명(furryparty)]

자바스크립트는 알고리즘이 복잡해지고, 코드가 길어질수록 그 특유의 자유성 때문에 이해못할 버그가 생김.

파이썬은 자유로워도 자료형에 있어서 심하게 자유롭진 않음. 오히려 상식적인 수준이고, 가역 관계의 자료형변환과 비교체계를 가져서 게임 엔진 내부의 인터프리터 언어로 쓰거나, 언어 구조가 비슷한 새 언어의 참조언어로 쓰임(고도 등).

자바스크립트는 그게 아님. 비교급만 해도 이해 못하는 비교(0==[] 등)이 너무 많고, 널의 표현만해도 Nan Null undefined 등 세개나 됌. 심지어 이 세개는 자유로운 자바스크립트면서 서로 다름취급임.

이것말고도, 객체와 프로토타입, 생성, 단일스레드등 게임엔진에는 적합하지 않은 특징이 너무 많음.

스레드 생성이나 클래스 생성도 요즘은 지원한다지만 언어의 근본자체와 맞지않기도 하고, 스레드쪽은 단일 프로그램으로 돌아가는게 아닌 새 프로세스를 생성하는쪽이라 일반적 스레드보다 무거움.

자바스크립트로 성공한 게임이 없진 않지만(뱀서). 규모가 커질수록 자스로 게임을 만들면 c#보다 더 버그가 빵빵터질거임. 심지어 자스는 조금만 이상해도 멈춰주지 않아. 걔는 이상한 리턴을 받아도 Nan undefined 등 이상 값을 내뱉는 한이 있더라도 안멈추는게 모토인 언어야(웹 브라우저에서 돌아가는걸 목표로 삼은 언어니까).

애초에 게임같이 기술집약적이고(우리가 엔진을 써서 못느낄뿐, 최소 컴퓨터분야에서 3개 이상의 분야가 결합된 하이테크 집합체임), 여러 객체들이 생성되는 개발에는 맞질 않지.

오히려 얘가 데이터 저장을 개같이 했는데, 로드할때는 못불러오면 유저데이터가 싹 클린해질수도 있음.

차라리 고도스크립트를 따로배워서 고도를 쓰거나, 어려워도 언리얼 쓰거나, 메이저 엔진인 유니티 쓰는한이 있어도 왠만해선 자스만으로 해결하려고는 안하는게 좋음.

서버 개발시에도 아키텍쳐를 처음부터 구조적으로 짜지 않고 자스의 쉬움과 편리함으로 짠 서버는 나중되면 비대해져서, 처음부터 다시 아키텍쳐를 짜거나, 딴언어로 이적하는 경우도 있어. 심하게는 별 성능 향상 기대못할텐데도 파이썬으로 이적하는 경우가 있는걸보면 할말다했지.

자스는 근본적으로 웹의 만능언어지, 겜 개발같은 언어는 아니란거야.

- dc official App

[익명(furryparty)]

자스는 즉, 이미 만들어진 프레임 워크(express fastify, 리액트)를 조립하고, 딱히 뭘 크게 손댈필요없을때 쓰는 언어임. - dc App

[익명(222.109)]

확실히 고수들은 다 비슷비슷하게 말하네

[ㅇㅇ 1(1.227)]

그러면 타스로 만들면 괜찮음?

[익명(furryparty)]

너 타스가 자스로 컴파일 되는건 알고 하는말이지? 그리고 그건 자료형에 메리트가 있을뿐이지, 딴건 여전히 위험해 - dc App

[ㅇㅇ 1(1.227)]

잘 몰라서.. 타스도 본문에 나온 문제들이 그대로 있음? 널표현이라든가 멈추지 않는다는 점이라든가

[익명(furryparty)]

타스로 짜서 컴파일해도 개발시 자료형 실수가 줄어들뿐이지, 외부에서 받아온 파일의 자료형의 문제는 여전히 존재함. 이는 타스는 자스로 컴파일하기 때문에 런타임시 자스랑 다를바 없기때문에 생기는 문제임. 예를들어 서버에서 json을 받아와서 파싱해서 저장한다치면, 타스에선 문제 없어보여도 자스에선 파싱과정에서 엉뚱하게 저장될 가능성이 있음. 그래서 자스 프로그래머들은 딴 언어에 비해 여러 디버깅하는편임. 유튜브사이트도 클라단자에서 f11눌러서 디버깅해보면 얘네도 오류떠있는 경우가 진짜 많음. 구글 소속까지 오류를 동반하는 코드를 짜야할정도로 골때리는 언어란거지. 그래서 c++과 자스는 공부할수록 골때리는 언어취급인거 - dc App