이제와서 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 업계는 전례가 없을 정도로 빨리 변하고 있으니까요.

Recent Posts
Showing 23 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위주로 쓸꺼면 왜 또 라이브러리가 필요하지? 싶은 경우가 많습니다. 그래서 가급적 배제하려고 하는데, 프로젝트의 성격에 따라 안쓸 수 없는 경우도 많습니다. 얼른 자바스크립트의 과도기가 지나갔으면 하네요.

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

    • ㅇㅇ
      응답

      제이쿼리 창시자가 인정했습니다. 그만하세요
      자기 경력 사라진다고 발버둥치는거 밖에 안보여요
      반박글 주르륵 적다가 보니까 다 억지로 억지로 안좋은거 좋다고 맞추는거밖에 안보여서 지웠습니다.

  • benant
    응답

    이글은 좀 태클 달고 싶은 생각이 많이 들지만 ㅎㅎㅎ 가볍게 보고 넘어 가겠습니다.
    전 좀 jQuery를 좋아라 하는 편이라서요. jQuery의 성능을 이야기 하기 전에 크로스브라우징 처리를 Javascript에서 어떻게 처리 했어야 했는가? 를 생각해 보시면 jQuery의 탄생 배경이기도 하니 왜 무거운건지 이해 되실거라 생각됩니다. jQuery가 나올당시에 있던 그 무지막지한 … 지금은 이름도 다 잊어버린 Javascript 라이브러리들 … 을 JQuery는 가볍고 신선한 코딩방식으로 재치고 개발자들의 선택을 받았습니다. 가장 큰것은 손쉽게 대부분의 브라우저에서 작동되는 결과물을 만들 수 있다는 것. 브라우저마다 다르던 DOM 처리 방법을 단일화 했다는 것. 요즘 많이들 쓰는 React나 썼던 Angular가 초기 로딩을 어마무시 하게 해야 한다는 단점(오죽하면 웹페이지 출력때문에 로딩이미지가 유행하게 된 단점)이 jQuery는 없다는 점이 제가 jQuery를 아직도 좋아라 하는 이유입니다.
    헛. 가볍게 보고 넘어간다는 것이 … 암튼, 글 잘 보고 갑니다. ^^

    • RIP_jQuery
      응답

      일간지 헤드라인 같은 제목은 마음에 안들지만 본문 내용에는 동의 합니다.

      크로스 브라우징 이슈는 20년 전부터 존재했음에도, 대응 코드를 작성하기 위해 노력하는 개발자를 필드에서 만나 본적이 없습니다.
      javascript, DOM, CSS 에 대한 이해도가 낮은 개발자들이 저질 코드를 양산했고, 그들이 jQuery를 사용하면서 부터 상황은 더 심각해 졌습니다.
      jQuery가 웹표준이라고 주장하는 프론트 엔드 개발자도 만나봤고, jQuery를 사용하지 않고서는 간단한 스크립트조차 작성하지 못하거나 각종 plug-in library를 남용하는 사례들을 빈번하게 겪었습니다.
      태생부터 jQuery는 language가 아닌 library로 그 한계가 명확해서 javascript를 대체할 수 없는 것이 너무도 당연할 뿐만 아니라,
      기본이 되는 javascript, DOM, CSS를 제대로 모르데 jQuery에 대한 이해도가 높을 수 있을까요?
      이제라도 특정 library에 종속되지 않고 시대의 흐름이나 상황에 맞는 library를 제대로 활용 할 수 있는 능력쯤은 갖춘 개발자가 늘면 좋겠습니다.

  • ㅇㅇㅇㅇ
    응답

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

  • 행인6
    응답

    다 됐고 어린이들은 jQuery면 다 되는 줄 알아요.
    for문도 안씁니다. 무조건 $.each, $(element).each로 조집니다.
    꼴뵈기 싫어요.

    • 박 종희
      응답

      each를 쓰는건 functional programming의 입장에서 나쁘지 않아요. 그치만 jQuery보다는 es6의 forEach같은걸 polyfill로 쓰는게 더 낫겠죠.

      • 행인7
        응답

        $(element).each 로 작업하면 될것을
        es6 polyfill 를 적용한 후
        Element 를 배열로 만든 다음 Element.forEach 로 작업하는게 더 낫다는 말인가요?

        $(element).each 나 Array.forEach 로 작동하는것을 for 문으로 작업하면 무슨일이 일어 나는지 모르시나요?
        ( 스코프, 호이스팅 어쩌구 저쩌구 많은 문제가 일어 납니다. )

        • 박 종희
          응답

          $(element).each 를 실행했을때 $(element)에서 무슨 일이 벌어지는지 생각해보면 굳이 쓸 이유가..

  • 일반인
    응답

    한마디로 고급 개발자들이 일반인이나 초급 개발자들이 자바스크립트를 jquery로 쉽게 구현 하는게 아니꼬아서, 어려운 자바스크립트를 강조하는거네
    예전 플래쉬 스크립트도 일반인과 초보스크립트자가 쉽게 사용하자 자바개발자들이 붙어서 플래쉬 스크립트를 어렵게 만들자 플래시 스크립트가 사장되다시피됐죠.

    • 박 종희
      응답

      생각없이 jQuery쓰다가 망하는 경우가 많아서 생각하고 쓰면 좋다는 글입니다. 예전보다 프론트에 요구하는 퀄리티가 높아져서요.
      그리고 플래시가 망한건 아이폰에서 플래시를 안썼기 때문입니다.

  • 일반인
    응답

    flash action script 2.0 넘어서 flash action script 3.0 업그레이 버전 되자 그때부터 일반인이나 초보 flash action script 사용자는 많이 줄은건 부인 못할겁니다.

    flash action script 1.X 이하는 일반 사용자들과 초보 사용자들이 접근하기 좋을 만큼 사용하기 쉬웠드랬죠.
    flash action script 2.X버전 도 일반인 상대나 배우는 초보자 이장에서 어려웠지만 그래도 나름 사용하기가 아주 어려운 건 아니였습니다.
    자바 개발자들이 flash action script 를 flash action script 3.0 버 전으로 나오게하자 그때부터 진짜 프로그래머 아니면 사용하기 어려워졌드랬죠.

    Flash 도 jquery 도 어려운걸 쉽게 구현하기위해 개발된 스크립트와 라이브러리 입니다.
    flash action script 3.0 가나오면서 그 의미가 쇄퇴했습니다.
    더구나 jquery는 복잡한 javascript를 쉽게 구현하고자 나온건데 이제와서 bootstrap5에서 jquery 를 버리고 javascript 로 도로 회귀한다는건
    이제 bootstrap5부터는 개발자들만 독식 하겠다는 거죠. 이제 bootstrap5부터는 예전 사용자만큼 이용자가 늘지않겠죠. 일반인과 초보자의 접근성과 이용성이 떨어지니

    • 박 종희
      응답

      jQuery랑 vue, react와의 상성이 안좋습니다.. 프론트엔드 개발 트렌드가 컴포넌트 기반으로 가고 있어서 일반인이 접근하기는 쉽지 않은데, 점점 개발자 중심으로 가고 있는거는 맞는거 같네요..

  • ㅎㅎㅎ
    응답

    옛날 도구든 최신도구든 손에 잘 익혀서 잘 쓰면좋은것같은데.. 왜 도구탓을.
    그리구 생각없이 쓰면 좋은도구든 옛날도구든 나쁜거아닌가 싶은디요..
    퀄리티야 쓰는사람에 달린거고.
    꼭 SNS나쁘다고 퍼거슨이 이야기했다고 퍼거슨이 말했으니 진리다 생각하는 사람들같네요
    왜 도구탓을하지. 쓰는사람이 문제인데..

  • 개발신입
    응답

    이제와서 보는거지만 2016년에 정말 말씀하신대로 올드한곳이나 작은 곳 아니면 jquery는 사용 안하고 vue, react를 많이 사용을 하네요.
    놀라고 갑니다. 그리고.. jquery만 사용하다가 react를 써보니 놀라울 만큼의 여러 기술이 눈에 뛰었지만… 러닝커브가 조금 있더군요…
    열심히 공부해야겠어요. 게시글 잘 보고갑니다

  • 백우
    응답

    아직도 JQuery쓰는 흑우 없제?

  • james
    응답

    es6개발에 jQuery와 같이 사용하면 jQuery를 버릴 이유가 없네요.
    2,422,069 <— 이 수치는 npm 에서 jQuery를 이번주에 다운받은 숫자입니다.

  • 개발잘하고싶다
    응답

    입사한지 얼마 안된 주니어 프론트엔드 개발자입니다.
    본문과 댓글들을 part1 부터 하나씩 읽어보며 어떻게 프론트엔드 생태계가 발전해왔는지를 본거같아 기분이 오묘하네요..
    제가 프론트 공부를 시작할때 쯤에는 jQuery보다는 vanila javascript를 잘 사용할수 있는지가 중요했던거같아요.

    현재는 jQuery를 좋아하시고 즐겨 쓰시던 분들이 어떤 생각을 하실지 정말 궁금해지네요!
    조금 공격적인 피드백도 있었지만, 이런 피드백들이 모여 더 좋은 방향으로 나아가는거 같아 괜히 기분이 좋습니다 !

  • 밍밍
    응답

    글부터 댓글까지.. 아 지금은 이렇게 많이 바꼈는데 당시에는 그랬구나 하고 보는 재미가 있네요.

  • devLee
    응답

    지금까지 약 15년간 프로젝트 진행한 개발자입니다. 신기술이 나오면 공부도 하고 해서 채워나가는 사람인데요. 과거를 비추어보면 표준이라는 기준이 계속 바뀐다고 생각합니다. 전 반대로 생각해보면 jquery라는게 다른 스크립트가 생기고 사라짐에 있어서 왜 오래 존재했는가에 초점을 둔다면 그만한 이유가 있습니다. openjs.org에서는 왜 계속 버전업해서 나오고 있는가.. 오히려 fetch api같은 경우 브라우저가 변경되면 문법이 바뀌든 소스를 다 고쳐야할 거라 생각되구요. 특정 브라우저, 특정 업체의 api를 사용하는게 장기적으론 좋은방법은 아닙니다. 그래서 개인적으론 모바일 쪽 보단 웹개발을 좋아합니다. es6에서 혹 구브라우저 버전 지원시 babel이란걸 이용해서 es5로 변경하는 단점이 있죠. 어떤분들은 신규브라우저만 쓰면 되는거 아니냐고 얘기하시는분은 실제 프로젝트 환경을 모르시는붘입니다. jquery는 버전업이되면서 계속 개선되어가는 형태입니다. 웹표준이라는게 그 시점에 따른 기준이란거란 얘기를 드리고 싶네요. jquery가 아직 전세계 사용률3위 라는걸 아시는지요. 기술들의 장단점은 분명 존재하지만.. jquery가 2007년부터 지금까지 사용하는데 있어서 꽤 오래이어져온 걸 보면 알수있습니다. jquery가 자바스크립트가 아니란 얘긴 동의하지 않습니다. jquery의 모든 파일 확장자는 .js입니다. .js는 대부분의 뿌리기술은 자바스크립트이고, 그것을 좀더 편하게 사용하고, 크로스브라우징, 멀티플랫폼에 대응되면서 버전업이 된 것입니다. 표준으로 나온 es6를 무시하는건 아닙니다. 각각의 장단점이 있다는 겁니다. 이렇게 오래 이어져온 자바스크립트기반의 js중 하나가 jquery라는 점을 말씀드리고싶네요. 새로운기술을 그시점에 적용한다고 그게 항상좋은 형태는 아니고, 다양한 시각과 다양한시점에서 봐야 그 기술을 더욱 활용가능하다고 생각이드네요.

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. captcha txt

Start typing and press Enter to search