04 ES2015'den sonra JavaScript 5 yıl sonra? Son büyük güncellemeden sonrasını yeniden oynatalım… JavaScript'in arkasında kim, hangi kuvvetler var? Bugün fırında ısıtılan yeni özellikler… Çatışmalar ve olası senaryo
sağlamaya ise 2002'de başladım. Yüksek lisans eğitimimi tamamlayana dek eğitim hayatım çalışma hayatına paralel gitti, bu anlamda hem alaylı hem de mektepliyim. Startup, ajanslar ve kurumsallarda yöneticilik tecrübem oldu. Bugün bir SaaS girişimi olan Datapad'de CTO görevini üstleniyorum. Kalan tüm zamanımı yazılım toplulukları için harcıyorum. CTO @ Datapad youtube.com/EserOzvataf twitter.com/eserozvataf github.com/eserozvataf
Bir iddia… 2015 yılına kadar JavaScript'in toplamda 4 farklı sürümü yer alıyordu ve her sürümde büyük güncellemeler duyuruluyordu. Daha sonra bu yapının yerini yıllık güncellemeler aldı. Neden?
Teklif Süreci Her şey açık! • • • JavaScript tek bir kuruluşa ait değildir. ECMA (European Computer Manufacturers Association) standartlaşmasında destek olur. ECMA'da geliştirici ve akademisyenlerden oluşan TC39 (Technical Committee 39) isimli komite JavaScript'ten sorumludur. Her yıl Haziran'da yeni bir ECMAScript standartı duyurulur. • • • • • Stage 0 tartışma. Stage 1 topluluğa sunum. Stage 2 taslak. Stage 3 adaylık. Stage 4 sonraki sürümde bizlerle. https://github.com/tc39/proposals https://tc39.es/
mu gidiyor? Y ön 1: Y enilikçiler Topluluğun standartları getirdikleri yeri kuzey yıldızı alan; ECMA'nın yeni standartlarını ve Web API'ları kucaklayıp bizleri yalın bir JavaScript dünyasına götüren yenilikçi akım. Y ön 2: Statükocular Biraz daha Facebook, Vercel, Microsoft gibi firmaların önünü çektiği, kendi elit mühendislerinin ürünlerini yapı taşı kullanan, ancak hem TC39'u 5-6 yıl geç yakalayan hem de Web API'larını dışarıda bırakıp kendi ekosistemlerine yatırımlara devam eden statükocu akım. t • • • • • Tehlikeler: Server Side Rendering kapıda… Ancak Server ile Client aynı çalışmıyor! Farklı bundle'lar üzerinden çalışıyoruz. Örnek: Kendi bundler'ını tanıtıp kendisi ekosistem oluşturmaya çalışan Next.js'de Intl kullanamıyorum! ECMA Standartlarını takip edip yazdığım kütüphaneyi Babel, Metro kullanan projelerin içine alamıyorum! Şirketlerin kendi standartları! Örnek: TypeScript'in decorator implementasyonu ile TC39'unkisi çok farklı ES Modules 2015'den bu yana var olmasına rağmen TypeScript halen "node module resolution"da ısrar ediyor!
ediyor? • • • • • Paketleyicilerle uğraşmamak! Build sistemlerini, build zamanını ve konfigurasyonları hayatımızdan çıkartmak Isomorphism ve determinizm: web, cloudflare workers, server side'da aynı kod ve aynı nesnelerle çalışın node_modules'dan kurtulup HTTP CDN üzerinden bağımlılık yönetimi Web API'lar sayesinde iyi dokümantasyon (MDN) ve binlerce sürümünü tekrar tekrar indirmediğimiz bağımlılıklar (her dependency'nin farklı bir axios sürümüne bağımlı olması) Deno sayesinde bütünleşik tooling (Test yazmak için Jest'i, Webpack'i, Babel'i ve TypeScript'i konuşturmanıza gerek yok!)
yeni yaklaşımlara erişmemize engel! Node.JS stdlib'e muhtaç kodlar commonjs, NPM ve node_modules Babel, PostCSS ve Transpilerlar Webpack, Metro ve Diğer Paketleyiciler ✗ ✗ ✗ React… React Native… React Server Components! ✗ Sürtünme yaratan, "yalınlıktan uzak", değişimin önünde engellerimiz: axios, moment, socket.io, v .s. ✗
önemli olmadığı bir senaryoya gidebiliriz. 1. Runtime'lar birbirine yaklaşacak Kendini yeni özellikler katmak isteyen runtime'ların en kolay özellik devşirebildikleri yapı şu anda Web API'lar. 2. Runtime'lar Web'e yaklaşacak 3. NPM devam edecek, ancak modül sistemi genişleyecek NPM desteği devam edecek olsa da, commonjs'i yolda kaybedebiliriz. Dosyalara CDN'den erişebildiğimiz ES Modules desteği de yaygınlaşacak. Deno'nun Go ve Rust'dan benimsediği "built-in tooling" yaklaşımına diğer runtimelar da yetişecek. 5 yıl sonra: Runtimelar Çatışmalar ve olası senaryo
Sınıflar . . 5 yıl sonra: JavaScript Çatışmalar ve olası senaryo ECMAScript dili geliştirmeye devam edecek. TypeScript, flow gibi type-checking yapan statik analiz araçlarının "transpile" ihtiyacı ortadan kaldırılmak isteniyor. Sınıflar maalesef JavaScript'de fonksiyonların yerini alabilir. Eskiden fonksiyonlar "birinci sınıf vatandaş" iken artık sınıflara özen gösterilmeye başlandı. Dekoratör desteğinin stabil bir hale gelmesi ile birlikte dilde daha fazla yer bulacak.
IDE'miz "Web Inspector" . 2. Server-Side Rendering ile 2 ileri 1 geri 3. Kullanılan araç sayısı azalacak ama karmaşa azalmayacak . . 5 yıl sonra: D X Çatışmalar ve olası senaryo Yeni nesil runtime'larda "Language Server" geliyor olsa da halen birçok ölçüm için en net arabirim Web Inspector. Bu kısa vadede değişmeyecek. Server-Side Rendering frameworkler ile birlikte olmazsa olmaz bir özellik olarak sunuldu / sunulacak. 2010'larda transpiler'ların olmadığı bir JavaScript geliştirme deneyimine asla erişemeyeceğimizi düşünüyorum. İnsanların git gide toolları azaltmak yönünde motivasyonlarını olduğundan. CSS'in de modülerliği sağlanabilirse buildless yapıya yaklaşabiliriz.
yapısına adapte olmak Deno'yu kullanıp kodlarınızı Node.js'e transpile edebilirsiniz (bkz: hex service) 2. Deno'yu kullanmak 3. Web API'lara ve stdlib'in yeni fonksiyonlarına yönelmek Web API'lar çoğunlukla ihtiyacınızı çözüyor. Deno'nun stdlib'ine CDN'den erişebiliyorsunuz 4. Build sistemlerinden kaçınmak Transpile süreçleri ve bundlerlara yatırım yapmamak Adaptasyon ve Sonuç Biz ne yapabiliriz? Nasıl "geleceğe yönelik" kod yazabiliriz? CommonJS ES Modules NPM CDN Node.js Deno 3rd Party Libraries Stdlibs + Web APIs Transpilers Buildless axios fetch moment, dayjs Intl, Temporal Lodash, Ramda ES2015+