Aşamalı geliştirmedeki kod tabanları neden artık değilse, JavaScript koduna eşit miktarda sahip?

Uzun zamandır web programcılığı yapıyorum ve bir yerlerde, bugün ne yaptığımızı neden yaptığımızı (ya da nasıl bu şekilde işler yapmaya geldik) izini kaybettim?

Temel ASP web geliştirme ile başladım ve çok erken, ekran ve iş mantığı sayfada karışık oldu. Müşteri tarafı gelişimi çılgınca değişiyordu (VBScript, farklı JavaScript tatları) ve sunucu tarafı doğrulamaları hakkında çok fazla uyarı aldık (ve böylece müşteri tarafı mantığından uzak durdum).

Daha sonra bir süre ColdFusion'a taşındım. ColdFusion muhtemelen ekran ve işletme mantığını etiketlerini kullanarak ayıran ilk web geliştirme çerçevesiydi. Bana çok net görünüyordu, ama çok ayrıntılı ve ColdFusion yüksek pazar talebinde değildi ve ben de devam ettim.

Sonra ASP.NET grubu vagonuna atladım ve MVC yaklaşımlarını kullanmaya başladım. Java'nın kurumsal sistemlerin fildişi kule dili gibi göründüğünü farkettim ve ayrıca MVC yaklaşımlarını denedim. Daha sonra, ASP.NET bu MVVM tasarım modelini geliştirdi ve Java (tam olarak, J2EE veya JEE) de MVC2 yaklaşımlarıyla mücadele etti ve çıktı.

Fakat bugün keşfettim, arka uç programlamanın artık heyecan ve ilerlemenin olmadığı yer. Ayrıca, sunucu tarafı tabanlı MVC uygulamaları modası geçmiş gibi görünüyor (insanlar artık gerçekten JSTL kullanıyor mu?). Bugün, üzerinde bulunduğum çoğu projede, JavaScript çerçevelerinin ve müşteri tarafı gelişimin tüm heyecan verici ve yenilikçi ilerlemelerin yapıldığı yer olduğunu öğrendim.

Sunucudan müşteri tarafı gelişimine bu hareket neden gerçekleşti? JEE projelerimden birine basit bir satır sayımı yaptım ve JavaScript'te Java'dan (üçüncü taraf kütüphaneleri hariç) daha fazla kod satırı var. Java veya C # gibi programlama dillerini kullanan çoğu arka uç gelişiminin yalnızca REST benzeri bir arabirim üretmek olduğunu ve görüntüleme, görselleştirme, veri girişi / çıkışı, kullanıcı etkileşimleri, vb. Gibi tüm zor çabaların ele alındığını biliyorum. Açısal, Omurga, Ember, Nakavt, vb gibi müşteri tarafındaki çerçeve üzerinden ...

JQuery öncesi dönemde, MVC'de M, V ve C arasında n-katmanlı gelişimde açık, kavramsal bir çizginin olduğu bir sürü diyagram gördüm. JQuery sonrası, bu çizgiler nerede çizilir? Görünüşe göre MVC ve MVVM orada JavaScript kodunda, müşteri tarafında.

Bilmek istediğim şey, neden böyle bir geçiş yaptık? (Sunucu tarafı programlamanın vurgusundan müşteri tarafına, derlenmiş dilleri tercih etmekten, komut dosyası dillerine, zorunluluktan işlevsel programlamaya, bunların hepsi aynı anda olmuş gibi görünüyor). ) ve bu geçiş / kayma hangi sorunları çözdü?

Bilgi işlem yükünü sunucu ile istemci arasında değiştirmek döngüsel bir olgudur ve uzun zamandır böyle olmuştur.

Topluluk kolejindeyken, Kişisel Bilgisayar daha yeni bir kafa alıyordu. Fakat Ethernet henüz yaygın kullanımda değildi ve kimsenin yerel bir alan ağı yoktu. O zamanlar, kolej öğrenci kayıtlarını işleyen ve programlama dersleri için bir platform görevi gören bir ana bilgisayara sahipti. İdarenin, zaman dilimi bazında anabilgisayarla bağlantısı olan terminalleri vardı, ancak öğrencilerin programlama görevlerini yerine getirmeleri için zorlu bir işlem olan kartları delmek zorunda kaldılar. Sonunda, öğrencilerin bir terminalde zaman içinde kaydolabilecekleri bir laboratuara yerleştirdiler, ancak yarım inç kalınlığındaki hataların çıktısını almanız hala yarım saat kadar sürdü. Tüm işlem çalışmaları ana bilgisayarda (sunucu) yapıldı.

Ancak ana bilgisayarlar pahalıydı, bu yüzden şirketler yerel alan ağları kurmaya başladılar ve işlem yükü sunucudan bireysel istemci makinelere kaydırıldı; bunlar tek tek kelime işlemeyi, e-tabloyu ve iş uygulamalarını yürütebilecek kadar güçlü, ancak bunu yapmak için yeterince güçlü değildi. işlem güçlerini başkalarıyla paylaşın. Sunucu, benzer özelliklere sahip (aynı zamanda daha fazla bellek ve sabit disk alanı) olan benzer bir makineydi, ancak çoğunlukla dosyaları paylaşmak için kullanılıyordu. Buna Müşteri / Sunucu adı verildi. İşlemlerin çoğu, istemci bilgisayarlara kaymıştı.

İstemci makinelerde tüm işlemlerin gerçekleştirilmesinin sakıncalarından biri, bu sürekli yazılım yükleme ve yükseltme döngüsüne ve bununla ilgili tüm sıkıntılara kilitlenmiş olmanızdı. Bu makinelerin programlama modeli (olaya dayalı, kodsuz kullanıcı arayüzleri), dağınık, bakımı zor programlar (büyük çamur topları) oluşturulmasını teşvik etti. Çoğu son kullanıcı, donanım ve yazılımlarını düzgün bir şekilde sürdürme becerisine sahip değildi, bu da BT bakım personelinin ordularını gerektiriyordu.

Bilgisayarlar gittikçe daha güçlü hale geldikçe, emek bölümleri mümkün hale geldi. Artık dosya sunucuları, veritabanı sunucuları, web sunucuları, yazdırma sunucuları vb. Olabilir. Her makine sağladığı görev için biraz optimize edilmiş ve gerekli uzmanlığa sahip biri tarafından bakımı yapılabilir. Web tarayıcısında çalışan programlar yazılabilir, böylece istemci kurulumları artık gerekli değildir. Buna Çok Katmanlı veya n Katmanlı denirdi. Tarayıcılar, temel anabilgisayar günlerinde olduğu gibi, aptal terminaller olarak kullanıldı; ancak, sunucuyla iletişim kurma yöntemi daha karmaşık, daha az özel ve zaman paylaşımı ve oylama yerine kesme mekanizmalarına dayanıyordu. İşlem sunuculara geri taşınmıştı.

Ancak, web geliştirme yepyeni bir baş ağrıları ile geldi. Tarayıcı için yazılan iş uygulamalarının çoğu statik formlar ve raporlardır. Kullanıcı arayüzünde çok az etkileşim vardı. Javascript henüz ikinci rüzgarını bulamamıştı ve yaygın uyumluluğunu engelleyen tarayıcı uyumsuzluklarında büyük sorunlar vardı. Ancak, işler çok daha iyi hale geldi. HTML5 ve CSS3, tarayıcı programlama modeline önemli ölçüde yeni yetenekler sunuyor, jQuery ortaya çıktı ve bir sürü programcının Javascript'in ne kadar yararlı olabileceğini keşfetmesine yardımcı oldu. Yeni ön uç UI çerçeveleri ortaya çıktı. Tarayıcıda yüksek etkileşimli kullanıcı arayüzleri yazmak mümkün oldu, hatta oyunlar tamamlandı. İşlem tekrar müşteriye geri döndü.

Bugün buluttaki işlem gücünü istediğiniz kadar satın alabilirsiniz, sunucudaki programları çalıştırabilirsiniz. Şimdi, bir yazılım geliştiricisi olarak, hem müşteride hem de sunucuda işlem gücünüzü nerede uygulayabileceğiniz konusunda pek çok seçeneğinizin olduğunu söyleyebilirim.

İki farklı konsepti karıştırıyor gibisin:

1. Sunum ve iş mantığını ayırma (MVC) => bakım kolaylığı
2. Bir düğüme yürütme atama => verimliliği artırın

Günlerde, İstemci / Sunucu bilişimi genellikle ilkleri ima etmekle karıştı, çünkü istemciler genellikle sunuculara kıyasla daha fazla işlem gücü sunmadılar. Bu nedenle "ağır" iş mantığı hesaplamasını (M) sunuculara taşımak doğal görünmekle birlikte, "hafif" görünüm işleme (V) 'yi müşterilere ulaştırmak doğaldı. Buna karşılık, ikisi arasında çeviri yapmak için bir çeşit hakem (C) uygulamak zorunda kaldınız.

Müşteriler artık kolay bir şekilde işlem süreci ile bir zamanlar bazı pahalı sunucu donanımlarının ima edildiğine, hatların iş mantığını nerede yürüteceğine karar verdi - istemci tarafı veya sunucu tarafı. Gerçekten, cevap sizin özel kullanım durumunuza ve takas seçiminize bağlıdır, örneğin:

• İstemci gecikmesine karşı karmaşıklık: sunucu tarafı işleme sistemleri daha basit tutar çünkü müşteriye herhangi bir kod dağıtılması / indirilmesi gerekmez, ancak hesaplama sırasında istemci tarafı gecikmesinin maliyeti de söz konusudur.

• karmaşıklık - sunucu yükü vs: istemci tarafında bilgi işlem sistem karmaşıklığını artırabilir ancak sunucu yükünü azaltmaya da yardımcı olabilir.

• merkezi uygulama vs merkezi olmayan uygulama esnekliği: mobil uygulama dünyasında, ağ bağlantısının kesilmesine rağmen müşterileri çalışır durumda tutmak önemli olabilir. Ancak, bu, iş mantığının birden fazla dağıtılmış versiyonunu yönetme pahasına gelir.

Bu, birçok işten çıkarmanın ayrıntılı bir listesidir.

Kullanıcılar her zaman aynı işlevselliği istediklerinden, masaüstü uygulamalarıyla sahip oldukları web uygulamalarıyla (yalnızca web siteleriyle değil) çanlar ve ıslık çalarlar. Tüm bunların tarayıcıda (aslında birden çok tarayıcıda) çalıştırılması, bir VB formunu küçük kodlu bir veritabanına bağlayabileceğiniz eski günlere benzemez. Sunucuya geri dönüş yapmanız gerekmediğinde bunu gerçekleştirmek daha kolaydır.

Java veya C # gibi programlama dillerini kullanan çoğu arka uç geliştirme, yalnızca REST benzeri bir arabirim üretmek ve görüntüleme, görselleştirme, veri girişi / çıkışı, kullanıcı etkileşimleri vb. Açısal, Omurga, Ember, Nakavt, vb gibi yan çerçeve ...

Belki arka uç programlama / servisler aynı eski şey gibi gözükse de, uygulamanın kalbi budur. Kodlama uygulamaları bu alanlarda daha verimli olabilir. Araçlar, diller, tarayıcılar ve çerçeveler hala gelişmektedir, bu nedenle UI / UX'in geliştirilmesi zordur. Eski ASP'nin sahip olmadığı yeni şeyler bunlar. Basit formlara ve html tablolarına sahip kullanıcı arayüzlerinden kurtulabilseydik, bu alanlarda da fazla ilgi / yutturmaca olmazdı, ancak kullanıcılar sürükle ve bırak, animasyonlar, geçişler, açılır pencereler vb.

Bugün, üzerinde bulunduğum çoğu projede, JavaScript çerçevelerinin ve müşteri tarafı gelişimin tüm heyecan verici ve yenilikçi ilerlemelerin yapıldığı yer olduğunu öğrendim.

Sunucudan müşteri tarafı gelişimine bu hareket neden gerçekleşti?

Burada aslında iki soru var:

1. Neden müşteri tarafında programlama, ilerlemenin gerçekleştiği yerde?
2. Uygulamalar neden sunucudan ziyade istemcide çalışmak üzere yazılmıştır?

İkisi aslında farklı.

Neden müşteri tarafında programlama, ilerlemenin gerçekleştiği yerde?

Çünkü çalışma zamanı, çevre ve ekosistem son üç yılda önemli ölçüde olgunlaştı ve bu, yenilikçilerin sömürmeyi beklediği yeni nişler açtı.

Ön uç geliştirme zordu . ECMAScript 3'ün kısıtlı özelliklerini kullanarak, kalın istemci uygulamaları oluşturmak için önceki tekniklere veya araçlara sahip olmayan bir ekosistemde tarayıcıları - her zaman düşmanca bir ortamı - programlamanız gerekiyordu. Modül yükleyici yoktu. Bağımlılıkları düzgün bir şekilde idare edemezsiniz. Astar araçlarının azlığı vardı. Altyapılar olgunlaşmamış ve ön uçların bu kötü sorunu çözebilecek yenilikçilere saygısızlığı vardı.

Bu faktörler adım adım değiştiğinden, zengin istemci uygulamalarını hızlı bir şekilde geliştirmek ve tutarlı bir şekilde çalıştırmak için kritik bir kitle yarattılar.

Sorunuza cevaben, o zaman, yeni ön teknoloji teknolojilerinin ilerlemeye ittiği ve darboğazları bıraktıkları ve müşterilerin kullanıcıların isteklerini yakalamalarına izin verdiği kadar değil.

Uygulamalar neden sunucudan ziyade istemcide çalışmak üzere yazılmıştır?

Çok fazla önemli neden var, ancak son yıllarda en belirgin olanı akıllı telefonların yükselişi.

Akıllı telefonlar orta derecede güçlü bilgisayarları ucuz, her yerde ve kullanışlı hale getiriyor. Gezegenin her yerindeki milyarlarca insana aittirler ve temel olarak gelişmekte olan ekonomilerin orta sınıflarına bilgi işlem getirmiştir. Ancak mobil ağlar, coğrafi, mühendislik ve politik Zor Sorunlar tarafından durgun, yamalı ve kısıtlıdır. Bu ortamda, uygulamaların yerel olarak yerel olarak depolanması ve isteksizce ve vatansız operasyonlarda verileri yukarı doğru yamalaması kaçınılmazdır.

Nasıl farklı olabilir? Akıllı telefonunuzun sadece aptal bir terminal olup olmadığını düşünün. Her devlet mutasyonunun asenkron ve yanılabilir olması gerekir. Her içerik yükü değerli kuruşlara mal olur. Beş dokuz çalışma süresi olan muazzam sunucu çiftliklerine yatırım yapmanız gerekecekti. Bilgi işlem maliyetleri doğrudan sizin tarafınızdan karşılanacaktır, bu nedenle ani bir popülerlik dalgası aslında işinizi zorlaştırabilir.

İstemci tarafı uygulamalar, bireysel kullanıcıya ait durumları hızlı ve eşzamanlı bir şekilde ele almanıza izin verir. Bilgisayar maliyetlerinizi kullanıcılarınıza indirmenize izin veriyorlar. Arıza süresi ve zayıf ağ bağlantısı ile kurtulmanıza izin verir. Sunucu kodunu o kadar aptal yaparlar ki, statik HTML ve JS dosyaları veya mobil uygulamalar için hazır yanıtlar gibi ağ altyapısında önbellekte saklanabilirler.

Çok geniş bir ifadeyle: Müşteri tarafı gelişimi, orta güçte kişisel bilgi işlemlerin düşük maliyetlerinden yararlanır ve yüksek güçte merkezi bilgi işlemin yüksek maliyetlerinden kaçınır.

Bazılarının zaten iyi cevapları olan birkaç soru sordunuz. Birkaçı henüz cevaplarını almadı:

Bilmek istediğim şudur, neden böyle bir geçiş yaptık (sunucu tarafı programlamanın vurgusundan müşteri tarafına ... tüm bunların hepsi aynı anda olmuş gibi görünüyor) ve bu geçiş / kaymanın hangi sorunları çözdü?

Robert Harvey mükemmel bir cevap verdi.

... derlenmiş dilleri tercih etmekten, betik dillerine,

Scripting dilleri , derlenmiş dillere göre ( ayrıca ) birçok avantaj sunar , örneğin:

• öğrenmesi ve kullanması daha kolay
• derleme süresini ortadan kaldırın (daha hızlı gelişme)
• daha fazla özellik sağlamak (üst seviye uygulama kontrolü)
• çalışan kodda hızlı değişikliklere izin ver
• vb.

... zorunluluktan işlevsel programlamaya,

İşte size iyi bir karşılaştırma, ancak dağıtılmış yazılımda (cloud computing'de düşünün), durum değişikliklerini yönetmenin (birçok düğümde senkronizasyon) çok büyük bir sorun olabileceğini söyleyerek özetlerim. İşlevsel programlamada, durum değişiklikleriyle başa çıkma ihtiyacı çok daha düşüktür.