jQuery를 사용하지 않는 경험적 기술적 이유는 무엇입니까?

jQuery를 사용하지 않는 경험적 기술적 이유는 무엇입니까?

---

컨텍스트 : 하루 종일 HTML, Javascript 및 CSS를 해킹하고 jQuery ( 또는 기타 동등한 도우미 프레임 워크 )와 같은 도구 를 무시 하고 사용을 거부 하는 프런트 엔드 개발자의 수가 놀랍 습니다. 나는 자바 스크립트 전문가에 대해 말하는 것이 아니라 매일 Joe 프로덕션 개발자들에 대해 이야기하고 있습니다. 기술적 인 장점이 없다고 생각되는 변명이나 개인적인 의견에 가까운 논쟁을 많이받습니다. 무언가를 놓치고 있지 않은지 확인하고 싶습니다.

질문 : jQuery를 사용하지 않는 경험적 기술적 이유는 무엇입니까?

나는 종교적이거나 독단적 인 주장이나 "다른 프레임 워크가 더 낫다"는 주관적인 의견을 찾고 있지 않습니다. 질문에서 모든 비교 가능한 프레임 워크에 대해 jQuery를 짚으로 생각하십시오.

---

2015 업데이트 :

2011 년 의이 답변에서 jQuery, YUI 또는 Prototype과 같은 라이브러리에 대해 이야기하고 있습니다. 2015 년에도이 추론은 Angular, React 또는 Ember와 같은 프레임 워크에 여전히 적용 가능합니다. 그 4 년 동안 기술은 엄청나게 발전했고, jQuery 나 YUI에 대해 본 것보다 React 나 Angular에 대한 편견이 훨씬 적다고 보지만, 같은 종류의 생각이 오늘날에도 여전히 존재합니다.

2016 업데이트 :

며칠 전에 게시 된 기사를 적극 권장합니다.

• 왜 jQuery인가? Single Page Web Applications 책의 저자 인 Michael S. Mikowski

그 기사는 기본적으로 바로이 질문에 대한 매우 상세한 답변입니다. 아래 답변을 작성할 때 사용할 수 있었다면 분명히 인용했을 것입니다.

원래 답변 :

나는 jQuery에 대해 대답 할 것이지만 YUI, Prototype, Dojo, Ext 및 기타 몇 가지 사용에 대해 들어 본 것과 동일한 주장입니다. 내가 들었던 주요 주장 :

1. jQuery 3.2.1의 경우 실제로 84.6KB 인 파일 크기 -평균 웹 사이트의 로고보다 작으며 대부분의 방문자의 캐시에 이미있을 가능성이 높은 Google의 CDN에서 제공 할 수 있습니다. jQuery를 사용하면 항상 자체 JavaScript 파일의 파일 크기가 더 작아 지므로 브라우저 캐시에 아직 저장되어 있지 않더라도 실제로는 더 작은 다운로드를 의미 할 수 있습니다 .

2. 속도 -순수한 JavaScript를 작성하는 것이 더 빠를 수 있지만 대부분의 사람들에게 이식 가능한 JavaScript를 작성 하는 것은 불가능 해 보입니다. 더 빠르지 만 모든 인기있는 브라우저에서 작동하지 않는 웹 사이트는 현실 세계에서 쓸모가 없습니다. 게다가 jQuery는 꽤 많은 최적화를 사용하여 실제로 매우 빠르며 모든 릴리스에서 계속 더 빨라지기 때문에 사소한 예제 외에는 손으로 더 빠른 코드를 작성하는 것이 실제로 그렇게 쉽지 않습니다. (*)

3. "지적 재산" -회사는 다른 사람의 코드를 사용하여 두려워하는 반면 실제로 jQuery는 할머니의 블로그에서 Amazon, Twitter에서 Bank of America, Google에서 Microsoft에 이르기까지 모든 곳에서 사용되는 오픈 소스 및 무료 소프트웨어입니다. 사용하면 모든 회사에서 사용할 수 있습니다.

4. 다른 논쟁이 심각하게 사용되는 것을들은 기억이 없습니다.

(*) 다음은 간단한 예입니다. getElementById ( 'someid') 대 jQuery ( '# someid')

getElementById를 더 빠르게 사용하고 있습니까? 예. 물론 모든 사람들은 Blackberry 4.6이 더 이상 문서에없는 노드를 반환 할 때 잡기 위해 항상 parentNode를 확인합니다. jQuery는 그렇습니다. 그리고 모두 IE와 Opera가 ID 대신 이름으로 항목을 반환하는 경우를 처리합니다. jQuery는 그렇습니다. 그렇게하지 않으면 코드를 이식 할 수 없으며 찾기가 매우 어려울 수있는 미묘한 버그가 발생합니다. 그리고 getElementById는 아마도 찾을 수있는 가장 사소한 예제입니다. 이벤트와 AJAX 및 DOM을 시작하지 마십시오.

최신 정보:

실제로 누군가 jQuery를 사용하지 않는 이유를 묻는 네 번째 결과가 있습니다. 나는 정말 대답 것이 아니라하지 않기 때문에이 목록에 넣어 깜빡 부족 어떤 대답. 코멘트 어제 가지고 그것에 대해 생각 나게했다. 이 거의 목록에 추가 할 수있는 "기술적 인 이유"입니다하지만 그럼에도 불구하고 흥미로운 일이 될 수 있으며, 실제로 할 수 가장 일반적인 반응.

제가 개인적 으로 이러한 모든 반응에 대한 주된 근본적인 원인 이라고 생각하는 것은 컴퓨터 과학 발전에 가장 큰 장애물이라고 생각하는 것입니다. 그렇게 중요하지 않습니다. "

한때 어셈블러, 컴파일러, 구조화 된 프로그래밍, 고수준 언어, 가비지 수집, 객체 지향 프로그래밍, 클로저 또는 현재 우리가 당연하게 여기는 거의 모든 것을 최적화하는 반응이었으며 오늘날에는 AJAX 라이브러리입니다. 언젠가는 우리가 한때 응용 프로그램 수준에서 원시 DOM API와 수동으로 상호 작용 했었다는 사실을 아무도 기억하지 못할 것입니다. 지금은 아무도 우리가 한때 장식되지 않은 원시 16 진수를 사용하여 프로그램을 작성했다는 사실을 기억하지 못합니다 .

---

jQuery는 모든 것을 DOM 중심 패러다임으로 표현합니다. 이는 오해의 소지가 있으며 애플리케이션 패턴으로 표현할 필요가 없습니다.

많은 개발자가이 DOM 중심 패턴을 사용하여 프로그래밍을 시작하고 결국 확장 가능하거나 재사용 가능한 것을 만들지 않았다는 것을 깨닫습니다.

레베카 머피는 좋은 쓰기까지 자신의 스위치가 jQuery를에서 도장 더 이유에 대해 블로그 게시물입니다 - 하지 jQuery를 대 왜 도장.

---

프레임 워크를 사용하지 않는 한 가지 이유는 배너와 같은 다른 웹 사이트에 임베드 가능한 코드를 작성할 때입니다. 복잡한 라이브러리 또는 다른 라이브러리를 임의로 삽입하면 네임 스페이스가 오염되고 잠재적으로 다른 사람의 사이트가 손상 될 수 있습니다. 어쨌든 일부 광고주를 지나치지 않을 것입니다.

프레임 워크가 이미 존재하고 동등하게 능력이있는 경우 프레임 워크를 추가하는 것을 거부합니다. 나는 그것을 너무 자주보고 그것은 내 애완 동물 증오이며 부당한 팽창으로 생각합니다. 그것은 완전히 또 다른 질문입니다.

그 외에는 정당한 이유를 생각할 수 없습니다.

---

파일 크기-그러나 실제로는 크로스 플랫폼 자바 스크립트 및 브라우저 차이에 대한 절대 신의 선물입니다. 툴킷에서 원하지 않는 (또는 근본주의적인 개발자 바보가되는) 몇 가지 좋은 이유가 있어야합니다.

---

• 파일 크기를 정당화 할 수 없습니다 (제공된 추상화를 사용하지 않는 스크립트보다 적더라도).
• 그들은 타사 도구에 의존하기를 원하지 않습니다.
• 그들의 사업은 (어떤 이유로 든) 어떤 라이브러리도 운영하기를 원하지 않습니다.
• 그들의 비즈니스는 직원이 작성하지 않은 JavaScript 코드를 실행하고 싶지 않습니다.

---

• 학습 : 실제로 모든 것을 코딩하고 더 많은 것을 배우십시오. (미리 코딩 된 것을 사용하는 대신)
• 크기 : jQuery에는 필요하지 않을 수있는 기능이 많이 있습니다. 사용하지 않을 경우 사용자가 많은 코드를 다운로드하게하는 이유는 무엇입니까?
• 대안 : 이 시점에서 수십 개의 더 강력하고 잘 구성된 웹 프레임 워크가 있습니다.
• 유연성 : jQuery는 매우 유연하지만 제공하지 않는 것이 필요할 수 있습니다.

---

꼭 jQuery를 좋아하지만 jQuery를 사용하지 않는 데에는 몇 가지 이유가 있습니다.

1. 다운로드 크기 / 대역폭 : jQuery 1.5는 이제 압축되지 않은 상태에서 200K가 넘습니다. 일부 라이브러리 크기는 이점을 정당화하기에는 너무 큽니다.
2. 성능 : 네이티브 JS 작성은 라이브러리 뒤에서 추상화하는 것보다 항상 빠릅니다.
3. 복잡성 추가 : 많은 사람들이 실제로 몇 가지 깔끔한 기능 만 필요할 때 전체 jQuery 라이브러리를 다운로드합니다.
4. 응용 프로그램 종속성 : 종속성을 도입하면 항상 중단이 발생합니다. jQuery에 버그가있는 경우 파일을 디버그하고 편집 할 수 있지만 나중에 업그레이드하면 문제가 발생합니다. 버그를 떠날 수는 있지만 이제는 수정을 위해 jQuery의 시간표에 의존하고 있습니다.

---

종종 불필요하기 때문입니다. 내가 원하는 것은 일부 입력의 유효성을 검사하거나 일부 필드를 강조하는 것뿐이라면 간단한 javascript / dom 코드를 작성하는 것만 큼 쉽습니다. 그리고 jQuery는 이러한 간단한 경우에는 실제로 도움이되지 않으므로 왜 사용 하는가?

분명히 매우 유용한 경우가 많이 있지만 때로는 사람들이 실제 이유없이 사용하는 것처럼 보입니다.

---

I would prefer to use jquery for dom manipulation or traversing the dom , which is really easy with jquery . Moreover, attaching an event or event delegation are so easy using jquery or other framework otherwise you have to write custom event attachment for IE or non IE browsers etc.

But it has some performance penalty when you use $.each instead of vanilla JS for and array.push()... other issues like if you bind an event and remove that without unbind it will have memory leak....

My conclusion is only use any framework for complex dom manipulation and rest use vanilla JS

---

Why not use jQuery?

I can't think of a good excuse to use vanilla JavaScript over jQuery (aside from the intimidation factor of learning something new), but some people prefer other JavaScript frameworks (like the excellent MooTools) due to the philosophical differences between them.

Some people simply don't like jQuery's DSL-ish syntax, but they recognize the importance of using a robust JavaScript framework.

Personally, I love jQuery, but I know people who use other frameworks and are no less productive.

참고URL : https://stackoverflow.com/questions/5099949/what-are-some-empirical-technical-reasons-not-to-use-jquery