Dev, karmaşık JavaScript kullanıcı arayüzlerine yaklaşıyor [kapalı]

Karmaşık istemci tarafı JavaScript geliştirme etrafında farklı yaklaşımların ve en iyi uygulamaların manzarasını anlamaya çalışıyorum.

Belki de ağır AJAX veya RIA (Flash / Silverlight gibi eklentiler değil) bu uygulama sınıfını ne etiketleyeceğinden emin değilim . Bu özelliklere sahip web uygulamalarından bahsediyorum:

• JavaScript'te zengin / yerel masaüstü UX'u taklit edin
• Sunucuyu veri API'si (JSON / Html-Templates) olarak kullanarak, istemci tarafı JS'deki davranışların çoğunu / tümünü içerir.

Bu, sayfa yenileme modelindeki tüm HTML'yi oluşturarak UI oluşturma için web sunucusunu kullanmaktan farklıdır.

Bazı örnekler:

• Google Dokümanlar / Gmail
• Mindmeister
• Temel İzleyici

HTML5'e geçtikçe, ağır JavaScript'le bu RIA geliştirme tarzını görebiliyorum, rekabet etmek daha yaygın ve gerekli hale geliyor.

SORU: Öyleyse bu tür ağır JS gelişmelerini yönetmek için ortaya çıkan ortak yaklaşımlar nelerdir?

İstemci tarafı kodu, bir uygulama özelliklerinde büyüdükçe, son derece karmaşıktır. Raw JS ile birden fazla ekip arasında bir geliştirme çabasını ölçeklendirmede sorunlar var (ya da duyuyorum ve buna inanabilirim).

Google, daha üst düzey bir dilden (Java) JS'ye derleyen GWT'yi oluşturarak, daha üst düzey dilin sahip olduğu mevcut geliştirme altyapısına (Eclipse, güçlü yazım, yeniden düzenleme araçları) ve tarayıcı uyumluluğunu ve geliştiriciden uzak diğer sorunlar.

C # için Script # gibi benzer bir şey yapan başka araçlar da vardır. Bütün bunlar JS'yi bir IL (Ara Dil) rolüne daha fazla koyar. yani. "Artık bu 'düşük seviyeli dilde' asla gerçekten yazmıyorsunuz."

Ancak bu 'JS'ye derleme' tek yaklaşım değildir. GWT'nin baskın yaklaşım olduğu belli değil ... ya da gerçekten olacak.

Kullanıcılar zengin istemci JavaScript ile ne yapıyor? Bazı yönlendirme soruları:

• Çoğu dükkan JS'yi elle mi üretiyor (jQuery ve ark gibi kütüphanelerin üstünde)?
• Yoksa açık bir en iyi uygulama ortaya çıkmadan birçok farklı yaklaşım var mı?
• Çoğu mağaza, geliştirici sunucu tarafı / sayfa yeniden çizim modelinin daha basit olması lehine RIA ölçeği geliştirmesinden kaçınıyor mu? Varsa, bu sürecek mi?
• JS'ye derlemek belki de gelecekteki bir trend midir? Yoksa bu sadece yanlış mı?
• İstemci JS'nin karmaşıklığını ve yeniden düzenlemesini nasıl yönetiyorlar?
• Çalışmaların modüler hale getirilmesi ve ekipler arasında dağılımı?
• MVC / MVP vb. Gibi istemci tarafı modellerin uygulanması, uygulanması ve test edilmesi

Peki, bu ağır JavaScript ve HTML5 geleceğimizde ortaya çıkan trendler neler?

Teşekkürler!

Bu yönde hareket eden gördüğüm Web uygulamalarının çoğu (ve konuştuğum Web geliştiricileri) jQuery'yi temel olarak kullanıyor.

GWT'nin (ve benzer çok düzeyli dillerin) ardındaki tüm mantık, JavaScript'in "gerçek programcılar" ın kullanması için çok açık / çok kırılgan / çok değişken olmasıdır. Ancak, sizin için lapa lapa / kırılgan / değiştirilebilir bitleri işleyen bir çerçeveniz varsa, o ekstra karmaşıklık katmanına eklemek için bir neden yoktur.

Sadece benim görüşüm…

GWT'nin riskli olduğunu söyleyebilirim. Bir kez kullanmaya karar verdiğinizde onunla sıkışıp kalırsınız. Temel olarak, işaretlemenizi, DOM'nizi ve CSS'nin bazı yönlerini bir yürütme ortamı olarak ele almanız anlamına gelir. İstemci kodunuz gittikçe daha karmaşık hale geldiğinden, elle yazılmış JavaScript'i GWT ile karıştırmak gerçekten zorlaşıyor. GWT'nin yerel yöntemleri vardır, ancak bunlar uygulanabilirlik açısından oldukça sınırlıdır. Bu büyük bir takas ve büyük bir bahis.

Google, GWT'yi iyi bir sunucu tarafı entegrasyonu ile çok hızlı bir X platformu yürütme ortamı olarak satmaya çalışıyor. Ancak diğerlerinin de belirttiği gibi, artık durum böyle değil - JQuery ve YUI daha hızlı olmasa da çok hızlı. Sayfalarınızı manuel olarak birleştirildiklerinde profillemek ve optimize etmek çok daha kolaydır, böylece CSS, işaretleme ve JavaScript üzerinde tam kontrol sahibi olursunuz.

GWT, altta yatan platformu sizden gizlemeye çalışır, bu da aslında bir şeyler yapmanın yanlış bir yolu olabilir. Bileşen web çerçeveleri adı verilen birçok çerçeve aynı şeyi yaptı. EL ve özel etiketler atılmış belirsiz XML'den türetilmiş kod yazmanız gerekiyordu. Çıktı, her yere serpilmiş küçük crappy JavaScript parçaları ile kötü biçimlendirilmiş HTML'nin bir karışıklığı olurdu. Sayfalar yavaş, buggy ve tamamen saklanamazdı.

Mevcut projemizde, düşük seviyeli eyleme dayalı bir çerçeve olan Stripes ve istemci tarafında JQuery kullanıyoruz. Bir bulmacanın tüm parçalarını açıkça gördüğünüzde Ajax'ı yapmak çok kolaydır: işte veriler üzerinde çalışan Sunucu tarafı kodunuz. İşte müşteri tarafı kodunuz - veri almak ve sayfalarda bir şeyler yapmak için. İşte CSS'niz, işaretlemeniz, işte temponuz - her şey temiz ve ayrıştırılmış. Kolayca genişletilebilir, hacklenebilir, ayarlanabilir ve hata ayıklanabilir. Onu seviyorum.

Hız ve basitliğe karşı tutumu ile JQuery'i seviyorum. Modülerlik ve kapsamlı widget'lar için YUI3'ü seviyorum. YUI CSS'yi tarayıcılar arasında tutarlılık sağladığı için seviyorum. Good Parts için JavaScript'i seviyorum. İşi Bitirmem için Java'yı seviyorum.

Sadece ÖPÜCÜK ve iyi olacaksın!

Bunları "Tek sayfalık uygulamalar" olarak duydum.

Bu yeni bir ortam ve kurallar henüz tam olarak yazılmamış. Geçen yıl (2010) nispeten büyük bir tek sayfalık uygulama üzerinde çalıştım ve bunlar kullandığımız araçlar.

Arka uç, sayfanın hazırlanan siparişi göndermek için kullanılan bir JSON hizmeti sağlamak için sunucu uygulamaları kullanan Java idi. Bu hizmet aynı zamanda bazı doğrulama adımları ve fiyatlandırma için de kullanıldı.

Ön uç kodu javascript idi. Biz kullanılan jQuery sayfa elemanlarının, manipülasyonunun yapmak Saf şablonu için ve RequireJs modüller halinde kodunu kırmak için. (En uygun indirmeleri sağlamak için RequireJs derleme aracı kullanılmıştır.)

Testlerimizi qUnit kullanarak yazdık ve her qUnit testini çalıştırmak için htmlunit kullanan, daha sonra sonuçları sonuçlar için kazıyan ve qUnit başarılı / başarısız durumuna göre başarılı veya başarısız olan bir jUnit testi yaptık . Bunlar arka uç için jUnit testlerimize eklenmiş ve Hudson / Jenkins kullanarak ci'ye yuvarlanmıştır .

Ext JS üzerine kurulmuş böyle bir uygulama üzerinde çalışıyorum. Uygulama modüler olarak düzenlenmiştir. Farklı bileşenler, Ext bileşen hiyerarşisinden kaldırıldığında kendiliğinden temizlenen bağımsız bileşenler olarak uygulanır. İsteğe bağlı yükleyiciler gerekmeden hemen önce ek bileşenler yükler (bir js dosyası = bir bileşen).

Bu yaklaşımın ölçeklendirilmesi o kadar zor değil. Karşılaştığım tek gerçek sınır, IE'de aynı anda ağaçta çok fazla DOM öğesine sahip olmakla ilgilidir. Buradaki çözüm, uygulamanın gizli bölümlerini stratejik olarak boşaltmaktır. Tüm DOM manipülasyonları Ext bileşen hiyerarşisiyle gerçekleştiğinden, DOM neredeyse tamamen soyutlanır ve geliştirme basit kalır.

Şahsen, jQuery gibi çerçevelerin sadece farklı tarayıcılar arasındaki varyasyonlarla uğraşmak için değil, aynı zamanda koda gürültü eklememesi için bu farklılıkları gizlemek için hayati olduğunu düşünüyorum. GWT, Websharper ve diğerleri gibi araçlar bunu daha da ileri götürüyor ve kesinlikle bir yeri var ama çoğu durumda bunun sadece fazladan bir dolaylama katmanı olup olmadığını merak ediyorum.

Kimsenin bahsetmediği için şaşırdığım bir şey birim testidir. Artık karmaşık sunucu tarafı uygulamalarının otomatik birim testlerine sahip olması gerektiği kabul edilmektedir ve RIA uygulamalarındaki JS'nin, bunu mümkün kılan mimari / kodla birlikte birim testine ihtiyaç duyacak kadar karmaşık olduğu zamanın geldiğini düşünüyorum.

Ancak, karmaşık sunucu tarafı uygulamalarından farklı olarak, gördüğüm ve duyduğum şeylere dayanan bağırsak hissim, karmaşık istemci tarafı uygulamalarının büyük çoğunluğunun kesinlikle hiçbir birim testinin olmamasıdır (burada selenyum testi, gerçek birim testi hakkında konuşmuyorum).

Bir sonraki ortaya çıkan trendin birim test (ve birim test edilebilir kod) tanıtımı olacağını düşünüyorum. Orta düzeyde birim test edilmemiş JavaScript içeren bir projeyi yeni tamamladıktan sonra, bunun son olacağını umuyorum.