Bir Kez Yazın, Her Yere Dağıtın: Ne Zaman Yerli Olunur?

Bir Kez Yaz, Her Yere Dağıt (WODE) , son on yılda birden fazla yerel uygulama yazmanın acısını hafifletmek olan birçok geliştirme çerçevesinin vaadi olmuştur. Hangi yolu seçeceğini belirlemek, yüksek başlangıç ​​maliyeti, geliştirme ekibi üzerindeki etkisi ve tersine çevrilmesinin olası olmaması nedeniyle bir proje yöneticisinin vermesi gereken en kritik kararlardan biridir.

Ionic gibi hibrit çözümler, uygulamaları platformlar arasında işlemek için web teknolojilerinden yararlanır, ancak genellikle nihai ürün, kullanıcının yerel bir görünüm ve his beklentilerine cevap vermez.

Ancak, "yerli" terimi bile son zamanlarda yerel koda göre derlenen çerçeveler tarafından bulandırıldı (örn. React Native, Xamarin, vb.).

Bu makale, çeşitli mobil geliştirme yollarının artılarını ve eksilerini özetlemekte ve ürün yöneticilerini daha bilinçli bir karar vermeleri için güçlendirmek amacıyla bunları ekip yapısı, maliyet ve kullanıcı deneyimi açısından değerlendirmektedir.

Bir Kez Yazın, Her Yere Dağıtın

Bir Kez Yaz, Her Yere Deploy Et kavramı, bir geliştirme ekibinin tek bir geliştirme yığını, uygulamanın konuşlandırılacağı platformun/platformların özetini kullanarak bir uygulamayı bir kez yazma ve yine de dağıtma yeteneğini sürdürme yeteneğini ifade eder. Android, iOS, Windows vb. gibi istenen tüm platformlara uygulama. İdeal olarak bu, sürdürülebilirlik, performans veya kullanıcı deneyiminden (UX) ödün vermeden gerçekleştirilir.

Mobil uygulama geliştirmenin alternatif ve tarihsel yöntemi, her platform için ayrı bir uygulama yazmanın basit sürecini içerir ve bu da elbette kendi potansiyel yüksek zaman ve kaynak maliyetini beraberinde getirir.

Genel olarak, bir geliştirme yolu seçerken göz önünde bulundurulması gereken faktörler şunları içerir:

• Projenin yaşı
• Geliştirme ekibinin yapısı ve boyutu
• Dağıtım için istenen platform(lar)
• Pazar için gerekli zaman çizelgesi
• Gerekirse başka bir yola geçmek için mevcut bant genişliği

Ne yazık ki, bu faktörlerin her birini mevcut yolların her birine uygulamak ve konuyla ilgili sayısız mevcut fikir arasında gezinmek oldukça yıldırıcı olabilir. Ayrıca, bu süreç genellikle proje yöneticisini uygulamanın gereksinimlerini karşılamak için hangi yolun en iyi olduğu konusunda bir belirsizlik duygusuyla karşı karşıya bırakır.

Yüksek düzeyde, farklı mobil geliştirme yolları iki kategoriye ayrılabilir: yerel veya WODE, yani yerel veya diğer her şey. Basitçe söylemek gerekirse, kişi ya yerel bir uygulama yazar ya da yazmaz. WODE kategorisi ayrıca iki gruba ayrılır:

• Hibrit çerçeveler - uygulamaları birden çok platformda işlemek için web teknolojilerinden yararlananlar.
• Karma olmayan çerçeveler - karma çerçevelerin yaptığı gibi bir uygulamanın içinde bir web görünümü oluşturmak yerine yerel UI bileşenlerini (ör. düğmeler, metin alanları ve hatta düzen yöneticileri) kullananlar.

WODE çerçevelerinin çoğu hibrittir ; ancak yine de bir WODE çerçevesinin faydalarını sağlarken hibrit çerçevelerin hem performansını hem de UX sınırlamalarını iyileştirmek için mevcut eğilim hibrit olmayan . Bu eğilim nedeniyle React Native, Xamarin ve Appcelerator gibi çerçeveler popülerlik kazanıyor.

Bu yolların (yerel, hibrit ve hibrit olmayan) her birinin farklı güçlü ve zayıf yönleri vardır ve sonuç olarak her birinin en uygun olduğu farklı kullanım durumları vardır. Bu makalenin geri kalanı, ekip oluşturma, proje maliyeti ve UX gibi rekabet eden öncelikler göz önüne alındığında her bir mobil geliştirme yolunun artılarını ve eksilerini özetlemektedir. Birkaç özel kullanım durumu dışında, yerel uygulamalar yazmak, kullanıcı deneyimini biraz daha yüksek bir maliyetle en üst düzeye çıkarır.

Genel olarak, “ ödediğinizin karşılığını alırsınız ” atasözü geçerlidir, bu nedenle maliyet, müşterilerin deneyiminden daha önemliyse, yerli doğru seçim olmayabilir. Bununla birlikte, UX hayati hale geldiğinde, yerel uygulamalar açık bir seçim haline gelir, çünkü UX'i geliştirmek için WODE tabanlı uygulamalar, yerel olmayan bir uygulama seçme amacını ortadan kaldıran zaman veya yerel uzmanlık şeklinde önemli bir maliyete neden olur. ilk etapta geliştirme yolu.

Ayrıca, bu maliyet ödense bile, WODE tabanlı nihai ürün, yerel muadili ile karşılaştırıldığında her zaman daha düşük bir UX sunacaktır. Sonuç olarak, yerel, çoğu geliştirme ekibi ve çoğu proje için neredeyse her zaman doğru seçimdir.

Yerel Uygulamalar

Yerel uygulamalar, verilen platformun çekirdek dilinde yazılır. Örneğin, Android uygulamaları Java ile yazılırken, iOS uygulamaları Obj-C veya Swift ile yazılır. Geliştirme mühendisinin dili ve örneğin üçüncü taraf paket entegrasyonu, yerleşim yönetimi, işletim sistemi (OS) etkileşimi vb. dahil olmak üzere platforma özgü nüansları anlamasını gerektirir.

Artıları

Son derece özelleştirilebilir . Her uygulama yerel bileşenler kullanılarak yazıldığından, özelleştirmenin tek sınırlaması, temel çerçevelerin arabirimidir ve bazen o zaman bile olmaz. Çoğu yerel geliştirme mühendisinin onaylayacağı gibi, sınırlı bir arabirime rağmen belirli bir görevi gerçekleştirmenin genellikle bir yolu vardır.

Bu fikrin basit bir kanıtı, belirli bir platform için destek topluluklarına göz atarak bulunabilir. Altta yatan çerçevelerin sınırlamalarına rağmen, "kayıt dışı" olabilecek bir görevin nasıl gerçekleştirileceğine dair sayısız örnek bulacaksınız.

Görünüşte basit bir görevin somut bir iOS örneği, örneğin bir sekme çubuğu, gezinme çubuğu vb. gibi tüm harici UI öğelerinin üzerinde tam ekran bir kaplama göstermek olabilir. Şekil 1'de gösterildiği gibi, bu normalde normal UI katmanı şu anda sunuluyor. Bu nedenle, tam ekran bir kaplamaya sahip olmak için, görünüm yığınındaki sekme çubuğunun üzerindeki gizli katmana eklenmelidir. Bu tür bir özelleştirme genellikle yalnızca yerel uygulamalarda mümkündür.

En yüksek performans . Beklendiği gibi, yerel bir uygulama performans için ölçütü belirler. Diğer çerçeve türlerinin çoğu bir veya daha fazla ara katman eklediğinden, doğal olarak yerel bir uygulamadan daha yavaş çalışırlar.

En bakımlı . İşletim sistemleri sürekli değişir. Dönem. Bunu yaptıklarında, son değişikliklerin yapılıp yapılmadığına bağlı olarak, kullanıcının kullanıcı tabanının yeni işletim sistemine yükselten bölümünü kaybetmemek için bir uygulama zamanında güncellenmelidir. Açıkçası, değişikliğin kullanıcıların kullanımına sunulması ile bir uygulamanın güncellenmesi arasında ne kadar az zaman geçerse o kadar iyidir. Yerel bir uygulama üzerinde çalışırken bu yeni işletim sistemini desteklemek için güncellenmesi gereken hiçbir bağımlılık olmadığında bu süre en aza indirilir.

Eksileri

Ek kaynaklar . Birden çok platform için uygulamalar yazarken, bir geliştirme ekibi genellikle desteklenen her platform için bir veya daha fazla mobil yazılım mühendisinden oluşur. Bu, elbette, bir geliştirme ekibinin boyutunu ve maliyetini doğal olarak artırır. Aynı zamanda, homojen bir beceri tabanına sahip olmanın aksine, mühendis ekibinin çeşitli becerilere sahip olmasını gerektirir. Bu, destek ve işbirliği açısından bir ekibi parçalama potansiyeline sahiptir.

Daha yavaş geliştirme döngüsü . Yerel uygulamalar, istenen her platform için ayrı bir uygulama yazılması gerektiğinden, daha yavaş bir geliştirme döngüsüne sahip olma potansiyeline sahiptir. Uç durum, her uygulama esasen seri olarak yazıldığından, ekipte tek bir mobil geliştirme mühendisinin bulunmasıdır.

Düşük performans . Hem profesyonel hem de aleyhte performansa sahip olmak garip görünebilir. Bir yandan yerel uygulamalar, geliştiriciye ince ayarlanmış, yüksek performanslı bir uygulama oluşturması için yeterli alan sağlar. Öte yandan, geliştiriciye kendilerini asacak kadar ip de veriyorlar. Ne yaptıklarını bilmiyorlarsa, sonunda, en iyi ihtimalle alt düzeyde bir uygulama ile sonuçlanacaklardır.

Not: Genel olarak bu, tüm çerçeve yolları (yerel, karma ve karma olmayan) için geçerlidir. Bir uygulama geliştiren mühendisler, denedikleri şey için yetersiz becerilere sahipse, ortaya çıkan uygulama muhtemelen tasarım gereksinimlerini karşılamayacaktır ve kullanıcılar tarafından iyi kabul edilmeyecektir.

Hibrit Uygulamalar

Hibrit uygulamalar, kullanıcı arabirimini tasarlamak için tipik olarak HTML/CSS/LESS kullanılarak yazılır: MVC tasarım modelindeki “V”. “C” veya denetleyici daha sonra tipik olarak JavaScript'te yazılır - ideal olarak AngularJS gibi bir JavaScript MVC çerçevesi kullanılarak. AngularJS gibi bir çerçevenin kullanılması, sınıfların ve sorumlulukların yalnızca jQuery kullanılarak genellikle mümkün olandan daha iyi ayrılmasını sağlar.

Bu tür hibrit çerçeve yığınına bir örnek, AngularJS tarafından desteklenen ve sonunda PhoneGap ve Cordova kullanılarak istenen platformda bir web görünümünde dönüştürülen ve işlenen bir İyonik görünüm katmanı olabilir. Açıkçası, bu tür WODE çerçevesi, ek karmaşıklık pahasına gelir.

Ayrıca JavaScript kullanımı, kendi tasarım temelli sınırlamalarını ve dil temelli sorunları da beraberinde getirir. Bu makalenin amacı, herhangi bir dilin yararlarını veya kusurlarını tartışmak değildir; ancak, bir proje yöneticisi olarak, birinin mobil teknik yığınında JavaScript kullanma seçimi hafife alınmamalıdır. Aşağıda, mümkünse JavaScript'ten neden kaçınılması gerektiğine ilişkin iyi yazılmış makalelerden yalnızca birkaçı verilmiştir:

• JavaScript Sorunu
  
• Neden React Native Developer değilim

Artıları

Minimal geliştirme ekibi . Hibrit çerçeveler, küçük bir geliştirme ekibinin - ve özellikle birincil bilgi temeli web geliştirme olan birinin - birden çok platformda basit uygulamaları hızla üretmesini sağlar. Bu, bir proje yöneticisinin ekibini küçük tutmasının yanı sıra ekibinin birden çok platform için yerel dilleri ve çerçeveleri öğrenme ihtiyacını ortadan kaldırmasına olanak tanır.

Daha hızlı geliştirme döngüsü . Daha küçük bir ekibe ek olarak, hibrit çerçeveler, web teknolojileri kullanılarak yalnızca tek bir görünüm katmanının tasarlanması gerektiğinden, birden çok platforma dağıtılırken daha hızlı bir geliştirme döngüsü sağlar.

Eksileri

Potansiyel olarak zayıf UX . Yalnızca tek bir görünüm katmanı yazmanın dezavantajı, birinin tek bir görünüm katmanıyla kalmasıdır. UI tasarımına yönelik tek boyutlu bir yaklaşım, kişinin uygulamasına tüm platformlardaki kullanıcılar için rahat ve tanıdık bir görünüm ve his vermediği için bu, zayıf bir UX ile sonuçlanabilir. Ek olarak, hibrit uygulamalar esasen kullanıcı arayüzüne gömülü bir web görünümü olduğundan, kullanıcılara yerel bir uygulamayla etkileşim kurmak yerine aslında bir web sayfasını görüntüledikleri izlenimini verebilir. Bu deneyim, neredeyse her zaman kullanıcı memnuniyeti ve nihayetinde elde tutma üzerinde olumsuz bir etkiye sahiptir.

Özelleştirmek için maliyetli . Her platform için özelleştirilmiş UI'ler tasarlayarak UX'i geliştirmek, zaman içinde oluşturulması maliyetli ve bakımı zor olabilen karmaşık ve benzersiz UI çerçeveleri ile sonuçlanır. Ayrıca, bir kişinin uygulamasının öne çıkmasına yardımcı olacak UI öğeleri oluşturmak için (örneğin, animasyon, özel görünümler, vb.), üst düzey UI tasarımını alt düzey çerçeveden bir şeye dönüştürmek için özelleştirilmiş köprü bileşenleri oluşturulmalıdır , Cordova gibi, anlayacaktır. Genel olarak, hibrit bir uygulamanın UX'i ne kadar çok özelleştirilir ve geliştirilirse, hızlı ve ucuz bir tasarım döngüsünün faydasını o kadar azaltır.

Daha düşük performans . Hibrit uygulamalar, uygulamanın görünümlerini bir web görünümü içinde oluşturduğundan, işletim sistemi çerçeveleriyle (örn. ağ oluşturma, Bluetooth, cihazdaki kişiler, vb.) uğraşırken, performansın büyük ölçüde düşmesine neden olan uygulama hataları yapma konusunda büyük bir potansiyel vardır. Şunu da belirtmekte fayda var ki, her şey bir web görünümü üzerinden görüntülendiğinden performansa büyük özen gösterilse bile, hibrit uygulamaların maksimum performansı her zaman yerel muadillerinden biraz daha düşük olacaktır.

Önemsiz eklenti yönetimi . Tasarım ekibinin haftalarca cilalamak için harcadığı, ardından geliştirme ekibi Cordova'nın onlarla çalışabilmesi için gerekli köprü bileşenlerini oluşturduğu sırada birkaç hafta daha geçen özel özellikleri hatırlıyor musunuz? Takımın başarmaya çalıştığı şey için destekleyici bir Cordova eklentisi olmadığı sürece çalışmazlar. Bu, iki şeyden biri anlamına gelir: ya ekibin kendisi oluşturur ya da işi yapan uygun bir üçüncü taraf eklentisinin bulunması gerekir. Ne yazık ki, çoğu zaman ikinci seçenek mevcut değildir. Sonuç olarak, özel eklentileri oluşturmak için ek geliştirme süresi, ardından uygulamanın gerektirdiği büyüyen Cordova eklentileri kitaplığını yönetmek için zaman içinde destek çabası oluşturmak gerekir. Elbette Cordova güncellemeleri gerçekleştiğinde bu eklentilerin de güncellenmesi gerekme olasılığı yüksek.

İşletim sistemi desteği gecikmesi . Daha önce bahsedilen basamaklı köprü bileşeni/Cordova eklentisi sorunu, işletim sistemi temel işlevselliği değiştirdiğinde daha da kötüleşir. Değişiklikleri desteklemek için Cordova, PhoneGap ve Ionic güncellendikten sonra, özel eklentilerin ve köprü bileşenlerinin de güncellenmesi gerekebilir. Bu çalışmanın gerektireceği büyüklük sırasına bakılmaksızın, uygulamanın yeni işletim sistemini güncelleyen son kullanıcıları desteklemediği ek süreye neden olur. Bu, elbette, Apple veya Google tarafından bozulmayan, geriye dönük uyumlu olmayan değişikliklerin yapıldığı ve hiçbir zaman gerçekleşmeyen en kötü durum senaryosudur… değil mi? Genel olarak, geliştiricinin kontrolü dışında olan ve önce güncellenmesi gereken herhangi bir ara çerçeve, yalnızca süreci geciktirmeye yarar. Son olarak, bir ara çerçeveye güvenmek, bu çerçevelerin zamanlaması çok bilinmediğinden proje yöneticilerinin plan yapması için bir baş ağrısı olabilir.

Hibrit Olmayan Uygulamalar

Hibrit olmayan uygulamalar, tıpkı hibrit benzerleri gibi hayata başlar - yerel olmayan bir platform dilinde tasarlanmış bir UI katmanı: React Native, JavaScript veya .NET kökleri nedeniyle C# tabanlı Xamarin tarafından desteklenen HTML/CSS kullanır.

Ancak, benzerlik burada sona eriyor. Hibrit olmayan uygulamalar yerel koda göre derlenir ve uygulamayı bir web görünümü aracılığıyla işlemek yerine platforma özgü bileşenleri kullanarak işler. Bu, en azından yüzeyde, her iki dünyanın da en iyisine sahip olan bir WODE çerçevesiyle sonuçlanır.

Daha önce tartışıldığı gibi, JavaScript kullanmayı seçmek, hafife alınan bir karar olmamalıdır ve JavaScript'i öğrenmek istemeyen veya JavaScript kullanmaya ilgisi olmayan bir geliştirme ekibi için anlaşma kırıcı olabilir.

Artıları

Hibritlere göre daha yüksek performans . Tahmin edilebileceği gibi, hibrit olmayan uygulamalar, gömülü bir web görünümüne güvenmek yerine yerel UI bileşenlerini (düğmeler, görünümler, düzen yöneticileri vb.) kullanarak uygulamayı oluşturma yeteneklerinden dolayı, doğası gereği hibrit uygulamalardan daha yüksek bir performansa sahiptir. Elbette geliştiriciler, dikkate değer veya korkunç bir performans sergileyen bir uygulama yazmakta hâlâ özgürler. Hibrit olmayan uygulamaların avantajı, benzer hibrit uygulamalarla karşılaştırıldığında daha yüksek bir performans temeline sahip olmalarıdır.

Minimal geliştirme ekibi . Hibrit çerçevelere benzer şekilde, hibrit olmayanlar, küçük bir geliştirme ekibinin - ve özellikle birincil bilgi temeli web geliştirme olan birinin - birden çok platformda basit uygulamaları hızla üretmesini sağlar. Bu, proje yöneticilerinin ekiplerini küçük tutmalarına ve ekibin birden çok platform için ana dilleri ve çerçeveleri öğrenmesini engellemesine olanak tanır.

Daha hızlı geliştirme döngüsü . Daha küçük bir ekibe ek olarak, hibrit olmayan çerçeveler, yalnızca tek bir görünüm katmanının tasarlanması gerektiğinden, birden çok platforma dağıtılırken daha hızlı bir geliştirme döngüsü sağlar.

Daha hızlı yinelemeler (React) . React çerçevesi, uygulamadaki değişikliklerin gerçek zamanlı olarak işlenmesine izin veren güçlü bir özellik sağlar: yeniden derlemeye, yeniden oluşturmaya vb. gerek yoktur. Sonuç olarak, React öykünücüsü, her uygulamanın süresini önemli ölçüde azaltan inanılmaz derecede güçlü bir geliştirme aracıdır. Çevrim.

Eksileri

Özelleştirmek için maliyetli . Hibrit muadili gibi, hibrit olmayan uygulamalar, her platform için özelleştirilmiş UI'ler tasarlayarak UX'in iyileştirilmesini gerektirdiğinde, zaman içinde oluşturulması maliyetli ve bakımı zor olabilen karmaşık ve benzersiz UI bileşenleri ile sonuçlanır. Bu aynı zamanda çerçevenin yerel eleman desteğindeki boşlukları tamamlamak için özelleştirilmiş köprü bileşenleri yazmak anlamına gelir. Melezler gibi, bu maliyet hızlı ve ucuz bir tasarım döngüsünün faydasını azaltır, ancak hibrit uygulamaların aksine, köprü bileşenleri istenen her platform için kendi ana dillerinde yazılır. Bu, öncelikle web geliştiricilerinden oluşan bir ekibe esnek bir alternatif olan hibrit olmayan uygulamalar yerine, hibrit olmayan yolu seçen ekiplerin yalnızca çerçevenin belirli dilini (örneğin, JSX veya C#) değil, aynı zamanda ayrıca her platformun ana dili (Java, Obj-C veya Swift).

Üçüncü taraf bağımlılıkları . Bu sınırlama iki farklı biçimde gerçekleşir. React Native durumunda, sayısız bağımlılık biçimini alır, yani kabaca 650. Sonuç, belirli bir zamanda bu bağımlılıklardan birinin veya daha fazlasının güncelliğini yitirmiş olma ihtimalinin çok yüksek olmasıdır. Ayrıca, işletim sistemi düzeyinde büyük bir değişiklik olması durumunda, bu bağımlılıkların çoğunun veya tamamının güncellenmesi gerekeceği olasılığının yüksek olduğu anlamına gelir. Potansiyel tasarruf lütfu, Facebook'un React kullanmasıdır, bu nedenle köşelerinde 300 lb goril olacaktır.

Xamarin söz konusu olduğunda, üçüncü taraf bağımlılık sorunu, bunları ilk etapta entegre etmenin son derece zor olmasıdır. Xamarin bu sorunun farkındadır ve Sharpie adlı bir yardımcı araç sağlar. Aracın amacı bazı entegrasyonlara yardımcı olmaktır, ancak ne yazık ki Sharpie genellikle yanlış kaynakları derlemeye ve bağlamaya çalışır, bu da geliştiriciyi başarıyla tamamlamak için düşük seviyeli derleme parametrelerini manuel olarak değiştirmek gibi zahmetli bir zaman alıcı görevi üstlenmeye zorlar. entegrasyon.

İşletim sistemi desteği gecikmesi . Hibrit olmayan uygulamalar, hibrit olanlarla aynı sorundan muzdariptir. Geliştiricinin kontrolü dışında olan ve önce güncellenmesi gereken herhangi bir ara çerçeve, yalnızca bir kişinin uygulamasını en son kullanıcıları desteklemek için güncelleme sürecini geciktirmeye hizmet eder. Ayrıca, daha önce belirtildiği gibi, bir ara çerçeveye güvenmek, bu çerçevelerin zamanlaması çok bilinmediğinden proje yöneticilerinin plan yapması için bir baş ağrısı olabilir.

Uzun vadeli destek (React Native) . Bu sorun, React Native'e özeldir ve bugüne kadar Facebook'un çerçevesi için uzun vadeli bir destek planı taahhüt etmemiş olması garip gerçeğiyle ilgilidir. Şirketin mobil uygulamaları için kendi çerçevesini kullandığı için bunun düşük bir risk olduğu söylenebilir, ancak herhangi bir proje yöneticisinin Facebook'un konu hakkında neden yorum yapmayı reddettiğini düşünmesi için bir duraklamaya değer.

Doğru Yaklaşımı Seçmek

Maliyet öncelikli bir konu olmadığında, Şekil 2 , geliştirme ekibinin yapısından uygulamanın gereksinimlerine göre yararlanırken yerel uygulamalar yazmanın neredeyse her zaman en iyi seçim olduğunu göstermektedir. İstenen platform sayısından daha az geliştirme mühendisi olduğunda, biraz daha ilginç hale geliyor. Bu durumda, ekip çok sıkı bir yayın takvimi altındaysa React kullanmak doğru seçimdir; Aksi takdirde, yerel olmak hala en iyi seçenektir.

Ekip esas olarak bir web geliştirme ekibi olduğunda ve özelleştirilmiş bir UX gerektiğinde, bazı ekip üyelerinin uygulamalarını yerel hale getirmek için bazı ekip üyelerini şapka değiştirmesi veya ekip üyeleri eklemesi daha iyidir. Bir uygulama, birçok uygulamanın yaptığı gibi özel öğeler gerektiriyorsa, gerçekten uygulanabilir, bakımı yapılabilir bir çerçeve seçeneği yoktur.

Ancak, özel bir UX gerekli değilse, yayın planına bağlı olarak Ionic veya React ile gitmek daha iyi olabilir. Takımın JSX öğrenecek zamanı yoksa, o zaman Ionic doğru seçimdir. Aksi takdirde, zaten birçok üçüncü taraf bağımlılığı gerektirdiğinden ve daha fazlasını eklemek kişinin geliştirme döngüsünü etkilemeyeceğinden React'i seçmek daha iyidir.

Projenin maliyeti birincil bir endişe olduğunda, tipik olarak, ilk adım, öngörülen maliyet için proje planını yürütmek için uygun ekibi devreye sokmak olacağından, mevcut ekip yapısı daha az öncelikli hale gelir. Şekil 3'te gösterildiği gibi, yerel uygulamalar WODE muadillerinden daha yüksek bir başlangıç ​​maliyetine sahiptir, ancak aynı zamanda daha yüksek bir potansiyel UX'e sahiptir. Ayrıca, projeye ne kadar para ve kaynak uygulanırsa uygulansın, WODE uygulamaları UX'lerinde her zaman sınırlı olacaktır.

Umarım bu makale, çeşitli mobil geliştirme yollarının artıları ve eksileri hakkında biraz ışık tutmuş ve ayrıca ekip yapısını hem uygulama gereksinimlerine hem de projenin maliyetine göre tartmaya yardımcı olmuştur. Mesajı, WODE çerçevelerinin kalitesiz olduğunu ve asla aranmaması gerektiğini iletmek değildi, daha ziyade yerelleşmemek için geçerli kullanım durumları olsa da, kişinin bunu yapmanın sonuçlarını tam olarak anlaması gerektiğiydi.