Vanilla JavaScript와 jQuery를 언제 사용해야합니까?


238

일반적인 jQuery 질문을 모니터링 / 시도하는 동안 jQuery 대신 javascript를 사용하는 특정 사례가 실제로 적은 양으로 작성하고 동일한 양 을 할 수 있음을 알았습니다 . 또한 성능상의 이점을 얻을 수 있습니다.

구체적인 예

$(this) vs this

클릭 한 객체 ID를 참조하는 클릭 이벤트 내부

jQuery

$(this).attr("id");

자바 스크립트

this.id;

이와 같은 다른 일반적인 관행이 있습니까? jQuery를 혼합하지 않고 특정 Javascript 조작을보다 쉽게 ​​수행 할 수있는 위치. 아니면 드문 경우입니까? (실제로 더 많은 코드가 필요한 jQuery "바로 가기")

편집 : jQuery 대 일반 자바 스크립트 성능에 대한 답변을 주셔서 감사하지만 실제로 훨씬 더 정량적 인 답변을 찾고 있습니다. jQuery를 사용하는 동안을 사용하는 대신 일반 자바 스크립트를 사용하는 것이 실제로 더 나은 인스턴스 (가독성 / 소형) $()입니다. 예를 들어 원래의 질문에 답했습니다.


질문을 이해하지 못했습니다. 라이브러리 코드 사용의 장점에 대한 의견을 찾고 있었습니까? 아니면 jQuery와 호환되지 않는 크로스 브라우저 호환 기술을 찾고 this.id있습니까?
user113716

1
대답에서 나는 모든 사람들 이이 질문을 철학적이라고 생각합니다. 내가 요약 한 것과 같은 인스턴스 목록을 거의 (일반적인) 연습으로 컴파일하기 위해 매우 정량적이었습니다.
jondavidjohn


답변:


207
  • this.id (알다시피)
  • this.value(대부분의 입력 유형. 내가 아는 문제 는 요소 에 속성이 설정되어 <select>있지 않거나 Safari에 라디오 입력 이없는 경우 IE 입니다.)value<option>
  • this.className 전체 "클래스"속성을 가져 오거나 설정
  • this.selectedIndex에 대해 <select>선택된 인덱스를 얻을 수 있습니다
  • this.options에 대한 요소 <select>목록을 얻기 위해<option>
  • this.text에 대해 <option>해당 텍스트 내용을 얻을 수 있습니다
  • this.rows에 대한 요소 <table>의 컬렉션을 얻기 위해<tr>
  • this.cells에 대해 <tr>세포를 얻는 데 (td & th)
  • this.parentNode 직접적인 부모를 얻기 위해
  • this.checked감사 @Tim Down 상태를 확인하려면checkbox
  • this.selectedThanks @Tim Down 의 선택된 상태를 얻으려면option
  • this.disabledThanks @Tim Down 의 비활성화 상태를 얻는 방법input
  • this.readOnlyThanks @Tim Down 의 readOnly 상태를 얻으려면input
  • this.href<a>요소에 대해href
  • this.hostname<a>의 도메인을 얻기 위해 요소에 대해href
  • this.pathname에 대해 <a>요소의 경로를 얻기 위해 그href
  • this.search<a>쿼리 문자열을 얻기 위해 요소에 대해href
  • this.src 유효한 요소에 대해 src

... 아이디어를 얻는 것 같아요.

성능이 중요한 경우가 있습니다. 루프에서 여러 번 반복해서 무언가를 수행하는 것처럼 jQuery를 버리고 싶을 수도 있습니다.

일반적으로 다음을 대체 할 수 있습니다.

$(el).attr('someName');

와:

위의 말은 잘못되었다. getAttribute대체는 아니지만 서버에서 전송 된 속성 값을 검색하면 해당 속성 setAttribute이 설정됩니다. 어떤 경우에는 필요합니다.

아래의 문장은 그것을 덮었습니다. 더 나은 치료를 위해이 답변참조하십시오 .

el.getAttribute('someName');

... 속성에 직접 액세스하기 위해. 속성은 속성과 동일하지 않습니다 (때로는 서로 미러링하지만). 물론 setAttribute있습니다.

특정 유형의 모든 태그를 풀어야하는 페이지를받은 상황이 있다고 가정 해보십시오. jQuery를 사용하면 간단하고 쉽습니다.

$('span').unwrap();  // unwrap all span elements

그러나 많은 것이 있다면 약간의 원시 DOM API를 원할 수 있습니다.

var spans = document.getElementsByTagName('span');

while( spans[0] ) {
    var parent = spans[0].parentNode;
    while( spans[0].firstChild ) {
        parent.insertBefore( spans[0].firstChild, spans[0]);
    }
    parent.removeChild( spans[0] );
}

이 코드는 매우 짧으며 jQuery 버전보다 성능이 우수하며 개인 라이브러리에서 재사용 가능한 함수로 쉽게 만들 수 있습니다.

while때문에 외부에 무한 루프가있는 것처럼 보이지만 while(spans[0])"라이브 목록"을 처리하기 때문에를 수행 할 때 업데이트됩니다 parent.removeChild(span[0]);. 이것은 Array (또는 Array-like object) 대신 작업 할 때 그리워하는 아주 멋진 기능입니다.


2
nice ... 그래서 대부분이 키워드를 jQuery 객체로 불필요하게 감싸는 것입니다.
jondavidjohn

1
@ jondavidjohn : 글쎄, 어떤 경우 this.value에는 몇 가지 브라우저 문제가있는 경우와 같이 어떤 경우에는 좋은 수정 사항이 있습니다 . 그것은 모두 당신의 필요에 달려 있습니다. 특히 성능이 중요한 경우 jQuery없이 쉽게 사용할 수있는 멋진 기술이 많이 있습니다. 더 생각하려고 노력하겠습니다.
user113716

3
답을 쓰려고했지만 대신 제안을 추가하겠습니다. 일반적으로 attr()지나치게 많이 사용됩니다. 하나의 요소 만 다루는 경우 거의 필요하지 않습니다 attr(). 제가 좋아하는 두 사람은 주위 혼란 있습니다 checked: 체크 박스의 속성 (하나의 주위에 신비한 주술의 모든 종류의 $(this).attr("checked", "checked"), $(this).is(":checked")그리고 유사 등) selected의 특성 <option>요소를.
Tim Down

1
Aaargh, @patrick, noooo : 추천했습니다 getAttribute(). 당신은 거의 그것을 필요로 하지 않습니다 : IE에서 깨졌으며 항상 현재 상태를 반영하지는 않으며 jQuery 가하는 일이 아닙니다. 속성을 사용하십시오. stackoverflow.com/questions/4456231/…
Tim Down

1
나는 오랫동안 JS를 사용하고 있었고 className, thx에 대해 몰랐다.
IAdapter

60

정답은 '일반 오래된'기본 JavaScript 대신 jQuery를 사용할 때 항상 성능 저하 가 발생한다는 것 입니다. jQuery는 JavaScript 라이브러리이기 때문입니다. 멋진 새 버전의 JavaScript가 아닙니다.

jQuery가 강력한 이유는 브라우저 간 상황에서 지나치게 지루한 작업을 수행하고 (AJAX가 가장 좋은 예 중 하나임) 무수한 사용 가능한 브라우저 간의 불일치를 매끄럽게하고 일관된 API를 제공하기 때문입니다. 또한 체인, 암시 적 반복 등과 같은 개념을 쉽게 촉진하여 요소 그룹에 대한 작업을 단순화합니다.

jQuery 학습은 JavaScript 학습을 대신 할 수 없습니다. 당신은 전자를 아는 것이 당신을 더 편하게한다는 것을 완전히 이해하도록 후자에 확고한 근거를 가져야한다.

-주석을 포함하도록 편집 됨-

의견이 빨리 지적되고 100 %에 동의하면 위의 진술은 벤치마킹 코드를 나타냅니다. '네이티브'JavaScript 솔루션 (잘 작성되었다고 가정)은 거의 모든 경우에 동일한 것을 수행하는 jQuery 솔루션보다 성능이 우수합니다 (그렇지 않으면 예제를보고 싶습니다). jQuery는 개발 시간을 단축 시키므로 다운 플레이를 의미하지는 않습니다. 쉽게 읽고 따르기 쉬운 코드를 사용하기 때문에 일부 개발자가 독자적으로 만들 수있는 것 이상입니다.

내 의견으로는, 대답은 당신이 달성하려는 것에 달려 있습니다. 성능상의 이점에 대한 귀하의 참조를 바탕으로 추정 한 것처럼 응용 프로그램에서 최상의 속도를 냈다면 jQuery를 사용하면 호출 할 때마다 오버 헤드가 발생합니다 $(). 가독성, 일관성, 크로스 브라우저 호환성 등을 원한다면 '네이티브'JavaScript보다 jQuery를 선호하는 이유가 있습니다.


8
jQuery가 순수한 JS에서 구현을 능가 할 수있는 상황의 예를보고 싶습니다. 당신이 무엇을 하든지, jQuery (또는 그 문제에 대한 다른 라이브러리)를 사용한다면 피할 수없는 기능 오버 헤드가 있습니다. calling에서 생성 된 사소한 오버 헤드를 피할 수있는 방법은 없습니다 $(). 전화를하지 않으면 시간이 절약됩니다.
gddc

16
잘못 작성된 수제 솔루션은 아마도 느릴 것입니다. jQuery 팀은 패키지에서 매우 효율적인 JavaScript를 실행했습니다. @Freelancer의 답변을 참조하십시오.
Stephen

3
잘못 작성된 솔루션은 항상 잘못 작성된 솔루션이 될 것이며 이는 언어의 결함이 아닙니다. 라이브러리가 잘 생각하면 '네이티브'기능으로 피할 수있는 오버 헤드가 발생한다는 사실은 변경하지 않습니다.
gddc

11
@gddc 필자는 jQuery가 "성능"(벤치 박스 외부에서 읽음) 순수 JS가 개발 시간 (비즈니스 측면에서 막대한 가치)을 줄이고 실험을 단순화하는 최상의 사례라고 생각합니다.
Ben

13
당신이 쓴 모든 것은 사실이지만, 당신은 위의 @Ben 노트를 생략했습니다. jQuery는 개발자를 더욱 빠르고 강력 하게 만듭니다 . 몇 년 전에 쓰고 많이 사용했던 KillClass () 구현 을 참조하십시오 . 그거 알아? 그것은 것 깨진 특정 가장자리 경우에. 잘못된 코드는 잘못된 코드이고 잘못된 코드는 잘못된 코드이지만 jQuery를 사용하면 개발자가 더 좋고 정확한 코드를 작성할 수 있습니다. 대부분의 경우 컴퓨터는 충분히 빠릅니다. 도움이 필요한 개발자입니다.
Phrogz

38

라는 프레임 워크가 있습니다. Vanilla JS. 당신이 농담을 얻을 수 있기를 바랍니다 ... : D 성능에 대한 코드 가독성을 희생합니다 ... jQuery벨로우즈를 비교하면 DOM요소 를 검색하는 ID것이 거의 35X 라는 것을 알 수 있습니다 빠릅니다. :)

따라서 성능을 원한다면 Vanilla JS를 사용하여 자신의 결론을 내리는 것이 좋습니다. for루프 내부와 같이 집중적 인 코드 중에는 JavaScript가 브라우저의 GUI를 중단하거나 UI 스레드를 잠그는 경험이 없을 수도 있습니다 .

Vanilla JS는 믿을 수 없을만큼 강력한 JavaScript 응용 프로그램을 구축하기위한 빠르고 가벼운 크로스 플랫폼 프레임 워크입니다.

그들의 홈페이지에는 성능 비교가 있습니다 :

여기에 이미지 설명을 입력하십시오


1
@ Leniel Macaferi Oh Man 나는이 답변을 좋아했습니다! 나는 바닐라와 다른 프레임 워크 간의 성능이 그러한 차이를 만들 수 있다는 것을 깨닫지 못했습니다! 어쨌든이 답변에 대한 명예의 전당 !! 추신 : 웹 사이트도 만들었습니까?
Steve

17

이미 받아 들여진 답변이 있지만 여기에 직접 입력 한 답변이 브라우저 간 지원을 실질적으로 보장하는 기본 자바 스크립트 메소드 / 속성 목록에 포괄적 일 수는 없습니다. 이를 위해 quirksmode로 리디렉션 할 수 있습니다.

http://www.quirksmode.org/compatibility.html

아마도 어떤 브라우저에서 작동하고 작동하지 않는 항목에 대한 가장 포괄적 인 목록 일 것입니다. DOM 섹션에 특히주의하십시오. 읽을 것이 많지만 요점은 모든 것을 읽지 않고 참조로 사용하는 것입니다.

웹 응용 프로그램을 심각하게 작성하기 시작했을 때 모든 DOM 테이블을 인쇄하고 벽에 매달아 사용하기 안전하고 해킹이 필요한 항목을 한눈에 알 수있었습니다. 요즘 나는 quirksmode parentNode compatibility의심이있을 때 와 같은 것을 구글에 보냅니다.

다른 것들과 마찬가지로, 판단은 대부분 경험의 문제입니다. 나는 전체 사이트를 읽고 jQuery를 사용할 때와 일반 JS를 사용할 때를 알아 내기 위해 모든 문제를 암기하는 것을 권장하지 않습니다. 목록 만 알아 두십시오. 검색하기가 쉽습니다. 시간이 지나면 평범한 JS가 선호 될 때의 본능을 개발하게됩니다.


추신 : PPK (사이트의 저자)도 읽는 것이 좋습니다 아주 좋은 책이 있습니다


14

언제:

  1. 현재하고있는 일에 대해 브라우저 간 지원이 제공된다는 것을 알고 있습니다.
  2. 타이핑하기에는 더 많은 코드가 아니며
  3. 눈에 잘 띄지 않으며
  4. jQuery가 더 나은 성능을 달성하기 위해 브라우저를 기반으로 다른 구현을 선택하지 않을 것이라고 확신합니다.

JavaScript를 사용하십시오. 그렇지 않으면 jQuery를 사용하십시오 (가능한 경우).

편집 :이 답변은 jQuery를 전반적으로 사용하거나 제외 할 때뿐만 아니라 jQuery 내에서 바닐라 JS를 사용할지 여부를 선택할 때 모두 적용됩니다. 사이에 선택 attr('id').id사이에 선택하는 동안, JS 찬성 몸을 숙 removeClass('foo').className = .className.replace( new Regexp("(?:^|\\s+)"+foo+"(?:\\s+|$)",'g'), '' )jQuery를 찬성 몸을 숙.


3
OP가 jQuery를 사용하려고하지만 jQuery 메소드 내에서 기본 JavaScript를 언제 어디서 사용할지 궁금합니다.
Stephen

.classList.remove('foo')최신 브라우저에서 제대로 작동하는 것 같습니다
Tyilo

3
@Tyilo classList.remove는 IE9에서 구현되지 않은 HTML5 ClassList API의 일부입니다 (예 : caniuse.com/#feat=classlist
corbacho

13

다른 사람들의 답변은 "jQuery vs. plain JS"의 광범위한 질문에 초점을 맞추 었습니다. OP에서 판단하면 이미 jQuery를 사용하기로 선택한 경우 바닐라 JS를 사용하는 것이 더 좋은지 궁금해하고 있습니다. 귀하의 예는 바닐라 JS를 사용해야 할 때의 완벽한 예입니다.

$(this).attr('id');

느리거나 내 의견으로는 읽기 쉽지 않습니다.

this.id.

jQuery 방식으로 속성을 검색하기 위해 새 JS 객체를 회전시켜야하기 때문에 속도가 느립니다. 이제 $(this)다른 작업을 수행 하는 데 사용 하려는 경우 반드시 해당 jQuery 객체를 변수에 저장하고 해당 작업을 수행하십시오. 그러나 요소의 속성 ( id또는 같은 src)이 필요한 많은 상황에 처했습니다 .

이와 같은 다른 일반적인 관행이 있습니까? jQuery를 혼합하지 않고 특정 Javascript 조작을보다 쉽게 ​​수행 할 수있는 위치. 아니면 드문 경우입니까? (실제로 더 많은 코드가 필요한 jQuery "바로 가기")

가장 일반적인 경우는 귀하의 게시물에 설명 된 사례입니다. $(this)jQuery 객체를 불필요하게 래핑 하는 사람들 . 나는 함께이 가장 많이 참조 id하고 value(대신 사용$(this).val() ).

편집 : 여기에 jQuery를 사용 하는 것이 attr() 느린 설명하는 기사가 있습니다. 고백 : 태그 위키에서 훔 쳤지 만 질문에 대해 언급 할 가치가 있다고 생각합니다.

다시 편집 : 속성에 직접 액세스하는 가독성 / 성능 함의를 감안할 this.<attributename>때 가능한 한 일반적으로 사용하려고 시도하는 것이 좋습니다. 브라우저 불일치로 인해 작동하지 않는 경우가있을 수 있지만, 먼저 시도한 후 작동하지 않으면 jQuery를 사용하는 것이 좋습니다.


아, 질문을 읽어 주셔서 감사합니다;) ... 그래서 이것이 더 광범위하게 예외입니까?
jondavidjohn

@jondavidjohn : 솔직히, 나는 그 전화를 주저하고 있습니다. 크로스 브라우저 문제로 인해 jQuery를 사용하는 것이 일반적으로 유리합니다. 와 같은 다른 예가 있습니다 this.style.display = 'none'. 보다 낫 $(this).hide()습니까? 나는 후자가 더 읽기 쉽다고 주장하지만 전자는 더 빠를 것입니다. jQuery없이 브라우저에서 특정 작업이 작동하는지 확인하기 위해 실험을하는 것이 아프지 않습니다. 이는 일반적으로 작업을 수행하기 위해 jQuery 객체의 요소를 래핑하기 전에 수행하는 작업입니다.
Andrew Whitaker

10

주로 성능에 관심이 있다면 주요 예제가 머리에 못을 박습니다. 불필요하게 또는 중복으로 jQuery를 호출하면 IMHO는 성능 저하의 두 번째 주요 원인입니다 (첫 번째는 빈약 한 DOM 탐색).

그것은 실제로 당신이 찾고있는 것의 예는 아니지만, 나는 이것을 자주 언급합니다 : jQuery 스크립트의 성능을 향상시키는 가장 좋은 방법 중 하나는 jQuery 객체를 캐시하거나 체인을 사용하는 것입니다.

// poor
$(this).animate({'opacity':'0'}, function() { $(this).remove(); });

// excellent
var element = $(this);
element.animate({'opacity':'0'}, function() { element.remove(); });

// poor
$('.something').load('url');
$('.something').show();

// excellent
var something = $('#container').children('p.something');
something.load('url').show();

흥미롭게도 var 인스턴스화와 동작의 분리가 실제로 처리 성능 향상으로 이어 집니까? 아니면 그냥 그 행동을 스스로 수행 할 수있게한다. (나는 추측을 덜 방해한다.)
jondavidjohn

1
선택한 요소를 재사용하는 경우에만 성능이 향상됩니다. 따라서 마지막 경우에는 var something체인을 사용했기 때문에 jQuery 객체를 실제로 캐시 할 필요는 없었지만 어쨌든 습관을 벗어났습니다.
Stephen

2
반면에 같은 예를 들어보십시오. $('.something')두 번 호출 하면 jQuery가 DOM을 두 번 통과하여 해당 선택기가있는 모든 요소를 ​​찾아야합니다.
Stephen

2
첫 번째 예의 경우 캐싱 $(this)은 jQuery 함수에 대한 호출을 줄입니다. 이것은 루프 시나리오에서 가장 큰 이익을 줄 것입니다.
Stephen

2
@Alnitak주의 사항 element과 같습니다 $(this). 여러 요소를 포함하지 않습니다.
Stephen

8

JS와 JQ가 확실히 겹치는 것을 발견했습니다. 당신이 보여준 코드는 그 좋은 예입니다. 솔직히 JS를 통해 JQ를 사용하는 가장 좋은 이유는 단순히 브라우저 호환성입니다. JS에서 무언가를 달성 할 수는 있지만 항상 JQ에 의존합니다.


8
JQuery는 JavaScript이기 때문에 겹치지 않았는지 궁금 할 것입니다.
simon

6

이것은 내 개인적인 견해이지만 jQuery는 JavaScript이므로 이론적으로 바닐라 JS보다 성능이 뛰어나다 고 생각합니다.

그러나 실제로는 손으로 쓴 코드가 jQuery만큼 효율적이지 않기 때문에 손으로 쓴 JS보다 성능이 우수 할 수 있습니다.

결론-작은 물건의 경우 바닐라 JS를 사용하는 경향이 있습니다 .JS 집중 프로젝트의 경우 jQuery를 사용하고 바퀴를 재발 명하지 않는 것이 좋습니다-생산성도 향상되었습니다.


1
라이브러리가 바닐라 JS를 능가하는 많은 예제가 있습니다. JS의 많은 내장 프로토 타입 메소드가 잘못 작성되었습니다.
에 예를 들어

3

thisDOM 요소로서의 첫 번째 답변의 라이브 속성 목록 은 매우 완전합니다.

다른 사람들을 아는 것도 흥미로울 것입니다.

이것이 문서 인 경우 :

  • this.forms 얻을 HTMLCollection현재 문서 양식 중
  • this.anchors얻기 위해 HTMLCollection모든의를 HTMLAnchorElementsname설정되고,
  • this.links얻기 위해 HTMLCollection모든의 HTMLAnchorElement와의를 href설정되고,
  • this.images얻을 수 HTMLCollection있는 모든의 HTMLImageElement
  • 더 이상 사용되지 않는 애플릿과 동일 this.applets

당신이 작업 할 때 document.forms, document.forms[formNameOrId]이렇게 이름 또는 확인 양식을 가져옵니다.

이것이 양식 일 때 :

  • this[inputNameOrId] 그렇게 명명되거나 식별 된 필드를 얻기 위해

이것이 양식 필드 인 경우 :

  • this.type 필드 유형을 얻으려면

jQuery 선택기를 학습 할 때 기존 HTML 요소 속성 학습을 건너 뛰는 경우가 종종 있습니다.


언급 한 속성은 DOM Level 2 HTML 사양에 정의되어 있으며 널리 지원됩니다. document.embeds그리고 document.plugins널리 DOM (0)을 지원합니다. document.scripts또한 HTML5 사양에 정의되어 있으며 널리 지원되는 (및 Firefox 9+ ) 편리한 모음 입니다.
Rob W

@Robw 따라서 이제 목록이 완성되고 확실히 유용하고 빠를 수 있습니다. 감사합니다;)
lib3d

2

평소와 같이 나는이 파티에 늦게오고있다.

jQuery를 사용하기로 결정한 것은 추가 기능이 아니 었습니다. 결국 아무것도 당신이 당신의 자신의 함수를 작성하는 것을 막을 수 있습니다.

메모리 누수를 피하기 위해 DOM을 수정할 때 배워야 할 많은 트릭이 있다는 사실이었습니다 (IE에 대해 이야기하고 있습니다). 나보다 훨씬 더 나은 JS 코더 인 사람들이 저술 한 모든 종류의 문제를 관리하는 하나의 중앙 리소스를 확보하려면 지속적으로 검토하고 수정하고 테스트 한 것이 신의 보냄이었습니다.

나는 이런 종류의 브라우저 간 지원 / 추상적 주장에 해당한다고 생각합니다.

물론 jQuery는 필요할 때 스트레이트 JS의 사용을 배제하지 않습니다. 나는 항상 두 사람이 완벽하게 협력하는 것처럼 느껴졌다.

물론 jQuery에서 브라우저를 지원하지 않거나 저사양 환경 (이전 전화?)을 지원하는 경우 큰 .js 파일이 문제 일 수 있습니다. jQuery가 작았을 때를 기억하십니까?

그러나 일반적으로 성능 차이는 문제가되지 않습니다. 충분히 빠르면됩니다. 기가 헤르츠의 CPU 사이클이 1 초마다 낭비됨에 따라 18 개월마다 두 배가되지 않는 유일한 개발 리소스 인 코더의 성능에 더 관심이 있습니다.

그것은 현재 접근성 문제를 조사 중이며 분명히 .innerHTML은 그다지 중요하지 않습니다. jQuery는 물론 .innerHTML에 의존하므로 허용되는 다소 지루한 메소드에 의존하는 프레임 워크를 찾고 있습니다. 그리고 그러한 프레임 워크가 jQuery보다 느리게 실행될 것이라고 생각할 수 있지만 성능이 충분하면 행복합니다.


2

기술적이지 않은 답변이 있습니다. 많은 작업이 jQuery와 같은 특정 라이브러리를 허용하지 않을 수 있습니다.

사실, 구글은 인터뷰어가 "죄송 합니다만 jQuery를 사용할 수는 없습니다. XYZ Corporation의 승인 된 목록 "을 참조하십시오. 바닐라 자바 ​​스크립트는 언제 어디서나 완벽하게 작동하며,이 문제를 결코 일으키지 않습니다. 당신이 도서관에 의지한다면, 당신은 속도와 편의를 얻지 만 보편성을 잃습니다.

또한 인터뷰에 관해 말하면, 다른 단점은 코드 퀴즈 중에 JavaScript 문제를 해결하기 위해 라이브러리를 사용해야한다고 말하면 실제로 문제를 이해하지 못하는 것처럼 나타납니다. 원시 바닐라 JavaScript로 해결하면 실제로 문제가 발생하기 전에 모든 부분을 이해하고 해결할 수 있음을 보여줍니다.


1

$(this) ~와 다르다 this :

를 사용 $(this)하면 jQuery 프로토 타입이 객체로 전달됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.