Teil on idee mobiilirakenduseks ja juba esimesel kohtumisel arendajaga kerkib küsimus: „Kas kasutame Flutterit või React Native'i?“ Mõlemaga saab ühest koodibaasist välja anda nii iOS- kui ka Android-rakenduse ning mõlema taga on suured ettevõtted ja laialdane kogukond. Selles artiklis selgitan ilma liigsete tehniliste detailideta, kuidas saate selle otsuse ettevõtja või asutajana langetada.
Lühike vastus
Enamiku ärirakenduste puhul võib õige valik olla kumbki. Erinevus ei tulene niivõrd rakendusest endast, vaid pigem teie meeskonnast, olemasolevast tehnoloogilisest taustast ja pikaajalistest plaanidest. Vale valik avaldub harva „aeglasema rakendusena“ – tavaliselt avaldub see „projektina, mida on raske hooldada“.
Kuidas need töötavad?
Flutter on Google'i arendatud raamistik, mis kasutab Dart-keelt. Operatsioonisüsteemi sisseehitatud komponentide asemel joonistab see kasutajaliidese oma renderdusmootoriga. Seetõttu näeb nupp iOS-is ja Androidis välja pikslitäpselt ühesugune.
React Native on Meta arendatud raamistik, milles kirjutatakse JavaScriptis või TypeScriptis. Teie kirjutatud komponendid vastavad platvormi päris natiivsetele komponentidele. Praegustes versioonides vaikimisi kasutusel olev uus arhitektuur on muutnud JavaScripti ja natiivse koodi vahelise suhtluse varasemast märgatavalt kiiremaks.
Jõudlus
Internetist leiate hulgaliselt võrdlustestide tulemusi, kuid need sõltuvad suuresti stsenaariumist, seadmest ja versioonist. Selles valdkonnas muutub kõik kiiresti, seega ma ei toetuks ühelegi üksikule numbrile. Praktikas näen järgmist:
- Tüüpilises ärirakenduses, kus on loendid, vormid, maksed, kaardid ja teavitused, ei märka kasutaja nende kahe vahel erinevust.
- Rohkete animatsioonide, kohandatud joonistuse või mängulaadsete ekraanide puhul on Flutteri oma renderdusmootoril sageli eelis.
- Tegelikud jõudlusprobleemid ei tulene tavaliselt raamistikust, vaid tarbetutest ümberrenderdustest, liiga suurtest piltidest ja halvasti kavandatud andmevoogudest.
Kasutajaliides ja disain
Kui soovite brändipõhist disaini, mis näeb igal platvormil välja täpselt ühesugune, pakub Flutter seda loomulikul viisil. Ekraani teostamine täpselt nii, nagu disainer selle Figmas joonistas, nõuab tavaliselt vähem vaeva.
Kui soovite, et rakendus tunduks igal platvormil „omas kodus“, tulevad kasuks React Native'i natiivsed komponendid. iOS-i kasutajad saavad iOS-ile omase käitumise, Androidi kasutajad Androidile omase. Loomulikult on mõlemad lähenemised võimalikud kummaski raamistikus – erinevus on selles, kumb nõuab vähem tööd.
Meeskond ja oskused
Sageli on just see otsustav tegur. Kui teie ettevõttes või agentuuris on juba veebiarendajaid, kes tunnevad Reacti ja TypeScripti, on React Native'ile üleminek palju lihtsam ning samad inimesed saavad töötada nii veebipõhise halduspaneeli kui ka mobiilirakenduse kallal.
Dart on vähem levinud, kuid seda on lihtne õppida ja Flutteri ökosüsteem on peaaegu täielikult selle ümber üles ehitatud. Kui plaanite projekti hiljem teisele meeskonnale üle anda, uurige, millise tehnoloogia jaoks on teie turul lihtsam arendajaid leida.
Ökosüsteem ja paketid
Mõlemal on küpsed paketid levinud vajaduste jaoks, nagu maksed, kaardid, kaamera, tõukemärguanded ja analüütika. Flutteri paketid tulevad pub.dev-ist, React Native'i paketid npm-ist.
React Native'i maailmas on Expo nüüd ametliku dokumentatsiooni soovitatud lähtepunkt. See lihtsustab oluliselt kompileerimist, uuendusi ja poodidesse esitamist. Flutter pakub oma ametliku dokumentatsiooni ja ühest allikast pärit tööriistadega kohe algusest peale ühtset kogemust.
Üks asi, millele tähelepanu pöörata: populaarne pakett ei ole tingimata hooldatud pakett. Enne paketi kasutuselevõttu tasub mõlemal pool kontrollida viimase versiooni kuupäeva ja avatud probleeme.
Kulud ja ajakava
Mõlemad raamistikud säästavad tavaliselt aega ja raha võrreldes eraldi iOS- ja Android-rakenduste kirjutamisega, sest suurem osa äriloogikast ja kasutajaliidesest on ühine. Kuluerinevus nende kahe vahel sõltub vähem raamistikust ja rohkem järgmistest küsimustest:
- Millist tehnoloogiat meeskond juba oskab?
- Kui palju koodi jagatakse veebipoolega?
- Kui palju kohandatud disaini ja animatsioone rakendus sisaldab?
- Kui palju seadmespetsiifilist natiivset koodi (Bluetooth, andurid, taustatoimingud) on vaja?
Mida rohkem natiivset koodi vajate, seda rohkem eraldi iOS- ja Android-tööd tuleb teha, ükskõik millise raamistiku valite. Seda tuleks hinnangus arvesse võtta.
Hooldus ja pikk perspektiiv
Töö ei lõpe rakenduse avaldamisega. Apple ja Google annavad igal aastal välja uusi operatsioonisüsteemi versioone ja poereegleid ning ka raamistikud ise uuenevad regulaarselt. Uuenduste edasilükkamine võib mõne aasta pärast muutuda suureks ja kalliks üleminekuks.
Flutteris asub enamik sõltuvusi ühes ökosüsteemis, mistõttu on uuendused suhteliselt etteaimatavad. React Native'is muudab Expo kasutamine versiooniuuendused märgatavalt lihtsamaks. Igal juhul on kõige olulisem planeerida rakendus koos regulaarse hooldusplaaniga.
Millal valida Flutter
- Soovite brändipõhist kasutajaliidest, mis näeb igal platvormil välja ühesugune.
- Rakenduses on palju animatsioone, graafikuid või kohandatud joonistust.
- Alustate nullist ja teil ei ole olemasolevat JavaScripti meeskonda.
- Plaanite samast koodibaasist jõuda ka teistele platvormidele, näiteks lauaarvutitesse või sardekraanidele.
Millal valida React Native
- Teie meeskond oskab Reacti ja TypeScripti.
- Soovite jagada äriloogikat, tüüpe või valideerimiskoodi oma veebirakendusega.
- Soovite, et rakendus kasutaks igal platvormil natiivseid komponente ja tuttavat platvormikäitumist.
- Soovite lisada olemasolevale natiivsele (Swift/Kotlin) rakendusele samm-sammult uusi ekraane.
Kiire otsustamise kontrollnimekiri
- Meeskond: Kes rakenduse ehitab ja kes seda hooldab? Millist tehnoloogiat nad oskavad?
- Disain: Kas olulisem on igal platvormil ühesugune välimus või platvormile omane tunnetus?
- Veeb: Kas teil on veebipõhine halduspaneel või veebisait ja kas soovite sellega koodi jagada?
- Seadme funktsioonid: Kas vajate Bluetoothi, taustal asukohatuvastust või eririistvara? Kas vajalikud paketid on mõlemal pool ajakohased?
- Hooldus: Kas teil on plaan hoida rakendust ajakohasena vähemalt kaks-kolm aastat?
Teie vastused neile küsimustele ütlevad palju rohkem kui ükskõik milline vaidlus selle üle, kumb raamistik on „parem“.
Kokkuvõte
Flutteri ja React Native'i vahel ei ole universaalset võitjat – on valik, mis sobib teie projekti, meeskonna ja eesmärkidega. Ehitan veebi- ja mobiilirakendusi ning saame selle otsuse teie vajadustest lähtudes koos selgeks teha. Kui soovite mulle oma rakenduse ideest rääkida, võtke ühendust ja selgitame välja, milline tee tagab teile väiksemad kulud ja lihtsama hoolduse.
