Ön uç bakış açısıyla cevap:
Yapamayacağınızı söyleyen herkesi dinlemeyin, çünkü 1996'da ortak yazdığım deneysel bir San Francisco Eyalet Üniversitesi web hizmeti nihayet birkaç yıl önce Internet cennetine gitti ve o zaman hiçbir zaman tek bir tarayıcı uyumluluğu düzeltmesi gerekmedi ; Bu, 40 yıllık hedefinizin neredeyse yarısı. Ve 1998'de bir Stanford Araştırma Enstitüsü projesi için yaptığım bu JavaScript tabanlı ön uç , birkaç yıl sonra daha serin bir şeyle değiştirildi, ancak orijinal UI'nin bugün küçük uyumluluk düzeltmeleriyle devam etmesinin bir nedeni yoktu.
İşin püf noktası, uygulamanızın yalnızca yaygın olarak desteklenen W3C / ECMA standartlarını kullanmasını ve kontrolünüzde temiz bir tasarıma sahip olmasını sağlamaktır . Modaya uygun 90'lar dönemi teknolojisine yazılan birçok web uygulaması bugün iyi ya da hiç işe yaramazken, büyük standartlara göre yazılmış 90'lar dönemi web uygulamaları hala işe yarıyor. Pasif görünebilirler ama çalışıyorlar.
Buradaki amaç, sunucularına çıkacak ve bir daha dokunmadan 40 yıl boyunca kalacak bir web uygulaması yazmak değil. Sıfırdan yeniden inşa edilmek zorunda kalmadan yeni özellikleri desteklemek için büyümeye devam edebilecek hatta yıllarca kullanımda olabilecek bir temel oluşturmaktır.
Her şeyden önce, resmi standartlara ve sadece resmi standartlara kod yazmanız gerekir . Onaylanmış bir ECMAScript standardının parçası olmayan JavaScript özelliği yoktur; ES5.1 mevcut sürümdür ve genellikle desteklenir, bu nedenle hedeflenmesi güvenlidir. Aynı şekilde, HTML5, CSS ve Unicode'un geçerli sürümleri de iyidir. Deneysel JavaScript, CSS3 veya HTML özelliği yoktur (satıcı önekleri olan veya tarayıcılar arasında% 100 anlaşma yapmayanlar). Ve tarayıcıya özel uyumluluk hackleri yok. Standarttayken ve herkes önek olmadan destekliyorsa, yeni bir özellik kullanmaya başlayabilirsiniz.
ES5 desteği, IE8 veya önceki sürümleri düşürmek anlamına gelir; bu, birkaç yıl içinde işe yaramayacak tarayıcıya özgü saldırılar gerektirdiği için yine de öneririm. Aslında adresinden bazal tarayıcı uyumluluğu setleri uzun ömürlü en iyi şans için ES5 en Sıkı Modu öneririm IE10 ve herkes son sürümlerinde . Bu tarayıcılar ayrıca, HTML5’in form doğrulama ve yer tutucu özelliklerinin birçoğu için yerel desteğe sahiptir; bu, çok uzun süre faydalı olacaktır.
ECMAScript'in yeni sürümleri, eski sürümlerle uyumluluğu korur; bu nedenle, kodunuz geçerli standartlara göre yazıldığında, gelecekteki özellikleri benimsemek çok daha kolay olacaktır. Örneğin, yaklaşan classsözdizimini kullanarak tanımlanan sınıflar, mevcut constructor.prototypesözdizimiyle tanımlanan sınıflarla tamamen değiştirilebilir . Böylece, beş yıl içinde bir geliştirici, ES6 formatına sınıfları dosya bazında, hiçbir şeyi bozmadan yeniden yazabilir - tabii ki, iyi bir birim testiniz olduğunu varsayarsak.
İkincisi, özellikle uygulamanızı kodlama biçiminizi değiştirirlerse , popüler JavaScript uygulama çerçevelerinden kaçının . Omurga tüm öfke, o zaman SproutCore ve Ember, ve şimdi Angular, herkesin tanıtmayı sevdiği çerçeve. Yararlı olabilirler, ancak ortak bir yönleri de var: yeni sürümler çıktığında ve uzun ömürlülüğü sorgulandığında sık sık uygulamaları kırıyorlar ve kod değişiklikleri gerektiriyorlar. Geçenlerde Angular 1.1 uygulamasını 1.2'ye yükselttim ve biraz yeniden yazmam gerekiyordu. Aynı şekilde, Omurga 2'den 3'e gitmek çok fazla HTML değişikliği gerektirir. Standartlar bir sebepten dolayı yavaş hareket ediyor, ancak bu çerçeveler hızlı hareket ediyor ve periyodik olarak kırılan şeyler maliyet.
Ayrıca, yeni resmi standartlar genellikle eski çerçeveleri eski bırakır ve bu olduğunda bu çerçeveler ya mutasyona uğrar (değişikliklerle birlikte) ya da geride kalır. ECMAScript 6 onaylandıktan ve tüm tarayıcılar standardize edilmiş Promise sınıfını destekledikten sonra tüm dünyanın rakip vaat eden kütüphanelerine ne olacağını biliyor musunuz? Eski hale gelecekler ve geliştiricileri onları güncellemeyi bırakacak. Doğru çerçeveyi seçtiyseniz, kodunuz yeterince iyi adapte olabilir ve eğer kötü bir şekilde tahminde bulunduysanız, büyük bir yeniden düzenlemeye bakıyor olacaksınız.
Bu nedenle, bir üçüncü taraf kütüphanesini veya çerçevesini benimsemeyi düşünüyorsanız, gelecekte kaldırmanın ne kadar zor olacağını kendinize sorun. Uygulamanızı sıfırdan oluşturmadan hiçbir zaman kaldırılamayan Angular gibi bir çerçeve ise, bu, 40 yıllık bir mimaride kullanılamayacağının iyi bir işareti. Bazı özel katman yazılımlarıyla soyutladığınız üçüncü taraf bir takvim widget'ıysa, değiştirilmesi birkaç saat sürebilir.
Üçüncüsü, ona iyi ve temiz bir uygulama yapısı ver. Bir uygulama çerçevesi kullanmasanız bile, geliştirici araçlarından, komut dosyalarından ve iyi bir tasarımdan yararlanabilirsiniz. Şahsen, Closure Toolkit'in bağımlılık yönetiminin bir hayranıyım çünkü hafif ve uygulamanız oluşturulduğunda ek yükü tamamen kaldırılıyor. LessCSS ve SCSS, stil sayfalarınızı düzenlemek ve piyasaya sürülmek üzere standartlara dayalı CSS stil sayfalarını oluşturmak için mükemmel araçlardır.
Ayrıca MVC yapılı tek kullanımlık sınıflar halinde kendi kodunuzu düzenleyebilirsiniz. Bu, birkaç yıl geleceğe geri dönmeyi ve bir şey yazdığınızda ne düşündüğünüzü bilmeyi ve yalnızca ihtiyacı olan parçaları değiştirmeyi çok kolaylaştıracaktır.
Ayrıca W3C’nin tavsiyelerine uymalı ve sunum bilgilerini tamamen HTML’nizin dışında tutmalısınız. (Buna "büyük yeşil metin" ve "iki sütun genişliğinde" gibi öğelerin sunum sınıf adlarını verme gibi hileleri içerir.) HTML'niz semantik ve CSS sunumlu ise, bakımı ve uyarlaması daha kolay olacaktır Gelecekte yeni platformlara. Görme engelli veya engelli insanlar için özel tarayıcılar için destek eklemek de daha kolay olacaktır.
Dördüncüsü, testlerinizi otomatikleştirin ve neredeyse tam kapsama sahip olduğunuzdan emin olun. Sunucu tarafında veya JavaScript'te olsun, her sınıf için birim testleri yazın. Ön uçta, her sınıfın desteklenen her tarayıcıdaki özelliğine göre performans gösterdiğinden emin olun. Her test için bu testleri inşa botunuzdan otomatikleştirin. Bu, hem uzun ömür hem de güvenilirlik açısından önemlidir, zira mevcut tarayıcılar onları gizlese bile erken hatalar yakalayabilirsiniz. Hem Jasmine hem de Google Closure'un JSUnit tabanlı test çerçeveleri iyi.
Ayrıca, Selenium / WebDriver'ın iyi olduğu tam UI işlevsel testlerini de yapmak isteyeceksiniz. Temel olarak, UI'nızdan geçen ve bir kişiyi test ediyormuş gibi kullanan bir program yazıyorsunuz. Bunları inşa botuna bağla.
Son olarak, başkalarının belirttiği gibi verileriniz kraldır. Veri depolama modelinizi düşünün ve kalıcı olmasını sağlayın. Veri şemanızın sağlam olduğundan ve bunun her işlem için de iyi bir şekilde test edildiğinden emin olun. Sunucu mimarinizin ölçeklenebilir olduğundan emin olun. Bu, ön uçta yaptığınız her şeyden daha önemlidir.