bu yana yazılım geliştiriyor, sektörü takip ediyorum. ➔ Alaylı ve okulluyum. ➔ Profesyonel olarak yönetici pozisyonlarında 10 yıllık bir deneyimim var. ➔ Yazılım geliştirmeye, geliştirme araçlarını takip etmeye hiç ara vermedim. ➔ Birçok açık kaynak proje ve topluluğa destek verdim, katkı sağladım, liderlik ettim. ➔ Şubat 2023 Kahramanmaraş depreminde gönüllülerle birlikte oluşturduğumuz Açık Yazılım Ağı’nda aktif görev aldım. ➔ YouTube üzerinde yayınlar yapıyorum. Ben kimim…
alanında nasıl bir yıl olduğunun geçmiş dönük değerlendirmesini yapıyorum: ◆ 2022: 5 yıl sonraki JavaScript'e bugünden bakış ◆ 2023: 2024'e Girerken JavaScript: Yeni JavaScript runtime’larıyla bir ekosistem örmek ◆ ve bu yıl, 2024: JavaScript ve Golang’in BFF ilişkisi ➔ Bu yılki konunun motivasyonu, bana gelen soruların büyük bir çoğunluğu: ◆ AI dönüşümüne karşı nasıl refleks göstermeliyiz? ◆ Frontend bitti mi, full-stack mi olmamız gerekiyor? ◆ Sektör daralıyor ne yapmalıyız? ➔ Hepsinin ortak yanıtı ”eldeki araçları daha iyi kullanıp daha verimli bir geliştirme çıktısı elde etmek gerekiyor”, peki bunu sağlamak için piyasada hem yönetici hem de developer olarak devam eden bir profesyonel olarak ben neler yapıyorum?... …ve ne anlatacağım
Bu paradigma değişiminde bir şeyleri kaybettik! Birçok kişi web development’ta olan bu paradigma değişimini PHP’e geri dönüş olarak adlandırdı… Peki web development’ın bugününe nasıl gelmiştik, neler kazanmıştık? Şimdi aniden 2010’a döndüğümüzde kazanımlarımıza ne oldu? ➔ Yıllarca JavaScript evangelisti olsam da, bir mühendislik problemi için her aracın “iyi” olduğu bir koşul var. JavaScript’in karmaşık bir web mimarisinde yanına arkadaşlarını alması bize daha akılcı bir yazılım çözümü oluşturmamızı sağlayacaktır. Mesela…
Statik, sıkı, derlenebilir Dinamik, esnek, yorumlanır Network performansı çok iyi 🫠 Sistem işlerine daha yakın Yazılımcıyı yormamaya odaklı İşlem overhead’i daha az Fazla kaynak tüketir Daha mikro, portatif uygulamalar yapılabilir Uygulamaları paketleme ihtiyacı vardır 🫠 Kullanıcı arabirimleri oluşturmak için çok iyi
proje için uygulanabilir olmaktan çok uzak. Refactor’ ü geçelim çok ciddi yeniden yazma gereksinimi oluşuyor. ➔ React’ın Server Component/Server Actions ile birlikte getirdiği mimari yaklaşımı kullanabileceğimiz Next.js dışında başka bir framework de elimizde yokken bu yaklaşıma bu kadar yatırım yapmak akılcı olmayabilir. Mevcut mimariyi dönüştürecek veya ileride olası sorunlara karşı riski dağıtmamızı sağlayacak bir orta yola ihtiyaç var. Sentez Gereksinimi - Bu uygulanabilir bir reçete mi?
Projeleri kompakt hale getirmek. Servisleri birlikte aynı dosya yapısında tutmak, kod paylaşımı yaptırmak gerçekten çok değerli. Bu küçülme, AI-assisted kodlama için de bir şans. ➔ Bilhassa büyük yapılarda polyglot yapıdan ödün vermemek, her dilin kendine özel güçlerini kullanmak gerekiyor. ➔ Örnek codebase: https://github.com/eser/acik.io/tree/template Benim Önerim - Best of two worlds
kullanım Protokolün net tanımlanması gerekiyor Yaygınlık 🫠 Esneklik Sürümlenmesi gerekir ama daha güvenilir Tek yönlü tetikleyene göre tasarlanmış Çift yönlü çalışabilir Stream/akış desteği biraz karışık Akış desteği var Okuma/yazma overhead’i fazla Daha performanslı
JS HTTP 20 36268 1813.189942/s Go HTTP 20 444956 22247.171517/s go gRPC 20 670514 33519.617865/s Yerel bilgisayarımda (M1 Max - 32GB RAM) yaptığım benchmark sonucudur. Grafana/K6 araç olarak kullanılmıştır. Kodlar repository üzerinde bulunmaktadır.
eser
nisei_k
forester3003
lamodatech
har1101
shogogg
pal4de
iotcomjpadmin
syoshie
3150
dip_tech
jcasabona
gr2m
mza
davidbonilla
paigeccino
morganepeng
danielanewman
sachag
reverentgeek
rasmusluckow
mclloyd
![[[]]]] 01 Paradigma Değişimi 02 Sentez Gereksinimi 03 Benim Önerim](https://files.speakerdeck.com/presentations/5a78c9d23e87479889d26ebfbd9a63ae/slide_3.jpg){kind=link}
