JavaScript ne zaman HTML oluşturmalı?

JavaScript'ten olabildiğince az HTML oluşturmaya çalışıyorum. Bunun yerine, mevcut işaretlemeyi ne zaman yapabilirsem değiştirmeyi tercih ediyorum ve yalnızca HTML'yi Ajax'ı kullanmak için iyi bir aday olmayan bir öğeyi dinamik olarak eklemem gerektiğinde üretiyorum. Bunun, kodun korunmasını çok daha kolay hale getirdiğini ve kodda hızlıca değişiklik yaptığını düşünüyorum çünkü işaretlemenin okunması ve izlenmesi kolaydır. Temel kuralm: HTML, belge yapısı için, CSS sunum içindir, JavaScript davranış içindir.

Ancak, tüm formlar ve içerik ağırlıklı kalıcı iletişim kutuları da dahil olmak üzere bir dizi HTML kodu üreten bir JS kodu gördüm. Genel olarak hangi yöntem en iyi yöntem olarak kabul edilir? Hangi durumlarda HTML oluşturmak için JavaScript kullanılmalı ve ne zaman kullanılmamalıdır?

Ne zaman javascript'te yoğun HTML jenerasyonuyla karşılaştıysam, neredeyse tamamen bağımsız bir kullanıcı arayüzü eklentisindeydi. Tüm eklentiyi tek bir .js dosyasında (stilleri özelleştirmek için + a. Ccs) kapsüllenmesine izin verdiğinden, uygulamada kullanılan çerçeveden kolayca yeniden kullanılabilir, dağıtılabilir ve bağımsız olmasını sağlar.

Dolayısıyla, tek başına bir javascript eklentisi veya farklı uygulamalar arasında kullanmak istediğiniz genel bir UI bileşeni yazıyorsanız, böyle bir yaklaşımın bir tarafı vardır. Aksi takdirde, html oluşturmayı javascript'ten ve sunucu tarafından uzak tuttuğunuzda hem temiz, hem yazması hem de bakımı daha kolay olduğunu düşünüyorum.

Bence asıl sorun, yanlış yazılmış geçici istemci tarafı HTML oluşturma için özenle yazılmış temiz yazılmış sunucu tarafını karşılaştırmanızdır. Elbette temiz bir şekilde yazılmış kodun okunması, bakımı ve izlenmesi kolaydır.

İstemci tarafındaki kodu "HTML höyükleri" olarak adlandırırsınız, ancak elbette, üretildiği her yerde aynı HTML'dir. "Höyük" gerçekten büyük bir kod yığınıdır.

Dışarıda bir sürü müşteri tarafı ayarlayan kütüphane var. Sunucu tarafındakilerle benzer şekilde çalışırlar. Kendisi için tercih gerektiği gibi, performans değiş tokuş karmaşık, ancak JSON genellikle o olur HTML ve istemci üzerinde şablonu olmasından daha kompakt olabilir bazı sunucu aramaları ortadan kaldırır. Öte yandan, müşteri JS'yi devre dışı bırakmış olabilir veya pratik olamayacak kadar yavaş olabilir, bu nedenle hedef kitlenize de bağlıdır. Genel olarak, yaklaşımların oldukça karşılaştırılabilir olduğunu düşünüyorum, en büyük faktör hedef kitlenizin tarayıcı yetenekleri.

Ancak, tam olarak ne yaptığınıza, JS'yi sunucu ortamınıza tercih edip etmediğinize, hangi şablon çözümü tercih ettiğinize vb. Bağlıdır.

İstemci tarafı şablonlarını kullanma eğilimi vardır, aşırı durumlarda tüm işleme istemci tarafını yaparken, yalnızca JSON biçiminde yalnızca RESTful API sağlayan sunucunuz olur. Bu yaklaşımın avantajı, JS kodunun ve şablonlarının, CDN aracılığıyla önbelleğe alınabilen, proxy'lenen ve dağıtılabilen statik kaynaklar olmasıdır. Sunucu tarafında oluşturulan dinamik HTML varsa, bu yapılamaz. Ayrıca, hafif formatta RESTful API'den yalnızca verileri döndürmek, sunucu tarafında daha az kaynak kullanır, bu da yanıtı daha hızlı yapar. Ayrıca daha hafiftir, daha az ağ aktarımı olur ve bu da daha hızlı olmasını sağlar. Bu şekilde, 3G gibi yavaş bağlantılarda bile çok duyarlı düşük gecikmeli uygulamalara sahip olabilirsiniz. Dolayısıyla bu yaklaşım mobil sayfalar ve uygulamalar için popülerdir.

JS şablonları uygulayan çok sayıda kütüphaneler vardır, popüler olanlardan biri olan Saf , Bıyık ve dust.js . Daha sonra LinkedIn tarafından kullanılmakta, "Tozdan JSP'leri bırakmak: LinkedIn'i dust.js müşteri tarafı şablonlarına taşımak" başlıklı makalesindeki avantajları açıkladılar .

İstemcide HTML oluşturmanın avantajı, işleme işini genellikle istemciyi boşta bekleten her istemciye boşaltmanızdır. Yalnızca JSON verisi ve statik içerik (HTML, JS ve CSS) sunmak için daha fazla sunucu kaynağını boşaltın.

Javascript ile sadece HTML üreten bir web uygulaması yapıyoruz. Sunucu isabetlerinin% 87'si JSON verisidir, statik içerik genellikle bir kez, ardından tarayıcı önbelleğinden yüklenir.

Ama SEO'ya ihtiyacınız yoksa kullanamazsınız - en azından kolay değil. Veya Javascript'in devre dışı bırakıldığı bir popülasyonu hedefliyorsanız, ancak bunun hala Youtube, Twitter, Facebook, Gmail, ... ile alakalı olduğundan emin değilim.

Dinamik sayfa yükleme ile ilgili olarak, bir "tüm JQuery AJAX Cloud!" sihir, sadece iki olası şey oluyor:

1. Bir öğenin kodu div (kötü) içine enjekte ediliyor veya
2. İçerik bir iframe içine yükleniyor (daha iyi, ancak aynı değil ...)

Asıl soruya gelince, sadece Javascript aracılığıyla HTML içeriği oluşturuyorum, sunucuda depolanan XML veya JSON verilerini okuyan bir tür web uygulaması oluştururken ve çok değişti.

Javascript’li bir sayfaya statik içerik yüklemek pek doğru olmaz, çünkü her zaman doğru yüklenmeyebilir veya müşteri onu devre dışı bırakacaktır ("bu sinir bozucu reklamları al!"). Buna ek olarak, çirkin document.write()bir zincirle karıştırıldığında HTML içeriğini değiştirmeyi gerçekten zorlaştırır document.createElement().

Demek haklısın; ham HTML'yi ya da dynamic-ish içeriği gerekliyse, gerekli olanı yazdırmak için sunucu taraflı bir komut dosyası kullanın. HTML'yi yalnızca sitenin İnternet bağlantısı olmadan çalışması veya benzer bir durumda olması gerekiyorsa enjekte etmek için Javascript kullanın.

Son bir not, bir web sitesine xmlhttprequests, er, AJAX uygulamak istiyorsanız, muhtemelen bunu yapmanın en iyi / en güvenli yolu, verileri bir veri biçiminde (XML gibi) depolamak, yüklemek ve buna göre çıktı almaktır. müşteriye. document.writeve element.innerHTMLgerçekten içeriği değiştirmeye devam etmenin en iyi yolu değildir ve gelecekte potansiyel olarak baş ağrısına yol açması zorunludur (neden bu komut dosyası çalışmıyor? Kırık <i>etiketim her şeyi italik hale getiriyor! vb.).

Benim mantığım şudur: ne zaman daha kolay ve kimse işaretlemeye aldırış etmiyorsa.

Ayrıca ikisini de kaldırabilir ve biçimlendirmeyi dikkate almanın çok zor olduğu ve DOM ağacına odaklanmayı tercih ettiğiniz bir sınır tanımlayabilirsiniz. Örneğin, dinamik satırları olan bir form (ör. "Başka bir ek ekle"), muhtemelen HTML’deki formu, "satır ekle" düğmesini ve gönder düğmesini istersiniz ... muhtemelen oluşturmak istemezsiniz Sunucu tarafı dilinizle ilgili HTML.

Başka bir kural da yeniden kullanılabilirlik olabilir. Çözümünüz müşteri tarafındaki diğer sorunlara uygulanabilirse, bunu js ile kaplayın.

Tek sayfalık uygulamalar (ala Google Mail) geliştiriyoruz ve uygulamalarımızda kelimenin tam anlamıyla sunucu tarafında HTML üretimi yok . Bunun yerine, istemci tarafımızı yapılandırmak için Backbone.js'yi ve JSON'umuzu sayfaya giren şablonlara dönüştürmek için Gidonları kullanıyoruz. Gerçekten çok iyi çalışıyor ve onu kullanan ilk uygulamamızın sonuna yaklaşıyoruz ve gelecekte daha da büyük bir projeyle başa çıkacağız.

Sunucunun yalnızca verileri sürdürmek ve sorgu sonuçlarını döndürmek için kullanıldığı her türlü şişman müşteri, JavaScript'in HTML oluşturmasını isteyeceğiniz bir poster çocuğu. Temiz ve kolay hale getirmek için iyi bir şablon motor kullandığınızdan emin olun.

Jquery'de html kodu üretiyorum çünkü bir portlet kullanıyorum ve jsp kodunun çalıştırılmasından sonra html koduyla bir döngü yapmam gerekiyor, javascript koduyla birlikte bir java içine giremiyorum. Bu yüzden bir javascript dizisinde java arraylist ve html üretmek için dizeleri kullanıyorum.