10주년을 맞는 jQuery 의 미래는?

§

2006년 8월말, John Resig 은 jQuery 를 세상에 내놓습니다. 그리고 바로 몇주뒤 MooTools 도 출시 됩니다.

둘다 DOM manipulation (AJAX 같은 기능들) 을 간편하게 구사할 수 있게 해주는 javascript library 라는 점에서 같은 기능을 가진 제품이지만, MooTools 는 OO (ojbect-oriented) 라는 점에서 jQuery 보다 더 근대적이고, 효율적인 library 라는 점을 강조했습니다.

jquery-mootools

물론 저는 초창기부터 MooTools 보다 jQuery 를 선호하고 더 친근감을 느꼈습니다. 그 이유는 jQuery 가 사용하기 더 간편하고 쉬웠기 때문입니다. (OO 개념도 제대로 잘 모르는데, OO 고 개뿔이고 일단 사용하기 편한게 최고 아니겠습니까? ㅋㅋㅋ)

이런면에서 jQuery 와 워드프레스는 많이 닮아 있습니다. 프로그래밍적으로 OO 같은 최첨단 개념을 사용하는 제품이 아니지만, 일단 사용자가 사용하기 쉽다는 점에서 말이죠. 웹의 오랜 추세를 보면 이런 사용하기 쉽고 친숙해지기 쉬운 제품들이 널리 애용된다는 사실을 잘 알 수 있습니다.

그래서 근대 웹에서 jQuery 는 무려 65%의 점유율을 유지하고 있습니다. 워드프레스가 CMS 시장에서 대략 69%의 시장점유율을 유지하고 있는 것 만큼 jQuery 의 웹시장 점유율은 독보적입니다. 마소의 .NET (Visual Studio 에 포함되서 .NET 플젝에 활용됩니다.) 부터 시작해서 대형 사이트에는 예외없이 jQuery 가 사용되고 있습니다.

jQuery 가 출시될 당시 javascript 을 제대로 이해하고 스크립팅 할줄 아는 개발자는 많지 않았습니다.

그 이유는 당시 javascript 는 element 의 class 를 바꾸는 기본적인 코딩 하나를 하기 위해 규식씨 (정규식) 까지 불러와야 하는, 스크립팅 하기가 몹시 난해하고 복잡한 언어였기 때문입니다. (많은 수 의 front-end 개발자들이 이해도 못하면서 그냥 ctrl+c,v 하는 수준이었던거죠.)

도대체 친해지기 힘든 정규식씨
도대체 친해지기 힘든 정규식씨 도대체 친해지기 힘든 정규식씨

그 예를 하나 보시죠. jQuery 가 출시되기 전까지는 div 의 class 하나를 더해주기 위해 이렇게 황당한 코딩을 해야했던 것 입니다.


function hasClass(ele,cls) {
	return ele.className.match(new RegExp('(\\s|^)'+cls+'(\\s|$)'));
}
 
function addClass(ele,cls) {
	if (!this.hasClass(ele,cls)) ele.className += " "+cls;
}
 
function removeClass(ele,cls) {
	if (hasClass(ele,cls)) {
    	var reg = new RegExp('(\\s|^)'+cls+'(\\s|$)');
		ele.className=ele.className.replace(reg,' ');
	}
}

저는 지금도 정규식씨랑 안친합니다. 정규식씨를 잘 모릅니다. 다행이 jQuery 때문에 정규식씨를 이해하지 못해도 코딩하는데 아무런 불편이 없었습니다. 왜냐하면 jQuery 에서 div 의 class 를 더해주는건, 이렇게 한줄로 가능하기 때문입니다.

$("#div").addClass('newClass');

정규식씨고 뭐고, javascript syntax 도 몰라도 어떤 코딩도 가능하게 만들어주는. 이래서 jQuery 는 정말 javascript 에 혁명에 가까운 제품이었습니다.

Ajax 예를 하나 보여드릴까요? 이게 예전에 Ajax 하던 방식 입니다.


load('test.txt', function(xhr) {
    document.getElementById('container').innerHTML = xhr.responseText;
});
 
function load(url, callback) {
        var xhr;
         
        if(typeof XMLHttpRequest !== 'undefined') xhr = new XMLHttpRequest();
        else {
            var versions = ["MSXML2.XmlHttp.5.0", 
                            "MSXML2.XmlHttp.4.0",
                            "MSXML2.XmlHttp.3.0", 
                            "MSXML2.XmlHttp.2.0",
                            "Microsoft.XmlHttp"]
 
             for(var i = 0, len = versions.length; i < len; i++) {
                try {
                    xhr = new ActiveXObject(versions[i]);
                    break;
                }
                catch(e){}
             } // end for
        }
         
        xhr.onreadystatechange = ensureReadiness;
         
        function ensureReadiness() {
            if(xhr.readyState < 4) {
                return;
            }
             
            if(xhr.status !== 200) {
                return;
            }
 
            // all is well  
            if(xhr.readyState === 4) {
                callback(xhr);
            }           
        }
         
        xhr.open('GET', url, true);
        xhr.send('');
    }

이걸 jQuery 로 하면?

$('#container').load('test.txt');

헐!! 진짜 헐 소리 나올정도로 jQuery 는 javascript 코딩을 혁명적으로 간편하게 만들어 준 제품 입니다.

그런데 최근 추세가, 이 jQuery 를 버리는 플젝들이 늘어나고 있습니다. 브라우져들이 (특히 IE) 근대화 되고, jQuery 에서 모티브를 얻은 Web API 들이 출현했기 때문입니다.

다시 div 에 class 를 더하는 예를 이 Web API 중 하나인 Element.classList 를 통해 어떻게 코딩 되는지 보여드리겠습니다.

div.classList.add("another-class");

ㅋㅋㅋ 개간단하죠? jQuery 와 비교해서 절대 더 복잡하지 않습니다.

저같은 경우, 이제 워드프레스 테마 정도는 jQuery 를 사용하지 않고 순수 javascript (바닐라 javascript 라고 합니다.) 만으로 구축이 가능합니다. (제 코딩실력이 발전하게 아니라 Web API 의 힘 인거죠.)

물론 아직도 순수 javascript 만을 사용하기에는 몇가지 문제점과 제약들이 존재합니다.

첫번째, 브라우져 지원입니다. (or lack thereof)

제가 예를 든 Element.classList 같은 경우, IE 11 이하에서는 지원도 되지 않고, IE11 에서도 지원이 제약적 입니다.

http://caniuse.com/#feat=classlist

항상 IE 가 말썽이죠. 그런데 왜 이런 사실이 전혀 놀랍지 않을까요? ㅋㅋㅋㅋ

두번째, 어마어마한 양의 기존 jQuery 플러그인들을 대체하기 어렵다는 것 입니다. 워드프레스의 예를 들면, lazy loading 같은 플러그인들이 전부다 jQuery 에 의존하고 있습니다. jQuery 를 사용하지 않으니, 당연히 이런 플러그인들이 먹통이 되고, 유일한 해결방법은, 직접 이 플러그인들을 제작해서 사용하는 것 입니다. (이래서 얼마전 저는 lazy loading 스크립트를 직접 제작해야 하기도 했습니다. 플러그인 하나까지도 완전히 홀로서기를 해야 하는데, 이게 심적으로도, 시간적으로도 많이 어렵습니다.

결국 새로운 플젝을 계획할때, jQuery 를 버릴려면 각 브라우져들의 지원여부와 대체해야 하는 기능들을 본인이 직접 제작할 수 있는지를 잘 판단해서 결정해야 합니다.

아, 왜 jQuery 를 버려야 하느냐구요? 그 부분을 말씀 안드렸네요. jQuery 는 무겁습니다. 그래서 모바일 플랫폼에서 많이 버벅거립니다. 모바일 앱과 사이트 경량화를 위해 jQuery 를 버리는 플젝들이 늘어나고 있는 것 입니다. [jQuery Mobile (모바일용 jQuery) 도 있는데, 이건 망작이니 쳐다도 보지 마세요.]

jQuery 의 또다른 문제는, 이 jQuery 는 native fuction 을 wrap 하기 때문에 에러가 나면 debug 을 할 방법이 없습니다. (단순한 jQuery conflict 을 말하는게 아니라, jQuery 자체에 어떤 에러가 발생하는 경우가 생깁니다. 물론 매우 드문경우긴 하지만, 이런 경우를 접하게 되면 정말 장님이 길찾아가는 듯한 느낌을 받게 됩니다.)

class_list_featured

마지막으로 하위 브라우져 지원을 위해서는 (하위브라우저란 그냥 병맛같은 IE 를 지칭 하고 있는겁니다) jQuery 생태계와 순수 javascript API 를 연결해주는 bridge (다리) 역활을 하는 각종 shim 들과 classie.js 같은 제품을 유용하게 사용하실 수 있습니다.

다시 div 에 class 를 추가하는 예를 들자면, classie.js 의 syntax 는 classList API 와 거의 동일 합니다.

classie.add(elem,"another-class");

이렇게 간단하면서도 하위브라우저 대응이 완벽하게 됩니다.

아우.. 이런것도 다 복잡하고 그냥 jQuery 써야겠어. 라는 생각이 드실수도 있습니다. 물론 이전에도 그렇게 생각하시는 분들은 많이 계셨습니다. 아우.. css 고 div 고 뭐고 너무 복잡해. 그냥 이미지 오려붙이고, 테이블 코딩할래.

그런데 이렇게 예전 방식을 고수하셨던 분들이나 제품들은 (그누보드의 경우 불과 몇년전까지도 테이블 코딩에 css 를 전혀 사용하지 않았었습니다. ㄷㄷㄷ) 머나먼 기억속의 추억으로 남게 되더라구요. 켁.

결국 변화에 적응하지 못하는 개발자나 제품들은, 살아남지 못하게 되는 것 입니다. 물론 그렇다고 jQuery 가 급격하게 사라질거란 단정을 하는 것 은 아닙니다. 제 개인적인 생각으로는, 서서히, 그리고 오랜 시간에 거쳐 소멸될거라 생각합니다. 10년이나 웹의 발전과 함께 해온 jQuery 가 하루아침에 급격하게 무너질꺼란 생각은 아무도 하지 않을 것 입니다.

*저 jQuery 굉장히 좋아하고 즐겨 사용해 왔습니다. jQuery 를 많이 사랑합니다. 많이 편하고 오래된 친구같아서 좋습니다. (결정적으로, jQuery 내에서는 나도 못하는게 없으니까..) 그런데 최소 웹에서는 편한자리에 오래 남아 있는게 좋은게 아니더라구요. ^^;;

hackya 는

Attorney, front-end developer, digital media artist, WordPress enthusiast, & a father of 4 wonderful children.

Tags: , , , ,

카테고리: ,

Ω

7 Comments

  • Estoque says:

    ‘어마어마한 양의 기존 jQuery 플러그인들을 대체하기 어렵다는 것 입니다. ‘ 공감합니다.

    경량화 작업하려고 jQuery 걷어내려고 시도 해봤는데 거의 모든 플러그인이 다 jQuery로 로드 되더라고요

    심지어 티스토리(다음/카카오)의 경우 자체 jQuery를 불러와서 쓰기 때문에 어짜피 다음이나 티스토리를 한번이라도 방문한 사람이라면 이게 케싱되어 있을거라서 이것을 로드해서 쓰는게 정신건강에 훨씬 좋습니다.

    대체제도 많이 나오고, 최신브라우저에서 지원하는 자바스크립트 api도 늘었지만 당분간은 jQuery는 건재할것 같습니다.

    • Matthew says:

      글쎄요.. 정신건강에 나쁠건 없죠. ㅎㅎㅎ

      요즘은 모르겠는데, 예전에 Joomla 하고 그누보드를 보면 javascript 가 inline 으로 작성되어 있었어요.

      이래서 그누보드나 줌라에서 jQuery 를 조금만 작성해서 붙이면 (특히 href click event) 무조건 에러가 뜨고 완전 시한폭탄이 따로 없었습니다. 물론 javascript 를 function 화 하지 않고, inline 으로 작성한 줌라 나 그누보드가 잘못한 부분이기도 하지만, 그렇다고 하더라도, 순수 javascript 을 작성했더라면 이런 문제가 발생하지 않을 부분이었거든요.

      또 jQuery 스트립트들이 어느 순서로 로딩되느냐에 따라서 에러가 뜨기도 하고 안뜨기도 하고. jQuery conflict 은 말할 것 도 없고.

      오히려 이런부분에서는 자유스러워진 거라서, 장점도 있고 단점도 있는 셈 입니다.

      • Estoque says:

        ‘ jQuery 스트립트들이 어느 순서로 로딩되느냐에 따라서 에러가 뜨기도 하고 안뜨기도 하고’ 이거 완전 핵공감 합니다.

        스크립트 여러개 쓸때 갑자기 먹통 도면 순서를 이리저리 바꾸다 보면 될때가 있죠

        이렇게 임시방편으로 쓰다가 나중에 추가로 코드를 집어넣어 수정할때 되면 멘붕오고…

        또 순서 바꿔서 돌려막고… 악순환의 연속이네요 -ㅁ-

  • codei says:

    jquery 가 문제 이기 보다, jquery를 어렵게 사용 하는 사람이 문제이다.
    워드프레스가 문제이기 보다, 테마를 이상하게 짜는 사람이 문제이다.

    뭔가 소오름.

    어찌되었든 웹 생태계가 스크립트 기반으로 흘러가고 있는 것은 사실입니다.
    아무리 좋은게 나와도 기존 사용자들이 다시 배우는 리스크를 감수 해야 할 수준이 아니면 점유율은 변화가 크지 않을 테구요.

    예전에 진도 프레임워크 라고 네이버에서 만든 프레임워크가 있는데,
    회사 상사가 이거 파보라고 해서 팟다가 똥물 나오는거 보고 얼마나 웃겼던지 ㅋㅋ
    이젠 아는 사람도 없을겁니다 ㅋㅋ
    [찾아보지도 마세요 jquery 모바일 보다 더 심합니다]

    • Matthew says:

      While I spent years trying to write “optimised” jQuery – through things like caching every $() call, always descending DOM queries from a closest parent, using global event handlers on things like scroll and resize, etc – you become aware at some point that there will always be a certain overhead purely from instantiating jQuery collections, and the amount of function invocation hidden inside jQuery methods to parse arguments etc. 라고 Patrick Kunka 라는 친구가 댓글을 달았는데, 저도 이 발언에 100% 동의 합니다.

      http://blog.wearecolony.com/a-year-without-jquery/

      jQuery 를 아무리 효율적으로 작성하려고 해도, 결국 jQuery 의 무거움을 느끼게 되는 거죠.

      그런데 함정은, 저 친구 회사 사이트는 UI 속도가 문제가 아니라 끌어오는 비디오 로딩 속도가 문제인.. ㅋㅋㅋㅋ

      진도프레임워크 네이버에서 써요.
      http://static.news.naver.net/pnews/resources/20160810_180553/js/news.jindo.js

      https://github.com/naver/jindojs-jindo

      몇년전에 개발자 사이트들 마다 이 제품 선전하는 글이 올라오곤 했었습니다. (이걸 쓰면 무슨 혜택을 주던가, 아무튼 그런 프로모션 비슷한 것도 네이버에서 했었을걸요.)

      네이버에서 필요해서 만든 것 같은데, 그때나 지금이나 전혀 관심이 생기는 제품은 아니네요. ㅎㅎㅎ

      • codei says:

        프레임워크나 라이브러리를 사용하면 무거워 지는것은 당연하죠.
        오직 퍼포먼스 대신 생산성!
        jquery 보다 더 심플한것도 있는데 왜?
        단지 귀찮아서 ( ..) [뭔가 대단한 이유 그런건 없다.]

        진도 배포판은 뭐라고 할까. 그거에요.
        네이버가 쓰는건 정식 버전. 배포판은 개발중인 베타 버전?
        기본적으로 뭔가 깔끔하지가 않음.
        [저도 막 써보라고 홍보할때 했다가 피해본 사람 중 1인]

        이런 의혹이 드는 대표가 페이스북.
        페북에서 배포하는 것은 [우린 써봣으니, 이젠 너희가 써보던가.] 라는 느낌으로 공개 합니다.
        그 중 하나가 hiphop-php 입니다.
        기존 php를 C++ 레벨까지 속도를 높여주는 물건인데, 그냥 기억속에서 지우세요. ㅎㅎ

        • Matthew says:

          위키도 HHVM 씁니다. query 속도는 php7이 더 유리하지만 concurrency 테스트에서는 HHVM 이 더 빠르다고 하네요. 그래서 당연히 위키 같은 경우는 php7 보다는 HHVM 으로 더 높은 속도향상이 이뤄지겠죠.

          작년에 HHVM 하고 php7 중 어느쪽이 더 빠르냐는 걸 놓고 논쟁이 진짜 많이 벌어졌었는데, 사실 benchmark 테스트는 의미없다고 봅니다.

          내 사이트에서 HHVM 과 php7 중 어느쪽인 빠른지 확인해보고 더 빠른쪽을 선택하는게 합리적인 선택이 아닐까 합니다.

          물론 HHVM 은 자주 뻗는다는 얘기도 있고… 아마 그런 의미에서 HHVM 을 기억에서 지우라고 하신 말씀 같습니다. ㅎㅎㅎ

Leave a Reply

Your email address will not be published. Required fields are marked *