Modern Web Uygulamaları Oluşturmanın Yedi İlkesi. Riak - web tabanlı depolama sistemi

Son zamanlarda, çoğunlukla UX ve performansla ilgili.

Kullanıcı arayüzlerini kontrol etmek için JavaScript kullanmak isteyen web siteleri için 7 uygulanabilir ilke sunmak istiyorum. Bu ilkeler, bir web tasarımcısı olarak ve aynı zamanda uzun süredir WWW kullanıcısı olarak yaptığım çalışmanın sonucudur.

JavaScript, ön uç geliştiriciler için inkar edilemez bir şekilde vazgeçilmez bir araç haline geldi. Artık kapsamı sunucular ve mikrodenetleyiciler gibi diğer alanlara doğru genişliyor. Bu programlama dili, öğrencilere bilgisayar biliminin temellerini öğretmek için prestijli üniversiteler tarafından seçilmiştir.

Aynı zamanda, çerçevelerin ve kitaplıkların yazarları da dahil olmak üzere, birçoğunun yanıtlamayı zor bulduğu rolü ve özel kullanımıyla ilgili bir dizi soru vardır.

• JavaScript, tarayıcı işlevlerinin yerine kullanılmalı mı: tarih, gezinme, oluşturma?
• Arka uç ölüyor mu? HTML oluşturmam gerekiyor mu?
• Tek Sayfa Uygulamalarının (SPA) geleceği olduğu doğru mu?
• JS, bir web sitesinde sayfalar oluşturmalı ve web uygulamalarında sayfalar oluşturmalı mı?
• PJAX veya TurboLinks gibi teknikleri kullanmam gerekiyor mu?
• Bir web sitesi ile bir web uygulaması arasındaki tam fark nedir? Geriye tek bir şey mi kalmalı?

Bu soruları cevaplama girişimlerim takip edecek. Bir kullanıcı (UX) perspektifinden JavaScript'in nasıl kullanılacağını araştırmaya çalıştım. Özellikle, kullanıcının ilgilenilen verileri elde etmesi için geçen süreyi en aza indirme fikrine özel önem verdi. Ağ teknolojilerinin temelleri ile başlayıp, gelecekteki kullanıcı davranışlarını tahmin etmekle son buluyor.

1. Sunucuda sayfa oluşturma

tl; DR: Sunucu oluşturma SEO için değil, performans içindir. Komut dosyaları, stiller ve sonraki API istekleri için ek istekleri dikkate alın. Gelecekte, HTTP 2.0 Push yönteminin kullanımını düşünün.

Öncelikle "sunucu üzerinde render olan uygulamalar" ile "tek sayfalı uygulamalar" arasında yapılan yaygın bir hataya dikkat çekmem gerekiyor. En iyi kullanıcı deneyimini elde etmek istiyorsak, kendimizi böyle bir çerçeveyle sınırlamamalı ve bir alternatifi bir başkası lehine terk etmemeliyiz.

Nedenleri oldukça açık. Sayfalar, Stuart Cheshire'ın ünlü makalesi "It's laency, aptal"da ünlü olarak gösterdiği gibi, fiziksel sınırlamaları olan internet üzerinden iletilir:

Stanford ile Boston arası 4320 km'dir.
Işığın boşluktaki hızı 300 x 10 ^ 6 m/s'dir.
Bir optik fiberdeki ışığın hızı, bir vakumdaki ışığın hızının yaklaşık %66'sı kadardır.
Optik fiberde ışığın hızı 300 x 10 ^ 6 m/s * 0,66 = 200 x 10 ^ 6 m/s'dir.
Boston'a iletimde tek yönlü gecikme 4320 km / 200 x 10 ^ 6 m / s = 21,6 ms.
Gidiş dönüş gecikmesi 43,2 ms.
Modern İnternet'te Stanford'dan Boston'a Ping yaklaşık 85 ms'dir (...)
Bu nedenle, modern İnternet ekipmanı, ışık hızının 0,5 katı hızında bir sinyal iletir.

85 ms'lik belirtilen sonuç iyileştirilebilir (ve şimdi biraz daha iyi), ancak kullanıcıların bilgisayarlarındaki bant genişliği ne olursa olsun, İnternet üzerinden bilgi iletirken gecikmede fiziksel bir sınırlama olduğunu anlamak önemlidir. artışlar.

Bu, genellikle yalnızca biçimlendirme içeren JavaScript uygulamalarının artan popülaritesi nedeniyle özellikle önemlidir.