jQuery v4.0 beta sürümü

• IE 10 ve altı desteği kaldırıldı; Edge Legacy, iOS <11, Firefox <65 ve Android Browser desteği de sonlandırıldı
• Birden fazla sürüm boyunca kullanım dışı bırakılmış (deprecated) durumda olan API'ler kaldırıldı: 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 prototipindeki dahili Array metotları olan push, sort, splice kaldırıldı; bu metotlara bağlı eklentiler etkilenebilir
• focusout, blur, focusin, focus ile ilgili olay sıralamasında jQuery'nin önceki override davranışı kaldırıldı ve IE dışındaki tarayıcılar artık güncel W3C sırası olan blur → focusout → focus → focusin düzenini izliyor
• jQuery.ajax, ikili veri ve FormData desteği kazanıyor; daha önce bilinmeyen veri türü sayıp string'e dönüştüren davranış yerine artık otomatik işleme yapılıyor
• dataType: "json" ve callback birlikte verildiğinde otomatik olarak JSONP isteğine yükselten jQuery.ajax davranışı kaldırıldı
• jQuery kaynak kodu AMD'den ES modules yapısına taşındı ve paketleme aracı RequireJS'ten Rollup'a geçirildi
• Trusted Types desteği eklendi; böylece TrustedHTML ile sarmalanmış HTML, require-trusted-types-for CSP yönergesini ihlal etmeden jQuery manipülasyon metotlarına girdi olarak kullanılabiliyor
• Asenkron script isteklerinin çoğu artık <script> etiketi kullanacak şekilde değiştirildi; böylece inline script kullanımından kaynaklanan CSP hatalarının önüne geçiliyor
• slim derlemeden Deferreds ve Callbacks kaldırıldı; böylece gzip ölçümünde 20k bytes'ın altına indi ve normal derlemeye göre yaklaşık 8k gzipped bytes daha küçük oldu
• IE11 desteği gerekiyorsa slim derleme yerine main derlemenin kullanılması veya native Promises polyfill eklenmesi öneriliyor
• Resmî sürümden önce kapsamlı bir yükseltme rehberi yayımlanacak ve geçişe yardımcı olması için jQuery Migrate plugin hazırlanacak
• Beta sürüm jQuery CDN ve npm üzerinden sunuluyor; üçüncü taraf CDN'ler betayı barındırmayacak ve 4.0.0 final sürümünü daha sonra barındıracak

[GN⁺]

Hacker News yorumları

• 2024 sonrasında bile jQuery’yi ayakta tutan gücü merak ediyorsanız, WordPress’in hâlâ web’in 1/3’ünden fazlasını oluşturduğunu ve kurulumların çoğu ile sayısız eklentinin jQuery’ye büyük ölçüde bağımlı olduğunu hatırlamak gerekir.
  Kullanımdan kaldırılması planlanan API’lerin veya fonksiyonların kaldırılmasında ilerleme kaydedilmesi iyi; jQuery’nin de önümüzdeki birkaç yıl boyunca web’de baskın kalması muhtemel.

  • Üstelik jQuery harika.
    Son 15 yıl kadar sektör, aşırı karmaşık ve gösterişli JavaScript framework’lerine kapıldı; oysa dinamik oluşturulmuş bir forma dinamik binding eklemek, hata durumlarını yönetmek ve birkaç Ajax çağrısı yapmak, web sayfalarının %99’unun ihtiyaç duyduğu JavaScript’in tamamı. Geri kalanı çoğu zaman abartı.
    Sektörün React’in karmaşıklığından uzaklaşıp htmx, Phoenix LiveView, Ruby on Rails Turbo ve doğrudan jQuery gibi basitliğe yöneleceğini düşünüyorum.
  • Kim ne derse desin, jQuery hâlâ güçlü, önemli ve etkisi büyük.
    jQuery’yi tüm yazılımlardan kaldırırsanız internetin dört bir yanındaki web sitelerinin hatırı sayılır bir kısmı durur.
  • Bu yalnızca WordPress meselesi değil.
    Eskiden çalıştığım şirket, kurumsal bir SaaS ürününü on binlerce satır jQuery koduyla işletiyordu.
    Gerçekten zorunlu hale gelmedikçe modern bir JS framework’üyle yeniden yazılması olmayacak. Kodun çoğu 10 yıldan da önce belirli müşteri ihtiyaçlarına göre yazılmıştı; modern framework kullanmanın işe alıma yardımcı olacağı argümanı da işlemiyor. Şirket frontend mühendislerine yalnızca 75 bin–90 bin dolar ödüyor, çalışan devri de düşük; mevcut mühendislerin çoğu 5 yıldan uzun süredir şirkette.
    En önemlisi, mevcut stack iyi çalışıyor ve eski müşteriler de memnun. Yazılım mühendisliğinin önemli bir kısmı, Bay Area veya Seattle gibi büyük teknoloji merkezlerine kıyasla yaşam maliyeti çok daha düşük şehirlerdeki bu tür sıkıcı işlerde gerçekleşiyor.
  • WordPress geliştiricileri teknoloji sektörünün tesisatçıları gibi.
    Gösterişli değil ama ihtiyaç duyan o kadar çok kişi var ki iyi para kazanabilirsiniz.
    Bir gün en yeni trendlerin peşinden koşan büyük teknoloji startup dünyasından emekli olursam, dürüstçe para kazanıp WordPress siteleri yaparak her gün saat 15.00’te işi bitirmek isterim.
  • Kısa süre önce HN’ye yazacaktım ama vazgeçtim: DOM üyeleri ile soyut sınıf örneklerinin birbirinin yerine kullanılabildiği event’leri tetiklemeyi sağlayan iyi bir event zinciri işleme/bubbling modeli hâlâ bulamıyorum.
    Çeşitli yerlerde kendi event dispatcher’larımı yaptım ama jQuery bu işi doğru yapıyor. Bugün bile jQuery’yi neredeyse yalnızca event işleme için kullanıyorum; ama o kadar işe yarıyor ki neredeyse her istemci tarafı projeye dahil ediyorum.
    Sormak istediğim şey, $(window).trigger('click') ile $(myClassInstance).trigger('myCustomEvent',{data}) çağrılarını aynı API üzerinden, asenkron dinlemeyi de kapsayacak şekilde işleyebilen hafif bir kütüphane bilen olup olmadığıydı.
    fetch() ve CSS seçicilerin yükselişi sayesinde artık jQuery’nin geri kalanı olmadan da idare edilebilecek gibi görünüyor; ama tekerleği yeniden icat etmeye gerek var mı, emin değilim. Sınıf örneklerinin event dispatch etmesinin kod kokusu olduğunu söylemeden önce: sıfırdan reaktif bir framework yapmak istiyorsanız buna mutlaka ihtiyaç var.
    Örneğin temel component sınıfım, kendisini içeren ekranda oluşan belirli bir özel resize event’ini dinliyor; o ekran da event’i, kendisi scroll olmazken içini yeniden yerleştirmesi gereken component’lara gönderiyor. Ekran sınıfı window.resize dinliyor ama yalnızca layout sorunlu olduğunda dispatch ediyor. Her component için window üzerine ayrı DOM resize listener’ı bağlamak mantıklı değil.

• HN’de jQuery’yi basit bir DOM seçme kütüphanesi olarak gören insanların düzenli olarak çıkmasına şaşırıyorum.
  Gerçekte ise yaygın destekli ve son derece kararlı bir araç seti; DOM seçmenin yanı sıra özellik manipülasyonu, Ajax istekleri, event işleme, animasyon ve genel amaçlı yardımcı fonksiyonlar da sunuyor.
  Üstelik jQuery’nin yerini alan native özellikler olsa bile API’leri onun kadar akıcı değil.
  Sunucu tarafı HTML’in üzerine yalnızca biraz işlevsellik eklemek yeterliyse ve tam kapsamlı bir JS UI framework’üne ihtiyaç yoksa, jQuery kararlı, güvenilir ve tarayıcılar arası uyumlu bir bağımlılık olarak küçük bir bedelden ibaret.

  • Birkaç yıl önce jQuery’yi bırakıp saf JavaScript’e geçtim ve bir daha arkama bakmadım.
    Native JS’te jQuery’de olan her şey var; genellikle kötü bakılan, yarım yamalak eklenti yığınları hariç. Bu eklentiler çoğunlukla yalnızca yapmak istedikleri şeyi yapar, onun dışında pek bir şey sağlamaz.
    Saf seçiciler daha uzun yazılıyor ama iyi bir kod editörü yazma hızını aynı seviyeye getirir. Tartışmak istemiyorum ama neden hâlâ bu kadar çok kişinin jQuery kullandığını pek anlayamıyorum.
    https://youmightnotneedjquery.com/
  • HN’deki yazar kitlesine bakınca bu çok da şaşırtıcı değil.
    DOM seçmenin biraz ötesine ihtiyaç duyduklarında, o dönemde moda olan büyük JS framework’ünü hemen eline alan çok kişi var; hep böyle yaptılar.
  • “jQuery’yi sadece DOM seçme kütüphanesi olarak görenler” deyip ardından seçim ve native fonksiyonları sıralıyorsunuz.
  • Projeye jQuery eklemek çok daha kolay.
    Build araçlarına ve beraberindeki baş ağrılarına gerek yok. React ile de bunu yapmak mümkün ama sundukları özellikler karşılaştırılabilir değil.

• Pek çok kişinin jQuery’nin son izlerini aktif biçimde silmeye çalıştığı bir dünyada, şu anda kimin jQuery ile aktif geliştirme yaptığını gerçekten merak ediyorum
  Eskiden jQuery ile yapılanların çoğu artık tarayıcılarda var; bence querySelectorAll bunun en güçlü örneği

  • Yaşlandım ve yeni teknolojiler daha az heyecan verici gelmeye başladı; bu yüzden yerel JS’in promise’leri, await, async yerine $.ajax() bana çok daha basit geliyor
    Alışmak için birkaç küçük kişisel projede saf JS de kullandım ama benim için $.ajax() ile halletmek kas hafızası gibi, doğrudan gelen yöntem
    Üstelik DOM manipülasyonu için yazdığım kodu gerçekten kullanan kişi sayısı muhtemelen 20 civarıdır. UI’dan sorumlu değilim, backend tarafındayım; yapacak kimse olmadığı için frontend de yazıyorum
  • Geçen yılki Stack Overflow anketine göre jQuery üçüncü en popüler seçenekti
    https://survey.stackoverflow.co/2023/#section-most-popular-t...
  • Az önce bir şirkette React’in son izlerini epeyce temizleyip HTMX ile değiştirme işi yaptım
    Kişisel olarak HTMX’i bazı açılardan jQuery’nin manevi halefi olarak görüyorum
  • Ben de jQuery’den kurtulmak için aktif olarak uğraşıyorum ama insanlar araca alışmış durumda; yeniden yazmanın maliyeti var, bu yüzden kaldıracak kadar irade ya da iş gerekçesi eksik gibi görünüyor
    Yeni bir projeye jQuery ile başlamak şüpheli görünebilir ama işleri saf JavaScript tarzı yerine jQuery tarzıyla halletmeye çok daha alışkın geliştiriciler kesinlikle var
  • Modern araç zincirlerinden hoşlanmayan tek kişilik geliştiriciler veya küçük ekip geliştiricileri kullanıyor
    Buna iyi bir örnek levelsio: https://twitter.com/levelsio/status/1750175827197567165
    Ben de o taraftayım ve hâlâ jQuery kullanıyorum
    Mevcut SaaS’im, fazla UI kodu olmayan bir uzantı olan https://www.snipcss.com; sonraki SaaS’im ise epey UI içeren, ChatGPT tabanlı bir web otomasyon uzantısı olacak. İkisi de jQuery kullanıyor
    querySelectorAll kullanan saf JS’e geçmememin başlıca nedeni, event bağlama şeklini sevmem; özellikle üst öğeye bağlayıp dinamik olarak eklenen alt öğeleri hedefleyebilmem, fonksiyon zincirlemeyi sevmem ve saf JS’e göre daha az kod yazmam

• Harika. Yalnız ben 4.0’ı çok uzun süre bekleyince sonunda bazı temel farkları olan kendi jQuery’mi yaptım
  Animasyonlar, tween’ler ve timeline’lar için jQuery’nin özel sistemi yerine saf CSS kullanıyor; tekil öğeleri ve listeleri şeffaf biçimde ele alıyor ve inline yaklaşımı benimsiyor

  • Bu tür modern ve hafif bir jQuery alternatifi olması gerektiğini hep düşünürdüm. İyi yapmışsın, söz dizimini de beğendim
    Ben de benzer bir şey uyguluyordum; inline event’ler ve standart dizi metotlarından fazlasını içeriyor [0]
    surreal ve eşlik eden proje css-scope-inline’da davranışın yerelliğinin (locality of behavior) nasıl uygulandığını anlatan bir yazı ya da screencast olsa güzel olurdu. Uzun vadede bakımını yapabilmek ve kendi projelerime de koyabilmek için anlamak istiyorum
    Web’e dair felsefe hakkında da konuşmak isterim. Bazı konularda iyi uyuşacağımızı düşünüyorum
    [0] https://hyperspace.so/All.js.png

• Kendimi 2008 civarında junior olduğum günlere dönmüş gibi hissediyorum. Projeye jQuery ekleyelim diye teknik liderle hararetli şekilde tartışmıştım
  Onun argümanı, küçültülmüş kütüphane boyutu olan 40KB’ın sayfa yükleme süresine çok büyük yük bindireceğiydi
  Sonra Ajax çağrılarını elle yazıp farklı tarayıcı desteğini test etmekle tam bir hafta geçirdi ama sonunda Internet Explorer 5’te çalıştırmayı başaramadı
  O dönemde jQuery gerçekten çok sayıda baş ağrısını çözdü ve sonunda kütüphaneyi projeye ekledi

  • İnsanlar bunu sık sık unutuyor: eski tarayıcılar birbirinden çok farklıydı ve jQuery bu açıdan kod tabanını bir arada tutabilecek tek makul yapıştırıcıydı
  • İyi mücadele veren teknik lidere alkış

• jQuery ekibi iyi iş çıkarmış. Sanırım jQuery’yi sonsuza kadar seveceğim
  Basitçe işi bitiren bir araç

  • Bootstrap, PHP, JQuery, WP gerçekten sonuç üreten insanların stack’i

• Tarayıcıların DOM seçimi desteği bu kadar iyileşmişken, 2024’te neden jQuery kullanıldığını merak ediyorum
  Küçümsemek istemiyorum; hâlâ geliştiriliyor olması harika bence ama kullanım alanının ne olduğunu anlamakta zorlanıyorum

  • document.querySelector()’ın desteklemediği, oldukça kullanışlı birkaç seçici var
    Örneğin :selected, :checked gibi şeyler; başka birkaç tane daha vardı ve pratikte birkaç kez karşıma çıktı
    Genel olarak DOM API, iyi API tasarımına dair sezgilerimin çoğuna ters düşüyor. jQuery API’dan da şikâyetlerim var ama çok daha iyi; okuma ve yazma akışı çok daha doğal
  • Belki de eski projeler yüzündendir
    Yaklaşık 15 yıllık eski bir .NET web uygulamasının bakımını yapıyorum ve jQuery’ye döndük. Web Components gibi daha modern bir şeyle tümünü refactor etme ya da yeniden yazma hayali güzel ama gerçekte bunu asla yapmayacağız
  • Tahminimce kullanışlı API ve devasa ekosistem yüzünden
  • Yönetici panellerinde jQuery’yi seviyorum
    Yalnızca 20 iç çalışanın gördüğü bir sayfaysa jQuery yeterince hafif, doğrudan CDN’den yüklenebiliyor, hiçbir transpile gerektirmiyor ve temelde ihtiyacınız olan her şeyi hallediyor

• Bu arada biz tüm low-code platformunun sürükle-bırak editörünü jQuery ile yaptık
  Editör, tüm kontroller, yani UI bileşenleri buna dahil; söylemeye gerek yok, nihai olarak üretilen kod da saf jQuery
  Ama büyük şirket yöneticileri satış mühendislerine sık sık neden React ya da Angular vb. olmadığını soruyor
  Bu yüzden jQuery’nin hâlâ bu kadar alakalı olduğunu okumak gerçekten sevindirici; kurucu ortağım ve CTO’mun stack’i taşımaya çalışmayıp bu tercihi desteklemeye devam etmesine de memnunum

• jQuery’nin ilk çıktığı zamanı hatırlıyorum
  Meslektaşlarımı ikna etmek için “Don’t Fear the $” adlı bir şirket içi sunum yapıp jQuery’nin sunduğu avantajları anlatmıştım

• jQuery’nin en parlak dönemini, onu Mootools’un yerine kullandığımız zamanları hatırlıyorum
  Birçok kişi React’ten HTMX’e geçiyor; belki de döngü tamamlanır ve web’in sadece saf jQuery kullandığını da görürüz

  • Benzer bir dönemden geçtik ama o keşmekeşi özlemiyorum
    Erişilebilirlik, mobil destek, gerçek zamanlı güncellemeler, görselleştirme ve birkaç PWA özelliğine sahip modern bir uygulamayı yalnızca jQuery ile yapmayı düşünmek bile gerçekten rahatsız edici geliyor
    HTMX abartısının da gerçekle yüzleşeceği anı bekliyorum. DSL benzeri sahte özniteliklerle uygulama programlama tarzı çabuk bıktıracak gibi
  • HTMX bana Mootools’u hatırlatıyor
    Küçük ve oldukça özelleşmiş bir JS kütüphanesi
  • HTMX, $().load() gibi
  • “Birçok” biraz abartı olabilir