이제와서 jQuery를 쓰면 안되는 이유 part 2

1. 사이즈가 크다.
jQuery minified 버전이 34Kb정도 된다고 하셨는데, 이는 대부분의 이미지 크기보다 작은 사이즈입니다.
게다가 js의 특성상 캐시가 되므로, 첫 페이지에서 다운받게 되더라도 이후에는 문제가 없는 부분이구요.
그 마저도 싫다면 cdn 서버를 이용하게 되면 다른 사이트에서 받은 jquery라도 캐시가 되어 나타납니다.

사이즈가 크다고 하기 전에 이미지를 스프라이트 형식으로 변환하여 사용중 인지, 폰트를 최대한 압축하여 사용중인지, css를 minified 버전으로 만들어서 사용 중인지, js 혹은 프로그램 오류로 잘못된 작동을 해서 느려진건 아닌지 부터 확인하는게 먼저인 것 같습니다.

위의 작업을 모두 한 뒤에도 느려서 jQuery를 안썼더니 속도가 빨라졌다고 하시면 제 입장에선 할말이 없겠네요.

2. Modular하지 않다.
jQuery를 모듈화해서 배포하면 잘 사용하는 사용자가 있겠지만, 제 입장에서는 현재로써도 크게 문제가 된다고 보여지진 않습니다.
이 부분은 계륵이라고 생각되어지는 부분이며 이렇게까지 사이즈를 줄이고 싶다면 직접 develop 버전을 받아서 수정해보는건 어떨까 싶네요.

3. 너무 쉽다.
이 부분은 아무리 생각해도 단점으로 볼 수가 없네요.
제 주관적으로 보기에는 성능을 위해 기계어를 쓰지 왜 고급 언어를 사용하냐는 것처럼 보입니다.
성능이 닳는 것에 비해 편리성이 월등히 높기 때문에 절대 단점이라고 볼 순 없다고 보며, 성능적으로 문제가 될 정도로 느려졌다면 그건 개발자의 잘못이라고 보여지네요.

4. jQuery는 javascript가 아니다.
이 부분은 제목과 내용이 너무 괴리가 있다고 느껴집니다.
“기존 javascript와는 다른 동작을 한다”라고 하는 편이 어떨까 싶네요.

$(“div”).css(“color”: “red”);라는 코드가 있을 때 내부적으로 div 배열을 for문으로 돌려서 각각의 객체에 style.color = red를 해주겠죠.
그런데 이걸 javascript로 적으면 좀 길어집니다.

그걸 가지고 “javascript가 아니다”라고 하시면, “프레임워크”의 존재의 의미를 잘 모르겠네요.
그리고 해당 부분은 $(“div”).each(function() { $(this).css(“color”:”red”});와 같이 기존과 같이 쓸 수도 있구요.
기존 javascript처럼 사용할 수 없다면 잘못된 것이겠지만, 오히려 길어질 코드를 더 쉽게 만들었다고 보이네요.

그리고 아래 적으신 $(“div”).text()를 하면 123, 456이 123456으로 나온다는 부분은 저도 조금 이상하게 동작하는거 같다는 생각을 합니다.
저나 작성자님이 잘못된건지 jQuery가 잘못된건지는 잘 모르겠지만, 잘못된 코드라면 결국 버전업을 하면서 해결될 문제이지 jquery를 써선 안될 문제는 아닌 것 같습니다.

추가로 $(“.some-class”)가 배열처럼 보이지 않기에 문제를 일으킬 소지가 있다는 말은 jQuery를 제대로 공부 안했다는 말 밖에 안된다고 생각합니다.

5. 웹 표준을 지키지 않는다.
말씀하신 Deferred의 경우 Promise/A+를 지키지는 않지만, “jQuery Deferred is based on the CommonJS Promises/A design.”라는 문구에 나온 것처럼 Promises/A를 기반으로 작성됐습니다.

이후 버전에서 말씀처럼 대신 할 기능이 있다면 치환될 가능성이 높으나, jQuery 경우 웹 표준보다는 호환성을 중시하기 때문에 “굳이 예전방식”이 아닌 호환을 위한 예전방식을 쓴다고 생각되네요.

장래에는 장래에 맞는 버전의 jQuery가 나오겠죠.

6. 업데이트의 문제
지금은 IE7 이하가 거의 보이지 않지만 IE8은 여전히 쓰는 사람이 많습니다.
그래서 한국 시장의 웹 개발을 역시 여전히 IE8까지는 지원하게 해달라는 요청이 많구요.(물론 이런 부분은 한국 시장이 잘못 된 부분이며, 고쳐져야한다고 생각합니다.)

IE9부터는 말씀대로 jQuery 3.x 버전에서 지원하고, 여전히 업데이트 중이기에 문제가 없습니다.
업데이트에는 문제가 없어 보이며 잘못된건 한국과 같이 구버전을 위해 구버전 jQuery를 사용해야 한다는 점 같네요.

7. Virtual DOM과의 상성이 안맞다.
Virtual DOM은 작업을 가상의 DOM에서 작업하고, 실제 DOM으로 이동 하면서 기존의 여러번 렌더링 되면서 저하되는 성능을 한번만 렌더링 하게 하여 성능을 올리게 하는 작업이죠.
이 부분은 template 기능과는 별개로 jQuery에서도 Virtual DOM을 감안하여 작성하면 해결할 수 있는 부분으로 알고있습니다.

“요즘 나오는 라이브러리들은 DOM을 직접 다루지 않고 template에서 자동으로 생성하기 때문에 jQuery와 함께 쓰기가 매우 애매합니다. 둘 중의 하나를 골라야한다면 Vue, React, Angular같은 새로운 라이브러리를 선택하는게 맞겠죠.”
라고 하셨는데,

이 부분은 새로운 라이브러리를 선택하는게 맞다고 강요로밖에 보여지지 않습니다.
DOM을 직접 다루지 않고 template에서 자동으로 생성하기 때문에 Virtual DOM을 이용하게 될 수는 있지만,
jQuery에서도 사용방법에 따라 충분히 Virtual DOM을 이용할 수 있으며, 프레임워크란건 각자의 용도에 맞게 사용하면 되는거라고 생각합니다.

데이터베이스도 1정규화부터 5정규화까지 6개의 단계가 있지만, 항상 5정규화가 맞는건 아닙니다.
성능에 따라 역정규화라는 것도 하죠.

객체지향에서도 클래스를 나누어 사용하면 재사용성도 높고, 유지보수에도 용이하지만,
너무 나누게 되면 더 복잡해져버리는 현상이 발생하죠.

똑같이 프레임워크들도 각각의 역할이 있고, jQuery가 말하는 3가지

Lightweight Footprint, CSS3 Compliant, Cross-Browser는 정말 잘 구현되어있다고 생각합니다.
만약 위의 jQuery의 역할이 자신이 개발하려는 목적과 다르다면 다른 프레임워크를 쓰는게 맞지,
jQuery의 본질 자체를 바꾸라고 하거나, 다른 프레임워크를 강요할 필요성은 없다고 봅니다.

그리고 어짜피 안쓰일만한 프레임워크는 시간에 따라 점점 사용자가 줄어들게 되어있습니다.

DOM 다루는데는 jquery 만한게 없는 건 사실이라 그닥 공감은 안 가네요..