Arka uçtan ön uca geçiş: bir çerçeve nasıl seçilir?
Yazar Mike Taylor
Çevirmen Xue Ming Deng
Tek Sayfalı Uygulamalar için Eşzamansız JavaScript (SPA), Web uygulamalarının kullanıcı deneyimini iyileştirmek için mükemmel bir fırsat sağlar. CSS çerçeveleri (Bootstrap gibi), geliştiricilerin yapı ve davranışla uğraşırken hızlı bir şekilde stiller sağlamasına olanak tanır.
Ne yazık ki, SPA ve CSS çerçeveleri tarafından sağlanan çözümler nispeten karmaşıktır.Geleneksel olarak ayrılmış endişeler (HTML yapısı, CSS stili ve JS davranışı gibi) doğal olarak birbirine karıştırılır ve bu, önceki nesiller tarafından öğrenilen derslere ters düşer. .
Bu endişeler karışımı, giriş seviyesi geliştiricilerin ve değerli uzmanların (görsel tasarım, erişilebilirlik, arama motoru optimizasyonu ve uluslararasılaştırma gibi) projeye anlamlı katkılar yapmasını engelleyebilir.
Tüm bu sorunların üstesinden gelebilecek birkaç geliştiricinin artan maliyetlerine ek olarak, dava açma, sıfır büyüme, dönememe, kaçırılan fırsatlar, işe alma ve personel sorunları gibi diğer gerçek dünya işlerini de etkileyebilir.
Sürdürülebilirlik sorunları ortaya çıktığında, görünüşte ihtiyatlı bir teknik karar da uzun vadeli maliyetlere yol açabilir.
Bu eğilimin altında yatan neden, geleneksel arka uç geliştiricilerin ön uca dönüşümünün, Web uygulamalarının sunucu tarafından istemci tarafına dönüşümü ile çakışmasıdır. Kendi eksikliklerini telafi etmek için, bu yeni katılımcılar kendi ihtiyaçlarını karşılayan, ancak tüm organizasyonu dikkate almayan araçlar ve uygulamalar geliştirdiler.
Yalnızca CSS çerçevesi tarafından sağlanan ön değere ihtiyacınız varsa, bunları doğrudan uygulamaya eklememeniz önerilir. Bunun yerine, belirli iş dilleri için tasarlanmış dahili CSS çerçevelerinin dekoratörleri olarak kullanılabilirler.
SPA çerçevesi açısından, endişelerin ayrılmasını zorlayan kodlama uygulamalarının benimsenmesi tavsiye edilir. Bu hedefe React ile ulaşılabilir, ancak Vue.js, geleneksel ön uç geliştiricilerle daha iyi işbirliği yapmak için daha iyi bir yol sağlar.
başlangıç
2014 yılında British Columbia Institute of Technology'nin (BCIT) web tasarım bölümüne girdim. Çalışmalarımı bitirdikten sonra, okul benden çevrimiçi öğrenme kurslarında onlara yardım etmem istendi. Twitter'ın CSS çerçevesi olan Bootstrap'i kullanabileceğimi söylediklerinde çok heyecanlandım ...
Ancak bu heyecan kısa sürede ortadan kalktı. Kullandıktan sonra yardım edemem ama neden kullanmamız gerektiğini merak ediyorum. Zımni sınıf adı ve < div > Etiketlerin ücretsiz kullanımı tüm mantığı HTML'ye sıkıştırıyor gibi görünüyor. Kısa süre sonra, diğer işlevsel gruplar yeni genel masraflarla başa çıkmakta zorlanırken, şikayetler görünmeye başladı.
Ekibimiz tarafından üretilen çevrimiçi kurslar, sonunda işletme, medya, hemşirelik ve mimarlık gibi teknik olmayan eğitmenlere verilecektir. Çözemezlerse, Ed-Tech Desteği ararlar. Ed-Tech sorunu çözemezse, bu işler elimize dönecektir.
Bu felaket bir durum çünkü personelimiz yetersiz. Öğretmenler çok gergindi, desteğe ihtiyaç duyan sorunlar yığıldı ve ekibimiz öğrencilerin dersi geçmesi için bir darboğaz haline geldi.
Bu çerçevelerin kullanım kolaylığı vaadi bizi cezbediyor, ancak bu vaatlerin çoğunun yüzeyde kaldığı ortaya çıktı. Bootstrap, çok fazla geri dönüş almadan çok çaba sarf etmemize neden oldu. Kılık değiştirmiş bir bakım tuzağına düştük.
Birkaç ay süren mücadelenin ardından ekip, minimalizme dayalı özel bir çerçeve oluşturmaya (daha doğrusu HTML'nin tüm karmaşıklığını ortadan kaldırmaya) koyuldu. Çevrimiçi öğrenme terminolojisini kullanarak süper temiz kod oluşturmak için bir çözüm.
Bugün (ve benim) küçük bir siyasi bombardımana hala dayanmak zorunda kalmamıza rağmen popüler bir ürün elde ettik. Bakım sorunlarını tamamen ortadan kaldırmanın yanı sıra, tüm çevrimiçi kursun kalitesini ve verimliliğini de artırır.
En önemlisi, ekibimiz artık bir darboğaz değil.
O zamandan beri, ön uç araçlar ve bunların yaygınlaşması konusunda daha dikkatli hale geldim. Benim endişem, bu araçların tüm kuruluşun yararına değil uygulayıcılarının yararına kullanılmasıdır. Düşünmeden edemiyorum:
Pek çok modern ön uç araç ve uygulama sadece teknik borçları gizlemekte mi?
Tarih
Eşzamansız JavaScript
2005 yılında Google, dünyayı şok eden Google Haritalar'ı başlattı. Ekranı sürüklediğinizde döşemeler birer birer görünecektir.
Çoğu kişi için bu AJAX'ın gücüne dair ilk deneyimleri. Bu, istemci uygulamalarının çok iyi bir kullanıcı deneyimi sağlama potansiyeline sahip olduğunu kanıtlayan bir "katil uygulama" dır. Bu, modern tek sayfalık uygulamamıza (SPA) doğru atılan önemli bir adımdır.
CSS çerçevesi
2011'de Twitter, geliştirme tarzlarına katılmamızı sağlamak için Bootstrap'i kullandı.
Bootstrap, yaygın olarak benimsenen ilk CSS çerçevesidir ve ön uç geliştirme için eşiği düşürür. Birdenbire, sunucu tarafı sayfa şablonları geliştiren arka uç geliştiriciler öğelere doğrudan sınıflar ekleyebilir; CSS gerekmez. Elde ettikleri yetenekler, geleneksel ön uç geliştiricilerinkilerle karşılaştırılabilir veya hatta onları aşar.
semptom
div
Günümüzde, CSS çerçeveleri hemen hemen her yerdedir. Bootstrap üstünlüğünü korumuş gibi görünüyor. Ek olarak, Tailwinds gibi bir araya getirilebilir çerçeve desteği de artıyor.
SPA çerçevesi, CSS çerçevesinden daha kararsızdır. Backbone, Knockout ve Ember, Google Angular ortaya çıkana kadar en yüksek pozisyonda kaldı. Diğer çerçeveler geldi ve geçti ve hiçbiri gerçekten değerde bir sıçrama sağlayamaz, ancak hepsi "JavaScript yorgunluğuna" yol açar.
Daha sonra Facebook, bir araya getirilebilir bileşenler ve hızlı sanal DOM fikrine dayanan bir çerçeve olan React'i başlattı; bu, motorlar ve boyayla Lego tuğlaları inşa etmeye benzer.
Geliştirici araçlarını açmadan önce her şey yolunda. Açtıktan sonra, bir grup kaotik "div" göreceksiniz.
Endişelerin karışımı
HTML etiketlerine 6 veya 7 gizli sınıf eklemek "styling" olarak tanımlanırken, büyük bir geri adım attığımızı düşünüyorum. Tablo düzeninin ötesine geçtik, ancak yalnızca satır içi stilden daha iyi.
Geliştiricilerin artık CSS'yi doğrudan HTML'nin stil özniteliğine eklemesi önerilir. Sorunları daha da kötüleştirmek için, bu etiketler artık üçlü ifadeler ve eşleme işlevleriyle doludur ve geliştiricileri HTML ile JavaScript arasında geçiş yapmaya zorlar.
Son birkaç yılda Web geliştirmeye katılanlar için bu çok sıra dışı.
sorun
Zor Ninja
2014 yılında, ön uç geliştiricilerin maliyeti, arka uç geliştiricilere göre önemli ölçüde daha düşüktü. Bugün, beş yıl sonra, ön uç geliştirme tam yığın haline geldi.
İş tanımındaki temel becerilerin listesinin katlanarak büyüdüğünü fark etmiş olabilirsiniz. Mükemmel çalışanlarınız kaçak avlanır ve istediğiniz adaylar daha yüksek maaşlı, daha iyi yan haklar ve daha esnek çalışma düzenlemeleri olan diğer şirketler tarafından çekilir.
Ama beni yanlış anlamayın, bu küçük bir grup insan için iyi bir şey, ancak küçük ve orta ölçekli bir işletmeyi (SMB) yürütmek isteyenler için yıkıcı olabilir.
Başarı stratejiniz yıldızları işe alma, eğitme ve elde tutma becerinize bağlı olduğunda, kendinizi dönerken bulabilirsiniz.
Uzmanlık eksikliği
Ninjalar aslında mevcut değil. Her şey iyidir, her şeyde iyi değildir. Çok yönlü bir kişi olarak, her konuda uzman olamayacağınızı biliyorum. Genelcilerin işinizde bir yeri olsa da, tek başlarına çalışmalarına izin verilmemelidir.
Takımdaki her geliştirici bir "JavaScript ninja" ise, aslında kendinizi bir kör noktaya maruz bırakıyorsunuz demektir. Hiç şüphe yok ki uygulamaların aşağıdaki gibi şeylerle dolu olacağına < div className = "btn" onClick = {this.handleClick} > Ne kadar trajik bir örnek.
Şöyle diyebilirsiniz: "Çalıştığı sürece kimin umrunda." Sağlam insanlar için sorun olmayabilir, ancak yardımcı teknolojiye güvenenler bazı uygulamalarınıza hiçbir şekilde erişemeyecektir.
Ahlaki açıdan mecbur değilseniz, parayla yönlendirilebilirsiniz. Erişilebilirlikteki ihmalin (A11Y), iş fırsatlarını kaybetme veya dava tehdidi açısından aslında büyük bir ekonomik riski temsil ettiği gerçeğini ciddiye almanız gerekir.
Ayrıca, uygulamayı çalıştırılabilir hale getirme isteği nedeniyle JavaScript uzmanları, arama motoru optimizasyonunu (SEO) görmezden gelebilir. Bu çok fazla zarara neden olabilir, çünkü paranın sürekli yakılması her şey için ölümcül olabilir. Ürün çekici değilse ürünün kalitesi yararsızdır.
Çeviklik kaybı
Bootstrap ve React gibi çerçeveler, inanılmaz bir ön hız sağladıkları için çekicidir. Bootstrap genellikle mükemmel bir prototip oluşturma aracı olarak kabul edilir. Ancak prototip oluşturma araçları, doğası gereği düşük maliyetli, düşük kaliteli ürünler getirme yeteneğine sahiptir.
"Bootstrap" kelimesi bile sınırlı kaynakların kullanımıyla eşanlamlı hale geldi. "İyi-hızlı-ucuz" modelinde, bu kararların bilinçli olup olmadığına bakılmaksızın hızlı ve ucuz seçersiniz. Başka bir deyişle, teknik borç dolu bir ürüne yatırım yapmayı seçersiniz.
Ne dediğime inanmıyor musun? Stilinizin modası geçmeye başladığında geleceği düşünün. Yeni rekabet daha çekici bir kullanıcı deneyimi getirdi, oyununuzu yükseltme zamanı, aksi takdirde konumunuzu kaybedersiniz.
Bootstrap'in sonsuz değişkenler listesini yeniden markalamaya ve düzenlemeye başlıyorsunuz. Bir süre sonra, istediğiniz değişikliklerin ancak tüm geliştiriciler döndürüldükten sonra tutarlı olabileceği ortaya çıkıyor.
Ek olarak, gerçekten istediğiniz derin özelleştirme, Bootstrap'in seçicilerin ücretsiz kullanımını kapsayacak şekilde karmaşık CSS özellikleri oluşturmayı içerir.
Düzeni değiştirmek istiyorsunuz, ancak her bileşenin col sınıfı kullanılarak sabit kodlandığını bulun. Ne yazık ki, her öğe farklı ekran çözünürlüklerine sahip alan için rekabet ediyor. Bir değişiklik, değişiklik yapmak için beş veya daha fazla yer gerektirir.
Her değişikliğin okunamayan yapı, stil ve davranış kodunun derinliklerine inmesi gerekmedikçe bu o kadar da kötü değil.Bu kodlar render fonksiyonundadır ve bu fonksiyonlar sadece her bileşen dosyasının sonunda bulunabilir ...
Birkaç ay sonra 10 kilo kahve içtikten sonra tekrar yarışmaya hazırsınız (ama bu doğru değil) ...
Hedefiniz kısa vadeli bir satın alma ise, umursamayabilirsiniz. Ancak unutmayın, teknolojinin esnekliği ve çevikliği güçtür. Ürünün uzun vadeli vizyonu yavaşça eğilen bir makine ise, müzakere masasında kendinizi bir dezavantajda bulabilirsiniz.
Sorunun etkisi
Artan işgücü maliyetleri, dava riskleri, kaçırılan iş fırsatları, sınırlı müşteri edinimi ve durumu hızlı bir şekilde kontrol edememe arasında, görünüşte önemsiz ve hatta akıllıca teknolojik kararlar, aniden gerçek dünya işlerini etkiledi.
Belirli türden uygulamalarla uğraşan bazı şirketler için, tartıştığım her şey tamamen kontrol altında. Ancak, diğer türden uygulamalar üzerinde çalışan diğer şirketler, körü körüne uzun vadeli taahhüt ve yüksek bakım kabusuna düşebilir.
Unutmayın, yazılım geliştirmeye kıyasla zamanının çoğunu bakım için harcayacaktır. Hızlı bir arama sonucunda, bakım maliyeti tahsisi ile ilgili aşağıdaki temel kuralları buldum:
- Yıllık bakım = ilk harcamaların% 15-20'si;
- Ömür boyu bakım = toplam harcamaların% 40-80'i (ortalama% 60).
Aşağıdaki 10 yıllık bir maliyet yatırım durumu, ilk yatırım 100 ABD doları ve yıllık bakım ücreti% 20'dir:
Gördüğünüz gibi, bakım maliyeti sadece 5 yılda geliştirme aşamasını aştı. 7. ve 8. yıllar arasında% 60 toplam maliyet eşiği aşıldı.
Tabii ki, bu sadece basitleştirilmiş bir maliyet örneğidir. En olası senaryo, bir uygulamanın tüm yaşam döngüsü boyunca, proje ne kadar büyükse, sürdürmenin o kadar zor olmasıdır. Uzun vadede, kısa vadeli hedefler, uzun vadeli sonuçlara yol açabilir ve bunlar yalnızca zamanla karmaşık hale gelir.
Ayrıca bu sürdürülemez projeleri bu kurallardan nasıl hariç tutacağımı da bilmek istiyorum, çünkü bakım maliyeti o kadar yükseldi ki proje başarısızlıkla sonuçlandı ve terk edildi ...
ana neden
Sunucu taraflı uygulamalardan istemci tarafındaki uygulamalara geçişin çok sayıda yetenekli geliştiriciyi arka uçtan ön uca çektiğine inanıyorum. Farklı güçlü ve zayıf yönler nedeniyle, bu programcılar ön uç geliştirme yöntemini değiştirmeye başladı.
Elbette, bu sadece bir hipotez, ancak aşağıdaki çizelgenin bir kısır döngü içinde olduğumuzu açıklamaya yardımcı olduğunu düşünüyorum:
Şekilde tırnak işareti kullanıldığını fark etmiş olabilirsiniz, bunun bir nedeni var. "Son derece yetenekli", yalnızca diğer geliştiricilerin ön uç araçları sunma becerileriyle, "Karmaşıklık" çözülmekte olan soruna ve "Düşük vasıflı" ise şu anda üretim ortamında kullanılan araçların karmaşıklığıyla ilişkilidir. Açısından.
Makul bir şekilde, "Son derece yetenekli" geliştiricilerin, tüm kuruluşun yeteneklerini geliştirmek yerine, ön uçtaki eksikliklerini telafi edecek araçlar sunduğunu varsayabiliriz. Örneğin, CSS çerçevesini kullanmaktan en çok yararlanan kişiler, CSS'yi sürdürme konusunda en az yeteneğe sahip kişilerdir.
Bootstrap destekçilerinden sık sık duyduğum bir söz "Güzel bir prototip oluşturmak ne kadar kolay" dır. Benzer şekilde, React'in destekçileri şöyle diyecekler: "JavaScript'i asla bırakmayın, bu duyguyu seviyorum."
Kuruluşunuzda bu durumlar yaygınsa, teknoloji yığınınız daha çok ön uçta çalışan geleneksel arka uç geliştiricilerin ihtiyaçları için tasarlanmış olabilir.
Altyapı çözümleri hakkında hararetli bir tartışmaya şahit oldum, bunlardan biri şuna işaret ediyor:
"Önemsiz görevleri kolaylaştırmak, ancak basit görevleri daha da zorlaştırmak için."
Ekibimizin sorunu çözmek için Bootstrap ve diğer alternatifleri kullanmaya çalıştığını görünce bunun gerekli olduğunu düşünmedim. Bana göre önemsiz sorunları önlemek için beceriksiz çözümler kullanmaya çalışıyorlar. Bu araçların savunucularına, ciddi zorluklara çözümler sunuyor gibi görünüyorlar.
çözüm
CSS çerçevesi
Bootstrap gibi çerçevelere bağımlılığı azaltmak için benim önerim çerçeveye özgü sınıfları doğrudan HTML'ye uygulamayı durdurmaktır. Bunun yerine, aşağıdaki uygulamaları teşvik ediyorum:
% our-uyarı-button { @extend .btn; @extend .btn-uyarı; } .empty-shopping-cart-button { @extend% bizim-uyarı-butonu; }Bu yaklaşım, uygulamayı, dahili CSS çerçevesi için bir "dekoratör" olarak görülebilen CSS çerçevesinden ayırmaya yardımcı olur. Artık ön hızdan ödün vermeden çerçeveleri kolayca değiştirebilir, stilleri geçersiz kılabilir ve hatta kendi kodunuzu yayınlayabilirsiniz.
Stilleri merkezileştirme yeteneği, UI tasarımcılarının CSS'yi bileşenler labirentinde sıkışıp kalmadan işleyebileceği anlamına gelir. Alana özgü bir dil kullanarak, teknik olmayan ekip üyeleri ve kuruluş genelindeki paydaşlarla daha iyi iletişim kurabilirsiniz.
Son olarak (ve en önemlisi), yapı ve stil arasında bir kaygı ayrılığına sahipsiniz.
SPA çerçevesi
Bu tartışmalı olabilir ve uzun vadeli inanılmaz bir aldatmaca gibi görünebilir, ancak aşağıdaki nedenlerden dolayı React'ten Vue.js'ye geçmenizi öneririm:
< şablon > < ! - Yapı-- > < / şablon > < senaryo > < ! - Davranış-- > < /senaryo > < stil > < ! - Stil-- > < / stil >Burada gördüğünüz şey, endişelerin ayrılmasını teşvik eden Vue'nun "tek dosya bileşeni" dir. Vue'yu (ve sadelik vaadini) gerçekten seviyorum.
Bence Vue kullanmanın çok güçlü bir ticari nedeni var çünkü JavaScript olmayan geliştiricilerin katkıda bulunmaya katılmalarının önündeki engelleri azaltıyor. Profesyonel becerilerin değerine ek olarak, ninjalar diğer alanlardaki uzmanlıklarını da açığa çıkaracaklar.
Beni yanlış anlamayın, Vue, React ve diğer çerçevelerin tüm özelliklerine sahiptir. Çok esnektir ve istediğiniz herhangi bir projeyi oluşturmanıza olanak tanır. Benzer şekilde, React'in uygulamasında ustalaşmak daha kolaydır (Vue'dan çok daha az olsa da).
Genel olarak benim tavsiyem, endişelerin ayrılmasını zorlayan kodlama uygulamalarını kullanmaktır. Basit bir kurallar dizisi halinde basitleştirilmiştir:
Yukarıda bahsedildiği gibi, kod tabanının akıllı ve akıllı olmayan bileşenlere bölünmesiyle birleştiğinde, HTML'de yeterli mantık ve stil özgürlüğünü korumak mümkün olmalıdır. Bazı kısayolları ortadan kaldırabilir, ancak uzun vadeli sürdürülebilirlik avantajları, ön maliyetleri telafi edebilir.
Orijinal İngilizce:
https://hackernoon.com/the-backendification-of-frontend-development-62f218a773d4
