Deno 2.8

• deno add ve deno install, CLI'da öneksiz paket adlarını varsayılan olarak npm: paketi olarak ele alıyor; böylece mevcut Node projelerinde npm install, yarn veya pnpm install yerine kullanmak kolaylaşıyor
• deno audit fix, npm bağımlılıklarında güvenlik açığı bulunan paketleri sürüm kısıtlarını karşılayan en yakın patch sürümüne otomatik olarak yükseltiyor ve major sürüm değişikliği gerektiren öğeleri ayrıca gösteriyor
• Yeni alt komutlar olarak deno ci, deno pack, deno transpile, deno why ve deno bump-version eklendi; bunlar yeniden üretilebilir kurulumlar, npm yayını için tarball oluşturma, TS→JS dönüşümü, bağımlılık yolunu izleme ve workspace sürüm güncellemelerini destekliyor
• Node.js API uyumluluğu, Node'nun kendi test suite'i ölçümüne göre Deno 2.7'de yaklaşık %42 seviyesinden Deno 2.8'de %76,4'e (3.405/4.457) yükseldi ve birçok node: modülü lazy load edildiği için bu modülleri kullanmayan programların başlangıcı hızlandı
• Performans tarafında, Deno 2.7.1'e kıyasla cold npm install süresi 3.319 ms'den 906 ms'ye inerek 3,66 kat hızlandı; node:buffer base64 3,07 kat, node:http throughput 2,21 kat ve node:crypto scrypt 2,12 kat iyileşti
• Uyumluluk değişikliği olarak, global setTimeout ve setInterval artık sayı yerine Node'un Timeout nesnesini döndürüyor; dönüş değerini number olarak saklayan veya tür kontrolü ya da aritmetikte kullanan kodların NodeJS.Timeout gibi türlerle güncellenmesi gerekiyor
• TypeScript 6.0.3 yerleşik olarak geliyor ve deno check ile LSP artık varsayılan olarak lib.node içerdiğinden NodeJS.*, Buffer, process gibi Node türlerini ek ayar gerektirmeden çözümleyebiliyor
• Hata ayıklama tarafında Chrome DevTools Network sekmesi Deno'nun fetch(), node:http/node:https ve WebSocket trafiğini gösterebiliyor; ayrıca --cpu-prof, --cpu-prof-flamegraph, --cpu-prof-md ile V8 profili, SVG flamegraph ve Markdown raporu üretilebiliyor
• Paket ve workspace yönetimi için catalog: protokolü, deno install --os --arch, --prod, nodeModulesLinker: "hoisted", .npmrc içindeki min-release-age ve --package-json eklendi; bunlar monorepo sürüm birliği, platformlar arası kurulum, production kurulumu ve mevcut Node projelerinin taşınmasını destekliyor
• deno compile, Next.js, Astro, Fresh, Remix, SvelteKit, Nuxt, SolidStart, TanStack Start ve Vite SSR projelerini algılayarak deno task build çalıştırıyor ve uygun giriş noktasını oluşturuyor; ayrıca büyük npm bağımlılık ağaçları işlenirken ilerleme durumunu da gösteriyor
• Testler ve Web API tarafında, Deno.test() içindeki sanitizeOps ve sanitizeResources için varsayılan değer false oldu; test bazında timeout ve fonksiyon düzeyinde coverage eklendi. Ayrıca OffscreenCanvas, aktarılabilir Headers, Request, Response ve Streams, SHA3 digest ile P-521 Web Crypto desteği geldi
• Yükseltme ve runtime temeli tarafında deno upgrade, mümkün olduğunda delta güncellemeleri kullanarak indirme boyutunu yaklaşık 48 MB'den 3–6 MB'ye düşürüyor; deno upgrade pr <number> ile PR build'leri kurulabiliyor ve V8 sürümü 14.6'dan 14.9'a yükseliyor

[GN⁺]

Hacker News görüşleri

• Deno varsayılan bir izin modeli sunduğu için faydalı, Rust ile yazılmış ve TypeScript'i yerel olarak destekliyor
  Web geliştirme/Node/Bun ekosistemine çok derinden hakim değilim ama birkaç yıldır küçük servislerde Deno'yu memnuniyetle kullandım. Bun'ın neden bu kadar hızlı büyüyor gibi göründüğünü merak ediyorum. Acaba daha çok bundler olarak kullanılıyor da JavaScript çalışma zamanı olarak daha az mı kullanılıyor, bilmiyorum
  Sadece izin sistemi bile Deno'yu çekici kılıyor; insanların Node'dan Bun'a geçip Deno'ya gitmemesini pek anlayamıyorum

  • Deno ve Bun ilk çıktıklarında odakları oldukça farklıydı. Deno, Node'un asıl yaratıcısı Ryan'ın Node'da yanlış gördüğü pek çok şeyi düzeltme girişimiydi; Bun ise en baştan Node uyumluluğuna ve Next.js gibi popüler framework'leri çalıştırmaya odaklandı
    Uzun süre boyunca pek çok bağımlılık ve framework Deno'da düzgün çalışmadı, hatta ilk zamanlarda npm'den bağımlılık yükleme özelliği bile yoktu. npm tedarik zinciri saldırılarına bakınca, Ryan'ın yaklaşımı belki de doğruydu
    Bu yüzden Bun, çok daha az yapılandırma gerektiren ve kutudan çıkar çıkmaz çalışan, kullanışlı özelliklerle dolu daha iyi bir Node gibi göründü. Deno ekibi de başarılı olmak için Node uyumluluğuna ihtiyaç olduğunu fark etmiş ve son birkaç yıldır buna odaklanmış gibi görünüyor. Şu anda Deno'nun Bun'dan daha Node uyumlu olduğunu düşünüyorum
  • Küçük bir TypeScript yan projesi başlatırken npm/yarn/berry/pnpm/bubble/vite/webpack/rollup/rolldown/rollout/swc/esbuild/teatime denizinde boğulmak yerine sadece Bun kullanabiliyorsun
    Bu arada, bunların bir kısmı Pokémon hareketi, geri kalanı ise gerçekten JS/TS ekosistemindeki araçlar
  • İkisini de kullanıyorum ve seviyorum. Bun, Node için drop-in replacement olmaya daha yakın
    Test yapılandırması, tsconfig ya da ES modülleriyle uğraşmak istemediğinizde genelde doğrudan çalışıyor. Deno'nun standart kütüphanesi güzel ve CLI desteği de harika; eskiden deno deploy'u da severdim ama son zamanlarda oldukça uğraştırıcı hale geldi
  • Ağırlıklı olarak backend geliştiricisiyim ama kişisel projelerde biraz frontend'e dokunduğumda Deno en mantıklı seçim gibi görünüyor
    Üzerinde çalışması gerçekten çok keyifli ve JS tarafında daha yaygınlaşmamış olmasına üzülüyorum
  • Deno'yu yaklaşık 1 yıl kullandım ve yukarıda söylenen avantajlar nedeniyle hoşuma gidiyordu ama Astro, Prisma, Vite gibi paketlerle çok fazla uyumluluk sorunu yaşadım
    Bu yüzden Bun'a geçtim ve her şey çok daha pürüzsüz oldu

• Deno'nun bugünlerde hangi durumda olduğunu merak ediyorum
  Node istikrarlı bir çözüm ve varlığını sürdürmeye devam edecek. Artık TypeScript de kullanabiliyorsunuz ve yakında yerel bağımlılıkları da içeren uygulamaları tek bir çalıştırılabilir dosya olarak derlemek mümkün olabilir
  Bun kafa karıştırıcı ama hızlı ve standart kütüphaneye her şeyi dahil etme yaklaşımı ilginç. Ayrıca Anthropic tarafından satın alındı
  Deno'nun sandbox ve üçüncü taraf bağımlılıkları içe aktarmanın kolaylığı gibi güçlü bir hikayesi vardı ama sandbox artık oldukça yaygınlaşmış gibi geliyor ve import yöntemi de sonuçta npm add'den o kadar çok daha iyi miydi, emin değilim

  • Deno yaklaşık 2 ay önce şirket çalışanlarının yaklaşık yarısını işten çıkardı: https://news.ycombinator.com/item?id=47467746
  • Anthropic tarafından satın alınmayı kim olumlu görüyor ki?
  • Ekosistemin durağanlaşmaması için birden fazla seçeneğin olması iyi
  • Tek çalıştırılabilir dosya olarak dağıtım zaten mümkün. Ürünümün CLI'ı bir Node single executable application
  • Yerel bağımlılıkları da içeren tek çalıştırılabilir derlemelerin mümkün hale geleceğini bilmiyordum. Bu güçlü bir özellik

• Deno harika. Küçük ve orta ölçekli web servislerini Deno ile yazıyorum
  İsviçre saati gibi çalışıyor ve projenin felsefesi Unix ruhuyla çok uyumlu
  Bana göre Deno'yu yapan insanlar biraz fazla mütevazı. Minnettar kullanıcılar projeye bağış teklif ettiğinde bunu kibarca reddediyorlar. Gerekçeyi anlıyorum ama bu, uzun vadede projeye gereksiz mali baskı da yaratabilir
  Projenin uzun vadeli başarısına bağımlı kullanıcılar için “lütfen paramı alın” tarzı aylık bir abonelik gayet uygun olabilir

  • Kullanması gerçekten çok keyifli. Neredeyse JavaScript ile Go'nun karışımı gibi hissettiriyor
    Hızlı ve esnek; diğer JS/TS alternatiflerinden daha güçlü yeteneklere sahip, biraz daha aklı başında bir paket yönetimi, daha iyi bir güvenlik modeli ve daha iyi bir standart kütüphane sunuyor. Ve çok hızlı

• Deno adına aşina olmayanlar için, Deno bir JavaScript ve TypeScript çalışma zamanı
  Deno 2.6'yı rakipleri Bun 1.3 ve Node.js 25 ile karşılaştıran bir inceleme var: https://www.devtoolreviews.com/reviews/bun-vs-node-vs-deno-2...

  • Bun'ın web isteklerini işlemede bu kadar daha hızlı olması şaşırtıcı. Yazıda etken olarak Zig gösteriliyor ama belleğin ince taneli kontrolü tek başına Node'a kıyasla 2 kattan fazla kazanç sağlayabilir mi diye merak ediyorum
    Benzer şekilde, açıkça söylenmemiş olsa da Bun sanki sıcak paket önbelleği durumunda çalıştırılmış gibi görünüyor. Diğer çalışma zamanlarında da önbellek var mıydı, merak ediyorum

• Deno'nun istikrarlı sürüm döngüsü etkileyici. Bu sürümde hangi performans iyileştirmelerinin geldiğini görmek için sabırsızlanıyorum

• Yeni deno pack komutu, güvenli ve basit paketleme için iyi bir ekleme
  Node.js kullanıyorsanız benzer bir tek komutluk çözüm https://www.npmjs.com/package/ts-node-pack ile mümkün
  Artık Node.js .ts modüllerini içe aktarmayı desteklediğine göre, daha fazla depo bunu build aşaması olmadan ya da checkout'a build çıktıları eklemeden kullanabilir

  • Bu blog yazısını görünce hemen düşünmeye başladım. deno pack, açık kaynak paketlerimde mevcut npm publish akışının yerini alabilir ve çalışma tarzımı Deno öncelikli/Deno merkezli hale getirmeyi sürdürmek için iyi olabilir
    Öte yandan Node'un TypeScript desteği büyürken bunu yalnızca TypeScript npm paketlerine çevirmek de ekosisteme gönderilen küçük bir mesaj olabilir diye düşünüyorum
    Yine de JSR'nin nispeten daha temiz bir ekosistem olarak var olmasına seviniyorum
  • Uzun süredir var olan DNT(https://github.com/denoland/dnt) ile oldukça benzer geliyor
    Ama Deno CLI'ın içine girmesi görünürlüğünü ciddi biçimde artırıyor

• Deno ilk dönem değerlerine biraz daha uzun süre bağlı kalsaydı, Node uyumluluğu baskısının bir kısmını AI ajanları telafi edebilirdi gibi geliyor
  Çünkü bu baskının önemli bir bölümü aşinalık sorunundan kaynaklanıyor. Eğer sadece express.js ile yapılandırma yapmayı biliyorsanız, sonradan çıkan her araç ya da çalışma zamanının da “pürüzsüz” bir geçiş için benzer soyutlamalar sunması gerektiğini düşünüyorsunuz. İlk çözümün başlangıçta ne kadar kötü olduğu fark etmiyor
  Bugün ise ürünle birlikte gerekli teknoloji yığınını da sunup geliştiricilere yeni teknolojileri tanıtmak mümkün; bu bazen gerçekten dokümantasyonun yerini alabiliyor ve daha iyi alternatif yaklaşımları göstermek için epey faydalı olabiliyor

  • Eğer bir SaaS sağlayıcısından aldığım JS/TS SDK hiçbir değişiklik yapmadan Deno'da çalışmıyorsa, bunu düzeltmek için bir saniyemi bile harcamam

• Çeşitli hobi projelerinde Deno kullanmış biri olarak, Deno'nun JS ekosisteminin gitmesi gereken yön olduğuna eminim
  Yine de iş ortamında bunu belirli ve çoğu zaman dar kapsamlı kullanım senaryoları dışında önermek zor. Çünkü bir noktada proje ticari nedenlerle yön değiştirirse sonunda Node gerekiyor

• Edge.js [1] çıktıktan sonra Deno'nun Node.js uyumluluğunu daha ciddiye almaya başlamasını görmek güzel
  Yaklaşık 2 ay içinde %40'lar seviyesinden %75 civarına çıkmış olması, tesadüf olsun ya da olmasın, doğru yönde açık bir adım
  Deno ekibinin eline sağlık
  [1] https://edgejs.org/

  • Kendi reklamını yapmaktan bıkmadın mı?

• Çoğu Node tarzı teamülü sarmalayıp Deno'yu çalışma zamanı olarak kullanıyorum. Gayet iyi çalışıyor
  Proje saf TypeScript ise doğrudan Deno ile çalıştırıyorum. Güvenlik için ek seçenekler güzel ve kurulum betiklerinin varsayılan olarak devre dışı olması da hoşuma gidiyor
  Hâlâ doğrudan Node kullanıyorsanız bırakmanızı tavsiye ederim. En azından Bun kullanmak bence daha iyi
  Ajan tabanlı iş akışlarında Rust ve TypeScript dışında bir şey kullanmak için neredeyse hiçbir neden yok. Buna katılmayabilirsiniz ama tür güvenliği, bellek güvenliği ve devasa iş külliyatı önemli. Ajanların kolay gezinmesi için zorlayıcı hatalar ve yerleşik kalıplar gerekiyor. UI tarafında ise o kadar çok tasarım örneği var ki TypeScript en mantıklı seçenek gibi görünüyor