제이쿼리 등장 시점(2006)의 웹 개발 문제
- 자바스크립트의 돔 선택, 이벤트 핸들링, 돔 수정 코드가 난잡함
- 오늘날처럼 css 선택자가 제대로 지원되지 않았고, 이벤트 할당도 불편했음.
- 브라우저간 호환성 문제, 이로 인한 반복적인 에러 핸들링 코드 작성
- getElementsByTagName() 같은 간단한 API도 브라우저마다 호환 여부가 달랐기 때문에 조건문으로 검사하는 코드가 반복적으로 작성됨
- AJAX, Animation 등 일부 최신 기능의 미지원. 그로 인해 JS단에서 setInterval이나 setTimeOut으로 기능을 직접 구현함. 이로인한 생산성 저하, 성능 저하
=> 이런 상황에서 해결책으로서 제이쿼리의 등장
제이쿼리가 주목받은 이유
- 적은 코드로 셀렉터, 이벤트 설정, 돔 조작이 가능
- 브라우저간 비호환성 해결 => 에러 코드 작성 감소
- AJAX, CSS 선택자 지원, 일부 애니메이션의 숏컷 메소드 지원
- 당시는 라이브러리의 문서화가 생소했으나 제이쿼리는 문서로 정리되어 접근성이 우수
- JQuery UI처럼 우수한 플러그인 지원(다양한 UI, 현재는 유지보수 모드)
=> 개발 뿐만 아니라 솔루션의 측면에서 제이쿼리가 널리 사용
쇠퇴와 현재의 위치
javascript와 css의 발전
- 제이쿼리 코드 대부분은 바닐라 js와 css로 대체 가능
바인딩 및 SPA 라이브러리와 프레임워크의 발전
- 가상돔(React, Vue)이나 angular, svelte 같은 최적화된 돔 조작 라이브러리 등장
- 실제 돔을 조작하는 제이쿼리가 안티 패턴으로 인식(전통적인 정적 컨텐츠 중심 사이트는 제이쿼리 사용)
구형 ie 등의 점진적 감소, 바벨 등의 컴파일러 이용으로 호환성 해결
=> 레거시
제이쿼리로 신규 프로젝트는 생성x
대신, 구형 프로젝트 유지 보수와 마이그레이션을 위해 사용됨
여기까지 봤을 때 제이쿼리는 신규 프로젝트를 위해 적극적으로 배우기보단, 구형 프로젝트의 관리를 위해 가볍게 배우는 정도면 충분할 것 같다. 정부 프로젝트나 SI 등에서 코드를 읽고 한정적으로 사용할 수 있도록.
아직 많은 사이트가 jquery를 사용하긴 하나, npm trend를 보면 그 다운로드 숫자는 계속 감소 추세다.
설치 방법
홈페이지에서 가이드 참조
크게 세 가지 방법이 있다.
- 스크립트 파일 다운 후 프로젝트에 직접 추가
- 패키지 매니저(npm, yarn) + 모듈 번들링
- CDN(ex: google code)으로 연결
참고. 각 방법의 장단점
CDN
외부 서버에 호스팅된 파일을 제공하는 서비스다.
호스팅 서버에서 버전을 관리하므로 직접 라이브러리 버전 관리를 할 필요가 없다. 속도 부분은 유의미한 수준의 차이는 없다.
단, CDN 서버가 불안정하면 문제가 생긴다.
script로 직접 삽입
CDN 네트워크에 의존성이 없어서 안정적이고 직접 버전을 관리할 수 있다.
버전 관리를 직접해야 하는게 번거롭다.
모듈+번들링
직접 프로젝트에 추가하는 방식이나, 의존성 버전 관리가 간편하다.
모듈 번들링으로 용량을 줄일 수 있다.(그런데, 이 부분은 확실할지 잘 모르겠다.)
스크립트는 개발자 버전과 프로덕트 버전(min.js)으로 나뉜다.
개발자 버전은 압축되어 있지 않고 디버깅에 용이하다.
반면, 프로덕트 버전은 압축되어 있어서 파일 크기가 작다.
참고 자료
'Jquery' 카테고리의 다른 글
| [JQuery] JQuery의 주요 컨셉 및 api 정리 (0) | 2024.04.04 |
|---|