jQuery v4.0 베타 버전

 (blog.jquery.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • IE 10 이하 지원이 제거되고 Edge Legacy, iOS <11, Firefox <65, Android Browser 지원도 중단됨
  • 여러 버전 동안 지원 중단(deprecation) 상태였던 API가 제거됨: jQuery.cssNumber, jQuery.cssProps, jQuery.isArray, jQuery.parseJSON, jQuery.nodeName, jQuery.isFunction, jQuery.isWindow, jQuery.camelCase, jQuery.type, jQuery.now, jQuery.isNumeric, jQuery.trim, jQuery.fx.interval
  • jQuery 프로토타입의 내부용 Array 메서드였던 push, sort, splice 가 제거되어 해당 메서드에 의존한 플러그인에 영향 가능성
  • focusout, blur, focusin, focus 관련 이벤트 순서에서 jQuery의 기존 오버라이드가 제거되고, IE를 제외한 브라우저가 현재 W3C 순서인 blur → focusout → focus → focusin을 따름
  • jQuery.ajax가 바이너리 데이터와 FormData 를 지원하며, 이전처럼 알 수 없는 데이터 타입으로 보고 문자열로 변환하던 동작이 자동 처리로 변경됨
  • dataType: "json"과 콜백이 함께 제공될 때 JSONP 요청으로 자동 승격하던 jQuery.ajax 동작이 제거됨
  • jQuery 소스가 AMD에서 ES modules로 마이그레이션됐고, 패키징 도구가 RequireJS에서 Rollup으로 전환됨
  • Trusted Types 지원이 추가되어 TrustedHTML로 감싼 HTML을 require-trusted-types-for CSP 지시문 위반 없이 jQuery 조작 메서드 입력으로 사용 가능함
  • 대부분의 비동기 스크립트 요청이 <script> 태그를 사용하도록 바뀌어 인라인 스크립트 사용으로 인한 CSP 오류를 피하도록 변경됨
  • slim 빌드에서 Deferreds와 Callbacks가 제거되어 gzip 기준 20k bytes 미만이 되었고, 일반 빌드보다 약 8k gzipped bytes 작음
  • IE11 지원이 필요하면 slim 빌드 대신 main 빌드를 쓰거나 native Promises 폴리필을 추가하는 구성이 권장됨
  • 정식 릴리스 전 종합 업그레이드 가이드가 공개될 예정이며, jQuery Migrate plugin이 마이그레이션 보조용으로 준비될 예정임
  • 베타 릴리스는 jQuery CDN과 npm에서 제공되며, 서드파티 CDN은 베타를 호스팅하지 않고 4.0.0 정식 릴리스를 나중에 호스팅할 예정임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 2024년 이후에도 jQuery를 움직이는 힘이 궁금하다면, WordPress가 여전히 웹의 1/3 이상이고 대부분의 설치본과 수많은 플러그인이 jQuery에 크게 의존한다는 점을 기억해야 함
    폐기 예정 API나 함수 제거가 진전되는 건 좋고, jQuery는 앞으로도 몇 년간 웹에서 지배적으로 남아 있을 가능성이 큼

    • 게다가 jQuery는 훌륭함
      지난 15년쯤 업계는 지나치게 복잡하고 화려한 JavaScript 프레임워크에 빠져 있었지만, 동적으로 생성된 폼에 동적 바인딩을 걸고 오류 상태를 처리하며 Ajax 호출 몇 번 하는 정도가 웹 페이지 99%에 필요한 JavaScript의 전부이고 나머지는 과한 경우가 많음
      업계는 React의 복잡성에서 벗어나 htmx, Phoenix LiveView, Ruby on Rails Turbo, 그리고 그냥 jQuery 같은 단순함으로 이동하게 될 것 같음
    • 누가 뭐라 해도 jQuery는 여전히 강력하고 중요하며 영향력이 큼
      모든 소프트웨어에서 jQuery를 제거하면 인터넷 곳곳의 웹사이트 상당수가 멈출 것임
    • WordPress만의 문제가 아님
      예전에 다니던 회사는 엔터프라이즈 SaaS 제품을 수만 줄의 jQuery 코드로 운영했음
      꼭 필요해지지 않는 한 최신 JS 프레임워크로 다시 쓰는 일은 일어나지 않을 것임. 대부분은 10년도 더 전에 특정 고객 요구에 맞춰 작성된 코드이고, 최신 프레임워크를 쓰면 채용에 도움이 된다는 논리도 통하지 않음. 회사는 프런트엔드 엔지니어에게 7.5만~9만 달러만 지급하고 이직률도 낮으며, 현재 엔지니어 대부분이 5년 이상 근무 중임
      무엇보다 현재 스택이 잘 동작하고 오래된 고객들도 만족함. 소프트웨어 엔지니어링의 상당 부분은 Bay Area나 Seattle 같은 빅테크 허브보다 생활비가 훨씬 낮은 도시의 이런 지루한 비즈니스에서 일어남
    • WordPress 개발자는 기술 업계의 배관공 같음
      화려하진 않지만 필요한 사람이 너무 많아서 돈은 많이 벌 수 있음
      언젠가 최신 유행을 좇는 빅테크 스타트업 세계에서 은퇴한다면, 정직하게 돈 벌며 WordPress 사이트를 만들고 매일 오후 3시에 일을 마무리하고 싶음
    • 얼마 전 HN에 올리려다 말았는데, DOM 멤버와 추상 클래스 인스턴스가 서로 바꿔 쓸 수 있는 이벤트를 트리거할 수 있게 해주는 훌륭한 이벤트 체인 처리/버블링 모델을 아직도 못 찾고 있음
      여기저기서 직접 이벤트 디스패처를 만들었지만 jQuery는 이 부분을 제대로 해냄. 지금도 거의 이벤트 처리에만 jQuery를 쓰지만 너무 유용해서 거의 모든 클라이언트 측 프로젝트에 포함
      묻고 싶었던 건 $(window).trigger('click')와 $(myClassInstance).trigger('myCustomEvent',{data})를 같은 API로 비동기 리스닝까지 처리할 수 있는 가벼운 라이브러리를 아는 사람이 있는지였음
      fetch()와 CSS 선택자의 부상 덕분에 이제 jQuery의 나머지는 없어도 될 것 같지만, 굳이 바퀴를 다시 만들 필요가 있나 싶음. 클래스 인스턴스가 이벤트를 디스패치하는 건 코드 냄새라고 하기 전에, 반응형 프레임워크를 처음부터 만들려면 반드시 필요함
      예를 들어 내 기본 컴포넌트 클래스는 자신을 포함한 화면에서 발생하는 특정 커스텀 resize 이벤트를 듣고, 그 화면은 스크롤되지 않으면서 내부를 재배치해야 하는 컴포넌트에만 이벤트를 보냄. 화면 클래스는 window.resize를 듣지만 레이아웃이 곤란할 때만 디스패치함. 모든 컴포넌트에 개별 DOM resize 리스너를 window에 붙이는 건 말이 안 됨

  • HN에서 jQuery를 단순한 DOM 선택 라이브러리로 보는 사람이 꾸준히 보여서 놀라움
    실제로는 널리 지원되고 매우 안정적인 도구 모음이며, DOM 선택뿐 아니라 속성 조작, Ajax 요청, 이벤트 처리, 애니메이션, 범용 유틸리티 함수까지 제공함
    게다가 jQuery를 대체하는 네이티브 기능이 있더라도 API가 그만큼 유려하지는 않음
    서버 측 HTML 위에 약간의 기능만 더하면 되고 완전한 JS UI 프레임워크까지는 필요 없는 작업이라면, jQuery는 안정적이고 신뢰할 수 있으며 브라우저 간 호환되는 의존성으로서 작은 대가에 불과함

    • 몇 년 전 jQuery를 버리고 순수 JavaScript로 옮긴 뒤 한 번도 돌아보지 않았음
      네이티브 JS에는 jQuery가 가진 것이 다 있고, 대개 관리가 부실하고 반쯤만 완성된 플러그인 더미만 없을 뿐임. 그런 플러그인은 보통 자기들이 하려는 것만 하고 그 외에는 별로 해주지 않음
      순수 선택자가 더 장황하긴 하지만 웬만한 코드 편집기라면 입력 속도는 똑같이 맞춰줌. 따지려는 건 아니지만 왜 아직도 그렇게 많은 사람이 jQuery를 쓰는지 잘 이해되지 않음
      https://youmightnotneedjquery.com/
    • HN 작성자층을 보면 그렇게 놀랍지는 않음
      DOM 선택 조금 이상이 필요해지면 바로 그때 유행하는 대형 JS 프레임워크를 집어 드는 사람이 많고, 늘 그렇게 해왔기 때문임
    • “jQuery가 그냥 DOM 선택 라이브러리라고 보는 사람들”이라고 해놓고는, 이어서 선택과 네이티브 함수들을 나열하고 있음
    • 프로젝트에 jQuery를 넣는 편이 훨씬 쉬움
      빌드 도구와 그에 딸린 골치 아픈 것들이 필요 없음. React도 그렇게 할 수는 있지만 제공 기능이 비교 대상은 아님

  • 많은 사람이 jQuery의 마지막 흔적을 적극적으로 제거하려는 세상에서, 누가 지금 jQuery로 적극 개발하고 있는지 진심으로 궁금함
    예전에 jQuery로 하던 것 대부분은 이제 브라우저에 들어가 있고, querySelectorAll이 가장 강력한 예라고 봄

    • 나이가 들었고 새 기술이 덜 흥미로워져서, 네이티브 JS의 promise, await, async보다 $.ajax() 가 훨씬 단순하게 느껴짐
      익숙해지려고 작은 개인 프로젝트 몇 개에서는 순수 JS도 써봤지만, 내게는 $.ajax()로 처리하는 게 근육 기억처럼 바로 되는 방식임
      게다가 내가 DOM 조작용으로 쓰는 코드를 실제로 쓰는 사람은 20명쯤일 것임. 나는 UI 담당이 아니라 백엔드 담당인데, 해줄 사람이 없어서 프런트엔드도 쓰는 것뿐임
    • 작년 Stack Overflow 설문 기준으로 jQuery는 세 번째로 인기가 있었음
      https://survey.stackoverflow.co/2023/#section-most-popular-t...
    • 방금 어떤 회사에서 React의 마지막 흔적을 한참 제거하고 HTMX로 바꾸는 일을 했음
      개인적으로 HTMX는 어떤 면에서 jQuery의 정신적 후계자라고 봄
    • 나도 jQuery를 없애려고 적극적으로 노력 중이지만, 사람들이 도구에 익숙해졌고 다시 쓰려면 비용이 드니 없앨 만큼의 의지나 사업적 근거가 부족한 것 같음
      새 프로젝트를 jQuery로 시작하는 경우는 의심스럽지만, 순수 JavaScript 방식보다 jQuery식으로 처리하는 데 훨씬 익숙한 개발자는 분명 있음
    • 현대적인 도구 체인을 싫어하는 1인 개발자나 소규모 팀 개발자들이 씀
      좋은 예로 levelsio가 있음: https://twitter.com/levelsio/status/1750175827197567165
      나도 그쪽이고 여전히 jQuery를 사용함
      현재 SaaS는 UI 코드가 많지 않은 확장 프로그램인 https://www.snipcss.com이고, 다음 SaaS는 UI가 꽤 있는 ChatGPT 기반 웹 자동화 확장 프로그램이 될 예정임. 둘 다 jQuery를 씀
      querySelectorAll을 쓰는 순수 JS로 가지 않는 주된 이유는 이벤트를 붙이는 방식이 마음에 들고, 특히 부모에 붙여 동적으로 추가된 하위 요소를 대상으로 삼을 수 있으며, 함수 체이닝이 좋고, 순수 JS보다 코드가 적기 때문임

  • 훌륭함. 다만 나는 4.0을 너무 오래 기다리다 결국 몇 가지 핵심 차이가 있는 자체 jQuery를 만들었음
    애니메이션, 트윈, 타임라인은 jQuery의 커스텀 시스템 대신 순수 CSS를 사용하고, 단일 요소와 목록을 투명하게 다루며, 인라인 방식을 택함

    • 이런 식의 현대적이고 가벼운 jQuery 대안이 있어야 한다고 늘 생각했음. 잘 만들었고 문법도 마음에 듦
      나도 비슷한 것을 구현하고 있었는데, 인라인 이벤트와 표준 배열 메서드 이상을 포함 [0]
      surreal과 동반 프로젝트 css-scope-inline에서 행동의 지역성(locality of behavior)이 어떻게 구현되는지 설명하는 글이나 스크린캐스트가 있으면 좋겠음. 장기적으로 유지하고 내 프로젝트에도 넣을 수 있도록 이해하고 싶음
      웹에 대한 철학도 이야기해보고 싶음. 몇 가지는 생각이 잘 맞을 것 같음
      [0] https://hyperspace.so/All.js.png

  • 2008년쯤 주니어 시절로 돌아간 느낌임. 프로젝트에 jQuery를 추가하자고 기술 리드와 격하게 토론했었음
    그의 논리는 축소된 라이브러리 크기인 40KB가 페이지 로딩 시간에 너무 큰 부담을 준다는 것이었음
    그러고는 Ajax 호출을 직접 작성하고 여러 브라우저 지원을 테스트하느라 꼬박 일주일을 보냈지만, 결국 Internet Explorer 5에서 동작하게 만드는 데 실패했음
    그 시절 jQuery는 정말 많은 골칫거리를 해결해줬고, 결국 그는 프로젝트에 라이브러리를 추가했음

    • 사람들이 이걸 자주 잊는데, 예전 브라우저들은 서로 크게 달랐고 jQuery는 그런 면에서 코드베이스를 붙잡아줄 수 있는 유일하게 합리적인 접착제였음
    • 좋은 싸움을 한 기술 리드에게 박수를 보냄

  • jQuery 팀 잘했음. jQuery는 영원히 좋아할 것 같음
    그냥 일을 끝내주는 도구임

    • Bootstrap, PHP, JQuery, WP는 실제로 결과물을 만드는 사람들의 스택임

  • 브라우저의 DOM 선택 지원이 훨씬 좋아진 지금, 2024년에 왜 jQuery를 쓰는지 궁금함
    깎아내리려는 건 아니고 아직도 개발이 이어진다는 건 멋지다고 생각하지만, 사용 사례가 무엇인지 헷갈림

    • document.querySelector()가 지원하지 않는 꽤 편리한 선택자가 여럿 있음
      예를 들면 :selected, :checked 같은 것들이고, 그 밖에도 몇 가지가 있었는데 실제로 몇 번 마주쳤음
      전반적으로 DOM API는 좋은 API 설계에 대한 내 감각 대부분을 거슬리게 함. jQuery API에도 불만은 있지만 훨씬 낫고, 읽고 쓰는 흐름이 훨씬 자연스러움
    • 레거시 프로젝트 때문 아닐까
      약 15년 된 오래된 .NET 웹 앱을 유지보수하는데 jQuery로 돌아감. Web Components 같은 더 현대적인 것으로 전체 리팩터링이나 재작성을 하는 꿈은 좋지만, 실제로는 절대 하지 않을 것임
    • 추측하자면 편리한 API와 거대한 생태계 때문임
    • 관리자 페이지에는 jQuery를 좋아함
      내부 직원 20명만 보는 페이지라면 jQuery는 충분히 가볍고, CDN에서 바로 불러올 수 있고, 어떤 트랜스파일도 필요 없으며, 기본적으로 필요한 걸 다 처리해줌

  • 참고로 우리는 전체 로우코드 플랫폼의 드래그 앤 드롭 편집기를 jQuery로 만들었음
    편집기, 모든 컨트롤, 즉 UI 컴포넌트가 포함되고, 말할 것도 없이 최종 생성되는 코드도 순수 jQuery임
    하지만 대기업 임원들은 영업 엔지니어에게 왜 React나 Angular 등이 아니냐고 자주 묻곤 함
    그래서 지금도 jQuery가 이렇게 관련성이 크다는 걸 읽게 되어 정말 반갑고, 공동창업자이자 CTO가 스택을 옮기려 하지 않고 계속 이 선택을 지지해줘서 기쁨

  • jQuery가 처음 나왔을 때가 기억남
    동료들을 설득하려고 “Don’t Fear the $”라는 내부 발표를 열고, jQuery가 제공하는 장점들을 설명했음

  • jQuery의 전성기, 우리가 Mootools 대체재로 쓰던 시절이 기억남
    많은 사람이 React에서 HTMX로 이동하고 있으니, 한 바퀴 돌아서 웹이 그냥 순수 jQuery도 쓰는 모습을 보게 될지도 모르겠음

    • 비슷한 시대를 거쳤지만 그 난장판들이 그립지는 않음
      접근성, 모바일 지원, 실시간 업데이트, 시각화, 그리고 몇 가지 PWA 기능까지 갖춘 현대적 앱을 jQuery만으로 만든다고 생각하면 정말 불쾌하게 들림
      HTMX 과열도 현실을 만날 때를 기다리는 중임. DSL 같은 가짜 속성으로 앱을 프로그래밍하는 방식은 금방 질릴 것 같음
    • HTMX는 Mootools를 떠올리게 함
      작고 매우 특화된 JS 라이브러리임
    • HTMX는 $().load() 같음
    • “많은”은 좀 과장일 수 있음
답변달기