React.js, Vue ve Angular gibi çerçeveler ve kitaplıklar aslında her web geliştiricisinin bilgilerinin sabit bir parçasıdır. Yeni bir projeye başlamadan önce, artık hangi çerçevenin kullanılacağı sorusu artık yoktur. Angular, Vue veya React.js kullanmak genellikle bir zevk meselesidir. O zaman yalnızca hangi ek araçların ve hangi arka uçun kullanılması gerektiğine karar vermeniz gerekir.
JS çerçevelerini nasıl kullanacağınızı gösteren platformlara bir bakış bunu doğruluyor - dünyanın en önemli web sitelerinin çoğu karmaşık çerçeveler ve kitaplıklar üzerine kuruludur.
Ancak tekrar tekrar, eski tartışma ortaya çıkıyor:
JavaScript çerçeveleri, vanilya JS web uygulamaları kadar hızlı olabilir mi?
Cevap hayır . Bunun nedeni ve neden hiç fena olmadığı - bu makale size cevapları verecektir.
… JavaScript çerçeveleri Vanilla-JS kadar hızlı olabilir.
Sunucu tarafında işleme ve istemci tarafında işleme, açıkça bir tarafı destekleyen bir tartışmadır. Çoğu durumda, sunucu tarafında oluşturma veya JavaScript tarafından oluşturulması gerekmeyen statik sayfalar daha üstündür.
Bunun neden böyle olduğu kolayca açıklanabilir.
Sunucu tarafı oluşturma (oluşturulan) / statik: HTML yapısı tamamlanmış sayfa istemci tarayıcısına gönderilir. İstemci tarayıcısı, neyi görüntülemesi gerektiğini doğrudan HTML yapısı aracılığıyla bilir.
İstemci tarafında oluşturma: Sunucu, istemci tarayıcısına henüz tamamlanmış bir yapıya sahip olmayan bir HTML şablonu gönderir. HTML şablonu okunur ve işlenir, bir veya daha fazla büyük JavaScript dosyası ister. Bunlar da gönderilir. JavaScript'i işlerken sayfanın HTML yapısı oluşturulur. Ancak o zaman tarayıcı görüntülemesi gereken şeyi görsel olarak görüntüleyebilir.
Dolayısıyla, istemci tarafında oluşturma, açıkça bir sapma gerektirir ve bu genellikle performans üzerinde olumsuz bir etkiye sahiptir.
Pek çok kişinin yanlışlıkla inandığı bir şey, sunucu tarafı oluşturmanın bir React.js veya Vue uygulamasını yalnızca en gerekli JavaScript kodunu yükleyen bir HTML yapısına sahip bir sayfaya dönüştürmesidir. Ancak bu tam olarak doğru değil.
Bu teze göre, React.js ve Next.js'deki aynı uygulamanın (bir kez CSR, bir kez SSR) Next.js durumunda çok daha küçük olması gerekecekti - çünkü React.js'nin arkasındaki tüm mantık kaldırılacaktı. Ancak durum bu değil.
Bunu kanıtlamak için Next.js ve React.js'de aynı uygulamayı yazdım - her ikisi de bir üretim sürümüne dönüştürüldü ve hangisinin daha büyük olduğuna Google Chrome'un Ağ sekmesinde baktım. Next.js uygulamasıdır.
Neredeyse 50 kb daha büyük.
Aynı uygulamayı saf vanilya JS'de tekrar uyguladım. 2,5 kb boyutundadır. Toplam boyut. Next.js'nin istemci tarafında oluşturulan React.js uygulamasıyla yaklaşık aynı boyutta olmasının nedeni, tüm React.js mantığının hala dahil edilmesidir. Örneğin durum ve sanal DOM için gereken tüm mantık.
Kabul edelim - sunucu tarafı oluşturma, web sitesinin ilk içerikli boyamasını hızlandırır, ancak yine de çerçevenin kendisi arka planda yüklenmelidir.
Kabul edelim - sunucu tarafı oluşturma, web sitesinin ilk içerikli boyamasını hızlandırır, ancak yine de çerçevenin kendisi arka planda yüklenmelidir. Bu nedenle, sunucu tarafında oluşturma, vanilya-JS'de uygulanan aynı uygulama kadar hızlı olmayacak. Normalde - neden çerçevelerin hala izinleri var, şimdi buna geçeceğiz.
Vanilla JS uygulamalarının her zaman bir çerçeve ile uygulanan aynı uygulamadan daha hızlı olması gerektiğinden bahsetmiştim. Normal durumda, çok önemli bir noktayı kastediyorum: Vanilla JS uygulamasının doğru bir şekilde uygulandığı durum.
Bu, tüm teknoloji sahnesinden geçen bir şey. Herkes performanstan bahsediyor, ancak neredeyse hiç kimse bunun nasıl başarıldığından bahsetmiyor. Programlama dili A, programlama dili B'den daha performanslı, diyorlar çabuk. Ancak bu yalnızca programlama doğru şekilde yapıldığı sürece geçerlidir. Kötü kod yazıp kendinizi dizinizden vurursanız, kağıt üzerinde performansın ne faydası var?
Next.js, React.js ve Vanilla JS'de uyguladığım küçük uygulama, bir düğme ile artırılabilen birden fazla sayı gösteremiyordu. Birkaç satır JavaScript ile onClick olayını ve DOM manipülasyonunu uygulayabileceğinizden, bunun gibi bir şey için bir çerçeve kullanmak tam bir abartıdır.
Ancak benim örneğim bile DOM'daki numarayı güncellemek için ne kullanılacağı sorusuyla başladı.
innerHTML,
innerTextYa
textContent?
Vanilla-JS'de aynı şeyi elde etmenin birçok yolu vardır. DOM öğelerini seçmek için kötü uygulamalar ve iyi uygulamalar da vardır. Kötü kararlar her zaman çok daha kötü performansa yol açabilir.
Çoğu JavaScript çerçevesi çok daha basittir. Bunlar sadece kullanabileceğimiz işlevler koleksiyonları değil, aynı zamanda işleri nasıl doğru yaptığımıza dair bir çerçeve sağlayan kendi felsefeleridir. Bu onlar hakkında gerçekten takdir ettiğim bir şey.
Bu nedenle JavaScript çerçeveleri, uygulamalar oluşturmamızı kolaylaştıran bir dizi özellik sağlar - her şeyden önce, yüksek performanslı uygulamalar oluşturmak daha kolaydır.
İşte çoğu dahil olan bazı daha kullanışlı özellikler:
İşte birçok çerçevenin sunduğu daha kullanışlı özellikler:
Onsuz her şeyi yeniden kullanılabilir bileşenlerde oluşturmayı hayal etmek zor. Her şeyi çok daha hoş, daha hızlı ve bakımı daha iyi hale getirir. Bu kavram sadece JavaScript çerçevelerinde değil, diğer teknolojilerde de kullanılmaktadır. Arka uçta bile, örneğin, görünüm oluşturmaya yönelik çerçeveler bir MVC modelini uygulamak ve uygulamanın tüm görsel parçalarını bileşenlere ayırmak için kullanılabilir.
Bileşenler sayesinde, sadece çok fazla çaba sarf etmiyoruz, aynı zamanda görsel ile durumla senkronize etmemize izin veriyorlar - ki bu neredeyse her çerçevede mümkün. Vue.js'de bu amaç için veriler vardır, React.js'de durum.
Bileşen modeli hakkında özellikle hoş bulduğum şey, bir noktada onu düşünmeye başlamanızdır. Bir uygulama için yeni bir fikrim olduğunda, birkaç eskiz yapıp bileşen yapısını organize ediyorum.
Web uygulamamızın parçalarını yalnızca ihtiyacımız olduğunda yüklemek inanılmaz derecede güçlüdür. Böylece ilk yükleme daha küçüktür, yapılacak daha az render vardır. Lazy-Loading, halihazırda birçok çerçevede bulunan ve kullanımı kolay bir özelliktir. Özellikle birçok çerçevenin bileşen odaklı felsefesi, tembel yükleme ile çalışmayı çok yararlı hale getirir.
Zaten React.js'ye dönüştüren başka bir özellik - tabii ki, Memoization'u vanilla JS'de de uygulayabilirsiniz, ancak bir çerçeve veya kitaplık için resmi bir özellik her zaman tercih edilen yoldur. React.memo içeren React için mevcut, diğer teknolojiler benzer özellikler sunuyor veya muhtemelen yakında gelecek.
Özel bir projede, geçen gün fark ettim - tamamen Vanilla JavaScript ile çalışmak istedim. Ama bu aynı zamanda her şeyi sıfırdan inşa etmek anlamına gelir - sadece kodu değil, özellikle konfigürasyonu da. Normal CLI'lerle neredeyse her şey zaten dahil edilmiştir.
TypeScript'ten JavaScript'e ve Sass'tan CSS'ye dönüştürme hızlı bir şekilde kurulur ve çok kolay bir şekilde çerçeve önyükleme dünyasına entegre olur. Babel ile küçültme ve kod dönüştürme bile genellikle dahildir - bu, yeni başlayanlar için harikadır.
JavaScript çerçeveleri harika. Gerekçeleri var ve avantajları Vanilla JS'nin dezavantajı. Bu, performans açısından tam tersi de geçerlidir.
Peki performans gerçekten o kadar kötü mü? Hayır, sanmıyorum. Sunucu tarafında işleme, önbelleğe alma, geç yükleme ve sıkıştırma, JavaScript çerçevelerini hızlandırmak için sağlam yardım sağlar. Elbette, her zaman bir şekilde daha iyi hale gelir - ancak belirli bir noktada, daha fazla optimize etmenin bir anlamı yoktur, çünkü milisaniyeler, kullanıcı deneyimini gerçekten etkilemez.
Tekrar tekrar, yeni bir projeye başlamak isteyen ve doğrudan mükemmellik için çabalayan insanlar görüyorsunuz - bu yüzden uygulamalarını tamamen Vanilla JS'de oluşturuyorlar - ve bu onları basitçe bir çerçeve kullanmaktan çok daha uzun sürüyor. Ek olarak, hatalara karşı duyarlılık genellikle daha yüksektir.
Neden bu kadar çok büyük şirket JavaScript çerçevelerine güveniyor? Tam bir Vanilla js uygulaması oluşturmak için teknik uzmanlığa sahip olmadıkları için değil, daha çok kullanımı kolay olduğu ve çok para tasarrufu sağlayabildikleri için.
Çoğu durumda çerçevelerin Vanilla JS'den her zaman daha yavaş olacağını söyleyen başlığı hatırlıyor musunuz? Bu yalnızca Vanilla JS'nin düzgün bir şekilde geliştirildiği varsayımı altında doğrudur.
Çerçevelerle ilgili sorun, kısmen hiç kullanılmayan veya çok az kullanılan çok sayıda kod sağlamalarıdır. Bununla birlikte, yüksek derecede karmaşıklık nedeniyle, bir Vanilla JS uygulaması bile oldukça büyük hale gelebilir - artı hata oranı daha yüksektir. Tek bir Vanilla JS geliştiricisinin her çerçevenin arkasındaki ekiplerden daha temiz çalışması pek olası değildir.
Bana göre, bir çerçeve kullanmanın mantıklı olduğu ve kullanılmadığı her proje için net bir çizgi vardır.
Bu sınır, uygulamanın uzmanlığı, süresi, performansı ve karmaşıklığı dikkate alınarak belirlenebilir . Tabii ki, deneyimli bir Vanilla JS Developer için, BMI'yi çerçeve olmadan hesaplamak için bir uygulama uygulamak çok daha mantıklıdır.
Öte yandan, birçok geliştiricinin artık NPM paketleri ve çerçeveleri olmadan çalışmak istemediği bir durum var. React.js'de yalnızca bir bileşeni olan küçük bir uygulamayı hayata geçirdiğimde bu hatayı kendim yaptım. Tabii ki tamamen gereksiz.
Okuduğunuz için teşekkürler :)
İletişimde kalmak için posta listeme katılın
React.js hakkında daha fazla bilgi:React.js'de kullanabileceğiniz 4 faydalı JavaScript Kestirmesi React + TypeScript ile Başlarken
Tarif Monorepo Hey! Ben Berkay Aydın, Jotform'da Mühendislik Direktörü ve Ön Uç Mimarıyım. Ön uç mimarimizi yeniden yapılandırırken öğrendiklerimi size anlatacağım.
Hey geliştiriciler, her şeyin doğru planlandığı ve uygulandığı ve sürümün sonunda sayfa Google'da 2. sayfada yer alan, büyüyen bir işletme için bundan daha kötüsü olamaz. Şimdi, bu tarihte herkes her şeyi Google'da araştırıyor ve ürününüzü Google arama sonuçlarının en üstüne çıkarmak, rekabette hayatta kalmak için çok önemli.
Gündem: Giriş: TL; Ama okuyabilirim: A / B testi, CloudFront ve Lamba @ edge hakkında zaten bilginiz varsa, AWS Lambda @ edge ile doğrudan A / B testine gidin. A / B testi nedir? A / B testi, kullanıcıların bir web sitesinin iki farklı versiyonunun katılımını karşılaştırmaya odaklanan bir UX araştırma metodolojisidir.
Bugün AppStore'daki birçok uygulama, tablo görünümünü kaydırırken içeriği tablo görünümü başlığındaki ölçekleme gibi davranışlara sahiptir. Bu tür davranışlara nasıl ulaşabileceğimizin en basit yaklaşımını size göstereceğim.
İlk blogumda söz verdiğim gibi 'DOM Nedir?' burada 'DOM işleme' üzerine bir blog var. Bu blogda DOM'a daha fazla dalacağız ve DOM işlemenin ne olduğunu ve nasıl yapıldığını öğreneceğiz.
Node.js'de akışların nasıl çalıştığını hiç merak ettiniz mi? Sahiptim.