- Firefox: the development nightly builds(Windows, Mac OS X)
- Safari: Leopard and Snow Leopard에서만 동작
- Chrome: Chrome’s Dev Channel. 이용하기 (Windows에서 잘 동작함)
- the Dev Channel’s home page로 이동해서 Dev Channel로 변경하고 크롬을 재시작합니다.
- 시작메뉴의 "구글 크롬(Google Chrome)" 탭에서 우클릭, 속성(properties) 선택
- 대상(Target) 필드 끝에 --enable-webgl --no-sandbox 옵션 추가 후 적용(ok)
- 시작메뉴에서 구글 크롬 실행시 webGL이 활성화 된 상태로 크롬을 이용하실 수 있습니다.
- 다음 예제가 잘 나오면 제대로 설정이 완료된 것입니다.
- <a href="javascript:alert(1)">test</a>
- <a href="" onclick="javascript:alert(1)">test</a>
Outer:
for (i = 1; i <= 10; i++)
{
document.write ("<br />");
document.write ("i: " + i);
document.write (" j: ");
Inner:
for (j = 21; j <= 30; j++)
{
if (j == 24)
{
continue Inner;
}
document.write (j + " ");
}
}
매거진에서는 jQuery와 Extjs의 Custom Event에 대해서만 소개를 하고 있었지만,
prototype이나 yui역시 Custom Event 와 관련된 기능을 제공하고 있었습니다.
jQuery나 prototype이 제공하고 있는 Custom Event기능은 그냥 흉내내기 수준에 불과해서 실무에 적용하기에 좀 부족한 면이 있는 것 같습니다. 하지만 YUI의 경우는 꽤 쓸만하게 구현을 해 놓은 것 같습니다. YUI의 CustomEvent utility 를 사용한다면 재사용 가능한 코드를 생산할 수 있을 것 같네요.
사용예제를 간단히 정리해보았습니다.
jQuery의 Custom Event
jQuery의 예제의 경우를 살펴보면,
- $(".expandableContainer") 에 toggleContents라는 이벤트리스너를 등록
- $(this).parent().parent().trigger('toggleContent') 메소드를 호출을 통해 이벤트 전송
$(this).parent().parent() === $(".expandableContainer") 이라는 것입니다. -_-;
서로 아주 굳게 결속되어있네요. 이렇게 된다면 Custom Event를 쓰는 의미가 없게 될 것 같은데요.
(prototype이나 extjs도 대충 비슷한 구조를 가지고 있습니다.)
하지만 YUI의 경우는 조금 다릅니다.
YUI의 Custom Event
- new YAHOO.util.CustomEvent("Custom Event Name") 를 통해서
모조 CustomEvent 객체(실제로 Event를 상속받아서 만들어진 객체가 아님)를 생성 - CustomEventObject.subscribe(function object) 메소드를 통해서 트리거이벤트 등록
- Player.Event.play.fire(object) 를 통해서 이벤트 발생(송출)시키면,
해당 CustomEventObject의 등록된 함수들이 실행됩니다.
이 때 object 인자를 통해서 Custom Property 도 함께 전달이 가능합니다.
이와 같은 유틸을 이용한다면, javascript코드를 모듈화시켜서 작성할 수 있도록 도와주지 않을까 싶네요.
(완벽하지는 않지만..-_-;)
다음 주소는 yboss 소개 페이지입니다.
http://icant.co.uk/sandbox/yboss/
그리고 아래 주소는 Yaho BOSS API 소개 페이지입니다.
http://developer.yahoo.com/search/boss/boss_guide/index.html
아래는 yboss에서 제공하는 샘플을 살짝 수정한 예제입니다.
CSS를 제외한 HTML코드만 간략하게 정리해봤습니다-_-;
쉽네요 ^^;;
1. jQuery.js는 jQuery라는 Super(말 그대로 Super 키워드 아님-_-) 객체를 생성하고 그 jQuery 객체로 Dom 객체 핸들링부터 Ajax 통신까지 수행한다. 반면 prototype.js는 기존의 javascript built-in object들을 prototype-based-inheritance를 통해서 기능을 확장시키거나, 기능별로 객체들을 구현해 놓았다. Element 객체, Class 객체, Ajax 객체 등이 있음. Number객체에 times같은 메소드를 추가 시켜 놓는다던지..
2. prototype.js에서 사용하는 $()는 Selector임. document.getElementById의 숏컷이라고 볼 수 있지만, $가 return 하는 객체는 prototype-based-inheritance를 통해서 prototype의 Element의 모든 property와 method를 shallow copy 해온 객체이다. 하지만 jQuery의 $()는 의미가 약간 다르다. jQuery의 $()는 selector function으로 쓰임과 동시에 jQuery 생성자로 쓰임. $()를 수행했을 경우 익명의 jQuery객체가 생성된다. 익명의 jQuery객체는 $() 생성자의 인자(스트링, element 객체)를 파싱하고, 넘오온 인자의 조건에 부합하는 element들의 주소를 배열로 가지게 된다. 예를 들어 $("a")는 페이지내의 모든 a태그 dom객체들의 reference를 가지고 있는 jQuery객체를 생성하는 코드이다. $("a")[0]이 참조하고 있는 것은 Dom 트리 구조를 trace했을 때 가장 처음으로 만나는 a태그가 될 것이다. 여기서 유의해야할 점이 있다. prototype.js의 Dom 객체가 이미 Element 클래스를 상속받았다면 extended라는 flag를 통해서 복사하지 않고 바로 해당 객체를 참조하는 로직만 수행한다. 그래서 $()함수를 통해서 여러번 같은 객체를 참조하는 방법이 합리적이라고 말할 수 있다. 하지만 jQuery에서 $()함수를 통해 같은 객체를 여러번 참조를 해서는 안 된다. $()함수를 한 번 실행할 때마다 jQuery는 익명의 jQuery객체를 생성하기 때문이다. 따라서 브라우져 메모리 사용을 줄이기 위해서는 여러번 참조해야할 객체의 경우는, 특정 변수에 할당해서 사용하는 것이 합리적이라고 할 수 있다.
한가지 참조할 점.
jQuery.js에서 $()를 호출할때마다 거대한 jQuery객체를 만들어내지는 않는다.jQuery 객체들은 prototype-based-inheritance를 통해서 jQuery를 상속받은 클론들이다. 이런 클론들은 delegation pointer를 가지고 원본(prototype)의 property와 method들을 참조하기 때문에 무겁지 않다.
위 2가지가 jQuery.js와 Prototype.js의 두드러진 차이점이라고 생각한다.
참고
편견1.프로토타입은 메모리 릭이 많다??
jQuery가 파일사이즈가 작기 때문에 메모리사용량도 적을 것이라는 오해에서 비릇됨.
prototype은 몇 부분의 코드에서 메모리 릭이 발생하는 문제가 오래전부터 지적되었기 때문에
더 오해가 생김. 하지만 프로토타입은 그런 문제들이 빠르게 패치되고 있음.
jQuery도 메모리릭이 발생하는 코드가 많음. 구글 JQuery User Group에 가서 memory leak 검색하면 전형적인
패턴들을 체크할 수 있다. 프로토타입이랑 비슷하게 이벤트 등록하고 해제하는데서 누수가 발생하는 경우가 많음.
편견2. jQuery는 파일사이즈가 작아서 초기 로딩이 빠르다.
jquery와 prototype core의 파일사이즈가 각각 '약' 70kb, 90kb이다.
(가끔 jQuery core와 prototype+scriptaculous를 비교하는 사람들이 있는데, jQuery 에반젤리스트일듯-_-
protoculous와 비교하려면 jQuery+jQueryUI를 해야함 )
그리 크게 차이나 보이지는 않는다. 이 원본을 가지고 공백제거 뉴라인제거에 gzip압축까지 하게 된다면..-_-;;
20-30kb 와 30-40kb 정도이다. 아주 미미한 차이임.
그리고 캐쉬를 사용하면, 파일사이즈 조금 더 작은 것은 큰 메리트가 아니다.
편견3. jQuery가 prototype보다 더 가볍다.
아마도 파일사이즈 때문에 나온 말인 듯. 아래 selector 수행속도의 차이를 보면 아니라는 것을 알 수 있음
아래 링크는 jQuery와 Prototype의 selector의 수행속도를 비교해 놓은 것이다.
http://claudio.cicali.org/article/100/prototype-and-jquery-benchmarked
아래 링크는 prototype.js 와 jquery.js의 특징들을 간단하게 비교해 놓은 슬라이드쇼
http://www.chazzuka.com/blog/index.php?p=47&t=jquery-vs-prototype-javascript-framework.html
--------------------------------------------------------------------------------------------------
오래전에 작성한 내용인데 -_-;;검색해서 오시는 분들이 많은 듯해서 업데이트를 해보려고 합니다. j
---------------------------------------------------------------------------------------------------
jQuery vs prototype을 비교할 때 항상 빠지지 않는 내용 중 하나가 jQuery 코드의 간결함입니다.
<div class="a">
<div class="b">b</div>
<div
class="b">b</div>
<div class="b">b</div>
<div class="b">b</div>
<div class="b">b</div>
<div class="b">b</div>
</div>
위와 같은 HTML 코드에서
className 이 "a"인 element의 하위 엘리먼트중, 클래스네임이 "b"인 element들만 숨기게 하고 싶을 때 jQuery는
$(".a .b").hide();
하면 되지만, prototype은
$$(".a
.b").each(function(obj,index){obj.hide();}):
로 작성해야 합니다.
------------------------------------------------------------------------
라고들 비교를 합니다.
그리고 jQuery code가 더 깔끔하고 편하죠? 라고 말을 합니다.
하지만
prototype Enumerable class의 invoke method를 사용하면 prototype에서도 간결하게 작성할 수가 있습니다.
아래처럼요.
$$(".a .b").invoke("hide");
위 문법대신 $$(".a .b").each(element.hide)
형식으로도 원하는 동작을 실행시킬 수 있다고 합니다. (Kita님 감사^^);
간결하죠?
아래 코드처럼 체이닝도
가능합니다. ㅡㅡ;;
$$(".a
.b").invoke("hide").invoke("addClassName","newStyle");
감사합니다.
2009.01.09 추가
JQuery와 prototype은 DOM 접근하고 핸들링하는 방식이 야간 다릅니다.
그리고 이 차이점에 performance에 영향을 미친다고 합니다.
prototype의 경우는 DOM Object에 attribute를 직접 접근해서 Element Class의 모든 속성을 writing합니다.
우리가 흔히 사용하는 hide show method를 예를 들어서 설명해보겠습니다.
prototype.js에서는 $("id").hide() (혹은 jQuery에서 $("#id").hide()를 실행했을 때 같은 동작을 합니다.
겉으로 봤을 땐 같아 보이지만 둘 사이에는 큰 차이가 있습니다. 바로 hide라는 메소드를 누가 가지고 있냐가 큰 차이입니다. prototype.js의 경우에는 해당 id의 DOM Object가 해당 메소드를 가지고 있습니다.
하지만 jQuery의 경우에는 jQuery라는 순수 javascript object가 해당 메소드를 가지고 있습니다.
순수 javascript object에 속성을 추가하거나 읽을 때와 Dom object에 속성을 추가하거나 읽을 때 퍼포먼스의
차이가 있습니다. 이부분은 나중에 다른 아티클에서 자세히 설명할 생각입니다. 성능향상과 여러가지 크로스브라우저이슈를 피하기 위해서는 DOM Object는 core 그대로 둔 상태에서 Javascript Object로 한번 Wrapping 하여 사용하는 전략을 사용해야합니다. 이 전략을 구사하고 있는 라이브러리가 바로 jQuery 이죠.
이 부분에서는 jQuery의 확실한 승리입니다. prototype.js도 앞으로는 jQuery가 쓰고 있는 전략으로 바꿀거라고 합니다. ㅡ.,ㅡ;블로그스피어에서 들은 풍월이라 잘은..^^;;
2009.01.16추가
prototype.js가 jQuery보다 느리지 않다 ..라는 믿음이 자꾸 깨어지고 있습니다. -_-;
제가 작업하고 있는 사이트는 iframe을 많이 사용하고 있습니다. iframe은 많은데 prototype.js를 쓰려고 보니...부모페이지와 자식페이지에서 prototype.js를 쓰려고 보니 양쪽페이지 모두 prototype.js를 삽입하고 이니셜라이징 해줘야 하는 문제가 발생하고 있습니다. ㅡ.,ㅡ; 프로토타입은 javascript natvie object 혹은 DOM natvie object의 원형(prototype)에 직접적인 변경을 함으로서 기능을 확장시킵니다. 여기서 파생되는 문제점들이 꽤 많습니다. 일단 퍼포먼스 힛!! 원형에 대한 (특히 natvie DOM object에 대한 ) 변형은 성능저하를 유발합니다. 그리고 또 한 다수의 iframe을 사용할 때 초기화 문제도 있습니다. 하위 iframe 페이지에서 prototype.js을 쓰고 싶다면 임베드하고 이니셜라이징을 해야하니깐요. 코드컴파일도 한번 더하고..javascript natvie object(String, Function ..) 등의 prototype에 attribute와 method를 추가해야하니깐요. jQuery는 이런 측면에선 정말 훌륭한 전략을 구사하고 있는 것 같습니다. ㅡ.,ㅡ; 팝업페이지나 하위 iframe 페이지에서 상위 혹은 오프너가 가지고 있는 jQuery object만 복사하거나 참조해서 사용하면 아무런 문제가 발생하지 않기 때문이죠.(사실 jQuery는 테스트용도로만 써봐서 확신할 순 없습니다. ㅋ)
| id | colour | random |
|---|---|---|
| 1 | red | 543 |
| 2 | red | 31 |
| 3 | red | 640 |
| 4 | yellow | 613 |
| 5 | yellow | 346 |
| 6 | yellow | 625 |
| 7 | orange | 145 |
| 8 | red | 671 |
| 9 | blue | 304 |
| 10 | yellow | 995 |
| 11 | green | 248 |
| 12 | purple | 929 |
| 13 | yellow | 118 |
| 14 | purple | 969 |
| 15 | red | 639 |
| 16 | orange | 982 |
| 17 | orange | 198 |
| 18 | green | 446 |
| 19 | yellow | 755 |
| 20 | purple | 831 |
라고 알고 있지만 다들 innerHTML만큼 빠르고 간편한 방법은 없다고 한다.
하지만 이런 경우 IE에서 dom 객체를 생성하지 못한다.
분명 innerHTML속성을 읽을 때는 제대로 접근한다.
하지만 Dom 객체는 생성되지 않는다. IE6,IE7에서 생성되지 않음
FF에서는 잘 된다.
최근에 IE Memory Leak에 관심이 많아지면서,
궁금해진 것이 IE Jscript의 GC가 어떻게 동작하는지였다.
How do the script garbage collectors work?? - http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx
위 글에서는 Jscript의 GC는 nongenerational mark-and-sweep garbage collector라고 소개하고 있다.
그러면서 더욱 더 혼란에 빠지기 시작했다. =_= 대부분의 IE Memory Leak 패턴은 상호참조나 순환참조에
의해서 생기는 것인데, Mark and Sweep은 순환참조나 상호참조되는 객체들도 깨끗이 지울수 있는
알고리즘이기 때문이다. 순환참조나 상호참조되는 객체들도 다 지우는데 왜 메모리누수가 나타나는거지
라고 한참 삽질을 하다가 알게 된 1가지 중요한 사실-_-;
IE Dom GC와 Jscript GC는 다르다는 것~!!!!!!!!!
아래 문서처럼 IE Memory Leak 패턴에 대해서 쉽고 잘 설명해놓은 글은 찾아보질 못했다.
http://www.codeproject.com/KB/scripting/leakpatterns.aspx
혹시 mark-and-sweep garbage collection algorithm에 대해서 한글로 설명된 문서가 필요하다면,
플래쉬 플레이어 GC에 대한 설명이 나온 한글 문서다. 물론 Jscript의 nongenerational mark-and-sweep garbage collection algorithm과 일치하지는 않지만 이해하는데 도움이 된다.
http://blog.naver.com/velocica/40042575271
