- Son dönemde Deno Deploy, KV, Fresh ve genel olarak şirket ile proje momentumu hakkında eleştiriler ve endişeler ortaya çıktı
- Bu eleştirilerin bir kısmı geçerli; ilerlemeyi kendi taraflarında yeterince açık paylaşmamaları da kafa karışıklığını büyüttü, ancak bu söylenti ve eleştirilerin önemli bir bölümü dayanaksız tahminler veya gerçeğe aykırı içerikler
- Deno 2'nin çıkışından sonra (Ekim 2023'ten bu yana) aylık aktif kullanıcı metriğine göre benimsenme oranı 2 katın üzerinde arttı
- Deno 2'nin güçlü Node uyumluluğu, gerçek uygulamalarda büyük bir engeli ortadan kaldırdı ve platform daha hızlı, güçlü ve basit hale geldi
Deno Deploy'daki değişim ve evrim
- En çok sorulan sorulardan biri, yakın zamanda Deno Deploy'da kullanılabilir bölgelerin azaltılmasının nedeni
- Bu azaltmanın arkasında maliyetin yanı sıra gerçek kullanım kalıpları ve ihtiyaçlardaki değişim de var
- Çoğu uygulama için önemli olan tüm bölgeler değil, veriye yakın konumlardaki hız, debug ve mevzuat uyumluluğu
- Deploy yayına alındığından beri 25'ten 35'e, şimdi ise 6 bölgeye kadar değişim yaşandı
- Birçok bölge gerçekte neredeyse hiç kullanılmadığı için, aşırı dağıtım performans düşüşüne (gecikme, kapasite sorunları) yol açıyordu
- Kullanıcıların ihtiyaçlarına uyan pratik bir “edge” vizyonu yeniden inşa ediliyor
- Deploy'un yeni bir sürümü geliştiriliyor ve platform tam uygulama barındırma yönünde evriliyor
- Alt süreçler, arka plan işleri, OpenTelemetry, build pipeline'ları, self-hosted bölgeler vb. desteklenecek
- Yakında uygulamaları belirli bölgelere sabitleme veya kendi bulutunda çalıştırma imkânı sunulacak
KV (anahtar-değer deposu) yönü
- Deno KV, yapılandırma gerektirmeyen, küresel tutarlılık garantili ve gerçek zamanlı özellikler sunan basit API'li bir depo
- Oturum verileri, feature flag'ler ve işbirliği durumu gibi kullanım alanlarına uygun, ancak genel amaçlı bir veritabanı değil
- Daha geniş veri yönetimi ihtiyaçları için iki çalışma yürütülüyor
- Mevcut ilişkisel veritabanlarının Deno Deploy içindeki entegrasyonunu güçlendirmek
- Compute ile state bağlantısını basitleştiren yeni bir proje üzerinde çalışmak (Cloudflare Durable Objects'ten ilham alıyor)
- Bu yön doğrultusunda KV beta olarak kalacak ve yalnızca kritik hata/güvenlik sorunlarına sürekli müdahale edilecek
- Genel durum yönetimi çözümünün merkezi ya da evrilmiş rolünü gelecekte başka projelerin üstlenmesi bekleniyor
Fresh framework'ünün durumu
- Fresh hâlâ şirket içindeki tüm uygulama ve web'lerin temeli ve aktif biçimde korunup geliştiriliyor
- Fresh 2 için yüksek beklentilerin ve uzun bekleyişin farkındalar
- Acele bir çıkış yerine temel kaliteyi ve yapıyı iyileştirmeye öncelik veriliyor
- Yakın zamanda yayımlanan ayrıntılı iyileştirmeler hakkındaki blog yazısına bakılabilir
- Bu yıl içinde kararlı bir Fresh 2 dağıtımı planlanıyor
Deno, bir runtime'dan fazlası olan platform
- Deno, yalnızca bir runtime'ın ötesinde tam teşekküllü bir JavaScript sistem platformu
- Tek bir araç zinciriyle yazma, çalıştırma, test etme, dağıtma, izleme gibi süreçler entegre biçimde yürütülebiliyor
- Entegrasyon, varsayılan ayarlar, flag'ler ve araçlar arası bağlantılar sürekli güçlendiriliyor
- Amaç, yalnızca özellik eşdeğerliği değil, bütünleşik bir ekosistem kurmak
- JavaScript geliştirme deneyiminin özsel kalitesini artırmayı hedefliyor ve bunun için kapsamını genişletmeyi deniyor
Bu platformun hedefi ve nedeni
- Betik dilleri, hızlı pratik geliştirmede vazgeçilmez bir rol oynuyor
- JavaScript'in standartlaşma, büyük ekosistem ve genel amaçlı ölçeklenebilirlik açısından geleceği daha da parlak
- “Piller dahil” bir platforma ihtiyaç var ve Deno bunu hedefliyor (izin yönetimi, web sunucusu, gözlemlenebilirlik, lint, type check vb. varsayılan olarak sunuluyor)
- Parçalanmış araçlar yerine birleşik bir deneyim sağlıyor
Gelecek planları ve iletişimi güçlendirme
- Deno daralmıyor; aksine genişleme evresine giriyor
- Platformun hızı, uyumluluğu ve olgunluğu sürekli iyileştiriliyor; JSR de bağımsız yönetişimle büyüyor
- TC39/ WinterTC gibi topluluk işbirlikleri ve JavaScript ekosistemi için çeşitli çalışmalar eşzamanlı sürüyor
- Deploy ve KV deneyimlerine dayanarak sürdürülebilir ve dağıtık yeni ürünler geliştiriliyor; yakında daha fazla bilgi paylaşılacak
- Tartışma ve güvensizliği azaltmak için iletişim güçlendirilecek ve geliştiricilerle güven ilişkisine önem verilecek
3 yorum
Peki,
denoyerinebundaha mı iyi?Deno'nun durgunluğu: küresel region sayısı 6'ya düşürüldü
Sanırım bu yazıya bir yanıt niteliğinde.
Fresh güncellemesinin neden geciktiğine dair ayrı bir yazı da paylaştı: Deno'nun web framework'ü Fresh 2 güncellemesi
Hacker News görüşü
En başından beri, çoğu geliştiricinin sadece basit stateless fonksiyonlar dağıtmadığı; full-stack uygulamalar gibi veritabanıyla iletişim kuran gerçek uygulamalar inşa etmenin yaygın olduğu açık görünüyordu diye düşünüyorum. Bunun ancak şimdi fark edilmiş olması biraz kaçınılmaz hissettiriyor
Son dönemde Deno, Deploy, KV, Fresh ve genel büyüme ivmesi hakkında eleştirel bir hava oluştuğu yönünde bir algı paylaşılıyor. Büyüme ivmesine yönelik eleştiriler hakkında özellikle bir yorum ya da yanıt görmedim; bunun bilinçli olarak mı yapılmadığını merak ediyorum. Eleştirilerin bir kısmının geçerli olduğu söylenmişken, hangi eleştirilerin geçerli olduğunun ve bunları nasıl çözmeyi planladıklarının da açıklanması güveni daha da artırırdı diye düşünüyorum. Bir şirketin eksilerini dürüstçe kabul etmesini, seçim yaparken aksine olumlu bir unsur olarak görüyorum. Migadu’nun pro/con sayfası gibi artıları ve eksileri şeffaf biçimde ortaya koymalarını beğendiğim bir deneyimimi paylaşıyorum
Başlangıçta Deno’dan beklentimin nedeni, mevcut ekosistemle uyumluluğa saplanmadan daha az karmaşıklıkla temiz bir başlangıç yapabilmesiydi. Node’a kıyasla yeni ve bazen rahatsız edici yanları vardı ama katlanılabilir düzeyde geliyordu. Fakat kendine özgü çözümler geliştirmek yerine giderek Node uyumluluğuna sarılmaya başladı ve şimdi bence Node’dan bile daha karmaşık hissettiren ikili bir yapıya dönüştü. Node paketlerinin Deno’da doğal olarak çalışması gerekir ama uygulanmamış API’ler ya da bug’lar nedeniyle çalışmadığı çok sayıda edge case oluşuyor. En sevdiğim test framework’ü olan AVA da hâlâ desteklenmiyor. Eskiden npm uyumluluk katmanını yok sayıp sadece Deno’nun kendisini kullanırdım, ama artık bu giderek daha can sıkıcı hale geliyor. Sadece komut satırı seçeneklerine bakınca bile birkaç yıl içinde inanılmaz karmaşıklaştığını görüyorsun ve bunların çoğu npm entegrasyonu için, yani benim için sadece gereksiz bilgi. Node uyumluluğunda en çok istediğim şey, Deno linter’ın ESLint yapılandırmasını desteklemesiydi ama buna ilgi yok gibi görünüyor. Yine de Deno’nun başarılı olmasını istememin nedeni, Node’un gelişmesini teşvik etmesi. Ancak Deno’nun bugünkü yönünün, başlangıçtaki amacıyla tutarlı hissettirmediğini düşünüyorum
Deno’nun yönünü kaybettiğini hissediyorum. Başta Rust ile yazılmış, güvenli ve hızlı bir JS/TS runtime’ı gibi sade bir konumlandırması vardı, şimdi ise web sitesindeki ‘Products’ açılır menüsüne dağınık biçimde birçok ürün eklenmiş durumda. Sanki Vercel’in NextJS’in ardından deploy platformu kurma yolunu izlemeye çalışmış gibi görünüyor
Deno, Node uyumluluğu ekleyerek ilk verdiği sözü bıraktığı anda benim için heyecanını kaybetti. Benim için Deno’nun temel çekiciliği, Node’daki istenmeyen karmaşıklığı ve tarihsel yükü ortadan kaldırmasıydı; şimdi ise yerleşik TypeScript ve permissions gibi birkaç küçük fark dışında Node’dan pek bir farkı kalmadı. bun.sh de aynı şekilde Node uyumluluğu sunuyor. Acaba Node uyumluluğu peşinde olmayan server-side TypeScript scripting engine bilen var mı diye merak ediyorum
npm uyumluluğunun bir özellik eklemesi olduğu, bu yüzden bir şey kaybedilmiş sayılmaması gerektiği söyleniyor. İsteyen Node API’lerini kullanmak zorunda değil, sadece jsr.io’daki istediği kütüphaneleri kullanması da yeterli. Pratikte Node’dan farklı bir geliştirme deneyiminin Deno’da hâlâ yaşanabildiği savunuluyor. Ama tam anlamıyla ‘saflık’ isteyenlerin sayısı çok değil, bu yüzden popülerlik ve pratikliği seçmelerinin daha iyi olduğu görüşü var
Node uyumluluğu hedeflemeyen bir TypeScript runtime arama gerekçesi sorgulanıyor. Node’un çeşitli sorunları olsa da yine de geniş ölçekte kullanılacak kadar yeterince işe yarar olduğu vurgulanıyor. Pratik bir alternatif oluşturmak için ya (1) büyük çaplı migration’ı haklı çıkaracak kadar güçlü avantajlar olmalı ya da (2) en azından düşük migration maliyetiyle birlikte net iyileştirmeler sunulmalı: performans, güvenilirlik, kullanılabilirlik gibi. Ama Deno’nun bu iki seçeneğin arasında sıkıştığı düşünülüyor. Mevcut Node kodunu doğrudan çalıştıramazken, aynı zamanda yeterince çarpıcı avantaj da sunmadığı için yalnızca ‘idealistleri’ ya da ‘hobi geliştiricileri’ çeken sınırlı bir yaklaşım olduğu yorumu yapılıyor
Node uyumluluğu peşinde olmayan TypeScript runtime olarak Cloudflare Workers workerd akla geliyor, ancak bunun özünde genel amaçlı bir backend runtime’ı olmadığı ve pratikte sunulan temel paket ya da yerleşik işlevlerin çok sınırlı olduğu belirtiliyor
Ben şahsen JSDoc kullanmayı tercih ediyorum. Node ile alakasız ve derleme zinciri karmaşıklığı olmadan benzer avantajlar sunuyor
Backend tarafında JS’ye bağlı kalmak gerekmiyorsa, TypeScript yerine daha iyi alternatifleri değerlendirmek daha mantıklı olabilir görüşü var. Tüm stack üzerinde kontrol sahibiysen, compile-to-JS bir dilde kalmak için çok da neden yok
Son yazının muhtemelen geçmişteki https://news.ycombinator.com/item?id=43863937 gönderisine bir yanıt olduğu düşünülüyor
CEO’nun yazdığı bir metin ama Deno’ya yönelik somut eleştirilerden çok iç kararları meşrulaştırmaya odaklanıyor. Buna rağmen Deno ürün ailesinin Deno ortamında oldukça iyi çalıştığı izlenimi de var
Hâlâ güven ya da kanaat oluşmuş değil. Deploy’un nasıl bir hâl alacağını yakında göreceğiz gibi duruyor ama KV, beta aşamasında daha ileri gitme niyeti yoksa yeni projelerde kullanmak için hiçbir neden bırakmıyor diye düşünüyorum. Fresh’in Q3 sonlarına doğru alpha olarak yeniden yapılandırılacağı söyleniyor ama aslında baştan beri sadece temel işlevler sunan bir framework’tü ve onun da dikkat çeken build/compile gerektirmeyen yapısı ortadan kalkıyor. Runtime gelişmeye devam ediyor, ancak “diğer runtime’larla özellik eşitliği peşinde değiliz” denmesine rağmen release note’larda Node/NPM uyumluluğuna yoğunlaşılması ilginç
KV için süren geliştirmeyi durdurma kararının gerçekten çok kötü bir tercih olduğu düşünülüyor. Şirketlerin KV kullanmamasının nedeninin özelliklerin zayıf olması değil, üzerindeki beta etiketi olduğu vurgulanıyor. Kendi adıma Cloudflare Workers KV’yi çok kullandım ve Durable Objects’e pek ilgi duymadığım için Deno KV beni heyecanlandırmıştı, ama artık bunu değerlendirme dışı bırakmak gerekecek gibi görünüyor. Yeni ürün duyurup ardından hemen ilgisiz bırakmak, stratejik açıdan da çok kötü bir izlenim yaratıyor deniyor
KV kullanmayı düşünürken önünü göremeyince alternatifleri değerlendirmeye başladığını dürüstçe paylaşıyor
Çoğu geliştiricinin basit stateless fonksiyonlar değil, full-stack uygulamalar, yani veritabanıyla sıkı entegre çalışan uygulamalar dağıttığı gerçeğinin aslında serverless dünyasının geneli için de geçerli olup olmadığı merak ediliyor. Eğer öyleyse, bunun başlangıçtaki serverless hareketinin niyetiyle uyumlu olup olmadığı ya da insanların sadece Docker/Kubernetes gibi karmaşık altyapılardan kaçınmak için mi bunu seçtiği sorgulanıyor
Deno Deploy’da bölge sayısındaki azalma hakkında sık sık soru geldiği söyleniyor. Deno tarafı, çoğu uygulamanın dünyanın her yerinde çalışmasına gerek olmadığını; veriye yakın yerde hızlı olması, debug edilmesinin kolay olması ve yalnızca yerel regülasyonlara iyi uyum sağlamasının yeterli olduğunu söyleyerek optimizasyon yönünü açıklıyor. Ama ben, Deno Deploy’un bölge konumlarının pratikte yeterince yakın olmaması nedeniyle performans açısından endişe duyduğum için kullanmadım. Veriye ve kullanıcılara daha yakın birçok seçenek zaten varken ve mevzuata uyum da çoğu durumda ülke düzeyinde yeterliyken, bu optimizasyon yönü bana ikna edici gelmiyor