Server-centric, Client-centric. Peki ya Developer-centric?

Uzun zamandır tartışma konusuydu sunucu ya da istemci odaklı RIA (Kallavi İnternet Uygulamaları) çözümlerinden hangisinin daha etkin olduğu. Kimine göre istemci odaklı olanlar daha iyi, kimine göre ise sunucu odaklı olanlar. İtinayla tartışılır...

Peki farkı neydi bu ikisinin? İstemci odaklı çalışanlar uygulama ekranlarında yapılan alengirli hokus-pokus hareketlerini (ki kullanıcıyı cezbeden çok güzel hareketlerdir bunlar) javascript falan kullanarak kullanıcının tarayıcı uygulaması (IE, Firefox vs.) üzerinde çalıştırırlar. Ha böyle olunca ne olur? Ufak tefek kıytırık getir-götür işleri için sunucu tarafı boşuna yorulmaz. Kullanıcının bilgisayarının da çorbada bir nevi tuzu olur.

Amma ve lakin bu işin bir de baş ağrıtıcı, mide bulandırıcı bir yönü vardır. Bu javascript denen dil çok karmaşık şeylerden bahsederse saçmalar, tarayıcılar söylemek istenenden farklı anlamlar çıkarabilir. O zaman da siz "akım" kodlarsınız kullanıcıya "b.kum" olarak gider, ayıp olur. Bunu önlemek için de tarayıcının suyuna gidilir, anladığı dilden konuşulur. Böyle olunca da buna uygun RIA'yı geliştirmek üstün nitelikler ve çelik gibi bir sinir sistemi gerektirir. Oluşan javascriptin WTFs/min oranı yüksektir. Bu ölçümün nasıl yapıldığından sonra bahsederim.

Bu işi başaran babayiğitlere örnek vermek gerekirse en başta bir Google iştiraki olan GWT gelir. GWT ile kodladığınız java kodları Google'ın yeminli tercümanları tarafından Javascript kodlarına tercüme edilerek tarayıcıya gönderilir. Bilindiği üzere bilgisayarlar "aptal" makinelerdir. Yani ne yapacağını inceden inceye söylemek gerekir. Yoksa şaşırıp afallar, salak. Madem ki serde istemci odaklı olmak var, o zaman çalışacak kodu tümüyle kullanıcının makinesine göndermek gerekli. Bu da sunucudan istemciye giden veri trafiğini artırır. Her ne kadar teknoloji ilerlemiş, fiber optik kablolar falan ayağa düşmüş olsa da bilinçli yazılımcı donanıma güvenerek iş yapmaz, (Hacettepe Bilgisayar Müh. mezunları bilirler, Mustafa hoca veri yapıları dersinde sineğin yağını çıkarır, posasını da geri dönüşüme gönderirdi. Sınav sorularında "yeni değişken tanımı yapmaksızın" ibaresi saç baş yolduracağına delalettir) istemciye göndereceği kodu kısa tutmaya çalışır. Bilgisayarın kitabını yazmış olan Tanenbaum amcamız 'As I did 20 years ago, I still fervently believe that the only way to make software secure, reliable, and fast is to make it small.' demiş dilinden anlayana. Kısacası "kısa kesin, Aydın havası olsun" demiş. Neyse gene çok dağıttık, toplayalım: istemci odaklı RIA çözümleri tarayıcıya çok yüklenirler. Bu da istemci tarafını şişirir. Bu da muhtelif meclislerde yazılımınızın yavaşlığının mevz-u bahis edilmesine sebep olur.

Gelgelelim, sunucu odaklı RIA çözümlerinde yukarıdakilerin hiç biri olmaz. Bunun yerine kullanıcılar Lütfen Bekleyiniz..., Processing..., Loading..., Lan iki dakka sabret... gibi AJAX sonrası dilimize pelesenk olmuş nevi şahsına münhasır deyimlerimizle sıkça aşina olurlar. Çünkü istemci tarafı tembeldir ve herşeyi sunucudan bekler. Tabiri caizse yerinden kalkıp mutfaktan su almak yerine yan odada ütü yapan karısından su isteyen tembel kocalar (aaa çok ayıp!) gibidir. Kadıncağız söylene söylene suyu getirir, bazen de sabrın sınırı aşılır, küser cevap vermez. (Ping! cevap yok!) Çünkü aynı anda bir yandan bebek altına yapmıştır, temizlenmesi için zırlar durur, küçük çocuk acıkmıştır, büyük olanın ise yarına yetişecek bir ödevi mutlaka vardır. Apache kabilesinden Wicket da bu mantıkla çalışır.

Bir "made in China" RIA çözümü olan ZKyı da sunucu odaklı bilirdik. Fakat Çan, çin çun ve Chen amcalar şu sıralar çıktım çıkacam (release candidate - RC) diyen 5. sürümde yukarıdaki yaman çelişkiyi farketmiş olacaklar ki orta yolu bulmuşlar ve az biraz kılıbıklaşarak, geliştiricileri de düşündüklerini beyan ederek developer-centric bir RIA yaklaşımı ortaya atmışlar. Server-Client Fusion diye adlandırdıkları bir yapı ile turnayı gözünden vurmuşlar. İşin detayına girip de kafa karıştırmaya hiç niyetim yok, merak eden zkoss.org'dan kendisi bakar. Hazır bakmışken ajax-as-a-service kısmına da bakar, bence. Zaten bileşen zenginliğiyle ön plana çıkan ZK'ya bu iki işlevsellik tuz-biber olmuş. (Diğer RIA çözümlerine de kapak olmuş da denebilir.)

Tadından yenir mi yoksa yanında mı yatılır bilmem ama üzerine tatlı niyetine güzel bir haber daha vereyim: Lisanslamayı değiştirmişler. Artık bundan böyle GPL (Kimine göre GPL bir virüstür, bulaştığı yazılıma kendini kopyalar ve yayılır.) değil, LGPL. Yani bundan böyle binbir emekle yazdığınız kodları sırf ZK kullandığınız için cümle aleme mal etmek zorunda değilsiniz. Bu da günün güzel haberi olsun.

Benden bu kadar, yorumlarınızı bekliyorum. Bundan önce bi kaç kere daha farklı konularda blog yazdım. Sonra da bi kaç kere okudum, beğenmedim sildim. Üsluba bir türlü karar veremedim, çünkü. Yarın biraz daha ağır takılayım dersem belki bunu da silerim, belki de silmem. Herkesin 29 Ekim Cumhuriyet Bayramı kutlu olsun. Ne mutlu TÜRK'üm diyene!


* Bu arada WTFs/min yöntemi (What the fucks per minute): Yazılmış kod parçası başka bir yazılımcı ile beraber kapalı bir odada başbaşa bırakılarak yazılımcının kodu incelemesi istenir. Kapının dışından bir gözlemci kulağını kapıya dayar ve içeriden gelen "What The Fuck" ünlemlerini sayar. Elde edilen sonuç incelenen kod kalitesi açısından oldukça belirleyicidir :)