“사랑하지만, 그래도” 자바스크립트의 싫은 부분 10가지

원문 : http://www.itworld.co.kr/slideshow/86901

우리는 자바스크립트를 좋아한다. 1992년에는 정적 웹 페이지가 보기 좋았지만, 지금의 웹 페이지들은 노래하고 춤추거나 기타 자바스크립트로 작성된 매혹적인 코드로 사용자들을 유혹한다. 우리는 매일, 거의 모든 플랫폼에서, 거의 모든 목적으로 자바스크립트를 쓰지만, 그렇다고 자바스크립트의 모든 면을 좋아한다는 뜻은 아니다.

여기서는 웹의 오랜 언어인 자바스크립트에 대해 우리가 싫어하는 10가지를 살펴보자. 물론 싫다고 해도 서버에 루트킷으로 침투해 엄청난 양의 스팸 메시지를 보내는 사람에 대해 느끼는 적개심만큼은 아니다. 어쩌면 단순한 불평 정도일 것이다. 판단은 여러분 스스로 하기 바란다. 

---

중첩 중괄호의 범람

물론 함수를 매개변수로 전달하는 것은 좋다. 매개변수를 호출하는 함수를 포함한 함수를 전달하는 것도 좋다. 그러나 어느 시점이 되면 중첩은 걷잡을 수 없게 된다. 모든 중괄호와 괄호의 수를 확인해서 코드가 어디서 풀리는지 확인할 정도로, 또는 여러분의 멋들어진 솔루션이 자바스크립트의 다른 단점들을 어떻게 해결했는지 일일이 확인해볼 정도로 한가한 사람은 없다. 프로그래머들은 무엇을 해야 하는가? 메소드 이름을 부여해서 이것을 이름으로 전달하면 된다. 하지만 그건 너무 단순하다는 이유로 너도나도 괄호에 넣은 코드로 뒤덮인 거대한 스파게티 덩어리에 메소드를 중첩하는 것이다.

---

브라우저 부야베스

물론 과거에는 브라우저 비일관성으로 인한 골치거리가 지금보다 더 컸다. 그러나 표준이 업체 간의 계속되는 알력으로 수렁에 빠져 있는 사이 각 브라우저는 코드와의 상호 작용 측면에 관한 거의 모든 부분에서 여전히 약간씩 다른 메커니즘을 사용한다. 예를 들어 공백을 파싱하는 방법과 같은 사소한 부분에서 아직도 큰 차이점들이 존재한다.

이런 점들이 프로그래머들을 미치게 한다. 결국 프로그래머들은 코드가 언제든 문제 없이 실행되도록 하기 위해 j쿼리와 같은 라이브러리의 품에 안긴다. 그리고 우리 모두가 알듯이 라이브러리는 훌륭하다. 단, 원래 훌륭한 라이브러리에만 해당되는 이야기다. 

---

다른 세계의 DOM

자바스크립트가 만들어진 목적은 웹 페이지를 쉽게 조작하기 위해서다. 그러나 자바스크립트는 페이지 자체와는 별개의 공간에서 실행되며, 이로 인해 프로그래머는 일종의 API를 통해 웹을 프로그래밍하고 있다는 느낌을 받게 된다. 어떤 작업을 수행하거나 효과를 렌더링하려고 할 때마다 DOM 개체를 검색해야 한다. 이 과정을 단순화하기 위해 어느 똑똑한 사람이 $ 함수를 만들어서 라이브러리에 추가했지만 사실 이것은 언어 자체의 일부여야만 한다. 각 브라우저가 이러한 DOM 개체를 취급하는 방법의 차이는 극히 미미하므로 별도의 세계로 분리해서는 안 되는 것이다.

---

사람들은 더 이상 자바스크립트로 프로그래밍하지 않는다

대부분의 코드는 개체를 찾고 목록을 조작하기 위해 jQuert나 기타 라이브러리에 많은 부분을 의존한다. 이런 코드는 그저 라이브러리 호출 목록의 결합체일 뿐이므로 자바스크립트라는 언어와는 거의 관계가 없다. 아예 이름을 jQuery로 바꾸고 자바스크립트는 잊는 게 어떨까? 

---

끝없는 라이브러리 재로드

표준 라이브러리의 캐시 가능한 버전을 사용하기 위한 온갖 노력에도 불구하고 대부분의 웹 사이트는 캐시 가능 버전을 사용하지 않는다. 결과적으로 웹 트래픽의 상당부분은 동일한 자바스크립트 라이브러리를 반복해서 재로드하는 데 따르는 트래픽이다. 이 라이브러리를 전 세계로 나르기 위해 소비되는 전기에만 얼마나 많은 에너지가 들어갈까? 사람들이 이 라이브러리가 로드되기를 기다리면서 낭비하는 시간은 얼마나 될까?

---

새 기능의 정체

위원회가 소집된다. 초안이 회람된다. 사람들이 토론한다. 그러나 여기서부터 진행 속도는 무척이나 느리다. 아무도 웹을 망가뜨리고 싶어하지 않지만, 모두가 새로운 기능을 원한다. 문제는 저마다 원하는 기능이 다르다는 점이다. 그래서 끊임없이 이야기만 오고 간다. ECMA스크립트의 다음 버전이 원래 나오기로 했던 때가 언제였더라? 

---

자바스크립트에 올라탄 멋진 도구들의 범람

자바스크립트로 컴파일되는 커피스크립트(CoffeeScript)나 다트(Dart)와 같은 언어는 얼핏 뭔가 그럴듯해 보인다. 누군가가 특정 작업을 더 효과적으로 하는 방법을 원했고, 기존 인프라스트럭처를 사용해서 신속하게 그것을 가능하게 하는 방법을 알아냈다. 그리고 모두가 동의할 때까지 기다릴 필요도 없이 파티에 동참하도록 했다. 그러나 이로 인해 불협화음이 발생했다. 모두가 조금 다른 코드를 작성하고 저마다 조금 더 멋진 버전의 미래를 그리기 때문이다.

게다가 결과물은 컴파일러에서 나오기 때문에 사람이 알아볼 수가 없다. 이것은 웹의 가장 멋진 특징 중 하나, 즉 모든 페이지의 HTML과 자바스크립트를 살펴보고 구조를 이해할 수 있다는 부분을 망치는 주범이다. 프로그래머들은 더 깔끔한 코드를 써야 한다.

---

자동 형식 변환 버그와 혼란

자동으로 통합되는 언어 변환 문자열이 있다는 것은 유용한 것 같지만 원하지 않을 땐 그 반대다. 게다가 더하기 기호는 추가와 연결, 두 가지를 모두 나타내므로 앞으로 일어날 일을 기억하기란 거의 도박에 가깝다. 변수 x가 문자열 1로 설정되면 x+1은 11이 되지만 x-1은 0이 된다. 문제가 없는 경우도 있지만, 다른 동작을 기대했다면 문제가 된다. 

---

값의 혼란

스피드 퀴즈: false, null, NaN과 undefined의 차이점은 무엇일까? 이 4가지는 여러 가지 측면에서 비슷하다. 서로 완전히 똑같은 것도 있다. 크롬에서 isNaN(undefined)은 true로 나오지만 undefined=NaN은 false로 나온다. 몇 시간 동안 이 수학 체계를 공부한다고 문제될 것은 없지만, 그 지식이 꼭 코드를 더 쉽게 짤 수 있게 해주지는 않는다.

---

잘못된 자바 정체성 

믿기 어려운 일이지만 사람들은 여전히 자바스크립트와 자바를 혼동한다. 이 혼동의 근본적인 원인은 누군가가 자바와는 거의 다른 언어임에도 자바에 편승하기로 결심하고 비슷한 이름을 지었기 때문이다. ECMA스크립트라고 부를 수도 있지만 그렇게 하면 아무도 알아듣지 못할 것이다. 기술 커뮤니티는 차이점을 인지할 수 있지만 일반인들은 그렇지 않다. 자바는 브라우저에 마크업을 전송하기 위해 서버에서 작동하며, 브라우저에서 실행되는 자바스크립트와 간혹 예외적으로 연동된다는 사실을 기억하는 것이 정녕 불가능할까? 우리도 가끔 이야기하면서 헷갈린다.