Linear’da bir görevi güncellemek yalnızca birkaç milisaniye sürerken, geleneksel bir CRUD uygulamasının yaklaşık 300 milisaniyeye ihtiyacı vardır. Peki, Linear bu hızı nasıl başarıyor? Performansın tek bir sihirli sırrı yoktur. Gerçek şu ki, doğru temel üzerine inşa edilmiş ve sayısız doğru kararla geliştirilmiştir. Bu makalede, Linear’ın bu hissi veren teknikleri incelenecek ve benzer yaklaşımları kendi projelerinizde uygulamanıza yardımcı olunacaktır.
Linear’ın Temel Hız Katmanları
Linear’ın performansının ardındaki ana teknik yaklaşımlar şunları kapsar:
- Tarayıcıda veritabanı kullanımı.
- İlk yüklemeyi anında hissettirme stratejileri.
- Gelişmiş senkronizasyon motoru.
- Hız odaklı tasarım prensipleri.
- Akıllı animasyon kullanımı.
Tarayıcıda Veritabanı
Çoğu web uygulaması aynı döngüde çalışır: kullanıcı tıklar, tarayıcı bir HTTP isteği gönderir, sunucu veritabanını sorgular ve yanıtı geri gönderir, tarayıcı arayüzü yeniden çizer. Bu süreç, ağ isteği tamamlanana kadar yüzlerce milisaniye süren bir bekleme veya dönen bir işaretçi ile sonuçlanır.
Linear ise geleneksel ilişkiyi tersine çevirir. Kullanıcı arayüzünün okuduğu gerçek veritabanı, IndexedDB aracılığıyla tarayıcıda bulunur. Değişiklikler önce yerel olarak uygulanır, ardından eşzamansız olarak sunucuya gönderilir ve sunucu, diğer istemcilere WebSocket üzerinden değişiklikleri yayınlar. Bu yaklaşım, Linear’ın performansının en kritik parçasıdır; zira en büyük darboğaz olan ağ isteklerini ortadan kaldırır. Kullanıcıdan ağ isteklerini ne kadar çok gizlerseniz, uygulamanız o kadar hızlı hissettirir.
Geleneksel bir web uygulaması için bir görevi güncelleme örneği, bir spinner göstermeyi, sunucuya PATCH isteği atmayı ve yanıtı beklemeyi içerirken; Linear’da bu süreç ‘issue.title = “Yeni Başlık”; issue.save();’ kadar basittir. İlk satır bellekteki veriyi (Linear’da MobX observable) güncellerken, ikinci satır senkronizasyon motorunun işleyip sunucuya göndereceği bir işlemi sıraya koyar. Kullanıcı arayüzü, yerel bellek güncellemesiyle eşzamanlı olarak yeniden render edildiği için bekleyecek bir şey yoktur ve spinner’lara ihtiyaç duyulmaz.
Linear’ın kurucu ortaklarından Tuomas, 2024’teki bir konferansta, ‘Yazdığım ilk kod satırları senkronizasyon motoruydu; bu, bir startup için alışılmadık bir durumdur’ demiştir. Bu, Linear’ın baştan beri benimsemek istediği yaklaşımı ve bunun getireceği ödünleşimleri bildiğini gösterir.
Çoğu geliştiricinin Linear gibi özel bir senkronizasyon motoru oluşturmasına gerek yoktur. Tanstack Query ve SWR gibi kütüphaneler, iyimser güncellemelerle şaşırtıcı derecede benzer bir performans sağlayabilir. Önemli olan, kullanıcı arayüzü yanıt verme hızının ağ gecikmesine bağlı olmamasıdır. İyimser istekler, gereksiz spinner’ları ortadan kaldırır, durumu anında günceller, arka planda doğrular ve yalnızca gerektiğinde geri alır.
Linear’ın Teknoloji Yığınına Bir Bakış
Linear, React, TypeScript, MobX, Postgres ve bir CDN gibi sade bir teknoloji yığını üzerine kurulmuştur. Kenar veritabanı, React Server Bileşenleri veya gösterişli bir çerçeve yoktur. En dikkat çekici karar, istemci tarafı renderlama (CSR) yaklaşımına bağlı kalmalarıdır. CSR, yavaş başlangıç yüklemeleri nedeniyle eleştirilse de, doğru mimari ve tasarımla anında bir his verebilir. Bu yaklaşım, zihinsel modeli basitleştirir ve sunucu taraflı renderlama ile gelen karmaşıklığın çoğunu ortadan kaldırır. Linear, istemci tarafı uygulamasını şu şekilde anında hissettiriyor:
İlk Yüklemeyi Anında Hissettirmek
Üretkenlik araçlarında, çalışmaya başlamadan önceki süre en önemli detaylardan biridir. Linear, ilk yükleme performansına büyük önem verir. Bir istemci tarafı uygulamasının yavaş yüklenmesine neden olan faktörler, HTML, JavaScript ve CSS istekleri, kimlik doğrulama ve API istekleridir.
Linear’ın Paketleyici Gelişimi: Parcel, Rollup, Vite, Rolldown
Uygulamanın hızını hissettirmenin ilk adımı, çalışma zamanından çok önce, derleme zamanında başlar. Ağ bir darboğaz olduğundan, mümkün olan en az JavaScript ve CSS’i göndermek hızlı yükleme süreleri için kritiktir. Linear’ın derleme sürecini dört kez yeniden yazdığı görülmüştür: Parcel → Rollup → Vite → Rolldown. Her geçişin amacı aynıydı: JavaScript ve CSS miktarını azaltmak ve geliştirici deneyimini iyileştirmek. Kendi blog yazılarına göre:
- %50 daha az kod gönderimi.
- Sıkıştırmadan sonra %30 daha küçük boyut.
- Soğuk önbellek sayfa yüklemelerinde %10 ila %30 hızlanma.
- Aktif görevler görünümünün ilk boya süresinde %59 düşüş (Safari’de).
- Bellek kullanımında %70 ila %80 düşüş.
Bu iyileştirmelerin çoğu, yalnızca modern tarayıcıları hedefleme, daha iyi ölü kod eleme ve agresif kod bölme kombinasyonundan geldi. Eski tarayıcı desteğini bırakmak (polyfill yok, ES5 transpilasyonu yok) büyük bir kazanç sağlarken, ölü kod ve parçalama çalışmaları da aynı derecede önemlidir. Linear, minified JavaScript olarak yaklaşık 21 MB kod gönderse de, bu kod yüzlerce yol düzeyinde parçacığa agresif bir şekilde bölünmüştür ve isteğe bağlı olarak getirilir. Buradaki ders, hangi paketleyiciyi seçeceğiniz değil, eski tarayıcıları bırakmanın, native ESM’ye geçmenin ve çılgınca kod bölme yapmanın önemidir.
İlk Yüklemeden Sonra Ön Yükleme
JavaScript’inizi mümkün olan en küçük parçalara böldükten sonra, arka planda çalışma yapmaya başlayabilirsiniz. Yüzlerce parçaya bölmek yeni bir sorun yaratır: her parça diğer parçaları içe aktarır ve tarayıcı, ana betiği ayrıştırmadan bunların ne olduğunu bilmez. Linear, herhangi bir JavaScript çalışmadan önce, tarayıcının tüm listeyi görmesini ve istekleri paralel olarak tetiklemesini sağlar. Bu, ana betik ilk ‘import’ ifadesine ulaştığında, parçaların zaten önbellekte olmasını sağlar. ‘index.html’ dosyasının ‘<head />’ bölümündeki ‘<link rel=modulepreload crossorigin href=’…’>’ etiketleri bu tekniğin temelidir. ‘crossorigin’ özniteliği, ön yükleme ve içe aktarma isteklerinin aynı kaynağa ait olduğunu belirtir, böylece tarayıcı önbelleğe alınmış kaynakları yeniden kullanır. Bu sayede, soğuk yükleme zaman çizelgesi sıralı bir şelaleden tek bir paralel toplu işe dönüşür. Ağ yine işi yapar, ancak hepsini aynı anda yapar. Bu tekniğin güzelliği, kullanıcının giriş sayfasına ilk geldiğinde tüm bu işi arka planda yapabilmenizdir.
Daha Fazla Hız ve Çevrimdışı Yetenekler İçin Service Worker
Linear’ın geri kalan parçaları, kullanıcının henüz ziyaret etmediği görünümler için yol düzeyinde parçalar, bir service worker tarafından arka planda önbelleğe alınır. Worker, kaynak kodunda yaklaşık 1.200 hash’li varlığı (yol parçaları, ikonlar ve fontlar dahil) içeren bir önbellek manifestine sahiptir ve bunları ilk sayfa yüklemesinden sonra tembelce indirir. Giriş ekranına ulaştıktan birkaç saniye sonra, tüm uygulama önbellekte hazır olur. Bu, iki şey sağlar: Sonraki navigasyonlar ağı tamamen atlar ve uygulama ağ bağlantısı olmadığında bile çalışmaya devam eder. Yerel-öncelikli senkronizasyon motoruyla birleştiğinde (ki zaten kullanıcının verileri IndexedDB’de bulunur), Linear çevrimdışı kullanılabilir hale gelir. Görevleri okuyabilir, yenilerini oluşturabilir, başlıkları ve açıklamaları düzenleyebilir, durumları değiştirebilirsiniz. Her şey yerel işlem deposunda sıraya alınır ve bağlantı geri geldiğinde sunucuya aktarılır. Özetle, hızlı yükleme süreleri için Linear’ın adımları, mümkün olduğunca kodu elemek, onu küçük parçalara bölmek ve arka planda önbelleğe almaktır.
Önbellek İçin Vendor Paket Kompozisyonu
Linear’ın kullandığı her paketin kendi parçacığını alması ve bağımsız olarak önbelleğe alınması ilginçtir. Geleneksel bir ‘vendor.js’ dosyası, herhangi bir değişiklikte tüm bağımlılık grafiğini geçersiz kılarken, Linear’ın parçalama yaklaşımı, satıcı önbelleğini tek bir büyük dosyadan ince taneli hale getirir. Tek bir bağımlılığı güncellemek, bir parçacığı geçersiz kılarken, geri kalanlar önbellekte kalır. Bu, hızlı yükleme süreleri sağlamak için bir başka detaydır.
Büyük Font Dosyalarını Yüklemek
Font yüklemesi, birçok uygulamanın yanlış yaptığı detaylardan biridir. Hata modları görünürdür: yarım saniye boyunca görünmez metin, gerçek font değiştiğinde düzen kaymaları, ön yüklemenin eşleşmemesi nedeniyle çift çekilen kaynaklar. Linear’ın kurulumu üçünü de önler: HTML’in ‘<head>’ bölümünde ‘<link rel=’preload’ href=’…’ as=’font’ type=’font/woff2′ crossorigin=’anonymous’>’ ve CSS’deki ‘@font-face’ kuralı. Değişken fontlar, tek bir woff2 dosyasında tüm 100-900 ağırlık eksenini kapsar ve her ağırlık için ayrı istekleri ortadan kaldırır. ‘font-display: swap’, yedek yığını hemen render eder ve Inter yüklendiğinde değiştirir. Dikkat edilmesi gereken hile: ön yükleme etiketindeki ‘crossorigin=’anonymous”. Bu olmadan, tarayıcı fontu ön yükler, ardından CSS daha sonra başvurduğunda tekrar çeker, çünkü iki isteğin farklı CORS modları vardır. Ön yüklemedeki ‘crossorigin’, tarayıcının önbelleğe alınmış olanı yeniden kullanmasını sağlar.
Satır İçi Uygulama Kabuğu
İlk yüklemeyi hızlı hissettirmenin bir başka ana tekniği: ‘<head/>’ içine yeterli CSS’in satır içi olarak eklenmesi, harici bir stil sayfası çekmeden yükleme durumunu boyayacak kadardır. Linear, bu durumda, kullanıcının bir uygulama kabuğu görmesi için gerekli kritik CSS’i satır içine alarak bir ağ isteğini ortadan kaldırır. CSS’in ötesinde, başlangıç deneyimini yüklemek için kritik olan bir dizi satır içi JavaScript de bulunur. Herhangi bir paket ayrıştırılmadan önce, ‘index.html’deki JavaScript, ‘localStorage.splashScreenConfig’i okur, ‘sessionStorage’ geçersiz kılmalarını birleştirir ve kullanıcının hatırladığı kabuk token’larını doğrudan ‘document.documentElement.style’a uygular. Bu, kullanıcının uygulamayı URL çubuğuna ‘enter’ tuşuna bastığı anda kullanıma hazır hissetmesini sağlar. İlk ‘index.html’ yanıtında başlangıç uygulama kabuğunu göndermekten daha hızlı bir yol yoktur.
Önce Render Et, Sonra Kimlik Doğrula
Kimlik doğrulama, çoğu uygulamanın performans bütçesini tükettiği bir başka adımdır. Geleneksel akış: HTML’i getir, paketi yükle, oturumu doğrula, kullanıcıyı getir, çalışma alanını getir, sonra render et. Kullanıcının bir şey görmesi bir ila üç saniye sürer. Linear, kimlik doğrulamasını mutasyonlarla aynı şekilde ele alır. Mutlu yolu varsayar ve arka planda doğrular. Bu, yüklemede neredeyse anında tam deneyimi render etmelerini sağladığı için mimarilerinin en sevilen yönlerinden biridir. Çoğu CRUD uygulaması, gerçek oturumu bir HttpOnly çerezinde tutar, ardından ön yüzün başlangıçta kullanıcının oturum açıp açmadığını anlaması için ikinci bir JS okunabilir çerez veya ‘/me’ isteği ekler. Linear daha basit bir şey yapar. Paralel bir kimlik doğrulama sinyali sürdürmek yerine, satır içi önyükleme betiği yalnızca ‘localStorage.ApplicationStore’ın var olup olmadığını kontrol eder. Eğer varsa, kullanıcı Linear’ı daha önce bu tarayıcıda kullanmış demektir, yani çalışma alanı zaten IndexedDB’de beklemektedir. Bu, veritabanının tarayıcıda yaşadığı ilk bölümle bağlantılıdır. Eksikse, render edilecek bir şey yoktur, bu yüzden kabuk oturum açmamış düzene döner ve giriş akışı devreye girer. Bu model, istemcinin yerel olana güvendiği, sunucunun doğruluk için gerçek kaynak olduğu ve ikisinin eşzamansız olarak uzlaştığı mimarinin geri kalanıyla tutarlıdır. Bu, bir mutasyon gibi, senkronizasyon motorları gibi çalışır. Kimlik doğrulama için mutlu yolu varsayın ve değilse geri dönün. Gösterilecek veri varsa: gösterin! Ve hemen render etmek için tarayıcınızın veri depolarından yararlanın.
Senkronizasyon Motoru
Linear’ı hızlı yapan şeylerin çoğu, tek bir kararın aşağı akışında yer alır: sunucu, kullanıcı arayüzü için bir doğruluk kaynağı değil, bir senkronizasyon hedefidir. Senkronizasyon motorlarının iç detayları zaten kapsamlı bir şekilde tersine mühendislikle incelenmiştir. Ancak hızı üreten üç ana sütun vardır, çünkü hız, herhangi birinin değil, hepsinin bir araya gelme şeklinin bir özelliğidir.
1. Veri Zaten Orada
Uygulama başladığında, çalışma alanını sunucudan getirmez. IndexedDB’den bir bellekteki MobX nesne havuzuna hidratlanır ve kullanıcı arayüzünden gelen her sorgu önce havuza gider. ‘Görevler yükleniyor’ durumu yoktur çünkü görevler zaten kullanıcının makinesindedir. İlginç bir şekilde, ölçeklendikçe veri senkronizasyon motorunda JavaScript paketleri gibi benzer temeller kullanılarak parçalanmıştır. Her şey bir kerede getirilmez: en ağır iki tablo olan Issue (Görev) ve Comment (Yorum) isteğe bağlı olarak tembelce hidratlanır. Bu, veri düzeyinde kod bölmedir ve motorun ölçeklenmesini sağlayan şeydir: başlangıç maliyeti, çalışma alanı boyutunu değil, çalışma alanı yapısını izler. 10.000 görevli bir çalışma alanı, 100 görevli bir çalışma alanı kadar hızlı başlar. Bir projeye tıkladığınızda görevler oradadır. Görevliye göre filtrelediğinizde dizin zaten oluşturulmuştur. Getirilecek hiçbir şey yoktur çünkü eksik hiçbir şey yoktur. Ya tarayıcınızdan hemen yüklenmiştir ya da kısa süre sonra kod bölünmüş tembel bir parçacıkta.
2. Mutasyonlar Ağ İçin Beklemiyor
Bir görevin durumunu değiştirdiğinizde, üç şey neredeyse aynı anda gerçekleşir: MobX observable güncellenir, böylece kullanıcı arayüzü değişikliği yansıtır; mutasyon IndexedDB’deki kalıcı bir işlem kuyruğuna yazılır ve sunucu için sıraya alınır. Ağ henüz dokunulmamıştır. Kullanıcı, kendi değişikliğini görmek için asla beklemez. Yeniden deneme, geri alma, yeniden yüklemeler arası dayanıklılık, hepsi arka plandadır. Sunucu reddederse, observable geri döner ve kısa bir titreşim olur, ancak pratikte bu neredeyse hiç olmaz çünkü çoğu geçersiz mutasyon işlem oluşturulmadan önce yakalanır. Ağ düşmandır ve ondan kaçınmak için elinizden gelen her şeyi yapmalısınız. Linear’ın akışı yerel mutasyonla başlar ve sunucuyu bir onay adımı olarak görür, bir izin adımı olarak değil.
3. Tek Delta, Tek Hücre
Sunucu bir mutasyonu (sizin veya başkasının) onayladığında, değişiklik küçük bir JSON zarfı olarak geri döner ve neyin hareket ettiğini açıklar. İstemci, bunu ilgili MobX observable’a yazarak uygular. Linear’daki her modeldeki her özellik kendi observable’ı olduğu için ve bunu okuyan her bileşen ‘observer()’ ile sarılı olduğu için, MobX hangi bileşenlerin hangi alanlara bağlı olduğunu tam olarak bilir. Bir görevin bir alanını güncelleyen bir değişiklik, tam olarak o alanı okuyan bileşenleri yeniden render eder. Üst liste değil, kenar çubuğu değil, tek bir hücre. 50 görevlik bir güncelleme, bir liste yeniden render’ı değil, 50 hücre yeniden render’ıdır. Bu, on kişinin aynı anda bir şeyler düzenlediğinde yoğun bir çalışma alanının pürüzsüz kalmasını sağlayan şeydir: güncellemeleri alma maliyeti, ekrandaki şeye göre değil, değişen şeye göre ölçeklenir. Gerçek zamanlı uygulamalar geliştirirken, tek tek bileşenlerin atomik güncellemeleri, bir uygulamanın performanslı hissetmesi için anahtardır. Basamaklı güncellemelerden mümkün olduğunca kaçınmak istersiniz ve Linear tam olarak bunu yapar.
Üçü Neden Bir Arada Çalışır
Herhangi birini çıkardığınızda uygulama yavaş hissetmeye başlar. İyimser yazmalar olmayan yerel bir veritabanı, kaydetmede yine de döner. Granüler observable’lar olmadan iyimser yazmalar her güncellemede yine de takılır. Yerel bir veritabanı olmadan granüler observable’lar başlangıç yüklemesinde yine de bekler. Linear’ın hızı, herhangi bir tek katmanın bir özelliği değildir. Sistemin bir özelliğidir. Paketleyici ve yükleyici kabuk, uygulamanın ilk boyamada hızlı hissetmesini sağlayan şeydir. Senkronizasyon motoru ise uygulamayı kullanmaya başladığınızda hızlı hissetmesini sağlayan şeydir.
Hız İçin Tasarım
Hız sadece bir mühendislik problemi değildir, aynı zamanda bir tasarım problemidir. Mükemmel bir şekilde inşa edilmiş bir senkronizasyon motoru bile yavaş bir giriş modeline yenik düşer: bir eyleme giden en hızlı yol bir fare, üç menü ve bir tıklama gerektiriyorsa, kullanıcı temel motor ne kadar hızlı çalışırsa çalışsın bu adımların bedelini öder. Linear’ın hızının bir diğer temel taşı, klavyeyi navigasyon ve işi tamamlama için birincil araç olarak nasıl entegre ettikleridir. Her yaygın eylemin bir kısayolu vardır. Komut paleti tek bir tuş vuruşu uzaklıktadır. Sağ tıklama menüsü özel olarak inşa edilmiştir. Bunların hiçbiri tesadüf değildir, aksine ilk günden itibaren düşünülmüş tasarım kararlarıdır.
Her Eylemin Bir Kısayolu Var
Tek harfler odaklanılan görevi düzenler. İki harfli kombinasyonlar gezinmeyi sağlar. Değiştiriciler global olarak hareket eder. Kurucuların Linear’ın ilk günlerinden bahsettiğini dinlerken, kısayolların baştan beri temel olduğu açıktır. Senkronizasyon motoru kısmen, herhangi bir eylemin herhangi bir zamanda gerçekleştirilebilmesi için tasarlanmıştır. Bu tasarım ve mühendislik kombinasyonunun her özelliğin arkasında devam ettiği hissediliyor. Kullanıcı arayüzünde her yerde kısayolları fark edeceksiniz. En sık kullanılanlar, en sık kullanıldıkları için tek karakterlerdir. Ayrıca, yeni başlayanları yabancılaştırmamak için her eylem fareyle de yapılabilir.
Komut Paleti Her Zaman Bir Tuş Uzaklıkta
‘⌘ k’ tuşu, kullanıcılara Linear’daki neredeyse her eylem üzerinde arama yapma imkanı sunan bir komut paletini açar. Görevler, projeler, etiketler, durum değişiklikleri, navigasyon, görev oluşturma, ayarlar, tema geçişleri. Komut, bir sunucu yerine yerel MobX nesne havuzunda arama yaptığı için inanılmaz derecede hızlıdır. Ağı kaçının. Mimari olarak, tüm uygulama tek bir pencereden erişilebilir. Navigasyon aramadır. Görev oluşturma aramadır. Durum değişiklikleri, durumlara göre kapsama alınmış aramalardır. Dahası, komut bağlamsaldır ve üzerinde çalıştığınız şeye uyum sağlar. Herhangi bir görünüm için temel eylemleri ve kısayolları öğretmek için harika bir yoldur. Tek bir ilkel, her yerde kullanılır, zaten bellekteki veriler üzerinde çalışır. Hızlı bir uygulama, hem inanılmaz mühendislik hem de tasarıma ihtiyaç duyar. Mükemmel bir senkronizasyon motoru ve kusursuz bir renderlama hattı oluşturabilirsiniz, ancak tasarım yanlışsa yine de yavaş hissettiren bir şey gönderebilirsiniz. Mühendislik hızı, tek bir etkileşimi hızlı yapar. Tasarım hızı, her etkileşime giden yolu kısa yapar. Tüm gün kullanılan bir araç için, bir kısayol ile iki saniyelik bir fare yolu arasındaki fark, her eylemde katlanarak artar. Kısayolları global bir komut paletiyle birleştirdiğinizde, inanılmaz derecede hızlı kullanılan bir uygulamaya sahip olursunuz.
Animasyonlar
Şimdiye kadar yapılan tüm çalışmalar kötü animasyonlarla boşa gidebilir. Ekipler, uygulamalarının her bölümünü hızlı hale getirmek için büyük çaba harcarlar. İlk yükleme, güncellemeler, veritabanı sorguları, hepsi. Kullanıcıların asla beklemesi gerekmemesi için milisaniyeler tıraşlarlar. Sonra, en son adımda, biri bir öğeye 500ms’lik bir yükseklik animasyonu ekler.
Yalnızca Birkaç Özelliği Canlandırmalısınız
Tarayıcılar üç katmanlı özellik değişikliğine sahiptir ve maliyet, renderlama hattındaki yerle ölçeklenir. Birleşik özellikler (‘transform’, ‘opacity’) işi GPU’ya devreder ve ana iş parçacığından bağımsız çalışır. Boyamayı tetikleyen özellikler (‘color’, ‘background-color’, ‘border-color’, ‘fill’) düzeni atlar ancak yine de pikselleri yeniden çizer. Düzeni tetikleyen özellikler (‘width’, ‘height’, ‘top’, ‘left’, ‘margin’, ‘padding’) tarayıcıyı sayfadaki her sonraki öğenin konumunu yeniden hesaplamaya zorlar. Asla bunları canlandırmayın. ‘margin-left’ sürümü, fareyle üzerine gelinen her satırın altındaki her satırın düzenini, her karede, geçişin tüm 200ms’si boyunca yeniden hesaplar. Uzun bir görev listesinde bu, akıcı ve takılan arasındaki farktır. Linear’ın uygulamasında canlandırdığı her bir özelliğe baktığınızda, bunların çoğunlukla birleşik özellikler (‘transform’ ve ‘opacity’) ve bazen ‘background-color’ ve ‘border-color’ gibi özelliklerle sınırlı olduğunu görürsünüz.
Ne Zaman Geri Duracağınızı Bilin
Sadece birleşik özellikleri canlandırmak kadar önemli olan bir şey de ne zaman hiç canlandırma yapılmayacağını bilmektir. Animasyonlara kapılmak kolaydır. Ancak her gün kullanılan bir araçta, bir pazarlama sitesinde seveceğiniz animasyonlar engel olmaya başlar. Yanlış yerde küçük bir gecikme bile kullanıcının fark ettiği şey haline gelir. Linear bunun çoğunu başarıyor. Komut paleti belki biraz yavaş kalıyor, ancak bu konuda yıllar içinde yaşlı bir huysuz oldum. Animasyonlarının çoğu, kökenlerine referans verdikleri için çalışır. Durum açılır penceresi durum hapından ölçeklenerek çıkar. Hareket, kullanıcının yeni öğenin nereden geldiğini anlatır, dekorasyon olarak hiçbir yerden belirmez.
Süreleri Kısa ve Dinamik Tutun
Çoğu tasarım sistemi varsayılan olarak olması gerekenden daha uzundur. Material’ın standart süresi 200ms, iOS’un yayı 350ms’ye yakındır. Daha kısa geçişlere varsayılan olarak ayarlamak, bir uygulamanın daha hızlı hissetmesini sağlamanın en kolay yollarından biridir ve Linear’ın varsayılanları sektör normunun oldukça altındadır. Linear, giriş ve çıkışlarda asimetrik zamanlama ile bir adım daha ileri gider. Vurgular, açılır pencereler ve panel çağrıldığında anında görünür, ardından kapatıldığında 150ms içinde solur. Linear’ın Tasarım Mühendislerinden Emil Kowalski’nin animations.dev adresinde inanılmaz bir kurs oluşturduğunu belirtmek gerekir. Animasyon prensipleri, pratik örnekler ve eğitimler hakkında derinlemesine bilgi verir.
Linear Nasıl Bu Kadar Hızlı?
Linear’ı hızlı hissettiren daha birçok detayı ele alabiliriz. Gerçek şu ki, bir uygulamayı performanslı yapan tek bir şey yoktur. Yüzlerce doğru kararın birikimidir. Linear’ın yaklaşımında sevdiğim şey, çoğunun ne kadar basit olduğudur. Next, Tanstack veya süslü bir çerçeve yok. Baştan itibaren kullanıcılarına en iyi hizmeti verecek mimariye karar verdiler ve buna sadık kaldılar. Sonuç, sunucu tarafı renderlananlardan daha hızlı (ve karmaşıklık olmadan) istemci tarafı renderlanan bir uygulama! Yapısı kabaca şöyledir: Sunucu, bir doğruluk kaynağı olmaktan ziyade bir senkronizasyon hedefidir. Veritabanı tarayıcıda yaşar. Mutasyonlar önce yerel olarak uygulanır ve arka planda uzlaşır. İlk yükleme, daha az kodu daha fazla parçaya bölerek gönderir ve kullanıcı giriş sayfasındayken bir service worker geri kalanını önbelleğe alır. Kimlik doğrulama, duruma göre varsayılır ve daha sonra doğrulanır. Senkronizasyon motoru, IndexedDB’den özellik başına MobX observable’larına hidratlanır, böylece 50 görevlik bir güncelleme, bir liste yeniden render’ı yerine 50 hücre yeniden render’ıdır. Giriş modeli klavye önceliklidir. Her yaygın eylemin global bir komut paletiyle bir kısayolu vardır. Animasyonlar GPU’da kalır, süreler 100ms sebep-sonuç eşiğinin altında oturur ve düzeni tetikleyen özellikler asla canlandırılmaz. Zor kısım uygulama değildir. Yıllar boyunca, kod tabanı olgunlaştıkça, genişledikçe ve yeni kısıtlamalarla karşılaştıkça zanaata olan bağlılıktır. Eğer henüz yapmadıysanız, Linear’ı tüm bunları eylemde görmek için ziyaret etmenizi öneririm.
Umarım bir şeyler öğrenmişsinizdir! Bunu yazmak ve Linear’ı Linear yapan detaylara dalmak eğlenceliydi. Dünyanın en iyi web uygulamalarını inşa etmeyi ve diğer insanların bunu nasıl yaptığını görmeyi seviyorum.
