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

 In Programming
[이제와서 jQuery를 쓰면 안되는 이유]가 이제와서 흥하고 있어서 2부를 써봅니다. 1부에서는 jQuery의 DOM 관리 문제에 대해 썼는데, 2부에서는 현재 jQuery에 어떤 이슈가 있는지 정리해보겠습니다.

jQuery의 이슈들

1. 사이즈가 크다.
jQuery 1.12.4 minified버전은 95K이고 압축하면 34K정도 됩니다. 크다면 크고 작다면 작은 사이즈입니다. 몇년전까지만해도 핸드폰의 사양이 낮아서 문제가 컸는데, 요즘은 그 정도는 아닙니다. 게다가 React나 Angular같은 라이브러리는 훨씬 더 크니 사이즈로 문제삼기는 좀 애매하죠. 필요없는 라이브러리를 제거한 slim버전은 27K인데, 예전 IE는 지원하지 않습니다.

2. Modular하지 않다.
한 프로젝트에서 jQuery의 모든 기능을 이용하는 경우는 없습니다. Javascript의 표준 모듈 방식인 것도 아니고, Tree Shaking도 지원하지 않기에 필연적으로 안쓰는 코드를 포함하게 되는데, 이게 옳은 일인지 고민이 필요합니다. 특히 Animation이나 AJAX는 너무 구식이라 더 좋은 대안을 쓰는게 낫습니다. slim 버전에서는 이와 같은 기능이 분리되었습니다.

3. 너무 쉽다.
document.getElementById(“some-id”)보다 $(“#some-id”)쪽이 훨씬 보기 편합니다. 그런데 너무 쉽다보니 $를 남발하게 됩니다. 생각보다 $를 쓰는게 메모리와 CPU를 잡아먹습니다. 그리고 jQuery.data같은 함수는 DOM에 직접 읽고 쓰는 기능을 제공하는데, 덕분에 속도면에서도 느리고 변수를 Global에 노출시키게 됩니다. 너무 편해서 잘못된 코딩을 하게 되는 것도 문제입니다만, 근본적으로 보자면 jQuery를 이해하지 못하고 쓰는게 문제겠죠.

4. jQuery는 javascript가 아니다.
기본적으로 jQuery는 Select한 element의 배열을 기준으로 작업합니다. $(“.some-class”) 이면 [el1, el2, el3]와 같은 Selector에 의해 선택된 배열을 내부에 가지고 있으면서 그 기준으로 작업을 합니다. 그런데 예를 들어 $(“div”).text()를 하면 div의 내용을 가져오는데, div가 두개가 있을 때는 두 div의 내용을 합쳐서 하나의 스트링을 반환합니다. < div >123< /div >< div >456</ div >이면 $(“div”).text()의 결과는 “123456”이 됩니다. 근데 과연 이런 동작이 맞을까요? 대부분 text()로 값을 가져오는 경우는 하나의 값이 필요해서 입니다. 두개의 text값이 필요하다면 각각의 값을 배열로 반환하는게 맞지 않을까 하네요. jQuery의 수많은 함수가 배열로 동작하는데, $(“.some-class”)가 배열처럼 보이지 않기에 문제를 일으킬 소지가 있습니다. 이와는 반대로 val()일때는 맨 처음 element의 값만 가져오도록 되어있는데 다른 함수들과 동작이 다릅니다.

jQuery의 hide, show는 element에 style을 적용합니다. < div style=”display:none” >처럼요. 그런데 element의 style은 우선도가 높기에 css에서 설정한게 안먹을 수도 있습니다. 그러므로 가급적 쓰면 안됩니다만 어디에고 그런 설명을 찾기는 어렵습니다.

jQuery만의 독특한 동작이 상당히 많습니다. 그게 틀린 방식은 아닙니다만 웹표준은 아닙니다. 그러므로 jQuery를 잘 쓰기 위해서는 jQuery 내부 동작을 잘 알아야 합니다. 근데 그럴꺼면 그냥 javascript로 작성하는게 더 편하지 않나 합니다.

5. 웹표준을 지키지 않는다.
지키지않는다는게 정확한 표현은 아니고, jQuery가 워낙 오래되서 웹표준이 정해지기 전에 나왔기 때문에 문제가 좀 있습니다. 예를 들어 jQuery Deferred는 하위호환때문에 Promise/A+ 표준을 지키지 않습니다. Ajax도 fetch라는 표준이 나와서 굳이 jQuery방식을 쓸 필요가 없구요. jQuery를 도입하게 되면 브라우저에서 지원하니 성능적으로 월등하고, 표준이라서 앞으로도 변함이 없는 기술을 놔두고 굳이 예전 방식을 써야 하는 상황이 됩니다. ES6로 들어서면서 Javascript의 기능도 많이 늘었기에 polyfill이나 transpiler로 처리하는게 장래를 생각하면 더 나은 방식입니다.

6. 업데이트의 문제
1.x버전과 2.x버전은 공식적으로 소프트웨어로서의 수명을 다했습니다. IE6~8을 지원하려면 1.x를 써야 하는데 그렇게 되면 차후의 서포트를 받지 못하게 됩니다. IE9부터는 jQuery 3.x에서 지원하므로 당분간은 문제가 없을 예정입니다만 IE9, 10지원을 포기하면 수많은 대안이 존재합니다.

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

이 외에도 문제는 많이 찾을수 있을테지만, jQuery같이 규모가 크고 수많은 사람들이 쓰고 있는 라이브러리에 치명적인 문제는 그리 많지 않습니다. 작은 사이트를 만들고 돌리는데는 아직도 jQuery만으로 충분합니다. 그러나 점점 트렌드가 바뀌고 있으니 준비하고 다음 단계로 넘어가야 하지 않을까 하네요. 특히나 Javascript 업계는 전례가 없을 정도로 빨리 변하고 있으니까요.

박 종희
TOKYO BRANCH Inc. Chief Technology Officer
Recent Posts
Showing 4 comments
  • kurien
    응답

    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의 본질 자체를 바꾸라고 하거나, 다른 프레임워크를 강요할 필요성은 없다고 봅니다.

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

    • kurien
      응답

      엔터를 꽤 많이 쳤는데, 엔터가 전부 사라져서 읽기 힘들어졌네요.
      추가적으로 해당 글이 “토론”형식의 글이라고 생각되어 조금 강한 어투로 적혀있을 수 있습니다.

      불쾌하셨다면 사과드리겠습니다.

    • 박 종희
      응답

      1번은 다양한 의견이 가능합니다. 글로벌 전개를 하게 되면 아프리카같은 낙후된 곳에서도 서비스 해야하는데 34Kb면 크다.. 뭐 그런 의견도 있습니다.
      2. 현재 ES modules가 browser에 채택이 되었지만, node에는 과도기적인 상황입니다. 그러나 내년에 node의 LTS버전이 나오면 해결되겠죠. 자바스크립트 모듈관리가 완전히 ES modules로 넘어가게 되면 jQuery의 설자리가 많이 줄어들지 않을까 하네요.
      3, 4는 jQuery를 잘 알고 쓰면 해결이 되지만, 리소스가 많지는 않습니다.
      5. 새로운 jQuery가 나오면 jQuery가 아니겠죠. 그런 의미에서 jQuery mini는 의미있는 시도라고 봅니다.
      6. IE8점유율이 올해들어 많이 줄었습니다. 이제는 대응을 안해도 되지않나 하네요.
      7. Spring/RoR같은 MVC프레임웍이 나왔다고 Classic ASP개발이 사라진건 아니죠. jQuery의 개발방법론이 구식이 되가고 있는 시점에서 새로운 방법론에 익숙해지는건 좋다고 봅니다.

      제가 part 2에 언급한 jQuery의 문제는 제가 문제라고 생각하는게 아니라 인터넷 상의 공통적인 의견을 모아놓은 것입니다. 제가 jQuery를 싫어하는 가장 큰 이유는 modern한 자바스크립트 개발 방법론을 적용할 수 없기 때문이죠. webpack이나 postcss가 대세인 시대에 jQuery같은 external하고 global한 라이브러리는 좀 쓰기가 그렇습니다. 그리고 jQuery의 장점은 거의 다 ES6에 흡수되어서 기능의 중복이 상당하기도 합니다. ES6위주로 쓸꺼면 왜 또 라이브러리가 필요하지? 싶은 경우가 많습니다. 그래서 가급적 배제하려고 하는데, 프로젝트의 성격에 따라 안쓸 수 없는 경우도 많습니다. 얼른 자바스크립트의 과도기가 지나갔으면 하네요.

      그리고 다양한 토론은 언제든 환영입니다. 좋은 의견 감사합니다.

pingbacks / trackbacks

Leave a Comment

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Not readable? Change text.

Start typing and press Enter to search