이제와서 jQuery를 쓰면 안되는 이유, 혹은 jQuery와 웹개발의 역사

 In Programming

TL;DR

jQuery는 DOM을 직접 다루는 기능이 너무 많기 때문에 안티패턴의 위험이 높다. jQuery를 쓰는 것자체가 나쁜 건 아니지만 좋은 개발을 위해선 위험한 기능은 쓰지 않도록 강제해야 한다.

 

올해로 jQuery가 나온지 10년이 되었습니다. 나올때부터 인기있던 jQuery지만 현재도 탑 밀리언 사이트 내의 이용율이 78%나 될 정도로 시장을 평정하고 있는 것은 놀라운 일입니다. 이런 인기의 비결은 무엇일까요? 작년 5월 jQuery 창시자인 존 레식은 트위터에서 이렇게 이야기했습니다.

이런 말 하는게 슬프지만 jQuery가 javascript를 대체하지는 않는다.  jQuery가 성공한 것은 DOM이 문제가 많다는 증거일 뿐이다. 원문 링크

프론트엔드 개발의 현재 상황에 대한 상당히 의미심장한 이야기이죠. 이 말의 의미를 제대로 이해하기 위해서 10년도 더 된 고릿적 이야기를 한 번 꺼내보겠습니다.

1990년대 웹개발에는 javascript가 나설 자리가 없었습니다. javascript의 기능자체도 별게 없었지만, 깔끔하게 정리된 문서도 없었고, 시장을 양분하고 있던 Netscape과 IE의 DOM구조가 완전히 달랐기 때문에 하나의 기능을 위해서 두번의 스크립트 개발이 필요했습니다. 이런 사정이 나아진 것은 Netscape가 완전히 망가진 2003년도 전후로 Windows XP와 IE6가 세상을 통일하기 시작하면서부터였습니다. 성능 좋은 브라우저가 시장을 독점하니 암흑의 시기가 끝나고 드디어 스크립트의 전성기가 열렸습니다. 2004년 말에 AJAX기능을 위시한 Web 2.0의 논의가 시작된 것도 그런 흐름 때문이였습니다.

Web 2.0의 유행을 타고 2005년 전후로 다양한 javascript 프레임웍이 출현했습니다. prototype, script.aculo.us, dojo등등.. 당시의 프레임웍은 DOM을 확장하고,  prototype을 이용해 타 언어의 class를 흉내내려하는 경우가 많았습니다. 그러한 방식은 자바스크립트를 좀 더 자바처럼 보이게 해주었습니다. 지금은 잘 이해가 안가겠지만 그땐 그게 쿨했습니다.

한편 Netscape의 후신인 파이어폭스가 2004년 말에 출시되었습니다. 휴식기간이 길었음에도 MS가 열심히 삽질을 해준 덕분에 파이어폭스의 기능과 성능은 IE를 월등히 뛰어넘었고 사용자들은 열광했습니다. MS입장에서 보자면 삽질할 만한 어쩔수 없는 이유가 있었지만, 그 덕분에 브라우저 시장의 유일한 지배자가 될 기회를 영원히 놓치고 말았습니다. 덕분에 다시 혼돈의 카오스가 열리게 됩니다.

2006년에 파이어폭스의 애드온으로 등장한 firebug덕분에 프론트엔드 개발은 정말이지 거대한 패러다임의 변화를 맞이했습니다. 과거에는 코드 내에 document.write나 alert를 넣는 매우 원시적인 방식으로 디버깅을 했었는데, firebug의 등장으로 한번에 상황이 바뀌게 되었습니다.(무려 console.log라니!) 덕분에 마이너했던 파이어폭스가 사이트 개발 할 때는 메인 브라우저가 되었고, IE는 출시전 테스트 단계에서만 쓰이는 찬밥 신세가 되었습니다. 그러면서 자연스럽게 웹표준을 준수하는 브라우저와 IE의 괴리가 문제가 되기 시작했습니다.

IE와 파폭은 DOM 구조가 달랐고, 기존의 프레임웍으로는 모듈화 하기가 쉽지 않았습니다. 하나의 브라우저가 시장을 지배하는 구조가 끝났기 때문에 다양한 문제가 파생했습니다. IE6가 만들었던 2003~2005년의 짧은 평화는 깨졌습니다. 이런 시대적 배경 속에 드디어 jQuery가 등장합니다. DOM을 추상화해서 관리해 주는데다, 깔끔한 플러그인 방식을 지원했기 때문에 jQuery는 나오자마자 선풍적인 인기를 끌었습니다.

2006년에 프론트엔드의 혁명이 시작되었다면, 2007년은  jQuery, 파이어폭스, Firebug가 적극적으로 시장을 넓혀가는 와중에 IE7이 삽질하고 있는 상황으로 요약할 수 있겠습니다. 2008년부터는 애플의 사파리와 구글의 크롬이 등장하면서 본격적인 브라우저 춘추전국시대로 돌입합니다. 그리고 그 즈음 iPhone으로 인해 모바일의 시대가 열리고 브라우저 파편화는 더욱 가속화 되어 현재까지 이어집니다. 2000년대 후반 jQuery가 지원하는 브라우저는 Nightly Build버전을 포함해서 11개 였는데, 요즘은 최소 30여개 이상입니다.

이렇게 생각할수도 있겠습니다. 브라우저가 파편화되더라도 표준만 제대로 지키면 문제없지 않겠느냐고요. 네, 이론적으로는 그렇습니다만 새로운 브라우저는 예외없이 새로운 문제를 만들었습니다. 이런 상황에서 jQuery가 업계 표준이 된 것은 당연합니다. 물론 jQuery만으로 모든 cross-browser문제가 해결 되는 것은 아니지만 jQuery없이 개발하는 건 상상하기 힘든 일입니다.

처음으로 돌아가서 존 레식의 이야기는 이런 의미입니다. 요즘 사람들은 브라우저의 파편화가 보편화된 시대에 살고 있고, DOM이 제대로 동작한다는 것을 믿을 수 없기 때문에 일상적으로 jQuery를 씁니다. jQuery의 개발 방법론이 좋아서가 아니구요. 이미 시대는 jQuery의 패러다임을 뛰어 넘었습니다. Babel을 통해 ES6가 현실화 되었고, MVC패턴과 two-way binding이 일상화 되었고, node.js로 서버도 만들고, 심지어 atom에디터같은 데스크탑 어플도 만들수 있는 시대가 되었습니다.

그런데 시대가 바뀌었음에도 jQuery만 하면 자바스크립트를 왠만큼 하는 것 처럼 생각하시는 분들이 많이 있습니다. 이미 jQuery가 제공하는 개발 방법론은 낡았는데 그대로 쓰시는 분들이 너무 많습니다. 예를 들면 .closest()같은게 대표적입니다. 박스를 만들고 그 중에 하나를 클릭하면 상위 엘리먼트에 클래스를 지정하는 경우를 가정해 봅시다.

<div class="box">
<ul>
  <li><a href="#dog" class="item">Dog</a></li>
  ...
</ul>
</div>

li를 클릭하면 상위 div에 class를 추가하는 스크립트를 .closest()를 이용해서 만들어 봅니다. 박스가 한 페이지에 여러 개 들어갈수도 있으니 each를 써서 이벤트를 지정해야합니다.

$("div.box").each(function(){
  var $items = $(this).find("li a.item");
  $items.on("click", function(e){
    var $this = $(this);
    $this.closest("div").removeClass().addClass($this.text().toLowerCase());
  });
})

여기서부터 문제가 생깁니다. javascript 코드에.closest(“div”)가 갑툭튀하는데, 이것만 봐서는 무슨 의미인지 알수가 없습니다. 실제로 html태그를 확인해야 하는데, 그러기위해선 크롬 디버그 창을 열고 해당 엘리먼트를 선택한 후 Source화면에서 하나씩 위로 올라가봐야 합니다.

스크립트 개발이 다 끝나고 나니, 애니메이션을 위해 여분의 div를 넣자는 의견이 나옵니다.

<div class="box">
<ul>
  <li><div class="anim"><a href="#dog" class="item">Dog</a></div></li>
  ...
</ul>
</div>

이렇게 되면 javascript는 전혀 건드리지 않고 html만 수정했는데, 프로그램이 동작하지 않습니다. jQuery가 DOM을 다루는데 스페셜리스트인 것은 좋은데, 이런 기능은 View와 Controller를 연동시키기때문에 안티 MVC패턴을 만듭니다. 역사가 10년이나 된 jQuery에는 안타깝게도 이런 식의 DOM을 다루는 스페셜한 기능이 너무나 많습니다. 그리고 이런 기능을 사용한 후에 자기는 jQuery 좀 할 줄 안다고 어깨를 으쓱대는 사람들도 많습니다.

※참고로 위의 코드는 이런 식으로 재작성이 가능합니다.

$("div.box").each(function(){
  var $box = $(this);
  $box.find("li a.item").on("click", function(e){
    $box.removeClass().addClass(this.href.replace(/.*#/, ""));
  });
})

2016년이 되면서 IE 10이하의 브라우저의 대응이 끝났습니다. 현장에서는 IE8이 대응리스트에서 사라지고 있는 중이고, 당장 저부터 다음 프로젝트에는 대응할 생각이 없습니다. 게다가 IE11을 제외한 모든 브라우저가 에버그린 업데이트를 지원하기 시작했기때문에 브라우저 파편화 문제는 많이 해결되는 추세입니다. 올해 말이면 더욱 더 좋아져 있겠죠.  jQuery가 단기간에 대체되지는 않겠지만, 앞으로는 점점 jQuery에 의존할 필요가 없어질 것입니다.

앞으로는 부작용없이 최소한의 기능만을 빌린 jqLite, bliss.js, u.js 등을 이용한 개발이나, ES6 스타일로 개발하는 것도 유망해 질 듯합니다. 복잡다단했던 웹 업계에 jQuery중독에서 벗어날 시기가 찾아온 것입니다.

 

P.S. 방문하시는 분들이 많아서 2부를 작성해봤습니다.

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

 

Recent Posts
Showing 22 comments
  • 이명성
    응답

    좋은 글 잘 봤습니다. ^^

  • 나그네
    응답

    좋은 글이네요. ^^

  • Pixel
    응답

    제목과 내용이 상이하군요.
    제목은 마치 문제가 엄청나 쓰지말아야될거 처럼써놓고
    내용은 의존할 필요가 없어졌다라니.

    뭔가 사기당한 느낌이군요.

    내용과 맞는 제목이라면
    “이제는 더 이상 jQuery에 의존할 필요없다. jQuery와 웹 개발의 역사”가 더 나을거 같습니다.

    • 박 종희
      응답

      제 주장은 jQuery에 있는 쓸데 없는 DOM관련 함수들은 될 수 있으면 쓰지말자입니다. 현실적으로 프로젝트를 하는데 있어서 아직도 IE대응을 요청하는 곳들이 있는데다 기존의 라이브러리가 jQuery에 의존하는 경우가 많아서 당분간은 안쓸수는 없는 상황이거든요. 가급적 줄여나가다가 나중에 완전히 없애는게 좋겠죠.

  • Shawn
    응답

    이런저런 문제를 떠나 저는 jQuery는 자바스크립트를 쉽게 쓸수있도록 해주는 라이브러리로 평가하고 있습니다.
    완벽한 표준화가 이루어진다해도 쉽게 사용할 수 있다는건 다른 이야기라 봅니다.
    예를들어 ajax를 구현하더라도 순수 자바스크립트로 짜는것과 작성하는 코드레벨자체가 다르니까요.
    WinAPI 와 MFC 의 차이로 본다고나 할까요. 예시로 든 closest함수는 글쎄요..
    저도 거의 안쓰는 함수지만 그냥 closest(‘div.box’)로 꼼꼼하게 써도 될 것 같은데..
    개발자가 요즘 패턴에 안맞는다면 안쓰면 그만이고 그렇다고 이런 류의 함수가 없어야하나 그것도 생각해볼 문제입니다.
    PHP와 마찬가지 아닐까요? MVC가 진리도 아니고 왠만큼 구식으로 짜는 사람도 커버를 해주잖아요.
    그리고 쉽게 검색해서 찾아쓸 수 있는 jQuery기반의 수많은 라이브러리도 무시할수없구요.
    물론 jquery만 쓰는 개발자를 저는 싫어합니다. 이것저것 갖다붙여 구현만 해놓고 결과물의 퀄리티는 대체로 안좋거든요.
    그런데 그런 개발자는 보통 다른걸 쥐어줘도 마찬가지인 경우가 많은것 같아요. ^^
    jQuery는 사라지지않을것이고 다만 동일한 레벨의 다른 쉬운 라이브러리로 대체될순 있다..는게 제생각입니다.

    • 박 종희
      응답

      저는 jQuery가 사라질 것이라는 입장이고 동일한 레벨의 라이브러리로 교체될 것이라는데 회의적입니다. ajax의 예를 들자면 ES6 fetch를 이용하면 순수한 자바스크립트로도 별 문제없이 작성이 가능합니다. 브라우저의 기능이 비약적으로 상승하고 polyfill이 자연스러워진 지금, jQuery의 대부분의 기능이 Vanilla Javascript로 대체가 가능한데, event.namespace와 Event Delegation은 대체가 어렵습니다. 범용 플러그인을 만들때 아주 유용한 기능이고 거의 없어서는 안된다고도 할수 있습니다. 그런데 요즘의 자바스크립트계는 전부 Component중심이라서 jQuery에서 제공하는 레벨보다 좀 더 고차원적으로 Event Handling이 가능해졌습니다. 이런 상황에서 jQuery를 계속 가져간다는 건 별 의미가 없지 않을까 합니다.

      • Shawn
        응답

        대체가능하다와 대체될것이라는건 다른 이야기란것이구요. 관점을 조금 바꿔서 다시 설명드릴게요.
        결국 이것을 주도하는것은 표준화인데 현실세계에선 완벽한 표준화는 불가능합니다. 권고안일뿐이니 브라우저 개발사들의 이해관계에 따라
        표준화에 반대하기도하고 지원하지 않기도 합니다. 대표적인게 비디오파일 재생포멧이죠. 따라서 언제나 예외상황이라는게 생길수밖에 없죠.
        그래서 반복적인 예외처리를 하는것보단 jquery 레벨의 추가 라이브러리를 도입하게 된다는 이야기입니다.
        그리고 결국 사이트개발이라는건 클라이언트 중심이라 아무리 새로운 기술을 도입하고 멋진 코드를 작성한다해도
        1% 의 점유율의 예외라고 해도 그게 고객의 책상위에 있으면 전부라는 말입니다.
        어짜피 버려야하는 브라우저는 분명있지만 그걸 가장 느리게 정리해주는게 jquery 정도밖에 없더군요.

        다시 개발난이도로 돌아가면..
        특정언어를 계속 쓰게되면 반복적으로 만들게되는 function 라이브러리가 생깁니다. 이런게 모이고 모여서 프레임웍이되는것이고 라이브러리가 되는거죠.
        작성하기 어려워서 쓰는 경우도 있지만 귀찮아서 쓰는 경우도 많은거죠. 동일한 레벨의 라이브러리라는건 이런 얘기입니다. 말씀하신대로라면 component 중심의
        새로운 라이브러리가 나와서 엄청난 유행이라는 운을 맞아야 jQuery를 밀어내는 것이지 javascript 레벨로 회귀하는일은 없을거란 이야기입니다.

        • 박 종희
          응답

          요즘은 node.js로 환경을 구축하기 때문에 왠만큼 복잡한 앱이라해도 Vanilla Javascript만으로 충분히 만들 수 있습니다. 예전에 Backbone + Handlebar로 작업한 앱을 표준 ES6로 재작성하고 rollup.js로 번들링했더니 훨씬 보기 쉽고 빠르고 편하더군요. node.js는 어차피 클라이언트하고는 상관없으니까 언제든 도입이 가능합니다. 가능하면 표준을 따르는게 가장 좋은 개발 방식이 아닐까합니다.

          IE8만 제외하면 사실상 jQuery의 방식으로 개발하지 않아도 별 문제 없다고 봅니다. Vista쓰는 사람이 없는데다 Windows7부터는 IE11을 지원하니까요. 몇년전만해도 mobile safari의 버그라던가 android 2.x대, 4.x초반대의 버그가 심각했는데 단말이 빨리 바뀌면서 지금은 예전같은 파편화 문제는 거의 사라졌습니다. 말씀하신 것처럼 비디오파일 재생 포맷 문제같은 새로운 파편화 문제는 계속 나오고 있습니다만, 그런 문제는 jQuery로(혹은 어떤 특정한 만능 라이브러리로) 해결될 문제는 아니라고 봅니다. 매번 문제가 달라지니 프론트엔드 개발자가 원인을 찾아서 케바케로 해결하게 되는 상황이니까요.

          어쨌든 jQuery를 쓴다하더라도 DOM에 대해 직접적으로 다루지만 않으면 부작용은 줄일 수 있습니다. jQuery가 필요하면 써야죠. 다만 DOM이 Global이고 안티패턴이라는 사실을 숙지하고 개발을 해야겠죠.

  • M
    응답

    대표적으로 이야기 해주신 closest()를 많이 사용하고 있는 개발자 입니다.

    왠지 낡은 방식을 그대로 쓰고 있다는 이야기에 ‘잉?’ 하는 생각으로 말씀해주신 예제 코드를 보았는데..
    해당 예제는 DOM 구조에 의존적인 자바스크립트를 짰기 때문에 나온 코드가 아닌가.. 라는 생각이 드네요.
    저 같은 경우는 data 속성을 이용하여 감싸고 있는 혹은 타겟으로 하는 영역을 명확하게 명시하는 방법으로 사용하고 있습니다.

    저도 jQuery 의존적인 문제에 대해서 공감하고 있지만
    사용하는 기능이 낡았다라는 것에 대해서는.. 조금 충격이네요.
    갑자기 최근 만들었던 모든 소스에 대해 다시 고민하게 만드는군요..

    jQuery가 아닌 다른 라이브러리도 충분히 많이 나올꺼란 생각도 합니다만
    아직까지 하위 브라우저나 크로스브라우저 대응에 대해서는 뚜렷한 해결책은 없어보입니다.

    • 박 종희
      응답

      Front개발에서 DOM은 항상 바뀝니다. 그래서 DOM을 직접 다루다보면 문제가 생길수 밖에 없습니다. 이제는 Component 방식이 대세입니다. 말씀하신 data속성을 이용하는것도 좋은 패턴이 아닙니다. 왜냐면 값이 global한데다 데이터와 코드가 연결이 안되서 말이죠. 작은 규모의 프로젝트라면 상관없을텐데 복잡한 어플을 작성하게되면 문제가 생깁니다. 서버개발쪽에서는 global을 거의 안쓰는데, 프론트쪽에서는 global이 왜 안좋은지에 대한 논의자체도 별로 없습니다. 매우 안좋은 패턴인데 이에 대해서는 추후에 다시 포스팅을 하겠습니다.

      하위브라우저나 크로스브라우저는 사실 요즘 같은 상황에서는 점점 대응이 필요없어지는 상황입니다. dom4같은 polyfill라이브러리를 쓰면 IE9이상에선 별 문제가 없습니다. 굳이 IE8을 지원해야 한다면 이야기가 달라지지만 한국에서도 IE8 점유율이 상당히 낮은 상황입니다. 제가 운영하는 사이트에서 IE8의 점유율은 현재 0.5%정도 됩니다. 요즘 튀어나오는 크로스브라우저의 골때리는 버그는 jQuery레벨에서 해결이 되는 문제가 아닌 경우가 대부분입니다. 특히 iOS Safari는 제2의 IE라 불러도 손색이 없을 정도입니다. 저의 경우 앞으로의 프로젝트에서는 적극적으로 jQuery를 배제할 생각입니다.

      • M
        응답

        말씀해주신대로 component 방식으로 모든 페이지가 변환된다면 맞을꺼 같은데..
        프로젝트 특성상 그렇게 모두 전환하지 못했던 부분이 있긴 합니다.

        하위브라우저나 크로스브라우저에 대해서 대응이 필요 없다는 부분은 고객 위주의 서비스에서는 불가피한 선택일듯 합니다.
        아직도 고객사에서 xp에서 화면이 왜 안나오냐는 이야기를 할때마다 답답한 마음이 풀리지 않습니다.
        (크롬도 더이상 xp 설치를 지원하지도 않는다는 사실 자체, 설득이 안됩니다..)

        global에 대한 부분도 공감합니다.

        어느 부분이 맞다 틀리다로 끝나는 것이 아니라 많은 논의가 필요하고
        선택하여 나가야할 부분들이 많은 것 같습니다.

        좋은 말씀 감사합니다.

      • SJ
        응답

        0.5퍼센트밖에 되지 않으면 포기해도 되는건가요?? 중요한건 대세인지 jQuery가 구린지를 이야기하는게 아니라 정상적으로 동작하는 코드를 만드는것이 가장 중요한 프로그래머의 덕목입니다. 최신기술을 쓰기위해서 사용자가 익숙한 브라우저를 변경하도록 강요하는것은 맞지 않다고 봐요.

        오래된 브라우저를 사용하시는 그분들 역시 중요한 사용자이고, 역으로 우리가 그러한 사용자로써의 입장이기도 합니다. 예를들어 대부분의 맥 사용자가 은행사이트를 들어갈때 괴롭힘당하는것처럼요. 말씀하신대로 jQuery에는 DOM을 지나치게 다루는 등의 문제가 많다는것은 맞습니다. 하지만 더욱 중요한건 최신브라우저 최신기능이 아니라, 정상적으로 돌아가는 기능을 프로그래머는 가장 중요하게 여겨야 한다는것을 이야기하고 싶어서 조심스럽게 댓글을 답니다.

        • 박 종희
          응답

          최신기술을 쓸수록 단가가 내려가고 더 좋은 서비스를 제공할수 있습니다. 예를 들면 최신 브라우저에서는 스크롤이 따로 쓰레드로 적용되는데 IE에서는 그렇지 않습니다. IE에서 패럴렉스 사이트를 한 번 만들어보시면 그 높은 난이도와 낮은 퀄리티에 놀라실껍니다. 게다가 테스트해야 할 페이지와 단말이 늘어날수록 장비를 사고 테스터를 고용하는데 드는 비용이 증가합니다. 그러므로 점유율이 낮은 브라우저의 지원은 기술의 문제라기 보단 그만큼 가치가 있는지 그 가치에 누가 돈을 쓸 것인지의 문제입니다. (그리고 오래된 브라우저의 사용자는 돈을 잘 안쓰는 편이라서 생각보다 중요하지 않다는 문제도 있습니다.)

          IT대기업의 경우는 점유율이 낮은 브라우저도 지원하지만 일반적인 IT 회사에서는 최소한의 기능으로 돌아가도록 만듭니다. 아주 화려한 기능을 넣는게 아니면 97~8% 정도는 커버합니다. 그런데 맥에서 은행 사이트에 들어가는 문제는 좀 더 복잡합니다. 정부 정책과 금융기관 내부의 의지와 관련이 있는데, 이건 점유율의 문제도 아니고 개발로 어떻게 할 수 있는 문제도 아닙니다. 심지어 카카오뱅크도 모바일 전용이니까요.

          세상엔 개발만으로 해결이 불가능한 문제가 많기에 오픈소스가 인기인 것입니다. 정부에서 강제하는 소프트웨어도 전부 오픈소스로 바꾸면 사정이 좋아지지 않을까요?

          • 땔감

            2017년만 해도 jquery가 괜찮다는 사람들이 이리 많았군요
            어떤식으로든 개발자가 실수하기 쉬운 도구는 쓰지 않는게 좋죠

  • 마이구미
    응답

    좋은 글이네요.
    글보다 댓글이 더 많은 것을 담고 있네요 ^^
    저도 jQuery가 사라질 것이라는 입장이여서… 많은 공감 얻고 갑니다~

  • 김형준
    응답

    jQuery, 저 역시 사라질 것이라는 입장에 동감합니다.

  • 김형준
    응답

    jQuery가 사라질 것이라고 생각하는 이유는…
    오히려 jQuery를 이용한 API가 순수한 DOM API나 JS 코드를 사용한 코드보다 더 복잡하고 이해하기 어렵다는 생각이 많이 들었기 때문입니다.
    jQuery의 원저작자도 언급했듯이.. jQuery는 과거 불안전한 DOM 기술을 대체하기 위한 임시방편이라는 입장에 절대적으로 동감합니다.
    지금의 웹기술은 과거의 불안전했던 많은 것들이 상당히 개선된 상태이고, 더욱 개선될 것입니다.
    이러한 상황에서 jQuery는 새롭게 시작되는 개발 프로젝트에서는 사용될 이유가 없겠죠..
    자신이 가진 기술에 대한 사랑과 고집보다는 새로운 기술에 대한 수용과 배움이 개발자의 더 나은 미덕이 아닌가 싶습니다.

  • 자스
    응답

    저도 코드가 이상해서생긴 문제지 제이쿼리의 문제는 아니라고생각하네요

  • Kurien
    응답

    적어주신 코드는 DOM 에 의존적인 코드가 문제입니다만, 이런 코드는 ECMAScript6을 써도 똑같은 현상이 발생할 수 있는 문제입니다.
    웹을 떠나서 어떤 프로그램에서든 의존적인 코드는 문제로 다루어지구요.

    의존적인 코드 때문에 jQuery를 쓰지 말아야한다?
    그럼 다른 프로그램에서도 의존적인 코드가 쓰일 수 있는데, 제가 보기엔 결국 프로그래밍 자체를 하지 말라는 것처럼 보여집니다.

    결국 코드를 작성하는 사람의 역량의 문제이며 위와 같은 현상을 jQuery 자체에서 제어할 수는 있겠지만 그렇게 되면 지금의 자유로운 jQuery의 느낌을 없애버릴 수 있을 것 같다고 보여집니다.

    결론적으로 말씀 하신 부분은 문제 자체에 오류가 있으며, 해당 문제가 있다고 한들 jQuery로 얻는 이점이 월등히 크다고 봅니다.
    제 생각에는 당장 jQuery가 사라질 일은 없을 것으로 보이네요.

    • 박 종희
      응답

      말씀하신대로 es6로도 같은 문제가 있을수 있고, jQuery가 당장 사라질 일도 없습니다. 다만 jQuery의 목표가 DOM을 더 잘 다루는데 있고, 점점 DOM을 직접 다룰 필요가 없어지기 때문에 jQuery의 존재 이유가 사라지는 것도 사실입니다. Evergreen한 브라우저 환경에서 좀 더 도전적인 개발을 하기 위해서 jQuery의 방법론에서 벗어날 필요가 있다고 봅니다. 실제로 2017년 들어서 IE의 점유율이 많이 줄기도 했구요.

  • benant
    응답

    예전에 Web 2.0이 한창일때 어느 세미나에서 화자가 이런말을 했던걸로 기억합니다. “AJAX가 나온건 Firefox가 지원해서다.”. 저는 그때 이런 생각이였었지요. “잉? IE는 이미 있었던걸 Firefox가 이제서야 늦게 지원하기시작했는데 Firefox때문이라고?” 그런데 결국에는 당시 유명한 2개의 브라우저에서 모두 AJAX 구현이 가능해 지면서 시작된것이니 더 태클걸 필요는 없었지요.

    위 본문에 쓰신 “… 성능 좋은 브라우저가 시장을 독점하니 암흑의 시기가 끝나고 드디어 스크립트의 전성기가 열렸습니다. 2004년 말에 AJAX기능을 위시한 Web 2.0의 논의가 시작된 것도 그런 흐름 때문이였습니다.” 이글에 반대 하시는 분들이 좀있겠네요. ㅎㅎㅎ IE는 이미 AJAX구현이 가능했지만 그걸 많은 개발자들이 알았지만 안쓰고 있었어요. 왜? IE만 되니까. 였습니다. 헛. 음… 그런데 한국 개발자들은 왜 안쓰고 있었는지 갑자기 궁금해지네요

    저처럼 몰라서 그랬나? 아닌데 MSDN 문서 보시며 하던분들은 아셨을건데 … ????

    아! 그분들은 Javascript쪽은 처다도 않봤지. ㅎㅎㅎ

    이상 줄이겠습니다. 글 잘보고 갑니다.

  • DD(먹는 것만 좋아하는 사람)
    응답

    3년 전 작성된 글을 우연히 들어와서 보다보니 마치 요리사와 음식, 그리고 음식점을 평가하는 요리 평론가가 떠오르게 만드는 군요. ^^

    2편의 글까지 생각해도 2년이 지난 지금 이 글+댓글 들을 쓰신 분들은 현재 시점에서 어떤 평들을 다시 할까 궁금해지기도 하구요.

    어느 분야에서든 평론가는 필요하다고 생각합니다. 당연히 그들의 평론은 개발자에게 좋은 자극이 될 수도 있구요. 그런데 제가 생각하는 진정 개발자는 평론에 의존하기보단 새로운 생각과 이를 뒷받침해주는 열정을 가지고 새로운 시도를 하고 거기서 새로운 창조를 합니다. <— 이점이 요리 평론가들만 아무리 많이 모여도 새로운 맛의 맛있는 음식이 만들어 지지 않는 이유기도 하구요. ^^

    어서 우리나라에서도 새로운 라이브러리든 아니면 프레임워크든 마치 요리 평론가와 평론만이 아닌 진정 독창성을 가진 요리를 만들어는 요리사와 같은 개발자들이 보다 많이 생기기를 기원해봅니다.(물론 이것도 그런 개발자를 잉태할 수 있는 사회 환경이 구축되어야 하긴 하지만요…)

    아무튼 여러모로 좋은 자극을 받아가게 되어 감사합니다. ^^

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