Ön Uç Çerçeveler: Çözümler mi, Şişirilmiş Sorunlar mı?

Modern ön uç çerçeveler, bağımlılıklarla tamamlanmış bir geliştirme ortamı indirmenizi ve kodunuzu tarayıcınızda görüntülemeye çalışmadan önce derlemenizi gerektirir. Bu iyi bir şey mi? Sorun, daha karmaşık siteler inşa etmemiz mi, yoksa çerçevelerin kendi başlarına karmaşık olması ve gereksiz bir karmaşıklık düzeyi getirmesi mi?

Günümüzde web geliştirme, 90'lardan bu yana çok gelişti; herhangi bir yerel uygulamanın yapabileceğine çok yakın deneyimler yaratabiliyoruz ve geliştirme süreci de değişti. Ön uç web geliştiricisi olmanın, Not Defteri'ni açmak, birkaç satır kod yazmak, tarayıcıda kontrol etmek ve bir FTP klasörüne yüklemek meselesi olduğu günler geride kaldı.

Geçmişin Ön Uç Web Geliştirmesi

Bariz olanı belirterek başlamalıyım: Dünya 10 yıl önceki gibi değil. (Şok edici, biliyorum.) Değişmeyen tek şey değişimdir. O zamanlar çok az tarayıcımız vardı, ancak çok fazla uyumluluk sorunu vardı. Bugün, "en iyi Chrome 43.4.1'de görüntülendi" gibi şeyleri pek görmüyorsunuz, ancak o zamanlar oldukça yaygındı. Artık daha fazla tarayıcımız var, ancak daha az uyumluluk sorunu var. Niye ya? jQuery'den dolayı. jQuery, her tarayıcıda ve her tarayıcının her sürümünde nasıl çalışacağı konusunda endişelenmenize gerek kalmadan DOM'yi yöneten JavaScript kodu yazmanıza izin veren standart, ortak bir kitaplığa sahip olma ihtiyacını karşıladı - 2000'lerde gerçek bir kabus .

Modern tarayıcılar standart olarak DOM'yi değiştirebilir, bu nedenle böyle bir kitaplığa olan ihtiyaç son yıllarda büyük ölçüde azaldı. jQuery artık gerekli değil, ancak yine de ona bağlı çok sayıda son derece kullanışlı eklenti bulabiliriz. Başka bir deyişle, web çerçeveleri gerekli olmayabilir, ancak yine de popüler olacak ve yaygın olarak kullanılacak kadar faydalıdırlar. Bu, React, Angular, Vue ve Ember'den Bootstrap gibi stil ve biçimlendirme modellerine kadar popüler web çerçevelerinin çoğunda ortak olan bir özelliktir.

İnsanlar Neden Çerçeveleri Kullanıyor?

Hayatta olduğu gibi web geliştirmede de hızlı bir çözüme sahip olmak her zaman kullanışlıdır. JavaScript'te daha önce hiç yönlendirici yaptınız mı? Sorunun üstesinden gelmek için bir ön uç çerçeveyi npm-kurabiliyorken neden acı verici bir öğrenme sürecinden geçiyorsunuz? Müşteri işlerin dün yapılmasını istediğinde veya belirli bir çerçeve için tasarlanmış başka bir geliştiriciden kod devraldığınızda veya zaten belirli bir çerçeveyi kullanan bir ekiple entegre oluyorsanız zaman bir lükstür. Kabul edelim - çerçevelerin bir nedeni var. Faydaları olmasaydı, kimse onları kullanmazdı.

Peki, bir web geliştirme çerçevesi kullanmanın bazı faydaları ve benzersiz özellikleri nelerdir?

Vakit nakittir. Bir proje geliştirirken ve müşteri hangi çerçeveyi kullandığınızı umursamıyor -aslında muhtemelen ne kullandığınızın farkında bile değil- sadece sonuç almakla ilgileniyorlar ve ne kadar hızlı olursa o kadar iyi. Yerleşik çerçeveler, müşterinin 1. günden itibaren can attığı, en başından itibaren anında bir ilerleme hissi yaratmanıza izin verir. Ek olarak, ne kadar hızlı geliştirirseniz, o kadar çok para kazanırsınız, çünkü çerçeve tarafından serbest bırakılan zaman daha fazlasını üstlenmeye yönlendirilebilir. projeler.

Her şey toplumla ilgili. Bir çerçeve seçerken bu çok önemli bir noktadır—bir soruna takıldığında size kim yardım edecek? İkimiz de bunun bir noktada olacağını biliyoruz. Çerçevenin amaçlamadığı veya çerçevenin asla size erişim sağlamak için tasarlanmadığı bir şeyi yapmanız gereken bir noktaya ulaşacaksınız, bu nedenle sizi destekleyen bir topluluğa sahip olmak çok önemlidir. Geliştirme, özellikle de serbest çalışma, sanal bir dünyaya dalmış olduğunuz için zor olabilir ve bir ekipteki tek ön uç web geliştiricisiyseniz, bu, bir web sitesi bulmak için deneyim ve uzmanlığa sahip tek kişi olduğunuz anlamına gelir. çözüm. Ancak kullandığınız ön uç çerçeve sağlam bir desteğe sahipse, dünyanın diğer tarafında aynı sorunla karşılaşan ve size yardımcı olabilecek biri olacaktır.

Standartlar güzeldir. Kendi kodunuzun eski bir parçasına baktığınızda, kolayca gezinebildiğinizi hiç fark ettiniz mi? Ya da en azından, başkası tarafından yazılmış bir kod parçasından daha kolay mı? Belirli bir şekilde düşünürsünüz ve şeyleri adlandırmak ve kodu düzenlemek için kendi yolunuz vardır. Bu bir standart. Sadece kendimiz için olsalar bile hepimiz onları takip ederiz. Kahvaltıda benzer şeyler yemeye, belirli bir saatte uyanmaya ve her gün anahtarlarımızı aynı yere koymaya meyilliyiz. Ve gerçekten de, eğer rutinlerimizi her gün değiştirirsek, bir şeyleri nasıl yapacağımızı bulmak gibi bir yük yüzünden hayat çok daha zor olurdu. Hiç anahtarlarınızı normalden farklı bir yere koyduğunuz için kaybettiniz mi? Standartlar hayatı kolaylaştırır. Bir ekibin veya geliştiriciler topluluğunun bir parçası olarak çalışırken kesinlikle vazgeçilmez hale gelirler.

Çerçeveler, onları kurduğunuz andan itibaren bir standart sağlar ve sizi belirli bir şekilde düşünmeye ve kodlamaya yönlendirir. Ekibinizle bir standart oluşturmak için zaman harcamanıza gerek yok; çerçevede işlerin nasıl yapıldığını takip edebilirsiniz. Bu, birlikte çalışmayı kolaylaştırır. Bir SPA'ya bir rota eklemek için oluşturulduğundan ve çerçevenizde, tüm rotalar bu ada sahip bir dosyaya yerleştirildiğinden, işlevin belirli bir dosyada olması gerektiğini bildiğinizde bir işlev aramak daha kolaydır. Bu düzeyde bir standardizasyona sahipseniz, farklı beceri düzeylerine sahip kişiler birlikte çalışabilir, çünkü ileri düzey kodlayıcılar işlerin neden bu şekilde yapıldığını bilirken, genç geliştiriciler bile standardın kendisini takip edebilir.

Çerçeveler Başarısız Olduğunda

Birkaç yıl önce, “Çerçeve kullanmıyorum - onlardan gerçek bir fayda görmüyorum” gibi bir şey söylemek, el feneri ve yabalı insanları kapınıza getirirdi. Ancak bugün giderek daha fazla insan kendilerine şunu soruyor: "Neden bir çerçeve kullanmalıyım? Onlara gerçekten ihtiyacım var mı? Onlarsız kodlama yapmak bu kadar zor mu?”

Ben kesinlikle onlardan biriyim - hiçbir zaman belirli bir çerçevenin hayranı olmadım ve tüm kariyerim boyunca onlarsız kodlama yaptım. Bu konuda bir seçeneğim varsa, seçimim her zaman "Hayır, teşekkürler" olur. Yıllardır JavaScript'te ve ondan önce ActionScript'te geliştiriyorum. Çoğu insan zaten ölü olduğunu düşündüğünde Flash'ta kod yazıyordum. (Biliyorum, biliyorum… ama çok fazla animasyon yapıyordum ve düz HTML'de animasyon yapmak zor.) Öyleyse, çerçeveler olmadan kodlamayı hiç düşünmeyenlerdenseniz, size bunun neden olabileceğine dair bazı nedenler göstereyim. mücadele etmek.

"Tek beden herkese uyar" bir yalandır. Kariyerinizde başardığınız her şeyi yapabilen tek bir yazılım parçası yazmayı hayal edebiliyor musunuz? Bu, web geliştirme çerçeveleriyle ilgili ana sorunlardan biridir. Projenizin, çerçevenin kapsamını genişletmek için kitaplıklar, eklentiler veya eklentiler ekleyerek çözme eğiliminde olduğumuz çok özel ihtiyaçları var. Hiçbir çerçeve ihtiyacınız olanın %100'ünü sunmaz ve hiçbir çerçeve %100 yararlı bulacağınız şeylerden oluşmaz.

Kullanmadığınız çok fazla kod olması, siteniz için yükleme gecikmesine neden olabilir ve bu, her ek kullanıcıyla daha da önemli hale gelir. Diğer bir konu da, “herkese uyan tek beden” zihniyetinin verimsiz kodla sonuçlanmasıdır. Örneğin, $('sku-product').html('SKU 909090'); , sonunda hepimizin bildiği, document.getElementById('sku-product').innerHTML = 'SKU 909090'; .

Tek bir satırdaki bu tür bir fark önemsiz görünebilir, ancak sayfanın belirli bir öğesinin içeriğini değiştirmek tam olarak React'in erdemidir. Şimdi, React, DOM'nin bir temsilini oluşturma ve oluşturmaya çalıştığınız şeydeki farklılıkları analiz etme sürecinden geçiyor. Değiştirmek istediğiniz içeriği en baştan hedeflemek daha kolay olmaz mıydı?

Üzerinden geçtiğin o yabani ot yığını dikenler çıkarıyor. İhtiyacınız olan kitaplık sürümünün kullandığınız çerçeve sürümüyle iyi çalışmadığını anlamak için çerçevenizi kullandığınız ve ona bir kitaplık eklemeye çalıştığınız bir durumda bulundunuz mu? Bazen iki kod parçasının birlikte çalışmasını sağlamak, kodu kendi başınıza yazmaktan daha fazla çaba gerektirir. Ve kullandığınız çerçeveler ve kitaplıklar genellikle tahmin bile edemeyeceğiniz gizli uyumsuzluklara sahip olabilecek diğer çerçeveler ve kitaplıklar üzerine kurulduğundan, sorun katlanarak daha karmaşık hale gelebilir ve projenin büyümeye devam etmesini istiyorum.

Jones'lara ayak uydurmak bir şeydir. Hiç AngularJS'de sadece Angular 4 piyasaya çıkana kadar görünmeyen bir şeye ihtiyacınız olduğunu öğrenmek için bir proje üzerinde çalıştınız mı? Angular 5'in piyasaya çıktığını biliyor muydunuz? Bu başka bir büyük sorundur; Tek bir ön uç çerçeveye bağlı kalsanız bile, yeni bir ana sürüm olduğunda, işler o kadar çok değişebilir ki, yapmak için çok çalıştığınız kod yeni sürümde bile çalışmaz. Bu, birçok dosyada yapılması gereken can sıkıcı küçük değişikliklerden kodunuzun tamamen yeniden yazılmasına kadar her şeye neden olabilir.

Bir çerçevenin en son yapılarına ayak uydurmak zordur, ancak aynı notta, güncellemeler tamamen durduğunda ve teknolojinin geri kalanına ayak uyduramadıklarında diğer çerçeveler zarar görür. 2010 yılında, hem AngularJS hem de Backbone ilk kez piyasaya sürüldü. Bugün, Angular beşinci ana versiyonunda ve Backbone tamamen spot ışığın dışında. Yedi yıl uzun bir süre gibi görünüyor. Web siteleri oluşturursanız, muhtemelen estetik ve işlev açısından tamamen değişmişlerdir. Bir uygulama oluşturuyorsanız, yanlış çerçeve üzerine bahse girmek, şirketi daha sonra işlerin yeniden yazılması gerektiğinde zorlu ve pahalı bir duruma sokabilir.

Sahip olduğun tek şey bir çekiç olduğunda, her şey bir çivi gibi görünür. Web geliştirme çerçevelerini sık sık kullandıysanız, bu muhtemelen sizin de başınıza geldi, burada tek bir kod tabanı, gelecekte kullanacağınız kodun şeklini, yalnızca çevresel olarak ilişkili olsa bile tanımlıyor. Diyelim ki YouTube gibi bir platform kuracaksınız ve Framework X kullanmak istiyorsunuz. Bu gün ve çağda kulağa saçma gelse bile, videolar için Flash kullanmaya karar verdiğiniz bir nokta olabilir çünkü gelen bu. çerçeve ile inşa edilmiştir.

Çerçevelerin fikirleri vardır ve güçlüdürler; Örneğin React, sizi JSX'i belirli bir şekilde kullanmaya zorlar. Kodun her yerde bu şekilde kullanıldığını görebilirsiniz. Bir alternatif var mı? Evet. Ama kim kullanıyor? Bu her zaman kötü bir şey değildir, ancak karmaşık animasyonlar gerçekleştirmeniz gerekiyorsa, React'in tamamına değil, yalnızca animasyon için bir çerçeveye ihtiyacınız olabilir. İnsanların, yalnızca bir öğeye düğüm eklemek için bir sayfaya jQuery eklemek gibi çılgınca şeyler yaptığını gördüm; bu, Vanilla JS'de document.getElementById('id_of_node').appendChild(node); ile gerçekleştirilebilir. .

Değerlendirme Kötüdür, ancak .innerHTML Makyavelisttir

Bu noktayı ayrı ayrı incelemek için zaman ayırmak istiyorum çünkü bence bu, daha fazla insanın çerçeveler olmadan kodlama yapmamasının nedenlerinden biri. DOM'a bir şey eklemeye çalışırken çoğu kodun nasıl çalıştığını gördüğünüzde, .innerHTML özelliği tarafından enjekte edilmiş bir grup HTML bulacaksınız. Hepimiz değerlendirmenin JavaScript kodunu çalıştırmak için kötü olduğu konusunda hemfikiriz, ancak burada eval ön plana .innerHTML istiyorum. HTML kodunu düz bir dize olarak eklediğinizde, oluşturduğunuz düğümlerden herhangi birine yapmış olabileceğiniz tüm referansları kaybedersiniz. getElementsByClassName kullanarak veya onlara bir id atayarak onları geri alabileceğiniz doğrudur, ancak bu pratik olmaktan daha azdır. Düğümlerden birinin değerini değiştirmeye çalışırken, kendinizi tüm HTML'yi yeniden oluştururken bulacaksınız.

Kodlamaya başladığınızda bu iyidir. Çok fazla deneyim olmadan birçok basit şeyi kolayca yapabilirsiniz. Sorun, daha çok uygulamalara benzeyen modern web sitelerinin karmaşıklığıyla ortaya çıkıyor - bu, düğümlerimizin değerlerini sürekli olarak değiştirmemiz gerektiği anlamına geliyor; bu, tüm yapıyı yeniden bağlayarak yapıyorsanız yüksek maliyetli bir işlemdir. .innerHTML aracılığıyla. React, bir gölge DOM aracılığıyla bu sorunu verimli bir şekilde çözer ve Angular, bir sayfada gösterilen bir değeri değiştirmenin kolay bir yolu olarak bağlamayı kullanarak bu sorunu giderir. Ancak, oluşturduğunuz düğümleri takip ederek ve yeniden kullanılacak veya güncellenecek olanları değişkenlere kaydederek de oldukça kolay bir şekilde çözülebilir. Genel olarak .innerHTML uzak durmak için başka nedenler de vardır.

Çerçevesiz Kodlamayla İlgili En Büyük Mitler

Vakit nakittir. Evet, bu konsepti daha önce geri getiriyorum. Pek çok insan, popüler bir web çerçevesi kullanmayı bırakırlarsa, anında 90'ların internetine geçeceğimizi düşünüyor, <marquee> herkesin favori etiketiyken, bir Geocities sitesinde GIF'leri döndürmenin popüler ve sinirli olduğu, Alta Vista'nın gittiği zaman- web aramaları için ve isabet sayaçları her yerde mevcuttu.

Web çerçeveleri ile, ilk kod satırlarınız çok zaman kazandıran ilerleme sağlıyor gibi görünüyor, ancak bir noktada kazançlar kayıplara dönüşüyor. Çerçevenin inşa edilmediği şeyleri nasıl yapacağını, kitaplıkların nasıl entegre edileceğini ve çerçeve ile güzel oynamalarını nasıl sağlayacağını ve çerçevenin standartlarını takip ederken oluşturduğunuz kodun gitmediğini öğrenmek için zaman harcıyorsunuz. hiç çalışmak ve şimdi yeniden yazmanız gerekiyor. İşleri çerçevesiz yaptığınızda, daha yavaş başlarsınız, ancak istikrarlı bir ilerleme kaydedersiniz. Sonunda, her şey kolay kısmın nerede olmasını istediğinizle ilgili. Toplam sürede çok fazla bir fark yaratmaz.

Kodum Çin Seddi'nden daha uzun olacak. Çerçevesiz yazmak, bir akış hizmetine abone olmak yerine bir film satın almak gibidir. İzlemek istediğiniz yüzlerce filme anında erişemezsiniz, ancak mağazadan indirmeyi asla düşünmeyeceğiniz binlerce başka film için para harcamanıza da gerek kalmaz. Sadece ihtiyacın olanı yazabilirsin.

Aracı faydalı mı? Emin. Ama genellikle gerekli değildir. Bir çerçevenin gereksinimlerine uyum sağlamanıza gerek olmadığından, yazdığınız her kod satırı daha fazla anlam taşır. Saf JavaScript ile daha fazla kod yazıyormuş gibi hissedebilirsiniz, çünkü DOM öğelerini oluşturmanın yolu, bir öğe oluşturmak, onu DOM'ye eklemek ve belki de stil için tek bir satır çağırmak yerine bir sınıf eklemek için satırlar alır. JSX'te kod. Ancak, jQuery veya React gibi bir kitaplık kullanarak kodu karşılaştırırsanız, Vanilla JS'nin uzunluğu oldukça benzer olabilir. Bazen daha uzun, bazen de daha kısa.

Tekerleği yeniden icat etmeye gerek yok. Her yerde bilgisayar bilimi profesörlerinin mantrası. Ve bu doğru—sadece özel olarak çerçeveler anlamına gelmesi gerekmiyor. Örneğin, veri yüklemek veya kaydetmek için bir Ajax isteği göndermek, neredeyse her web uygulamasında bir gerekliliktir, ancak bir çerçeveye sahip olmamak, kodu her seferinde yeniden yazmanız gerektiği anlamına gelmez. Kendi kitaplığınızı veya kod tabanınızı oluşturabilir veya başkalarından kod çıkarabilirsiniz. Ne kadar küçükse, gerektiği gibi değiştirmek veya ayarlamak o kadar kolay olur, bu nedenle bir proje için özel bir şeye ihtiyacınız olduğunda kullanışlı olur. Bir üçüncü taraf kitaplığının veya çerçevesinin içerebileceği dosya dağlarında gezinmektense 100-200 satırlık kodu değiştirmek daha kolaydır.

Sadece küçük proje için çalışacaktır. Bu çok yaygın bir efsanedir, ancak hiç de doğru değildir; Şu anda, Google Drive gibi bir modül de dahil olmak üzere, bir şirketin tüm yönlerini çevrimiçi olarak tek bir yerden yönetmek için tam bir sistem üzerinde çalışıyorum. Çerçeveler olsun ya da olmasın, çok benzer adımlardan geçiyorum ve çok benzer sorunlarla karşılaşıyorum. Fark ihmal edilebilir düzeydedir. Ancak, çerçeveler olmadan tüm kodum daha küçük ve daha kolay yönetilebilir.

KANIT İSTİYORUM

Peki. Teori hakkında konuşmayı bırakalım ve gerçek dünyadan bir örneğe geçelim. Birkaç gün önce, bir mağaza için logolu markaların bir listesini göstermem gerekiyordu. İlk kod jQuery kullanıyordu, ancak Mozilla'ya yüklenirken henüz logoları yüklenmemiş markalar için bozuk bir resim simgesi gösteriliyordu. X Şirketi henüz işini bitirmedi diye mağazanın bitmemiş görünmesini sağlayamayız, ancak özelliğin yayınlanması gerekiyordu.

Aşağıdaki kod, .innerHTML jQuery eşdeğerini kullanır:

 var list_brand_names = ['amazon', 'apple', 'nokia']; var img_out = ''; for (i=0;i<list_brand_names.length;i++) { var brandName = list_brand_names[i].toLowerCase(); img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' /></a>"; } jQuery("#brand-images").html(img_out);

jQuery'nin artılarını ve eksilerini çok derinlemesine incelemeden, buradaki sorun, yarattığımız görüntülere herhangi bir referansımızın olmamasıdır. Kod değiştirmeyi gerektirmeyen çözümler olsa da, bu fırsatı kullanarak herhangi bir kitaplık olmadan nasıl yapılabileceğini görelim:

 var brands = ['amazon', 'apple', 'nokia']; var brand_images = document.getElementById("brand-images"); for (var iBrand = 0; iBrand < brands.length; iBrand++) { var link = document.createElement('a'); link.setAttribute('href', '/pages/' + brands[iBrand]); link.style.display = 'none'; brand_images.appendChild(link); var image = new Image(); image.src = "images/" + brands[iBrand] + "png"; image.onload = function(){ this.parentNode.style.display = ''; } link.appendChild(image); }

Orijinal jQuery kodu altı satır uzunluğundayken, vanilya JS çözümü on iki satır aldı. Sorunu çözmek için, yüklenene kadar her görüntüyü gizlemek, kodlamak için iki kat daha uzun sürer. Öyleyse alternatife bakalım. jQuery'de de çözülebilir mi? Buna bir bak:

 img_out += "<a href='/pages/" + brandName + "'><img src='images/" + brandName + "' onload="showImage(this)"/></a>"; function showImage(image){ image.parentNode.style.display = ""; }

Birkaç ek kod satırıyla, artık jQuery ve vanilya arasında yalnızca üç satırlık bir fark var, ancak jQuery'de, img_out satırının duraklamanız gereken noktaya kadar hızla çok karmaşık hale geldiğini görebilirsiniz. ve ne yaptığınızı dikkatlice düşünün. Nitelikler, işlevler ve benzerlerini eklemek için düğüm işlevlerini kullanarak doğrudan DOM'yi kodlamak daha uzun olabilir, ancak her satırın daha net, daha kesin bir anlamı vardır, bu da gelecekte okunmasını ve sürdürülmesini kolaylaştırır.

Şimdi React'e bir göz atalım:

 function BrandLink(props) { var url = "images/" + props.brand + ".png"; return (<a href="{props.brand}"><img src={url}/></a>); } class Brands extends React.Component { constructor() { super(); this.state = {brands: ['amazon', 'apple', 'nokia']}; } render() { const links = this.state.brands.map((step, move) => { return (<BrandLink brand={step} key={step}/>); }); return (<div className="brands">{links}</div>); } } ReactDOM.render(<Brands />, document.getElementById("root"));

Bu sürüm açıkça yetersizdir. Kod, vanilyadakinden daha kısa değil ve hala sorunu çözme ve içlerindeki görüntü yüklenene kadar bağlantıları gizleme noktasına bile gelmedik.

Her örnek için sonuçlar farklı olacaktır. Bazen, jQuery daha kısa olacaktır. Bazen React kazanır. Vanilla JS'nin ikisinden de daha kısa olabileceği zamanlar vardır. Her halükarda, buradaki amaç, birinin doğası gereği diğerinden üstün olduğunu kanıtlamak değil, vanilya JS kullanmak ile kod uzunluğu söz konusu olduğunda bir çerçeve kullanmak arasında önemli bir fark olmadığını göstermekti.

Çözüm

Hemen hemen her gerçek yaşam sorununda olduğu gibi, hiçbir şey siyah veya beyaz değildir. Web geliştirme çerçeveleri olmadan kodlama, bazı projeleriniz için en iyi çözüm, bazılarında ise bir kabus olabilir. Her araçta olduğu gibi, anahtar sadece nasıl kullanılacağını değil, ne zaman ve onu kullanmanın avantaj ve dezavantajlarının neler olabileceğini öğrenmektir. Saf JavaScript'te kodlama, tıpkı herhangi bir çerçevede olduğu gibidir; ustalaşmak, onu rahat hissetmeden önce zaman alır.

Ama en azından benim için temel fark, çerçevelerin gelip gitmesi ve bir çerçeve uzun süredir popüler olsa bile, bir sürümden diğerine önemli ölçüde değişebilir. Saf JavaScript, tamamen alakalı olmayı bırakıp başka bir dil ortaya çıkana kadar çok daha uzun bir süre için bir seçenek olacaktır. O zaman bile, bir dilden diğerine, belirli bir çerçeveyle diğerine aktarabileceğinizden daha fazla kavram ve strateji olacaktır. Tek bir proje söz konusu olduğunda zaman ve çabanın kabaca eşdeğer olması, bilgi amortismanındaki azalma ve bir sonraki zorluğa birlikte alabileceğiniz dersler dikkate alınması gereken çok önemli faktörlerdir.