Figma'nın TypeScript'e geçiş yolculuğu

 (figma.com)
5 puan yazan GN⁺ 2024-05-05 | 1 yorum | WhatsApp'ta paylaş
  • Figma, mobil render alma ve prototip görüntüleyicide kullandığı kendi dili Skew'ün onboarding, entegrasyon ve ekosistem açısından sınırlara dayanması üzerine tüm Skew kodunu TypeScript'e taşıdı
  • Geçişin zemini, mobil tarayıcılarda WebAssembly desteğinin yaygınlaşması, çekirdek yolların C++ motoruyla değiştirilmesi ve prototipleme ile mobil ekiplerinin büyümesiyle oluştu
  • Migrasyon, Write Skew, build Skew → Write Skew, build TypeScript → Write TypeScript, build TypeScript olmak üzere 3 aşamada ilerledi ve Skew-to-TypeScript transpiler geliştirme akışını korudu
  • Gerçek taşıma sürecinde dizi destructuring performansı, devirtualization farkları, başlatma sırası, source map bağlantısı ve koşullu derleme eksikliği gibi uyumluluk sorunları ortaya çıktı
  • Sonunda birim testlerini geçen ve Skew'e benzer performans sunan bir TypeScript kod tabanı elde edildi; Figma bundan sonraki adım olarak iç ve dış kod entegrasyonu, paket yönetimi ve TypeScript ekosisteminden yararlanmayı görüyor

Skew'den TypeScript'e neden geçildi

  • Skew, Figma'nın ilk dönem yan projelerinden doğdu ve hem web'i hem de mobili destekleyen bir prototip görüntüleyiciyi hızlıca geliştirme ihtiyacını karşıladı
  • JavaScript'e derlenen bir dil olarak gelişirken ileri düzey optimizasyonlar ve hızlı derleme süreleri sundu, ancak prototip görüntüleyicide kod biriktikçe bakım maliyeti büyüdü
    • Yeni işe başlayanların öğrenmesi zordu
    • Kod tabanının geri kalanıyla kolay entegre olmuyordu
    • Figma dışında bir geliştirici ekosistemi yoktu
  • TypeScript'e geçişten beklenen etki, geliştirme hızını ve iş birliği kapsamını büyütmekti
    • Statik import ve yerel paket yönetimiyle iç ve dış kod entegrasyonunu sadeleştirmek
    • Linter, bundler, statik analiz araçları gibi büyük geliştirici topluluklarının ürettiği araçlardan yararlanmak
    • async/await gibi modern JavaScript özelliklerini ve daha esnek bir tip sistemini kullanmak
    • Yeni geliştiricilerin onboarding sürecini ve diğer ekiplerin katkı eşiğini düşürmek

Geçişi ancak yakın zamanda mümkün kılan koşullar

  • Figma mobil kod tabanını ilk oluşturduğunda mobil tarayıcılar WebAssembly desteklemiyordu ve büyük bundle'ları yüksek performansla yüklemek de zordu
  • TypeScript de henüz erken aşamadaydı; bu yüzden statik tipler ve daha katı bir tip sistemi sunan Skew o dönemde daha gerçekçi bir seçimdi
  • WebAssembly, 2018'e kadar mobilde yaygın destek kazandı ve Figma'nın testlerine göre 2020'de mobil performans güvenilir bir seviyeye ulaştı
  • Skew'ün ilk güçlü yanı; constant folding, virtual call elimination gibi geleneksel derleyici optimizasyonları ve gerçek tamsayı işlemleri kullanan JavaScript üretimi gibi web'e özgü optimizasyonlardı
  • 2020 benchmark'larında Safari'de Figma prototipini TypeScript ile yüklemenin neredeyse 2 kat daha yavaş olabileceği görüldü ve iOS'ta Safari'nin izin verilen tek tarayıcı motoru olması geçişi engelleyen bir etkendi
    • iOS 17.4 ile Apple, AB kullanıcıları için başka tarayıcı motorlarına izin verdi ancak diğer bölgelerde kullanıcılar için WebKit hâlâ tek tarayıcı motoru
  • Sonrasında Skew motorunun birçok çekirdek bileşeni C++ motorundaki karşılıklarıyla değiştirildiği için TypeScript'e geçişin performans riski azaldı
    • Buna dosya yükleme gibi en sıcak kod yolları da dahildi
    • Böylece TypeScript'e geçildiğinde performans kaybının tolere edilebileceğine dair güven oluştu
  • Prototipleme ve mobil ekipleri daha büyük organizasyonlara dönüştükçe otomatik migrasyon ve geliştirici deneyimi iyileştirmelerine kaynak ayrılabildi

3 aşamalı kod tabanı geçişi

  • 2020'deki ilk migrasyon prototipinde TypeScript performansı neredeyse 2 kat daha yavaştı
  • WebAssembly desteği ve mobil motorun C++'a geçişi yeterli seviyeye geldikten sonra, Figma Maker Week sırasında mevcut prototipi düzeltip tüm testleri geçen çalışan bir migrasyon gösterdi
  • Hedef tüm kod tabanını TypeScript'e geçirmekti, ancak elle yeniden yazım geliştirme hızını düşürebilir, runtime hataları ve performans gerilemeleri yaratabilirdi
  • Skew ile TypeScript arasındaki anlam farkı, basit bir “tipli JavaScript” geçişinden daha büyüktü
    • TypeScript'te namespace ve class'lar ancak dosya import edildikten sonra başlatılır
    • Import sırası beklendiği gibi değilse runtime hatası çıkabilir
    • Skew ise yükleme anında tüm sembolleri runtime'da tüm kod tabanı boyunca kullanılabilir kılar
  • Figma, Evan Wallace'ın geçmişte başlattığı çalışmayı temel alarak Skew-to-TypeScript transpiler geliştirdi

  • Phase 1: Skew yaz, Skew derle

    • Mevcut build süreci korunurken transpiler geliştirildi
    • Üretilen TypeScript kodu GitHub'a commit edilerek geliştiricilerin yeni kod tabanı biçimini görmesi sağlandı

  • Phase 2: Skew yaz, TypeScript derle

    • Tüm birim testlerinden geçen TypeScript bundle'ı üretildikten sonra, production trafiği TypeScript kod tabanı build'ine kademeli olarak yönlendirildi
    • Geliştiriciler hâlâ Skew yazıyordu ve transpiler Skew kodunu TypeScript'e çevirip GitHub'daki TypeScript kodunu güncelliyordu
    • Üretilen kodun tip hataları da düzeltilmeye devam etti
    • TypeScript, tip hataları olsa bile geçerli bir bundle üretebiliyordu

  • Phase 3: TypeScript yaz, TypeScript derle

    • Tüm kullanıcılar TypeScript build sürecinden geçtikten sonra, TypeScript kodu geliştirme için tek doğruluk kaynağına dönüştürüldü
    • Kod birleştirmesinin olmadığı bir zaman bulunarak otomatik üretim süreci durduruldu ve kod tabanındaki Skew kodu silindi
    • Cuma gecesi otomatik üretimi kaldıran ve CI işlerini TypeScript dosyalarını doğrudan çalıştıracak şekilde değiştiren merge yapıldı
    • Kademeli dağıtım sırasında Smart Animate özelliğindeki bozulma içeride fark edildi; gated rollout sayesinde dağıtım durdurulup sorun düzeltildikten sonra plan yeniden gözden geçirilebildi

Transpiler'da ortaya çıkan sorunlar

  • Derleyiciler genelde frontend ve backend'den oluşur
    • Frontend, girdi kodunu parse eder, tip ve sözdizimi denetimi yapar, ardından ara gösterime (IR) dönüştürür
    • Backend, IR'yi başka bir dile dönüştürür
    • Skew derleyicisinin backend'i obfuscated ve minified JavaScript üretir
  • Transpiler, backend'inin insan tarafından okunabilir kod ürettiği özel bir derleyici türüdür; Figma'nın da Skew IR'den insanın okuyabileceği TypeScript üretmesi gerekiyordu
  • İlk uygulama, Skew'ün JavaScript backend'inden ciddi ölçüde ilham aldığı için görece sorunsuz ilerledi ancak sonlara doğru takibi ve işlenmesi zor pek çok sorun çıktı

  • Dizi destructuring performansı

    • Örnek prototipte Skew ile TypeScript'in çevrimdışı performans farkı incelenirken TypeScript'te kare hızı daha düşük çıktı
    • Bunun nedeni JavaScript'teki array destructuring idi
    • const [a, b] = function_that_returns_an_array() gibi işlemlerde JavaScript, diziyi doğrudan indekslemek yerine iterator oluşturup dolaşır
    • Figma, JavaScript'in arguments anahtar sözcüğünden argüman almak için bu yaklaşımı kullanıyordu ve bazı test senaryolarında performans düşüyordu
    • Destructuring yerine arguments dizisini doğrudan indeksleyen kod üretilerek kare başına gecikme en fazla %25 iyileştirildi

  • Skew'ün devirtualization optimizasyonu

    • Skew derleyicisi belirli koşullarda class içindeki fonksiyonları dışarı alıp global fonksiyon hâline getiren devirtualization optimizasyonu uygular
    • myObject.myFunc(a, b) ifadesi myFunc(myObject, a, b) biçimine dönüşebilir
    • TypeScript bu optimizasyonu yapmaz
    • Smart Animate bozulması, myObject'in null olduğu bir durumda yaşandı
    • Devirtualized çağrı normal çalışırken, devirtualized olmayan çağrı null erişim istisnası üretti
    • Figma, aynı sorunu taşıyan çağrı noktalarını bulmak için devirtualization'a katılabilecek tüm fonksiyonlara log ekledi
    • Kısa bir süre loglama açıldı, production log'ları incelendi ve sorunlu çağrı noktaları düzeltildi

  • Başlatma sırası farkı

    • Skew'de değişken, class, namespace ve fonksiyon tanımlarını kodun neresine koyduğunuz önemli değildir
    • TypeScript'te ise global değişkenlerin veya class tanımlarının başlatılma sırası önemlidir
    • Class tanımından önce static class değişkenini başlatmak derleme zamanı hatasına yol açar
    • İlk transpiler, namespace kullanmadan tüm fonksiyonları global scope'a düzleştirerek Skew'e benzer davranışı korudu
    • Ortaya çıkan kod okunması zordu; daha sonra transpiler düzeltilerek TypeScript kodu doğru sırada üretildi ve okunabilirlik için namespace yeniden eklendi
    • Sonunda birim testlerini geçen ve Skew performansına denk TypeScript kodu derleyebilen bir transpiler ortaya çıktı
    • Bazı küçük sorunlar için transpiler'a yeni düzeltme eklemek yerine Skew kaynak kodunda elle değişiklik yapıldı veya TypeScript'e geçildikten sonra düzeltildi

Source map ile hata ayıklama deneyimini korumak

  • Figma, TypeScript'e geçiş sırasında da geliştiricilerin kesintisiz hata ayıklayabilmesi için source map'leri kritik gördü
  • Tarayıcı debugger'ı yalnızca JavaScript'i anlar, ancak geliştiriciler breakpoint'i Skew veya TypeScript kaynağına koyar
  • Source map, derlenmiş JavaScript konumlarıyla orijinal kaynak konumlarını eşler
    • Örneğin helper → c, myInt → a, arrayOfInts → b gibi eşlemeler yapılabilir
  • Genellikle .map uzantılı tek bir source map dosyası nihai JavaScript bundle'ına bağlanır
  • Mevcut altyapı Skew → JavaScript source map üretiyordu, ancak Phase 2'de pipeline Skew → TypeScript → esbuild bundling akışına dönüştü
  • Eski source map aynen kullanıldığında JavaScript ile Skew kodu arasındaki eşleme bozuluyor ve geliştiriciler debug yapamıyordu
  • Yeni build süreci source map'i 3 adımda oluşturdu
    • Step 1: esbuild, TypeScript → JavaScript source map ts-to-js.map üretir
    • Step 2: transpiler, her Skew dosyası için Skew → TypeScript source map üretir
    • Step 3: iki source map birleştirilerek Skew → JavaScript nihai source map oluşturulur
  • Nihai source map sayesinde yeni JavaScript bundle'ı Skew koduna eşlenebildi ve Phase 2 sırasında da geliştirici deneyimi korundu

TypeScript'te koşullu derlemeyi ele alma

  • Skew, üst düzey if deyimleri ve derleyiciye verilen defines seçeneğiyle koşullu derleme destekliyordu
  • Bu özellikle aynı kod tabanından farklı bundle'lar üretilebiliyordu
    • Kullanıcılara dağıtılan gerçek bundle
    • Yalnızca birim testleri için olan bundle
    • Debug veya release build'de farklı uygulamalar kullanan fonksiyonlar ya da class'lar
  • TypeScript'te koşullu derleme olmadığı için Figma, tip kontrolünden sonra esbuild'in defines ve dead code elimination özelliklerini kullanarak bundle aşamasında koşullu derleme yaptı
  • Bu yaklaşımda defines, tip kontrolünü etkileyemez
    • BUILD == "TEST" olduğunda var olan testOnlyFunction gibi kodlar TypeScript'te aynı şekilde var olamaz
  • Çözüm, class ve method'ları her zaman tanımlayıp method içinde BUILD değerine göre dallanacak biçime dönüştürmek oldu
    • Test dışı build'lerde testOnlyFunction çağrılırsa Unexpected call to test-only function hatası fırlatılır
  • Nihai JavaScript, orijinal Skew kodunun ürettiği JavaScript ile aynı olacak şekilde derlenebildi
  • Ancak bazı semboller eskiden yalnızca belirli derleme modlarında varken bu değişiklikten sonra tüm modlarda var oldu ve nihai bundle biraz büyüdü
  • Testlerde bundle boyutundaki artış kabul edilebilir bulundu ve export edilmeyen üst düzey semboller tree-shaking ile kaldırılabildi

Geçiş sonrası yön

  • Tüm Skew kodunun TypeScript'e taşınmasıyla Figma'nın temel kod tabanlarından biri modernize edildi
  • İç ve dış kodla entegrasyon kolaylaştı, geliştiriciler daha verimli çalışabilir hâle geldi
  • O dönem Figma'nın ihtiyaçları ve yetkinlikleri açısından kod tabanına Skew ile başlamak doğru bir karardı
  • Teknoloji olgunlaştıkça geçmişte uygun olmayan TypeScript bugün doğru seçenek hâline geldi
  • Figma bundan sonraki çalışma alanı olarak şu olasılıkları inceliyor
    • Kod tabanının geri kalanıyla entegrasyon
    • Çok daha kolay paket yönetimi
    • Canlı TypeScript ekosistemindeki yeni özellikleri doğrudan kullanma
  • Geçiş sürecinde import çözümleme, modül sistemi ve JavaScript kod üretimi gibi TypeScript'in çeşitli yönleri de öğrenildi

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-05
Hacker News yorumları

  • Figma'nın JS için özel bir dili olması da şaşırtıcı, bunun TS'den hızlı olması daha da şaşırtıcı
    Ama sonunda daha yavaş olan TS'ye geçmeleri de ilginç
    Böyle şeyler epey sık görülüyor: Şirket başlangıçta kendi teknolojisini geliştiriyor, büyüdükten sonra daha “standart” bir şeye taşınıyor

    • Oldukça tipik bir akış gibi görünüyor. Başlarda Evan gibi çok yetenekli bir kişi tüm araç zincirini ve ürünün çekirdeğini kuruyor; sonra ayrılıyor, kenara itiliyor ya da ilgisini kaybediyor
      Ekip ve ürün çok daha büyüyünce, daha tanıdık ve yaygın kullanılan bir stack'e yeniden platform değiştiriliyor
      Böyle bir geçişin başarısı büyük ölçüde kurumun mühendislik kültürünün ne kadar sağlam olduğuna bağlı. Dayanağım yok ama Evan ve kurucuların Figma'da harika bir mühendislik kültürü oluşturmuş gibi göründüğünü, hatalar çıksa bile bunları düzeltecek yeterli dayanıklılığa sahip olduklarını düşünüyorum
    • Dikkatli okursanız performansa duyarlı kısımların tamamının C++/WASM'a taşındığını görürsünüz
      O noktada geriye sadece yapıştırıcı kod kalmıştı ve özel dilin artık var olma nedeni kalmamıştı
    • PHP topluluğunda da benzer bir şey olmuştu. Facebook başlıca örnek ama Yahoo'nun da epey kurum içi optimizasyonu vardı; başka şirketlerin de performans ya da güvenlik için kendi yamalarını yaptığını gördüm
      Sonra topluluğun arayı kapatıp şirketten daha büyük bir ivme kazandığı noktada, standart uygulamaya geçmek mantıklı hale geliyor
      Google'ın Borg'dan k8s'e uzanan akışını da biraz benzer görüyorum. Ancak Google, topluluğu kendi yarattıkları standardın etrafına davet eden taraftı
    • Dar bir kullanım alanında TS'den hızlı olmak nispeten düşük bir çıta. Ama ölçek büyüdükçe bu çıta, piyasada bulunabilecek geliştirici havuzuyla birlikte değerlendirilmek zorunda
      Tamamen yeni bir framework'ü ilk kez görüp öğrenebilecek geliştiricinin maliyetini, zaten kullanılan bir platform ya da teknoloji hakkında belgelenmiş deneyimi olan geliştiricinin değeriyle karşılaştırmak gerekir
      Tamamen şirket içi geliştirmeye gidildiğinde herhangi bir dil ya da framework'ten muazzam performans çıkarabilirsiniz; ancak proje daha fazla durumu ele almak zorunda kaldıkça bakım için gereken geliştirici sayısı artar ve sonunda, yavaş olup gereksinimlere tam uymasa bile hazır yazılımın daha iyi hale geldiği bir nokta gelir
      Uzun vadede unicorn düzeyinde işe alım kriterlerini sürdürebiliyorsanız tamamen özel bir stack'i de koruyabilirsiniz. Ama çoğu organizasyon, ortalama yeni işe alınan kişinin ileride sürdürebileceği tarafa geçmek zorunda kalır; bu da genellikle ünlü ve sıkıcı yazılım tedarikçilerinin ürünleri anlamına gelir
    • Özel dil gibi alışılmadık ve tuhaf şeyler, uygulayıcısı değil de basit kullanıcısıysanız —örneğin o dili kullanan bir geliştiriciyseniz— özgeçmişte dezavantajdır
      Hırslı biri için ayrılma nedeni olabilir; işe alımı zorlaştırır ve onboarding süresini uzatır. İleride özel dili bıraktığınızda büyük bir geçiş projesi de gerekir
      Performans artışı muazzamsa, daha güvenli kod yazmayı sağlıyorsa ya da yalnızca yeni dil öğrenmeyi seven kişileri işe almak gibi bir niyetiniz varsa bazen buna değer

  • Bu projede çalıştım. Twitter'da biraz daha yazdım: https://twitter.com/andrew_k_chan/status/1786769203912925477
    Yazının başlığı yanıltıcı. Figma'da kod tabanının başka kısımlarında neredeyse 10 yıldır Typescript kullanılıyordu ve bu sürenin neredeyse tamamında Typescript kodu Skew'den daha fazlaydı
    Blog yazısında anlatıldığı gibi Skew; mobil motorda, daha sonra prototipleme oynatıcısında, yansıtma özelliğinde ve hatırlamadığım bir iki ürün alanında kullanıldı

  • Skew, TypeScript'ten sadece biraz daha hızlı değildi
    Eski Figma CTO'su Evan Wallace'a göre, daha katı tip sisteminin mümkün kıldığı optimizasyonlar sayesinde 1,5~2 kat daha hızlıydı

    • Keşke tarayıcılar JS'in "use strong" modu geliştirmesini sürdürseydi
      Görünüşe göre oldukça büyük zorlukları vardı ama daha öngörülebilir optimizasyonlar için dinamikliği bir miktar azaltmak, üretim düzeyi uygulamalar için iyi bir ödünleşim gibi geliyor
    • “Daha katı tip sistemi sayesinde 1,5~2 kat hızlıydı” sözü muhtemelen o kadar basit değil
      Sıcak yürütme yollarını optimize ederseniz 2 katlık avantajın ortadan kalkma olasılığı epey yüksek
      Elbette bu durumda birçok yerde optimize JS yazmaya zorlanırsınız ve bunun okunabilirliği etkilediği söylenebilir. Doğru; ama bunun alternatifi araç desteği ve bilinirliği düşük, tamamen yeni bir JS derleme dili kullanmaktı
      Bugünden bakınca buna değmemiş gibi görünüyor; blog yazısı da tartışmalı eski bir teknoloji seçimini biraz iyi gösterme çabası gibi duruyor
    • Tüm yazıda en şaşırtıcı olan 2 katlık hız farkıydı
      TypeScript kullanımını bu performansı veren alt kümeyle sınırlamanın mümkün olup olmadığını merak ediyorum

  • const [a, b] = function_that_returns_an_array() gibi bir işlemi tamamlerken JavaScript’in diziden doğrudan indeksleme yapmak yerine diziyi dolaşan bir yineleyici oluşturması ilginç
    JS, yapı parçalama atamasında neden diziyi doğrudan indekslemiyor?

    • Herhangi bir nesneye Symbol.iterator eklenirse yinelenebilir nesne olabilir ve yapı parçalama bu nesnelerde de çalışmak zorunda. Hatta dizinin kendi Symbol.iterator’ı bile yamalanabildiği için VM’in bunu ele alması gerekiyor
      Array.prototype[Symbol.iterator] = function*() { yield 1; yield 2; yield 3; }
      [...[4, 5, 6]]
      [1, 2, 3]
      Yineleyici protokolünün berbat performansı o zaman da tartışılmıştı ama kaçış analizi bunu çözer denerek görmezden gelindi [0]. Aradan neredeyse 10 yıl geçmişken kaçış analizi hâlâ bunu çözemedi; GC’yi çok fazla kullanıyor ve hâlâ pek iyi değil. Performansın farkında olmayan insanların tasarladığı kötü bir spesifikasyon
      Kullanıcı Symbol.iterator’ı yamalamadıysa motorun dizilerde yapı parçalama atamasını ve splice işlemlerini özelleştirip yineleyici protokolü ek yükünü ortadan kaldırması da mantıklı olabilir, ama bu da ayrı bir baş ağrısı
      [0] https://esdiscuss.org/topic/performance-of-iterator-next-as-...
    • Proxy gibi şeyler var olduğu için gibi görünüyor
      Daha da garibi, bazı JavaScript motorlarında iki üç elemanlı dizileri yapı parçalamayla ayırırken {0: foo, 1: bar} biçimindeki nesne yapı parçalama daha hızlı olabiliyor

  • Skew’in kolaylık sağlayan özelliklerini kaybetmenin sürekli geliştirici deneyimi etkisi pek ele alınmıyor; yalnızca kod tabanını taşırken bir kez yapılan dönüşümden söz ediliyor
    Örneğin TypeScript’te dosyaları doğru sırayla içe aktarmak zorunda kalmanız kolayca mümkün olabiliyor; aksi hâlde bozulabiliyor. Ayrıca yapı parçalama yavaş olduğu için performans azıcık bile önemliyse kullanılmamalı
    TypeScript’i birkaç yıl kullanınca böyle onlarca tuzak olduğunu görüyorsunuz; bazıları JavaScript’ten miras, bazıları değil. Çok sayıda mühendis varsa en azından kapsamlı bir stil rehberi gerekiyor
    Skew’in ortadan kalkmasına üzülen mühendisler olup olmadığını merak ediyorum

    • Geliştiricilerin sonuçtan memnun kalmasını sağlamak kesinlikle önemliydi. Bu yüzden kullanıma alma sürecine, geliştiricilerin Skew yazmaya devam ettiği ama değişikliklerin üretilen TS olarak otomatik check-in edildiği bir aşama ekledik
      Böylece geliştiriciler PR incelemelerinde sonucun nasıl görüneceğini görebiliyor ve sorunları bildirebiliyordu
      Performans ve çalışma zamanı doğruluğu açısından TS’te bazı tuzaklar olduğu doğru. Dizi yapı parçalama gibi sorunları enstrümantasyon ve sıkı izleme ile yakaladık
      Skew’in bazı özelliklerinin, örneğin operatör aşırı yükleme ve tamsayı tiplerinin kaybolması kesinlikle üzücüydü. Ama geçiş sonuçta tüm ekibin aldığı bir karardı ve ben de bunun doğru karar olduğunu düşünüyorum

  • “async/await gibi modern JavaScript özellikleri ve daha esnek bir tip sistemi” deniyor; o hâlde Skew’de yalnızca callback mi vardı?

    • Belki Promise vardı?

  • Figma’yı pek bilmeyen biri olarak, neden WebAssembly kullandıklarını merak ediyorum

    • Figma’nın UX tasarım yazılımı olduğunu muhtemelen biliyorsunuzdur. Yani temelde bir grafik programı. Şekiller çiziyor, kaydırıyor, yakınlaştırıp uzaklaştırıyorsunuz
      Figma bunu olağanüstü iyi yapıyor. Karmaşık UI ekranlarının çok olduğu çok büyük bir tuvalde bile inanılmaz derecede seri
      Günümüz masaüstü uygulamaları arasında bile bu kadar iyi çalışan çok az şey var. Bu tür optimizasyonun Figma’nın başarısının önemli bir parçası olduğundan eminim
    • Vektör düzenlemede CPU’ya bağlı işler çoktur. Evan’ın WASM’e geçiş hakkında yazdığı bir yazı var: https://medium.com/figma-design/webassembly-cut-figmas-load-...
    • İlk hedef tarayıcı içinde Photoshop idi

  • Figma’nın güvenlik sorununu, yani izinleri çözmek için özel bir TypeScript DSL + derleyici oluşturma biçimine dair ilginç ayrıntılar başka bir blog yazısında da var
    https://www.figma.com/blog/how-we-rolled-out-our-own-permiss...

  • Biraz can acıtıcı geliyor. Her büyük şirketin kendi dahili aracı, dili, Kubernetes benzeri şeyi var. Neden paylaşmıyorlar ki
    Skew açık kaynak olsaydı daha iyi bir TypeScript olabilirdi

    • Skew açık kaynak ama artık bakımı yapılmıyor: https://github.com/evanw/skew
    • Bu bakış açısını pek sevmiyorum; genellikle açık kaynak deneyimi eksikliğinden kaynaklanıyor
      Açık kaynak olması, bedava katkı geleceği anlamına gelmez. Önemsiz olmayan her PR’ın uzun inceleme, tartışma, hatta belki yeniden yazım gerektirmesi gerekir

  • TypeScript’i seviyorum ve TypeScript ile full-stack sistemlerimiz de var, ama mükemmel değil. Bir monorepo’da TypeScript’i yapılandırmak kâbus gibi.
    pnpm monorepo’su altındaki iç paketlerle birlikte anlaşılır hâle getirmek için tüm yolların birbiriyle uyumlu olması adına tsconfig.json üzerinde çok fazla elle çalışma yapmak gerekiyor.
    Ayrıca mükemmel tsx paketi çıkana kadar production toolchain’i fiilen bakım yapılamaz durumdaydı.
    Bir de akıl almaz derecede yavaş. Zod yüzünden TypeScript dil sunucusu performansının ciddi biçimde yavaşlaması sorunu vardı; sonunda proje referanslarını devreye alıp proje referansı yönlendirmelerini kapatmak zorunda kaldık.
    Genel olarak TypeScript’i daha iyi hâle getirmek için çok alan var. Özellikle monorepo ve performans tarafında.

    • Zod’un type checking hızını ne kadar yavaşlatabildiği konusunda epey istisnai bir örnek olduğunu hesaba katmak gerekir. Örneğin https://dev.to/nicklucas/typescript-runtime-validators-and-d... adresindeki bir test neredeyse 300 ms’ye kadar çıkıyor, diğer kütüphaneler ise 100 ms’ye bile pek yaklaşmıyor.
    • Zod’un yavaş olduğu biliniyor. Örneğin Typebox çok daha hızlı. “Değiştirin” demek istemiyorum; bunun bir TypeScript sorunu ya da TypeScript’in çözmesi gereken bir sorun olmadığı anlamına geliyor.
      Monorepo sorunu, tüm paketlerde aynı yapılandırmayı kullanmamışsınız gibi geliyor. Öyleyse önce aynı yapılandırmayı ve kodlama standartlarını zorunlu kılmayı düzeltirdim. Bu da TypeScript’in sorunu değil.
      Acaba tsx’ten önce ts-node mu kullanıyordunuz? Öyleyse tsx çok daha sağlam. Sadece düzgün çalışıyor.
    • Belirli araç ve kütüphane seçimi kombinasyonlarını TypeScript’in desteklemesi gerekmiyor; tersine araç ve kütüphane tarafının uyum sağlaması gerekiyor.
      Orta ölçekli bir monorepo’da, birden çok uygulama ve çok sayıda servisi çoğunlukla TypeScript ile çalıştırıyoruz; sıradan npm workspaces tabanlı yapılandırmayla bile gayet iyi işliyor.
    • Zod yavaş diye TypeScript yavaş demek, JavaScript yavaş diye C++ yavaş demeye benziyor.
      TypeScript’in hızlı olduğu anlamına kesinlikle gelmiyor; ama JavaScript ile yazılmış olduğu için hızlı olması da zor.
      Ancak büyük ölçekli bir uygulamada tip çıkarımı için TypeScript’in kodu çalıştırmasına izin vermek kendi yarattığınız bir sorun gibi görünüyor.