JavaScript는 잘못이 없다. 정말로.
Cho Minkyu
1668

ECMAScript의 가장 큰 문제는, 과거의 설계 문제에 대한 개선의 의지가 없다는 것입니다. 새로운 스펙을 추가할 시간에 기존 설계의 문제에 대한 고민을 하지 않는다면 20년이든 30년이든 비판받아야합니다. 정상적인 foreach 인터페이스 하나 없는데 무슨 기능을 추가합니까?
사람들이 Javascript에 대해 잘 모르고 이야기한다는 주장에도 동의할 수 없습니다. Webpack, Babel등에 불평하려면 Javascript에 대한 충분한 이해가 있어야 가능합니다. 이런사람들에게 “Javascript를 못하기때문에 불평하는것이다” 라는 주장은 공격일 뿐입니다. (한창 PHP에 대한 비판이 있을때도 PHP커뮤니티에선 동일한 반응을 보였었죠)
프론트엔드가 복잡해지고 있다고 하는데, 프론트엔드는 단순해지고있습니다. jQuery를 이용해 DOM 수정을 단순화했고, knockout을 이용해 data binding을 단순화 했고, React를 이용해 DOM 수정과 data binding을 하나로 통합하는 방식으로 “단순화”되고 있습니다. 엔지니어는 복잡해지기 위해 새로운 도구를 만들지 않습니다.
알아야할게 너무 많은건 분명한 사실입니다. ECMAScript라는 표준이 있는데, 이 표준을 사용하기 위해 수많은 preprocessor에 대해 알아햐 하는게 과하다고 생각하지 않나요?
ES2016을 사용하기 위해 webpack+babel을 사용하는것입니다. webpack+babel을 사용해 ES2016을 사용할 수 있는게 쿨한게 아닙니다.
흔히 안되던걸 억지로 되게 만드는 도구가 나타나니 쿨해보일 수 있습니다. 하지만 이건 애초에 안된다는것에서 시작된 문제입니다.
ES2016에 있는 모듈 시스템을 사용하기위해 Common JS의 모듈 시스템과 AMD를 이해해야한다는건 알아야할게 너무 많은게 아닌가요?

분명히 Javascript에는 문제가 많습니다. 이러한 문제를 가려줄 도구들이 있는건 맞지만 그 도구가 너무나도 많고, 그 도구가 존재해야하는 이유가 바람직하지 못합니다. 이러한점은 분명히 짚고 넘어가야하며, 이에 대한 비판은 필요한 비판입니다.

Javascript를 비판하는 사람들을 Javascript를 못하는, 편견에 붙잡힌 사로잡힌 사람으로 보는 시선이 불편해서 댓글을 남깁니다.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.