jQuery를 사용하지 않는 경험적인 기술적 이유는 무엇입니까?
컨텍스트:저는 HTML, 자바스크립트, CSS를 하루 종일 해킹하고 jQuery(또는 다른 동등한 도우미 프레임워크)와 같은 도구를 무시하고 사용을 거부하는 프론트엔드 개발자의 수에 충격을 받았습니다.자바스크립트 gurus를 말하는 것이 아니라 Joe production developers를 매일 참호에서 이야기하는 것입니다.저는 변명이나 개인적인 의견에 가까운 주장을 많이 받지만, 기술적인 장점이 없다고 생각합니다. 저는 제가 무언가를 놓치고 있지 않은지 확인하고 싶습니다.
질문:jQuery를 사용하지 않는 경험적인 기술적 이유는 무엇입니까?
저는 종교적이거나 독단적인 논쟁이나 주관적인 의견을 찾고 있지 않습니다. "다른 틀이 더 나은 것처럼" jQuery를 질문의 모든 유사한 틀에 대한 빨대맨으로 간주합니다.
2015년 업데이트:
2011년의 이 답변에서 저는 jQuery, YUI 또는 Prototype과 같은 라이브러리에 대해 이야기하고 있습니다.2015년 현재에도 그러한 추론은 Angular, React 또는 Ember와 같은 프레임워크에 여전히 적용 가능합니다.그 4년 동안 기술은 엄청나게 발전했고, 비록 제가 JQuery나 YUI에 대해 본 것보다 리액터 앵글에 대한 편견은 상당히 적었지만, 같은 종류의 사고는 오늘날에도 여전히 존재합니다.
2016년 업데이트:
며칠 전에 발표된 기사를 적극 추천합니다.
- 왜 jQuery인가요? 마이클 S.싱글 페이지 웹 애플리케이션 북의 저자인 Mikowski
그 기사는 기본적으로 바로 이 질문에 대한 매우 상세한 답변입니다.만약 제가 아래에 답을 쓸 때 그것을 사용할 수 있었다면 - 저는 분명히 그것을 인용했을 것입니다.
원래 답변:
jQuery에 대해 답변하겠지만, 그것들은 제가 YUI, Prototype, Dojo, Ext 등을 사용하는 것에 반대하는 것과 같은 주장입니다.내가 들은 주요 주장들:
파일 크기는 사실상 jQuery 3.2.1의 경우 84.6 KB입니다. 아마도 평균 웹사이트의 로고보다 작고 Google의 CDN에서 제공될 수 있습니다. 대부분의 방문자는 이미 캐시에 저장되어 있을 가능성이 높습니다.jQuery를 사용하는 것은 항상 자신의 자바스크립트 파일의 파일 크기가 작다는 것을 의미하므로 브라우저 캐시에 아직 없을지라도 실제로는 더 작은 다운로드를 의미할 수 있습니다.
속도 - 순수 자바스크립트를 쓰는 것이 더 빠를지 모르지만, 대부분의 사람들은 휴대용 자바스크립트를 쓰는 것이 불가능해 보입니다.더 빠르지만 모든 인기 있는 브라우저에서 작동하지 않는 웹사이트는 현실에서는 쓸모가 없습니다.jQuery 이외에도 실제로는 꽤나 빠른 속도를 내기 위해 상당히 무거운 최적화를 사용하고 있으며, 매 릴리스마다 훨씬 더 빨라지고 있기 때문에 사소한 예를 제외하고 직접 코드를 작성하는 것은 실제로 그리 쉽지 않습니다. (*)
한 회사가 다른 사람의 코드를 사용하는 것을 두려워하는 반면, 사실 jQuery는 오픈 소스이며 자유 소프트웨어로서 여러분의 할머니의 블로그에서 아마존, 트위터에서 뱅크 오브 아메리카, 구글에서 마이크로소프트에 이르기까지 어디에서나 사용할 수 있다면 어떤 회사든 사용할 수 있습니다.
저는 다른 논쟁이 심각하게 사용되는 것을 들은 기억이 없습니다.
(*) 여기 간단한 예가 있습니다. getElementById('someid') vs. jQuery('#someid')
getElementById를 사용하는 것이 더 빠릅니까?물론 모든 사람이 Blackberry 4.6이 문서에 더 이상 없는 노드를 반환할 때 항상 상위 노드를 확인합니다. 그렇죠? jQuery가 확인합니다.그리고 IE와 오페라가 ID가 아닌 이름으로 아이템을 반납하는 경우는 모두가 처리하죠? jQuery가 처리합니다.그렇게 하지 않으면 코드를 휴대할 수 없기 때문에 찾기가 매우 어려울 수 있는 미묘한 버그가 발생합니다.getElementById는 이벤트나 AJAX, DOM에 대해서는 시작조차 하지 않는 가장 사소한 예입니다.
업데이트:
실제로 jQuery를 사용하고 싶지 않은 이유를 묻는 네 번째 결과가 있습니다.제가 이 목록에 넣는 것을 잊어버린 이유는 그것이 사실은 답이 아니라 답이 없기 때문입니다.어제 받은 댓글을 보고 생각이 났습니다.이는 목록에 "기술적인 이유"로 추가되는 것은 아니지만, 그럼에도 불구하고 흥미로울 수 있으며 실제로 가장 일반적인 반응일 수 있습니다.
하지만 제가 개인적으로 이 모든 반응의 근본적인 이유라고 의심하는 것은 컴퓨터 과학의 진보에 가장 큰 장애물이라고 생각하는 것입니다. "전 그런 적이 없기 때문에 그것을 사용하고 싶지 않습니다. 그러므로 그것은 그렇게 중요하지 않을 것입니다."
한때는 어셈블러, 컴파일러, 구조화된 프로그래밍, 고급 언어, 가비지 컬렉션, 객체 지향 프로그래밍, 폐쇄 등 우리가 당연하게 여기는 거의 모든 것에 대한 반응이었고, 오늘날에는 AJAX 라이브러리가 되었습니다.아마도 언젠가는 아무도 우리가 한 때 애플리케이션 레벨에서 원시 DOM API와 수동으로 상호 작용했다는 것을 기억하지 못할 것입니다. 지금처럼 아무도 우리가 한 때 원시, 꾸밈없는, 이해할 수 없는 16진수를 사용하여 프로그램을 작성하곤 했다는 것을 기억하지 못할 것입니다.
jQuery는 모든 것을 오해의 소지가 있고 애플리케이션 패턴으로 표현할 필요가 없는 DOM 중심의 패러다임으로 표현합니다.
많은 개발자들이 이러한 DOM 중심의 패턴으로 스스로 프로그래밍을 하게 되고 결국 확장하거나 재사용할 수 있는 어떤 것도 만들지 못했다는 것을 깨닫게 됩니다.
레베카 머페이는 jQuery에서 Dojo로 전환한 그녀 자신의 멋진 글을 가지고 있습니다 - 블로그 게시물은 왜 jQuery가 아닌지와 왜 Dojo에 관한 것입니다.
프레임워크를 사용하지 않는 한 가지 이유는 배너와 같은 다른 웹 사이트에 내장 가능한 코드를 작성하는 경우입니다.복잡한 라이브러리를 임의로 삽입하는 것은 네임스페이스를 오염시키고 다른 사람의 사이트를 손상시킬 가능성이 있습니다.어쨌든 광고주들을 제치고 시도해 보지는 않을 거야, 연못에 빠진 쓰레기 같은 놈들 말이야, 하지만 나는...
저는 프레임워크가 이미 존재하고 동등한 능력을 갖추고 있을 때 추가하는 것을 반대합니다.나는 그것을 너무 자주 보는데 그것은 나의 애완동물 혐오입니다. 나는 그것이 부당한 붓기라고 봅니다.그것은 완전히 다른 질문입니다.
그 외에는 하지 말아야 할 정당한 이유를 생각할 수 없습니다.
파일 크기 - 하지만 그 이상으로 크로스 플랫폼 자바스크립트와 브라우저 차이에 대한 절대적인 신의 보냄입니다.툴킷에서 그것을 원하지 않는 아주 좋은 이유가 있어야 할 것입니다(또는 근본주의 개발자 바보가 될 수도 있습니다.
- 파일 크기를 정당화할 수 없습니다(제공된 추상화를 활용하지 않는 스크립트보다 작을지도 모르지만).
- 타사 툴에 의존하고 싶지 않습니다.
- 그들의 사업체는 어떤 이유로든 어떠한 라이브러리도 운영하고 싶어하지 않습니다.
- 그들의 사업체는 직원들이 작성하지 않은 어떠한 자바스크립트 코드도 실행하기를 원하지 않습니다.
- 학습:실제로 모든 것을 코딩하고, 더 많은 것을 배우기 위해. (사전 코딩된 것을 사용하는 것보다)
- 크기: jQuery에는 필요하지 않을 수도 있는 수많은 기능이 있습니다. 사용하지 않을 경우 사용자가 코드를 그렇게 많이 다운로드하게 만드는 이유는 무엇입니까?
- 대안: 현 시점에서 수십 개의 강력하고 잘 구성된 웹 프레임워크가 있습니다.
- 유연성:jQuery가 정말 유연하긴 하지만, 제공되지 않는 것이 필요할 수도 있습니다.
저는 jQuery를 좋아하지만 jQuery를 사용하지 않는 이유가 있습니다.
- 다운로드 크기/대역폭: jQuery 1.5는 이제 압축되지 않은 상태로 200K를 넘었습니다. 라이브러리 크기가 너무 커서 이점을 정당화할 수 없습니다.
- 성능:네이티브 JS를 쓰는 것은 항상 라이브러리 뒤에서 추상화하는 것보다 빠를 것입니다.
- 복잡성 추가:많은 사람들이 jQuery 라이브러리에서 몇 가지 깔끔한 기능만 필요로 할 때 전체 jQuery 라이브러리를 다운로드 할 것입니다.
- 응용프로그램 종속성:의존성을 도입하는 데는 항상 문제가 있습니다.jQuery에 버그가 있으면 파일을 디버깅하고 편집할 수 있지만 나중에 업그레이드하면 문제가 발생합니다.버그를 방치할 수도 있지만, 이제는 jQuery의 타임테이블에 의존해서 수정할 수 있습니다. 자신의 것이 아니라요.
왜냐하면 그것은 단지 불필요한 경우가 많기 때문입니다. 제가 원하는 것은 입력을 검증하거나 필드를 누르는 것뿐이라면 단순한 자바스크립트/돔 코드를 작성하는 것만큼 쉽습니다.그리고 jQuery는 그런 간단한 경우에는 별로 도움이 되지 않는데, 문제는 왜 그것을 사용하는가 하는 것입니다.
분명히 그것이 매우 유용한 경우가 많지만, 때때로 사람들은 진짜 이유 없이 그것을 사용하는 것 같습니다.
저는 돔 조작이나 돔 횡단을 위해 jquery를 사용하는 것을 선호합니다. jquery는 정말 쉽습니다. 게다가 이벤트나 이벤트 위임을 첨부하는 것은 jquery나 다른 프레임워크를 사용하면 매우 쉽습니다. 그렇지 않으면 IE 또는 non IE 브라우저를 위한 사용자 지정 이벤트 첨부 파일을 작성해야 합니다.
그러나 vanilla JS for and array.push(...) 대신 $.each를 사용하면 성능 저하가 발생합니다. 이벤트를 바인딩하고 바인딩을 해제하지 않고 제거하면 메모리 누수가 발생합니다.
제 결론은 복잡한 돔 조작을 위한 프레임워크를 사용하고 바닐라 JS를 사용하는 것입니다.
왜 jQuery를 사용하지 않습니까?
jQuery보다 바닐라 자바스크립트를 사용하는 좋은 핑계는 생각나지 않지만(새로운 것을 배울 때의 위협 요소를 제외하고), 어떤 사람들은 그들 사이의 철학적 차이 때문에 (뛰어난 MooTools와 같은) 다른 자바스크립트 프레임워크를 선호합니다.
어떤 사람들은 단순히 jQuery의 DSL과 같은 구문을 좋아하지 않지만, 강력한 자바스크립트 프레임워크를 사용하는 것의 중요성을 인식합니다.
개인적으로 저는 jQuery를 좋아하지만 다른 프레임워크를 사용하고 생산성이 떨어지는 사람들을 알고 있습니다.
언급URL : https://stackoverflow.com/questions/5099949/what-are-some-empirical-technical-reasons-not-to-use-jquery
'programing' 카테고리의 다른 글
| 괄호가 "typedefint (f)(void)"인 typedef는 무엇을 의미합니까?기능 시제품입니까? (0) | 2023.11.04 |
|---|---|
| 자바스크립트로 소리 알림 재생? (0) | 2023.11.04 |
| 파워셸에서 @()의 의미는 무엇입니까? (0) | 2023.10.30 |
| Cree(): 포인터가 잘못되었습니다. (0) | 2023.10.30 |
| 하나의 SQL 조회에서 모든 상위 행 가져오기 (0) | 2023.10.30 |