현재버전

일단 절대적인 것은 없다는 전제로, 제이쿼리가 장기적으로 사장될 가능성이 높은 기술인 건 분명하다고 봅니다.

가장 큰 이유는 본문에서 언급한 성능보다는 현재 유행하는 개발 흐름과 맞지 않기 때문입니다.

풀어서 말하면, 요즘 프론트엔드 기술은 대체적으로 어떤 상태값을 바탕으로 화면을 '렌더링'한다는 개념으로 접근하는 경우가 많습니다.

그리고 그런 접근에서 상태의 변화를 감지해서 화면을 갱신하는 흐름을 무시하고 외부에서 제이쿼리 같은 라이브러리로 DOM을 직접 조작하는 것은 금기시하는 방식입니다.

또한, 대부분의 주요 프론트엔드 기술은 컴포넌트 기반으로 한 재사용을 지향하고 있기 때문에 컴포넌트의 동작과 렌더링에 필요한 모든 것을 컴포넌트 경계 안에 가두려고 하는 경향이 있습니다.

반면 제이쿼리는 태생부터 CSS 셀렉터로 임의의 DOM을 잡아서 무언가 조작을 하겠다는 개념이기 때문에 그런 접근과 충돌할 가능성이 높습니다.

그리고 전통적으로 제이쿼리를 쓰는 이유는 방금 언급한 CSS 셀렉터를 폭넓게 사용해서 DOM 조작을 할 수 있다는 점, 그리고 다양한 플러그인이 있다는 점 두 가지 정도를 들 수 있는데, 첫 번째는 요즘 대부분의 브라우저가 네이티브하게 동일 기능을 지원해서, 그리고 두 번째는 리액트 등 현대적 프론트엔드 기술도 관련 생태계가 충분히 발전했기 때문에 더 이상 큰 장점이라 하기 어렵습니다.

또한, 이러한 생태계의 변화는 단순히 이젠 다른 기술을 제이쿼리 만큼 편리하게 쓸 수 있다는 것에 그치는 것이 아니라, 앞으로 점점 제이쿼리 관련 플러그인 등은 신규 발표나 업데이트가 드물게 일어난다는 것을 뜻하기도 합니다.

종합해보면, 단순히 기능이나 성능 비교를 할 것이 아니라 접근 방법이나 생태계의 변화를 고려하면 제이쿼리가 사양 기술임은 부정할 수 없다고 봅니다.

수정이력

2021-11-19 15:16:51 에 아래 내용에서 변경되었습니다.

일단 절대적인 것은 없다는 전제로, 제이쿼리가 장기적으로 사장될 가능성이 높은 기술인 건 분명하다고 봅니다.

가장 큰 이유는 본문에서 언급한 성능보다는 현재 유행하는 개발 흐름과 맞지 않기 때문입니다.

풀어서 말하면, 요즘 프론트엔드 기술은 대체적으로 어떤 상태값을 바탕으로 화면을 '렌더링'한다는 개념으로 접근하는 경우가 많습니다.

그리고 그런 접근에서 상태의 변화를 감지해서 화면을 갱신하는 흐름을 무시하고 외부에서 제이쿼리 같은 라이브러리로 DOM을 직접 조작하는 것은 금기시하는 방식입니다.

또한, 대부분의 주요 프론트엔드 기술은 컴포넌트 기반으로 재사용을 지향하고 있기 때문에 컴포넌트의 동작과 렌더링에 필요한 모든 것을 컴포넌트 경계 안에 가두려고 하는 경향이 있습니다.

반면 제이쿼리는 태생부터 CSS 셀렉터로 임의의 DOM을 잡아서 무언가 조작을 하겠다는 개념이기 때문에 그런 접근과 충돌할 가능성이 높습니다.

그리고 전통적으로 제이쿼리를 쓰는 이유는 방금 언급한 CSS 셀렉터를 폭넓게 사용해서 DOM 조작을 할 수 있다는 점, 그리고 다양한 플러그인이 있다는 점 두 가지 정도를 들 수 있는데, 첫 번째는 요즘 대부분의 브라우저가 네이티브하게 동일 기능을 지원해서, 그리고 두 번째는 리액트 등 현대적 프론트엔드 기술도 관련 생태계가 충분히 발전했기 때문에 더 이상 큰 장점이라 하기 어렵습니다.

또한, 이러한 생태계의 변화는 단순히 이젠 다른 기술을 제이쿼리 만큼 편리하게 쓸 수 있다는 것에 그치는 것이 아니라, 앞으로 점점 제이쿼리 관련 플러그인 등은 신규 발표나 업데이트가 드물게 일어난다는 것을 뜻하기도 합니다.

종합해보면, 단순히 기능이나 성능 비교를 할 것이 아니라 접근 방법이나 생태계의 변화를 고려하면 제이쿼리가 사양 기술임은 부정할 수 없다고 봅니다.

2021-11-19 15:13:36 에 아래 내용에서 변경되었습니다.

일단 절대적인 것은 없다는 전제로, 제이쿼리가 장기적으로 사장될 가능성이 높은 기술인 건 분명하다고 봅니다.

가장 큰 이유는 본문에서 언급한 성능보다는 현재 유행하는 개발 흐름과 맞지 않기 때문입니다.

풀어서 말하면, 요즘 프론트엔드 기술은 대체적으로 어떤 상태값을 바탕으로 화면을 '렌더링'한다는 개념으로 접근하는 경우가 많습니다.

그리고 그런 접근에서 상태의 변화를 감지해서 화면을 갱신하는 흐름을 무시하고 외부에서 제이쿼리 같은 라이브러리로 DOM을 직접 조작하는 것은 금기시하는 방식입니다.

또한, 대부분의 주요 프론트엔드 기술은 컴포넌트 기반으로 재사용을 지향하고 있기 때문에 컴포넌트의 동작과 렌더링에 필요한 모든 것을 컴포넌트 경계 안에 가두려고 하는 경향이 있습니다.

반면 제이쿼리는 태생부터 CSS 셀렉터로 임의의 DOM을 잡아서 무언가 조작을 하겠다는 개념이기 때문에 그런 접근과 충돌할 가능성이 높습니다.

그리고 전통적으로 제이쿼리를 쓰는 이유는 방금 언급한 CSS 셀렉터를 폭넓게 사용해서 DOM 조작을 할 수 있다는 점, 그리고 다양한 플러그인이 있다는 점 두 가지 정도를 들 수 있는데, 첫 번째는 요즘 대부분의 브라우저가 네이티브하게 동일 기능을 지원해서, 두 번째는 리액트 등 현대적 프론트엔드 기술도 관련 생태계가 충분히 발전했기 때문에 더 이상 큰 장점이라 하기 어렵습니다.

또한, 이러한 생태계의 변화는 단순히 이젠 다른 기술을 제이쿼리 만큼 편리하게 쓸 수 있다는 것에 그치는 것이 아니라, 앞으로 점점 제이쿼리 관련 플러그인 등은 신규 발표나 업데이트가 드물게 일어난다는 것을 뜻하기도 합니다.

종합해보면, 단순히 기능이나 성능 비교를 할 것이 아니라 접근 방법이나 생태계의 변화를 고려하면 제이쿼리가 사양 기술임은 부정할 수 없다고 봅니다.

2021-11-19 15:13:01 에 아래 내용에서 변경되었습니다.

일단 절대적인 것은 없다는 전제로, 제이쿼리가 장기적으로 사장될 가능성이 높은 기술인 건 분명하다고 봅니다.

가장 큰 이유는 본문에서 언급한 성능보다는 현재 유행하는 개발 흐름과 맞지 않기 때문입니다.

풀어서 말하면, 요즘 프론트엔드 기술은 대체적으로 어떤 상태값을 바탕으로 화면을 '렌더링'한다는 개념으로 접근하는 경우가 많습니다.

그리고 그런 접근에서 상태의 변화를 감지해서 화면을 갱신하는 흐름을 무시하고 외부에서 제이쿼리 같은 라이브러리로 DOM을 직접 조작하는 것은 금기시하는 방식입니다.

또한, 대부분의 주요 프론트엔드 기술은 컴포넌트 기반으로 재사용을 지향하고 있기 때문에 컴포넌트의 동작과 렌더링에 필요한 모든 것을 컴포넌트 경계 안에 가두려고 하는 경향이 있습니다.

반면 제이쿼리는 태생부터 임의의 CSS 셀렉터로 DOM을 잡아서 무언가 조작을 하겠다는 개념이기 때문에 그런 접근과 충돌할 가능성이 높습니다.

그리고 전통적으로 제이쿼리를 쓰는 이유는 방금 언급한 CSS 셀렉터를 폭넓게 사용해서 DOM 조작을 할 수 있다는 점, 그리고 다양한 플러그인이 있다는 점 두 가지 정도를 들 수 있는데, 첫 번째는 요즘 대부분의 브라우저가 네이티브하게 동일 기능을 지원해서, 두 번째는 리액트 등 현대적 프론트엔드 기술도 관련 생태계가 충분히 발전했기 때문에 더 이상 큰 장점이라 하기 어렵습니다.

또한, 이러한 생태계의 변화는 단순히 이젠 다른 기술을 제이쿼리 만큼 편리하게 쓸 수 있다는 것에 그치는 것이 아니라, 앞으로 점점 제이쿼리 관련 플러그인 등은 신규 발표나 업데이트가 드물게 일어난다는 것을 뜻하기도 합니다.

종합해보면, 단순히 기능이나 성능 비교를 할 것이 아니라 접근 방법이나 생태계의 변화를 고려하면 제이쿼리가 사양 기술임은 부정할 수 없다고 봅니다.

cat-footer