- Yalnızca HTML, CSS ve JavaScript kullanan temel web geliştirme tekniklerini açıklıyor
- Build araçları ve framework'ler olmadan, sadece standart web teknolojileriyle site ve uygulama geliştirme yöntemlerini tanıtıyor
- Web Components ve modern CSS özelliklerinden yararlanarak yapılandırma ve stil verme yöntemlerini ele alıyor
- Framework karmaşıklığı ve bakım yükü olmadan basit bir geliştirme ortamı ve uzun vadeli avantajlar hedefliyor
- Halihazırda web standart teknolojilerine aşina geliştiricileri ana hedef kitle olarak görüyor
Plain Vanilla Web'e Genel Bakış
Web geliştirmede build araçları ve framework'ler olmadan, yalnızca standart web teknolojileriyle site ve uygulama oluşturmanın temel tekniklerine genel bir bakış
- Yalnızca editör, tarayıcı ve web standartları kullanılan bir ortamı açıklıyor
- İlk kurulum ve sunucu tarafı mantığı olmadan production ortamına dağıtım yapılabilen bir yapıyı tanıtıyor
Ele Alınan Konular
1. Bileşenler (Components)
- Web Components kullanarak HTML, JavaScript ve CSS ile yüksek seviyeli yapı taşları oluşturma yöntemini anlatıyor
- React veya Vue gibi framework'lerin bileşen yaklaşımına alternatif bir yöntem sunuyor
2. Stil Verme (Styling)
- Modern CSS'in gücünden yararlanarak CSS Modules, PostCSS ve SASS'ın sağladığı kolaylıkların nasıl karşılanabileceğini gösteriyor
- Klasik CSS'in ötesine geçen, yapısal ve modüler stil oluşturma anlayışı sunuyor
3. Siteler (Sites)
- Web Components tabanlı olarak web projeleri oluşturma ve build araçları ya da sunucu tarafı olmadan dağıtma yöntemini anlatıyor
- Pratik ve sade bir dağıtım iş akışı sunuyor
4. Uygulamalar (Applications)
- Tek sayfa web uygulamalarını yalnızca vanilla tekniklerle oluşturma yöntemini anlatıyor
- Yönlendirme ve durum yönetimi yaklaşımlarını açıklıyor
Kimler İçin Öneriliyor
Halihazırda HTML, CSS ve JavaScript'i belli ölçüde kullanabilen geliştiricilere yönelik
- Web geliştirmeye yeni başlayanlara Odin Project veya MDN gibi temel öğrenme yolları öneriliyor
Neden Vanilla Yaklaşımı?
Modern framework'ler yapısal ve güçlü özellikleri hızlıca sunuyor olsa da, artan araç ve framework karmaşıklığı ile sürekli bakım yükünü de beraberinde getiriyor
- Plain Vanilla yaklaşımı, kısa vadeli bazı kolaylıklardan vazgeçme karşılığında sadelik ve neredeyse sıfır bakım gibi uzun vadeli avantajlar sunuyor
- Günümüz tarayıcıları, mükemmel web standardı desteği sayesinde bu yaklaşımı pratikte mümkün kılıyor
1 yorum
Hacker News görüşleri
Artık "vanilla mı framework mü" tartışmasından çıkıp "bunun gerçekten bir web sitesine ihtiyacı var mı?" açısından bakıyorum
Web uygulamalarında, özellikle de B2B SaaS alanında, gerçekten böyle bir web arayüzüne ihtiyaç olup olmadığı konusunda şüphe duymaya başladığınızda, tarayıcıya hiç dokunmadan da işi epey ileri götürebildiğinizi fark ediyorsunuz
Benim web sitesi ve uygulama yapmaya harcadığım zamanın büyük kısmı yönetim odaklı UI/UX'e, yani yöneticinin veritabanı alanlarını değiştirerek uygulamanın müşteri beklentilerine uygun çalışmasını sağlaması kısmına gidiyordu
Pek çok durumda, işletmeye yalnızca yapılandırma şablonları (Excel dosyaları gibi) verip sonuçları doğrudan SQL tablolarına eklemek/birleştirmek çok daha hızlı, kolay ve gereksiz işi daha az kılıyor
Web yalnızca tek bir UI/UX biçimi sunuyor. E-posta ya da düz metin dosyaları daha esnek olabiliyor
Özellikle de devlet kurumları gibi alıcıların konuyu yeterince bilmediği ve sık sık fazla ödeme yaptığı durumlarda
Satın alma ekiplerinin neye ihtiyaç duydukları konusunda daha fazla eğitilmesi gerekiyor
Gerçek bir urn mağazasında sepet yoksa, sanal mağazada neden olsun ki
Özel marangozluk aletlerini internetten alırken de yalnızca bir forma bilgi girdim, parçalar faturayla birlikte geldi ve istersem ödeme yapmamak da sorun değildi
Hem çevrimiçi hem çevrimdışı ticarette çok çeşitli modeller var; ilginç şekillerde geçimini sağlayan insanlara dikkatle bakarsanız bunu her yerde görebilirsiniz
Azıcık bakım kabiliyeti olduğunda, Excel şablonu + basit özel script yaklaşımı çok daha esnek hale geliyor.
Son kullanıcı zaten ham veriyle çalışabilen bir kullanıcı seviyesindeyse özellikle çok etkili oluyor
Ve hâlâ B2B'nin %99'u bu şekilde ilerliyor
Framework'lere karşı değilim. Sadece birçok durumda gereksiz olduklarını düşünüyorum
Daha tek satır kod yazmadan neden 100KB'lık JS eklemek gerektiğini hep sorgulamışımdır
Ekibimle birlikte https://restofworld.org sitesini hiçbir framework kullanmadan yaptık
Anketler, outreach ve e-posta geri bildirimleri kullanılabilirlik ve okuma deneyimi açısından son derece olumluydu
İleride framework de kullanabiliriz ama şu ana kadar vanilla JS gayet iyi iş görüyor
Bir tarafta 30+ kişilik ekiplerde büyük web uygulamaları yapan insanlar var ve "framework'süz yapıyoruz" dendiğinde hemen büyük ölçekli zorunlu özelliklerin nasıl ele alındığı sorgulanıyor
Ama cevap şu oluyor: O özelliklere ihtiyaç yok, çünkü bu şey zaten bir blog gibi; dolayısıyla baştan framework gerektirmiyor
Öte yandan, çok büyük ölçekli web uygulaması deneyimi olmayanlar da "insanlar neden framework kullanıyor ki" diye düşünüyor
Web gerçekten çok farklı türde yazılımların toplamı.
Bu yüzden framework hakkında konuşurken hangi yazılım türünden bahsedildiğini netleştirmek gerektiğini düşünüyorum
Bu örnekte bu bir WordPress blogu
WordPress gibi büyük bir framework kullanılıyor, sadece statik render ediliyor
TFA'nın kastettiği şey, hiç build tool olmadan, yalnızca modern web standartlarını kullanmak. Yani sadece editör, tarayıcı ve web standartları
Çalıştığım kurumsal uygulamalarda 100KB'yi dert etmeye hiç gerek yoktu
Çoğu birden fazla ekibin geliştirdiği büyük uygulamalardı ve React vb. kullanıyordu.
Lob/B2B tarafında kimse ilk sayfa yüklemesini umursamıyor
Kullanıcılar uygulamayı her gün kullanıyor ve statik varlıkların çoğu zaten doğrudan tarayıcı önbelleğinden geliyor
Next.js gibi akıllı framework'ler kullanırsanız içerik route bazında immutable chunk'lara ayrılıyor
İlk render statik HTML olduğu için kullanıcı açısından hydration da fark edilmiyor
Ama vanilla vs framework tartışmasında bu tip örneklerin hep haber/makale siteleri olması, bunların karmaşık uygulamalar olmaması nedeniyle bende hep "ben zaten framework kullanmazdım" hissi uyandırıyor
Sonuçta gerçek kullanım örneği olarak daha etkileşimli uygulamalar görmek gerekiyor
Bugünlerde framework ve tutarlı desenler kullanıp diğer bağımlılıkları minimumda tutmayı tercih ediyorum
iPhone'da geri gidince tüm sayfanın yeniden yüklenmesine o kadar alışmıştım ki
Ama geliştiriciler eğlence olsun diye loading screen'lere, hydrate edilen component'lere, aşırı animasyonlara ve sinir bozucu modal'lara takılıp kalıyor
Ayrıca sonsuz kaydırma, kaydırma çubuğunun konumundan nerede olduğumu takip etmeyi zorlaştırdığı için kullanılabilirlik açısından ölümcül
Bunu inşa etmiş olmanız takdiri hak ediyor
Örneğin Mithril ile her şey 10KB gzipped içinde yapılabiliyor
Arama işlevli reaktif tabloları, etiketleri/doğrulaması/hata yönetimi düzgün formları kendiniz yazmayı düşününce, Svelte UI kütüphanesi ve 25KB ek yükle iyi tasarlanmış, doğrulanmış bir çözüm kullanmak varken neden bunu sıfırdan yapasınız ki
Ayrıca WordPress de bir framework
Framework kullanmak siteleri yavaşlatmaz. WordPress olsun ya da başka bir şey
Fazla hızlı
Geliştirici üretkenliği için (teoride).
Pratikteyse çoğu zaman o kadar da yardımcı olmuyor
Bu yaklaşımın sivri köşeli sorunları olup olmadığını merak ediyorum
Yaklaşık 2 bin kullanıcı için bir sistem geliştiriyorum ve bu insanlar reaktif UI'yi hiç önemsemiyor
Monolit bir şey yapıp, sayfa yenilenmesini de dert etmeden, sadece işi halletmeye odaklanmak en doğrusu
Bunun motivasyonu büyük ölçüde teknik değil, native uygulama dağıtımının fazla maliyetli olmasıydı
Web, uygulama dağıtımı için ucuz bir standart sağlıyor ama UI teknolojisi hâlâ pek iyi değil
Geçmişte X11, Java, Flash gibi birçok yarım kalmış deneme oldu; umarım bir gün web uygulaması geliştirmeyi daha rahat hale getiren bir yol çıkar
https://developer.mozilla.org/en-US/docs/Web/CSS/@view-transition
Yazılımların çoğu, 120 yıl önceki mekanik cihazlardan daha yavaş ve daha az tepkisel
npm paketi çekmeye gerek yok
Backend express/node, tüm kod bir arada, geliştirme ortamında sunucu React'in varsayılan sunucusuyla çalışıyor, gerçek dağıtımda ise başka türlü çalışıyor; sonuç olarak geliştirme sunucusunun kolaylıkları (hot reload vb.) anlamsızlaşacak kadar tuhaf build ve işletim süreçleri gerekiyor
Reddit, X(Twitter vb.) gibi büyük şirketlerin SPA'ları bile mobilde çok dengesizdi
Twitter ölçeğinde değilseniz ya da API merkezli bir platform değilseniz, SPA konusunda bu kadar ısrar etmenin gereği yok bence
Milyarlarca dolarlık şirketler dâhil kimsenin düzgün yapamadığı şeyi benim daha iyi yaparım özgüvenine kapılmamak lazım
Her şeyi React ile baştan yazmak gerekmiyor
Orijinal yazarın bahsettiği gelişmiş SPA benzeri özellikler isteğe bağlı
Ayrılan kullanıcıları da incelediniz mi merak ediyorum
Böyle bir dünyada yaşamak isterdim
Ben framework öncesi dönemden geliyorum; o zamanlar her şey daha hamdı ve sadece jQuery bilen insanlara sık rastlanırdı
Bugün query selector sonrası dönemde framework'lerin maliyet/fayda dengesinin o kadar güçlü olmadığını düşünüyorum (test framework'leri ayrı, onlar gerçekten çok iyi)
React denen framework hapishanesine kapandık ve tüm başarısızlıklar spagettiye dönmüş karmaşıklığın sonucu
State machine'ler el yordamıyla düğümleniyor, çevrilmiş/sıkıştırılmış/transpile edilmiş çıktılar da okunmaz halde
Source map'ler de bakımın üstüne eklenen ayrı bir karmaşıklık katmanı
Framework'lerin neden ortaya çıktığını anlıyorum ama yeni bir mühendisin vanilla JS yerine sürekli framework öğrenmesinin daha kolay olduğunu düşünmekte zorlanıyorum
HTML sadece metin render etmeyi biraz daha kolaylaştırmak için yapılmış bir işaretleme diliydi, HTTP de öyle
Eskiden metin/işaretleme oranının yüksek olması gerekiyordu, şimdi ise bu tamamen tersine döndü
Ama tüm uygulama geliştirmeyi bunun üstüne kurmanın gelecek olduğuna inandık ve React'in içine bakınca da on yılların hileleri ve numaraları görülüyor
Eskiden Excel+VB ile uygulama yapmak ya da PDF+PostScript birleşiminden uygulama çıkarmaya çalışmak gibi absürt şeyler vardı
Bunca şeyin ardından birkaç MB JS tüketimi ister istemez aşırı geliyor
Veri değiştiğinde UI'ın anında tepki vermesi kısmı; bunu elle listener yazarak, diff update yaparak ve event temizleyerek kurmak neredeyse elle bellek yönetimi yapmak gibi hissettiriyor
jQuery döneminde böyleydi ve hata çoktu
Component tabanlı, bildirimselliğe dayanan görünüm modülerliği mümkün olduğunda vanilla JS'ye dönerim ama bana göre henüz kesinlikle orada değiliz
Belirleyici bir parça eksik
React ve Angular ES2015 öncesinde kesinlikle anlamlıydı
Ondan sonra frontend framework'lerindeki değişimden yoruldum
React'in içinde bile component yaklaşımı, state yönetimi yaklaşımı sürekli değişiyor
Ben hâlâ Web Components konusunda ikna olmuş değilim
Özellikle @scoped, import {type:css} gibi yeni özellikler gelse bile, öğeleri statik olarak render edip sonra modern JS ile dinamik güncellemek bana çok daha anlamlı geliyor
Web Components yaklaşımlarının çoğuna şüpheyle bakıyorum ve yeniliğin React/Svelte gibi framework'lerin dışında sürmesi gerektiğine inanıyorum
Web Components'in yönettiğim çeşitli sitelerde faydalı olduğunu hiç hissetmedim
Shadow DOM hakkında her sayfada onlarca kez bahsediliyor ama bunların çoğu aslında onu sisteme kattığınız için ortaya çıkan sorunlar
Benim uygulamama özel component'lerde Shadow DOM sorunu da yok
Backend'de bunun Web Components ile nasıl yapıldığını merak ediyorum
Kendi etiketlerinize ek metotlar ekleyebilir ve güncelleme mantığını component içinde kapsülleyebilirsiniz
Hafif kütüphanelere dayanan ya da doğrudan elle yazılabilen pratiklere ihtiyacımız var
HTMX'in bazı yönleri güzel ama yine de script etiketi gibi davranıyor; URL/metot bilgisi HTML'de açıkça dursun, hx-target gibi şeyler ise JS tarafında sadece data- attribute olarak tanımlansa yeterli olurdu
Kullanmadığım HTMX özelliklerinin de pakete dâhil olmasını istemiyorum
Web Components'in diğer framework'lerde component denen şeylerin yerine geçtiğini düşünmüyorum
Bileşik değerleri (Object, Array vb.) attribute içine koyamıyorsunuz, çok fazla boilerplate var ve reaktivite de yok
Ben vanilla JS benzeri kodlamayı signals[1] yaklaşımıyla yapıyorum
Her W3C standardı doğru cevap değil; XHTML'in başarısızlığından ders çıkarmak gerek
[1] https://wrnrlr.github.io/prelude/
http://youmightnotneedjs.com
Bu yaklaşım daha çok hobi olarak web sayfası yapanlara uygun gibi geliyor
Framework'lerin amacı standardizasyon, iyi uygulamaları tasarıma gömmek ve geliştirmeye hızlı başlamayı sağlamak
Web sitesinin kendisinin özünde bir değeri yok; önemli olan içeriği ne kadar verimli sunduğunuz ve doğru şekilde, zamanında geliştirdiğiniz
Bu açıdan framework'ler bugünkü ve gelecekteki maliyeti azaltıyor
Gerçek büyük şirketlerde kararlar moda, teamül ve popüler framework'lere yönelik savunmacı reflekslerle alınabiliyor; artan karmaşıklığın üretkenliği nasıl düşürdüğü takip edilmiyor ve hatta yanlış kararlar bireysel/takım teşvikleriyle uyumlu olabiliyor
Yani "rasyonel seçim olmak zorunda" mantığıyla framework seçimini meşrulaştıramazsınız
Sonuçta framework kullanmak iyi uygulamaların otomatik olarak izleneceği anlamına gelmiyor; hatta daha şişkin ve daha yavaş sistemler ortaya çıkabiliyor
Gerçekten harika bir kaynak
Web geliştiriyorsanız temel teknolojilerin nasıl çalıştığını bilmeniz ve web platformundan sonuna kadar yararlanabilmeniz gerektiğini düşünüyorum
Onun üstüne build sistemi/framework kullanıp kullanmamak, yalnızca trade-off'ları bilerek özgürce verilecek bir karar olmalı
Benim kişisel olarak Remix(/React-router v7+)'i sevmemin nedeni de web standartları felsefesine yakın olması
Yani daha az geliştirmeyle daha fazlasını yapabilmeniz; örneğin sunucu verisini değiştirmeyi sadece HTML form ile bile mümkün kılması
Ayrıca https://every-layout.dev sitesini de öneririm. Yalnızca tarayıcının yerel CSS özellikleriyle yüksek performanslı, erişilebilir ve esnek yerleşimler kurmanın çeşitli tekniklerini öğretiyor
Ben 1998'den beri profesyonel olarak web geliştiriyorum
Geçen hafta tamamen vanilla ile küçük bir proje yaptım ve gayet iyi çalışıyor
Mastodon için uzun bir thread yazma web aracı
Yaparken sürekli "framework kullanmadan yanlış bir şey mi yapıyorum" diye düşündüm
Herkes sanki framework bekliyormuş gibi bir hava var
Splinter, splinter.almonit.club, ilgilenen baksın