Yaklaşık 15 yıl önce seyahat acenteleri, havaalanı çalışanları ve havayolu şirketleri için uygulamalar geliştirdiğimiz bir şirkette çalışıyordum. Ayrıca kullanıcı arayüzü bileşenleri ve tek sayfalı uygulama yetenekleri için kendi şirket içi çerçevemizi de oluşturduk. Her şey için bileşenlerimiz vardı: alanlar, düğmeler, sekmeler, aralıklar, veri tabloları, menüler, tarih seçiciler, seçimler ve çoklu seçimler. Hatta bir div bileşenimiz bile vardı. Bu arada div bileşenimiz harikaydı, tüm tarayıcılarda köşeleri yuvarlatmamıza olanak sağladı, ister inanın ister inanmayın, o zamanlar bunu yapmak kolay bir şey değildi.
Çalışmalarımız tarihimizde JS, Ajax ve dinamik HTML'nin bizi geleceğe taşıyan bir devrim olarak görüldüğü bir noktada gerçekleşti. Aniden, bir sayfayı dinamik olarak güncelleyebildik, bir sunucudan veri alabildik ve diğer sayfalara gitmekten kurtulduk; bu da yavaş olarak görüldü ve iki sayfa arasında ekranda büyük beyaz bir dikdörtgenin yanıp sönmesiyle sonuçlandı. Jeff Atwood (StackOverflow'un kurucusu) tarafından popüler hale getirilen bir ifade vardı: “JavaScript'te yazılabilen herhangi bir uygulama eninde sonunda JavaScript'te de yazılacaktır.” - Jeff Atwood
O zamanlar bize bu, aslında gidip bu uygulamaları yaratma cesareti gibi geldi. Her şeyi JS ile yapmak genel bir onay gibi geldi. Yani her şeyi JS ile yaptık ve işleri yapmanın diğer yollarını araştırmaya gerçekten zaman ayırmadık. HTML ve CSS'nin neler yapabileceğini doğru bir şekilde öğrenme dürtüsünü gerçekten hissetmedik. Web'i bütünüyle gelişen bir uygulama platformu olarak algılamadık. Özellikle tarayıcı desteği söz konusu olduğunda bunu çoğunlukla çözmemiz gereken bir şey olarak gördük. İşleri halletmek için daha fazla JS kullanabiliriz. Web'in nasıl çalıştığı ve platformda nelerin mevcut olduğu hakkında daha fazla bilgi edinmek için zaman ayırmanın bana faydası olur mu? Elbette, muhtemelen gerçekten ihtiyaç duyulmayan bir sürü kodu tıraş edebilirdim. Ama o zamanlar bu kadar olmayabilir. Görüyorsunuz, o zamanlar tarayıcı farklılıkları oldukça önemliydi. Bu, Internet Explorer'ın hâlâ baskın tarayıcı olduğu, Firefox'un ise hemen ikinci sırada olduğu, ancak Chrome'un hızla popülerlik kazanması nedeniyle pazar payını kaybetmeye başladığı bir dönemdi. Her ne kadar Chrome ve Firefox web standartları konusunda oldukça iyi anlaşsalar da uygulamalarımızın çalıştığı ortamlar IE6'yı uzun süre desteklemek zorunda olduğumuz anlamına geliyordu. IE8'i desteklememize izin verildiğinde bile tarayıcılar arasındaki birçok farklılıkla uğraşmak zorunda kaldık. Sadece bu değil, aynı zamanda zamanın web'i platformda yerleşik olarak bu kadar çok yeteneğe sahip değildi.
Bugün hızla ilerleyin. İşler büyük ölçüde değişti. Bu yeteneklere her zamankinden daha fazla sahip olmamızın yanı sıra bunların kullanılabilir olma oranı da arttı. O halde soruyu tekrar sorayım: Web'in nasıl çalıştığı ve platformda nelerin mevcut olduğu hakkında daha fazla bilgi edinmek için zaman ayırmanın bugün size faydası olur mu? Kesinlikle evet. Bugün web platformunu anlamayı ve kullanmayı öğrenmek, sizi diğer geliştiricilere göre büyük bir avantaja sokar. Performans, erişilebilirlik, yanıt verme yeteneği ve bunların tümü üzerinde çalışıyorsanız veya yalnızca kullanıcı arayüzü özelliklerini sunuyorsanız, bunu sorumlu bir mühendis olarak yapmak istiyorsanız, kullanabileceğiniz araçları bilmek, hedeflerinize daha hızlı ve daha iyi ulaşmanıza yardımcı olur. Artık Bir Kütüphaneye İhtiyacınız Olmayabilecek Bazı Şeyler Bugün tarayıcıların hangileri desteklediğini bildiğimizde soru şu: Neyi bırakabiliriz? 2025'te köşeleri yuvarlatmak için bir div bileşenine ihtiyacımız var mı? Tabii ki yapmıyoruz. Border-radius özelliği, şu anda kullanılan tüm tarayıcılar tarafından bu noktada 15 yıldan fazla bir süredir desteklenmektedir. Daha şık köşeler için köşe şekli de yakında geliyor. Şimdi tüm büyük tarayıcılarda bulunan ve kod tabanınızdaki mevcut bağımlılıkları değiştirmek için kullanabileceğiniz nispeten yeni özelliklere bir göz atalım. Önemli olan tüm sevdiğiniz kitaplıklarınızı hemen bir kenara atıp kod tabanınızı yeniden yazmak değil. Diğer her şeye gelince, öncelikle tarayıcı desteğini dikkate almanız ve projenize özel diğer faktörlere göre karar vermeniz gerekir. Aşağıdaki özellikler üç ana tarayıcı motorunda (Chromium, WebKit ve Gecko) uygulanmıştır, ancak bunları hemen kullanmanızı engelleyen farklı tarayıcı desteği gereksinimleriniz olabilir. Ancak şu an bu özellikleri öğrenmek ve belki bir noktada bunları kullanmayı planlamak için hala iyi bir zaman. Popover'lar ve Diyaloglar Popover API,
Elbette internet bağlantı hızınız da artmış olabilir ancak bu herkes için geçerli değil. Ayrıca herkes aynı cihaz özelliklerine sahip değildir. Platformda yapabileceğiniz şeyler için üçüncü taraf kodunu kullanmak, büyük olasılıkla daha fazla kod göndereceğiniz ve dolayısıyla normalde olduğundan daha az müşteriye ulaşacağınız anlamına gelir. Web'de kötü yükleme performansı, büyük vazgeçme oranlarına yol açar ve marka itibarına zarar verir. Cihazlarda Daha Az Kod Çalıştırma Ayrıca, müşterilerinizin cihazlarına gönderdiğiniz kod, platformun üzerinde daha az JavaScript soyutlaması kullanıyorsa muhtemelen daha hızlı çalışır. Ayrıca varsayılan olarak muhtemelen daha duyarlı ve daha erişilebilirdir. Bütün bunlar daha fazla ve daha mutlu müşterilere yol açar. Meslektaşım Alex Russell'ın, servet eşitsizliği nedeniyle milyarlarca kullanıcısı olan pazarlarda premium cihazların büyük ölçüde bulunmadığını gösteren yıllık performans eşitsizliği açığı bloguna bakın. Ve bu fark sadece zamanla büyüyor.
Yerleşik Duvar Düzeni Yakında gelecek ve beni çok heyecanlandıran bir web platformu özelliği de CSS Masonry'dir.
Masonluğun ne olduğunu açıklayarak başlayayım. Masonluk Nedir? Duvarcılık, yıllar önce Pinterest tarafından popüler hale getirilen bir düzen türüdür. Öğelerin parçanın başlangıcına olabildiğince yakın bir şekilde paketlendiği bağımsız içerik parçaları oluşturur.
Birçok kişi Masonluğu portföyler ve fotoğraf galerileri için mükemmel bir seçenek olarak görüyor ve bunu kesinlikle yapabilir. Ancak Masonry, Pinterest'te gördüğünüzden daha esnektir ve yalnızca şelale benzeri düzenlerle sınırlı değildir. Duvar düzeninde:
Parçalar sütunlar veya satırlar olabilir:
İçerik parçalarının hepsinin aynı boyutta olması gerekmez:
Öğeler birden fazla parçaya yayılabilir:
Öğeler belirli parçalara yerleştirilebilir; her zaman otomatik yerleştirme algoritmasını takip etmek zorunda değiller:
Demolar Aşağıda, Chromium'da yakında kullanıma sunulacak CSS Masonry uygulamasını kullanarak yaptığım birkaç basit demo yer almaktadır. Öğelerin (bu durumda başlık) birden fazla parçaya nasıl yayılabileceğini gösteren bir fotoğraf galerisi demosu:
Farklı boyutlardaki parçaları gösteren başka bir fotoğraf galerisi:
Bazı parçaların diğerlerinden daha geniş olduğu ve bazı öğelerin düzenin tüm genişliğini kapladığı bir haber sitesi düzeni:
Öğelerin belirli parçalara yerleştirilebileceğini gösteren bir kanban panosu:
Not:Önceki demolar Chromium'un henüz çoğu web kullanıcısının kullanımına sunulmayan bir sürümüyle yapılmıştı çünkü CSS Masonry tarayıcılarda henüz yeni uygulanmaya başlıyor. Ancak web geliştiricileri, Masonluk mizanpajları oluşturmak için kütüphaneleri yıllardır memnuniyetle kullanıyor. Günümüzde Masonluk Kullanan Siteler Aslında Masonluk bugün internette oldukça yaygındır. İşte Pinterest dışında bulduğum birkaç örnek:
Ve daha az belirgin olan birkaç örnek daha:
Peki bu düzenler nasıl oluşturuldu? Geçici Çözümler Kullanıldığını gördüğüm bir hile bunun yerine Flexbox düzeni kullanmak, yönünü sütuna değiştirmek ve sarmaya ayarlamaktır. Bu şekilde, farklı yükseklikteki öğeleri birden fazla bağımsız sütuna yerleştirerek bir Duvar düzeni izlenimi verebilirsiniz:
Ancak bu geçici çözümün iki sınırlaması vardır:
Öğelerin sırası, gerçek bir Duvar düzeninde olacağından farklıdır. Flexbox'ta öğeler ilk önce ilk sütunu doldurur ve dolduğunda bir sonraki sütuna geçer. Duvarcılıkta öğeler, hangi yolda (veya bu durumda sütunda) daha fazla alan varsa o sırada yığılır. Ancak aynı zamanda ve belki daha da önemlisi, bu geçici çözüm, Flexbox konteynerine sabit bir yükseklik ayarlamanızı gerektirir; aksi halde sarma gerçekleşmez.
Üçüncü Taraf Masonluk Kütüphaneleri Daha gelişmiş durumlar için geliştiriciler kütüphaneleri kullanıyor. Bunun için en iyi bilinen ve popüler kütüphaneye kısaca Masonry denir ve NPM'ye göre haftada yaklaşık 200.000 kez indirilir. Squarespace ayrıca kodsuz bir alternatif olarak Masonry düzenini oluşturan bir düzen bileşeni sağlar ve birçok site bunu kullanır. Bu seçeneklerin her ikisi de öğeleri düzene yerleştirmek için JavaScript kodunu kullanır. Yerleşik Duvarcılık Masonry'nin artık tarayıcılarda yerleşik bir CSS özelliği olarak görünmeye başlaması beni gerçekten heyecanlandırıyor. Zamanla Masonry'yi Grid veya Flexbox'ta kullandığınız gibi, yani herhangi bir geçici çözüme veya üçüncü taraf koduna ihtiyaç duymadan kullanabileceksiniz. Microsoft'taki ekibim, Edge, Chrome ve diğer birçok tarayıcının temel aldığı Chromium açık kaynak projesinde yerleşik Masonry desteğini uyguluyor. Mozilla aslında 2020 yılında Masonluğun deneysel bir uygulamasını öneren ilk tarayıcı satıcısıydı. Ayrıca Apple da bu yeni web düzenini ilkel hale getirmekle çok ilgilendi. Özelliği standartlaştırma çalışmaları da CSS çalışma grubu içinde genel yön ve hatta yeni bir görüntüleme tipi ekran olan ızgara şeritleri hakkında anlaşmaya varılarak ilerlemektedir. Masonluk hakkında daha fazla bilgi edinmek ve ilerlemeyi takip etmek istiyorsanız CSS Masonluk kaynakları sayfama göz atın. Zamanla, Masonluk tıpkı Grid veya Flexbox gibi bir Temel özellik haline geldiğinde, onu basitçe kullanıp aşağıdakilerden faydalanabileceğiz:
Daha iyi performans, Daha iyi yanıt verme, Kullanım kolaylığı ve daha basit kod.
Gelin bunlara daha yakından bakalım. Daha İyi Performans Kendi Masonry benzeri düzen sisteminizi oluşturmak veya bunun yerine üçüncü taraf bir kütüphane kullanmak, öğeleri ekrana yerleştirmek için JavaScript kodunu çalıştırmanız gerektiği anlamına gelir. Bu aynı zamanda bu kodun render engelleneceği anlamına da gelir. Gerçekten de, JavaScript kodu çalıştırılana kadar ya hiçbir şey görünmeyecek ya da her şey doğru yerlerde ya da doğru boyutlarda olmayacak. Duvar düzeni genellikle bir web sayfasının ana kısmı için kullanılır; bu, kodun ana içeriğinizin normalde olabileceğinden daha geç görünmesini sağlayacağı ve algılanan performansta ve arama motoru optimizasyonunda büyük bir rol oynayan LCP'nizi veya En Büyük İçerikli Boya metriğinizi düşüreceği anlamına gelir. Masonry JS kütüphanesini basit bir düzen ile ve DevTools'ta yavaş bir 4G bağlantısını simüle ederek test ettim. Kitaplık çok büyük değil (24 KB, gzip'li 7,8 KB), ancak test koşullarımda yüklenmesi 600 ms sürdü. Masonry kütüphanesi için 600 ms'lik uzun yükleme süresini ve bu süre zarfında başka hiçbir işleme faaliyetinin gerçekleşmediğini gösteren bir performans kaydı:
Ayrıca, ilk yükleme süresinden sonra indirilen betiğin ayrıştırılması, derlenmesi ve çalıştırılması gerekiyordu. Bunların hepsi, daha önce de belirtildiği gibi, sayfanın oluşturulmasını engelliyordu. Tarayıcıdaki yerleşik Masonry uygulaması sayesinde yüklenecek ve çalıştırılacak bir komut dosyasına sahip olmayacağız. Tarayıcı motoru, ilk sayfa oluşturma adımı sırasında kendi işini yapacaktır. Daha İyi Yanıt Verme Bir sayfanın ilk yüklenmesine benzer şekilde, tarayıcı penceresinin yeniden boyutlandırılması, sayfa düzeninin yeniden oluşturulmasına yol açar. Ancak bu noktada sayfa Masonry JS kütüphanesini kullanıyorsa betiği tekrar yüklemenize gerek yoktur çünkü zatenBurada. Ancak öğeleri doğru yerlere taşıyan kodun çalıştırılması gerekir. Artık bu özel kütüphane, sayfa yüklendiğinde bunu yapmada oldukça hızlı görünüyor. Ancak pencere boyutlandırmasında farklı bir yere taşınması gerektiğinde öğelere animasyon uygular ve bu büyük bir fark yaratır. Elbette kullanıcılar, tarayıcı pencerelerini yeniden boyutlandırmak için biz geliştiriciler kadar zaman harcamıyorlar. Ancak bu animasyonlu yeniden boyutlandırma deneyimi oldukça sarsıcı olabilir ve sayfanın yeni boyutuna uyum sağlaması için gereken süreyi artırır. Kullanım Kolaylığı ve Daha Basit Kod Bir web özelliğini kullanmanın ne kadar kolay olduğu ve kodun ne kadar basit göründüğü, ekibiniz için büyük fark yaratabilecek önemli faktörlerdir. Elbette hiçbir zaman nihai kullanıcı deneyimi kadar önemli olamazlar ancak geliştirici deneyimi sürdürülebilirliği etkiler. Yerleşik bir web özelliğinin kullanılması bu açıdan önemli avantajlar sağlar:
HTML, CSS ve JS'yi zaten bilen geliştiriciler büyük olasılıkla bu özelliği kolayca kullanabilecekler çünkü bu özellik web platformunun geri kalanıyla iyi entegre olacak ve tutarlı olacak şekilde tasarlandı. Özelliğin nasıl kullanıldığına ilişkin değişikliklerin bozulması riski yoktur. Bu özelliğin kullanımdan kaldırılması veya sürdürülmemesi riski neredeyse sıfırdır.
Yerleşik Masonluk durumunda, bu bir düzen ilkel olduğundan, onu tıpkı Grid veya Flexbox gibi CSS'den kullanırsınız, JS içermez. Ayrıca boşluk gibi mizanpajla ilgili diğer CSS özellikleri de beklediğiniz gibi çalışır. Bilmeniz gereken hiçbir hile veya geçici çözüm yoktur ve öğrendiğiniz şeyler MDN'de belgelenmiştir. Masonry JS lib için başlatma biraz karmaşıktır: sütun ve boşluk boyutlarını ayarlamak için gizli HTML öğelerinin yanı sıra belirli bir sözdizimine sahip bir veri niteliği gerektirir. Ayrıca, sütunları yaymak istiyorsanız sorunları önlemek için boşluk boyutunu kendiniz eklemeniz gerekir:
Bunu yerleşik bir Masonry uygulamasının neye benzeyeceğiyle karşılaştıralım:
Boşluk gibi şeyleri kullanabilen ve izlerin ızgarada olduğu gibi açıklık 2 ile yapıldığı daha basit, daha kompakt kod ve boşluk boyutunu içeren doğru genişliği hesaplamanızı gerektirmez. Neyin Mevcut Olduğunu ve Ne Zaman Mevcut Olduğunu Nasıl Bilirsiniz? Genel olarak soru, yerleşik Masonry'yi bir JS kütüphanesi üzerinden kullanmanız gerekip gerekmediği değil, ne zaman kullanmanız gerektiğidir. Masonry JS kütüphanesi muhteşemdir ve uzun yıllardan beri web platformundaki bir boşluğu doldurmaktadır ve birçok mutlu geliştirici ve kullanıcı için. Yerleşik bir Masonluk uygulamasıyla karşılaştırırsanız elbette birkaç dezavantajı vardır, ancak bu uygulama hazır değilse bunlar önemli değildir. Bu harika yeni web platformu özelliklerini listelemek benim için kolay çünkü bir tarayıcı satıcısında çalışıyorum ve bu nedenle ne olacağını bilme eğilimindeyim. Ancak geliştiriciler sıklıkla, anket üstüne anket yaparak yeni şeyleri takip etmenin zor olduğunu paylaşıyor. Bilgi sahibi olmak zordur ve şirketler zaten öğrenmeye her zaman öncelik vermez. Bu konuda yardımcı olmak için, ihtiyacınız olan bilgileri hızlı bir şekilde alabilmeniz için güncellemeleri basit ve kompakt yollarla sağlayan birkaç kaynak aşağıda verilmiştir:
Web platformunda gezgin sitesi bulunur: Sürüm notları sayfası ilginizi çekebilir. RSS'yi seviyorsanız sürüm notları akışının yanı sıra Yeni Mevcut ve Yaygın Olarak Kullanılabilir Temel akışlarına da göz atın.
WebPlatform Durumu kontrol paneli: Çeşitli Temel Yıl sayfalarını beğenebilirsiniz.
Chrome Platform Durumu'nun yol haritası sayfası.
Biraz daha zamanınız varsa tarayıcı satıcılarının sürüm notları da ilginizi çekebilir:
Krom Kenar Firefox Safari
Daha da fazla kaynak için Web Platformunda Gezinme Hile Sayfama göz atın. İşlemim Hala Uygulanmadı Bu da sorunun diğer tarafı. Zamanı, enerjiyi ve takip etmenin yollarını bulsanız bile sesinizi duyurma ve en sevdiğiniz özellikleri uygulama konusunda hâlâ hayal kırıklığı yaşıyorsunuz. Belki yıllardır belirli bir hatanın çözülmesini veya belirli bir özelliğin hala eksik olan bir tarayıcıya gönderilmesini bekliyordunuz. Söyleyeceğim şey şu, tarayıcı satıcıları dinliyor. Geliştirici sinyallerini ve geri bildirimlerini sürekli tartıştığımız çeşitli kuruluşlar arası ekiplerin bir parçasıyım. Hem her tarayıcı satıcısının dahili, hem de forumlar, açık kaynak projeler, bloglar ve anketlerdeki harici/kamuya açık birçok farklı geri bildirim kaynağına bakıyoruz. Ayrıca geliştiricilerin özel ihtiyaçlarını ve kullanım örneklerini paylaşmaları için her zaman daha iyi yollar yaratmaya çalışıyoruz. Bu nedenle, eğer yapabiliyorsanız, lütfen tarayıcı satıcılarından daha fazlasını talep edin ve ihtiyacınız olan özellikleri uygulamamız için bize baskı yapın. Bunun zaman aldığını ve aynı zamanda korkutucu olabileceğini anlıyorum (yüksek giriş engelinden bahsetmiyorum bile), ama aynı zamanda işe de yarıyor. İşte kendi (veya şirketinizin) sesini duyurmanın birkaç yolu: Yıllık JS Durumu, CSS Durumu ve HTML Durumu anketlerine katılın. Tarayıcı satıcılarının işlerine öncelik vermesinde büyük rol oynuyorlar. Belirli bir standart tabanlı API'nin tarayıcılar arasında tutarlı bir şekilde uygulanmasına ihtiyacınız varsa bir sonraki Birlikte Çalışma projesi yinelemesinde bir teklif göndermeyi düşünün. Daha fazla zaman gerektirir ancak Shopify ve RUMvision'ın Interop 2026 için istek listelerini nasıl paylaştıklarını düşünün. Bunun gibi ayrıntılı bilgiler, tarayıcı satıcılarının öncelik vermesi açısından çok yararlı olabilir. Tarayıcı satıcılarını etkilemeye yönelik daha yararlı bağlantılar için Web Platformunda Gezinme Hile Sayfama göz atın. Sonuç Son olarak, bu makalenin size düşünmeniz gereken birkaç şey bıraktığını umuyorum:
Masonluk ve diğer yaklaşan web özellikleri için heyecan. Kullanmaya başlamak isteyebileceğiniz birkaç web özelliği. Yerleşik özellikler lehine birkaç parça özel veya 3. taraf kodunu kaldırabilirsiniz. Gelecek gelişmeleri takip etmenin ve tarayıcı satıcılarını etkilemenin birkaç yolu.
Daha da önemlisi, umarım sizi web platformunu tam potansiyeliyle kullanmanın yararları konusunda ikna edebilmişimdir.
