Front-End Framework’lerinin Karşılaştırılması (2019)
Tags: frontend, framework, turkce, karsilastirma
Published: 2020-12-15 13:50:02

**Front-End** frameworkleri arasında seçim yapmak çoğu zaman oldukça yorucu olabiliyor. Bir tarafta bir framework’ün savunucuları diğer tarafta başka bir framework’ün daha iyi olduğunu iddia edenler arasında sıkışıp kalıyoruz genelde. [@jacekschae](https://medium.com/@jacekschae) sağolsun bu dertten bir nebze kurtulmuş olabiliriz.

**freeCodeCamp** üzerinde bir kaç gün önce harika bir araştırma yayınladılar. Ben de şimdi aynı makaleyi **Türkçe** olarak sizlerle paylaşacağım.

Orjinal Makale için -> https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

Üçüncü defa Önyüz frameworklerini [Real World](https://github.com/gothinkster/realworld) adı verilen örnek uygulamaları kullanarak karşılaştırıyoruz. Peki neden Real World uygulamalarını kullanıyoruz?


**Gerçek Hayattan Uygulamalar**
Normalde bildiğiniz üzere genellikle “To-Do” uygulamaları kullanılır bu tarz testler için. “To-Do” uygulamaları aslında pek de gerçek bir uygulama niteliği taşımıyorlar. **RealWorld Projesi** içerisinde belirlenen uygulamalar, gerçek hayatta bir uygulama geliştirirken karşılaşacağınız şeylere daha yakın bir perspektif sunuyor.

**Standart**
Projenin belirlenmiş sıkı kuralları var. Aynı zamanda hali hazırda bir Back-end sistemi, statik dosyaları zaten bulunuyor.

**Uzmanlar tarafından yazılıyor veya test ediliyor**
RealWorld app için geliştirilmiş olan uygulamalar ya o framework’ün uzmanları tarafından yazılıyor ya da yine o framework’ün uzmanları tarafından kontrol ediliyor.

# Hangi kütüphaneleri/frameworkleri karşılaştırıyor?
Şuana kadar yazılmış olan RealWorld örnek uygulamaları reposunda 18 adet uygulama bulunuyor. Biz de bu uygulamaları karşılaştıracağız testimizde.

**Burada önemli olan nokta framework’ün ne kadar çok takipçisi/destekçisi olduğu değil RealWorld örnek uygulamaları içerisinde varolup olmamasıdır.**

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/4iryhiu85rtiqyft4i8j.png)

# Hangi ölçümlere baktık?
**Performans**
Uygulamanın açılması ve kullanılabilir duruma gelmesi ne kadar sürüyor?

**Boyut**
Uygulama ne kadar büyük? Bu noktada sadece compile olmuş Javascript dosyalarının büyüklüklerini karşılaştıracağız. Zaten CSS tüm projeler için ortak ve CDN üzerinden yükleniyor projelere. Ayrıca HTML de tüm projeler için ortak, haliyle tüm projeler için bizim için tek önemli olan nokta compile edilmiş veya dönüştürülmüş JavaScript dosyalarının büyüklüğü.

**Kod’un uzunluğu**
İlgili RealWorld uygulamasını yazmak kaç satır kod ile mümkün oluyor? Bazı projelerde kodun daha rahat okunabilmesi açısından birkaç değişiklik olsa dahi sonuçlara çok bir etkisi yok bunun. Bu test sırasında bizim için önemli olan tek klasör src/ ve altındakiler.

# Ölçüm #1: Performans
Performans skorlarını ölçerken Chrome’un Lighthouse Audit’ini kullanacağız. Lighthouse bize 0 ve100 arasında bir değer geri döndürüyor. 0 en düşük skor.

**Ayarlamalar**
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/2f7p113djy6xbrbp2bex.png)
Performans skoru şu ölçümleri göze alacaktır
*İçeriğin ekranda ilk çizildiği hal için geçen süre
*İçeriğin ekranda düzgün şekilde ilk çizildiği hal için geçen süre
*Hız İndeksi
*İlk CPU İşlemi
*İlk Kullanılabilir hal için geçen süre
*Kullanıcı aksiyonlarına verilen cevaptaki gecikmenin ortalama değeri

[Lighthouse’un skorlarıyla ilgili daha detaylı bilgi almak için tıklayın](https://web.dev/performance-scoring/)


**Performans (Özet Geç!)**
Sonuç olarak uygulamayı ne kadar hızlı bir şekilde ayağa kaldırırsanız kullanıcı deneyimi de o denli iyi olacaktır.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/6ug8lft6ik98ntvxkbhi.png)
*Not: PureScript ne yazık ki demo uygulamasının yetersizliklerinden dolayı bu teste alınmadı.*

**Sonuç olarak;**
Çoğu uygulama 90 üzerinde not aldı. Yani iş performansa gelince çok da farketmeyecektir hangisini kullandığınız.

# Ölçüm #2: Boyut
Chrome’un Geliştirici araçları içerisindeki Network Tabındaki büyüklüğü. Projelerin serverdan dönen GZIPlenmiş response headerları ve response bodyleri.
Bu ölçüm frameworkün direk büyüklüğüyle beraber proje içerisinde kullanılmış extra tüm bağımlılıkları da gözönüne aldığından build işleminde kodun gereksiz kısımları ne kadar düzgün ayıklanabiliyor onu da görmüş olacağız.

**Boyut (Özet Geç!)**
Küçük boyutlu dosya demek daha hızlı indirilebilmesi ve daha kolay işlenilmesi demek.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/w5xyfs5iwlqyt8tvbn5c.png)
**Sonuç olarak;**
Bu ölçüm sırasında bir çok duygusal nokta var aslında. Svelte — Büyülü bir şekilde ortadan kaybolan UI Framework’ü —gerçekten de dediğini yapıyormuş meğer. Stencilde aynı şekilde bu testlere yeni eklenmiş olmasına rağmen oldukça iyi iş çıkarıyor. İkisi de oldukça yeni teknolojiler olmasına rağmen iş frameworklerin boyutlarına gelince ikisi de limitleri oldukça zorluyor.

# Ölçüm #3: Kod’un Uzunluğu
[cloc](https://github.com/AlDanial/cloc) adlı repoyu kullanarak projelerin src/ klasörleri altındaki kodun toplam uzunluğunu hesapladık. Bunu yaparken boş satırları ve not satırlarını dikkate **almadık**. Peki bu ölçüm neden var?
> Eğer debugging dediğimiz şey uygulamalardaki hataları düzeltmek içinse, programlama dediğimiz şey de o hataları oraya koymak içindir.
— Edsger Dijkstra

**Kod’un Uzunluğu (Özet Geç!)**
Ne kadar az satır kod ile bir proje ortaya çıkıyorsa eğer kod içerisindeki hatanın bulunma hızı da daha az kod kontrol eidleceği için daha hızlı olacaktır. Aynı zamanda projeyi idare etmek az satırlı bir proje için daha kolay olacaktır.
![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/cvluf968jvz6dt3kebq0.png)
*Imba için Not: [cloc](https://github.com/AlDanial/cloc) Imba projesi içerisindeki .imba dosyaları ile çalışmadığı için Imba’yı bu teste almadık.

Elm için Not: Elm geliştiricileri genelde kodlarını yazarken kodu yatayda çok uzatmadan biraz daha dikey bir stili tercih ediyorlar. Bu nedenle kod uzunlukları yüksek çıktı. — [en azından bize söylenen bu.](https://twitter.com/rtfeldman/status/983384187116949505)

Angular+ngrx için Not: Kod uzunluğunu hesaplarken yalnızca/libs klasörünü ve sadece .ts ve .html dosyalarını göz önüne aldık. Eğer bu yaptığımız yanlış ise lütfen bizi bilgilendirin. Böylelikle doğru sayıyı hesaplayabiliriz.

Hyperapp için Not: Bu makalenin İngilizce versiyonu ilk yayınladığında Hyperapp için hesaplamalarımız yanlışmış. [Mateusz Kwasniewski](https://twitter.com/kwasniew) sayesinde düzgün bir şekilde hesaplamanın yolunu bulduk. Teşekkürler…*

**Sonuç olarak;**
Konu kodu kısa tutmaksa ClojureScript ateş ediyor💥. Eğer kodun kısalığı sizin için önemliyse ClojureScript, AppRun, ve Svelte aradığınız frameworkler.

# Yani
Şunu akılda tutmak gerekiyor ki burada elmaları elmalarla karşılaştırmıyoruz. Bazıları Code Splitting dediğimiz kodu parçalara bölüp ihtiyaç anında yüklenmesi gibi teknolojiler kullanırken bazıları kullanmıyor örneğin. Bu uygulamalardan bazıları GitHub’da bulunurken bazısı Now’da bazısı Netlify’da. Ama hala aralarından en iyisini bulmak mı isitoyrsunuz? En iyi framework sizin hitiyaçlarınıza en iyi cevap verendir.

**S:** Projenizde veri tipleri kullanacak mısınız?
**C:** Elm, PureScript, ve TypeScript’e bakın — Angular, AppRun.


**S:** Küçük boyutlu hızlı bir şeyler mi arıyorsunuz?
**C:** Svelte, Stencil, ve AppRun’a göz atın.


**S:** Az kod çok iş mantığında mısınız?
**C:** ClojureScript, AppRun ve Svelte aradığınız frameworkler olabilir.


**S:** Yeni bir şeyler mi öğrenmek istiyorsunuz?
**C:** Daha önce kullanmadığın bir tanesine şans ver 😉.

# Kapanış
Bu harika araştırmayı yaptıkları için tekradan [@jacekschae](https://medium.com/@jacekschae)’ye teşekkür ederim. Çeviride bir hata varsa lütfen bilgilendirin.

Orjinal Makale: https://medium.freecodecamp.org/a-realworld-comparison-of-front-end-frameworks-with-benchmarks-2019-update-4be0d3c78075

İyi Hackler!