Yeni JavaScript çerçeveleri yazma konusundaki fikrimi değiştirdim

In: Genel


Birkaç ay önce, web ekosisteminin amansız üssel büyümesinin neden olduğu kara bir kişisel bunalım bulutunun derinliklerindeyken, hakkında yazmıştım. muhtemelen nasıl yeni bir JavaScript çerçevesi yazmamalısınız. Ama fikrimi değiştirdim. Belki sen meli yeni bir JavaScript çerçevesi yazın. İşte bu yüzden.


Düşündüğümüzden daha az seçenek var

şu anda inşa ediyorum WTF: Çerçeve Nedir? — geliştiricilerin yeni projeleri için ihtiyaç duydukları özelliklere göre bir sonraki JavaScript çerçevesini seçmelerine yardımcı olacak yeni bir araç. WTF fikri, Jamstack topluluğunda en sık sorulan sorudan ortaya çıktı: “Hangi JavaScript çerçevesini kullanmalıyım?” cevap varken Her zaman “Bu duruma göre değişir”, geliştiricilerin bu bağımlılıkları derinlemesine incelemelerini ve proje türü inşa ediyorlar.

WTF, projeniz hakkında sadece iki soru sorar ve size projenizi oluşturmaya uygun JavaScript çerçevelerinin bir listesini gösterir.

  1. Ne tür bir web sitesi kuruyorsunuz?
  2. Birden çok sayfada durumu korumak için web sitenize mi ihtiyacınız var?

TL;DR, ilk sorunun statik bir site mi, sunucu tarafı oluşturma gerektiren bir site mi yoksa ikisinin bir kombinasyonuna mı ihtiyacınız olduğunu belirlemesidir; ve ikinci soru, tarayıcıda yerel olarak farklı yollar için HTML oluşturan bir Tek Sayfalı Uygulamaya (SPA) veya her yolun teslim edilen kendi HTML dosyasına sahip olduğu Çok Sayfalı bir Uygulamaya (MPA) ihtiyacınız olup olmadığını belirler. sunucudan ve istemci tarafı JavaScript’e dayanmaz.

Bir JavaScript çerçevesini WTF listesine dahil etme kriterleri aşağıdaki gibidir:

  1. Kod aktif olarak korunur (geçen yıl bir sürüm yayınlandı)
  2. Proje kararlı bir sürüm yayınladı (en az sürüm 1)

Ve işte benim gülünç 300-yeni-JavaScript-frameworks-haftada-abartma biraz düz kalıyor. Projemin hem statik içerik hem de sunucu tarafında oluşturulmuş sayfalar sunması gerektiğini ve durumu birden çok rotada yönetmem gerekmediğini varsayalım. Şu anda sadece dört WTF’de seçim yapabileceğiniz seçenekler: Eleventy, RedwoodJS, Next.js ve Gatsby.

Ve burada daha da sinir bozucu oluyor.

Next.js veya Gatsby, kullanım durumum için tamamen uygun değil, çünkü aslında Varsayılan olarak SPA’lar. Sen yine de Yapabilmek Next.js ile statik bir HTML dışa aktarımı oluşturun veya Gatsby ile statik bir site oluşturancak yerel bağlantı etiketlerini kullanmayı hatırlamanız gerekir. <Link /> MPA kavramını korumak için JavaScript’in önceden getirilmesini önlemek için bileşen. Ayrıca, hem Next.js hem de Gatsby’deki statik site derlemeleri, sunucu tarafı oluşturma işlevini kullanamaz. Dolayısıyla bu iki çerçeve ile projeniz ya hibrit bir SPA ya da geçici çözümlere sahip statik bir MPA’dır.

Eleveny iyi bir seçenektir, ancak uç işlevsellikte sunucu tarafı oluşturma şu anda yalnızca Netlify’da çalışan deneysel bir özelliktir.

Ve böylece, teoride harika bir seçenek olabilecek, ancak henüz ihtiyacım olduğundan emin olmadığım pek çok genel gider ve entegrasyonla birlikte gelen tam yığın bir çerçeve olan RedwoodJS ile kaldık!

sadece yok yeterli seçenek.


çözülmesi gereken sorunlar var

Burada sadece bir problem sundum – ve birçok. Zach Leatherman’ın (Eleventy’nin yaratıcısı) belirttiği gibiayrıca sunucu tarafı oluşturmayı tanımlamanın birçok yolu vardır, bu yüzden yeni projemin hangi tür SSR’ye ihtiyacı olduğunu bilmiyorsam hangi çerçeveyi kullanacağıma nasıl karar verebilirim, ya da hiç SSR’ye ihtiyacı varsa? Dahası, web gelişmeye devam ettikçe, geliştiriciler şunu varsayıyorlar: sunucular ve sunucusuz aslında derleme sürelerini kısaltabilir ve statik sitenizin hızıyla eşleşin. Yani ben meli kesinlikle sunucuları kullanıyor musunuz? Artık statik siteler mi inşa etmeliyiz? 🌶

Ve SPA vs MPA tartışması sürüyor. Astro’nun temel sağlayıcısı Ben Holmes, modern tarayıcı API’lerinin Çok Sayfalı Uygulamalar oluşturabileceğini savunuyor hissetmek Tek Sayfalı Uygulamalar gibi — SPA çerçevelerini gelecekte çok daha az gerekli hale getirmek.

Ve bu sadece yüzeye dokunuyor. React, neredeyse on yıldır SPA çerçevesi olarak tercih edilse de, aşağıdakiler gibi daha genç çerçeveler: SolidJS reaktif DOM güncellemeleriyle gelen performans kısıtlamaları ve genel giderlerin üstesinden gelmek için hamleler yapıyor. Kesinlikle yeni çerçevelerle çözülebilecek sorunlar var. Ve biz geliştiricileriz; sorunları çözmek için inşa ediyoruz, değil mi?


Çerçeveler sorunları çözmeye yardımcı olabilir

Olarak Ryan Carniato, SolidJS’nin yaratıcısı şöyle diyor: “Yeni çerçevelere ihtiyacımız var. Şu anda inovasyona ihtiyacımız var.” Daha iyi bir web ekosistemi oluşturmak için birlikte çalışmak üzere çerçeve yazarlarını nasıl bir araya getirmeye kararlı olduğunu açıklamaya devam ediyor. “Qwik, Astro, Solid, Marko, 11ty ve Angular artık fikirleri paylaşmak için samimi bir alanı paylaşıyor [and to] bu teknolojiler ile onları kullanacak insanlar arasındaki boşluğu kapatmak.” Bir çerçeve yazarı olma konusundaki görüşlerini paylaştığı için Ryan’a gerçekten minnettarım. Aslında web ekosisteminin bu kısmındaki görüşlerime meydan okumaya yardımcı olan ve bu yazıyı yazmam için bana ilham veren şey buydu.

Bu nedenle, çözmek istediğiniz bir sorun varsa ve bu sorun yeni bir JavaScript çerçevesi oluşturarak çözülebilirse, o yeni JavaScript çerçevesini oluşturun. Seninleyim. Ve bir gün denemek isterim.



Bir cevap yazın

Ready to Grow Your Business?

We Serve our Clients’ Best Interests with the Best Marketing Solutions. Find out More

How Can We Help You?

Need to bounce off ideas for an upcoming project or digital campaign? Looking to transform your business with the implementation of full potential digital marketing?

For any career inquiries, please visit our careers page here.
[contact-form-7 404 "Bulunamadı"]