React Native är ett ramverk som skapats av Facebook och som gör det möjligt att utveckla native mobilappar för iOS och Android med en enda JavaScript-kodbas.
År 2012 sa Mark Zuckerberg: ”Det största misstaget vi gjorde som företag var att satsa för mycket på HTML5 istället för native-applikationer”. React Native presenterades på Facebooks React.js-konferens i februari 2015 och släpptes som öppen källkod i mars 2015.
I takt med att React Native blir allt populärare och allt fler populära mobilappar (som Facebook, Instagram, Pinterest, Uber, Discord, SoundCloud, Skype…) skrivs om helt eller delvis i React Native, uppstår frågan:Bör mobilutvecklare använda React Native för mobilutveckling istället för att satsa helt på native-utveckling med Java eller Swift?
Innan vi börjar jämföra dessa språk och ramverk ska vi först titta på hur React Native bygger en mobilapp. Ramverket React Native använder biblioteket React.js för att skapa enäkta native mobilapp. Den viktiga skillnaden mellan React och React Native är att det senare användernative komponenteristället för webbkomponenter för att skapa användargränssnittet, tillsammans med JSX – en syntax som används för att bädda in XML i JavaScript.
Det innebär i princip att du kan utveckla mobilappar på ungefär samma sätt som du skulle utveckla webbappar. Låt oss illustrera detta med ett enkelt exempel på en anpassad komponent:
Vi kan genast se likheterna med kodstilen inom webbutveckling. React Native-komponenter såsom <TouchableOpacity> och <Text> definieras och organiseras på exakt samma sätt som HTML-komponenter såsom <button> eller <div>.
Att formatera React Native-komponenter med StyleSheet är dessutom nästan exakt samma sak som det gamla goda CSS:et, där den enda skillnaden är att fältnamnen är skrivna med camelCase (borderRadius) istället för CSS-bindestreck (border-radius).
React Native använder en uppsättning komponenter, till exempel <Image>, <View>, <ScrollView>, <TextInput>, <FlatList> som motsvarar deras motsvarigheter i iOS och Android, samt vissa plattformsspecifika komponenter såsom <DatePickerIOS> och <ProgressViewIOS> för iOS eller <ViewPagerAndroid> och <ToastAndroid> för Android.
Mot bakgrund av detta skulle man kunna hävda att det definitivt är mycket enklare, billigare och snabbare att utveckla mobilappar i React Native än i native iOS och Android. Men är det verkligen så enkelt? Låt oss diskutera för- och nackdelarna med respektive metod mer ingående, utifrån specifika kriterier.
React Native gör det möjligt att använda en enda JavaScript-kodbas för två olika plattformar. Det innebär inte bara att det blir enklare att underhålla appen genom att ha samma utvecklingsprocess för båda plattformarna och återanvända samma kod, utan det kräver också färre resurser, eftersom det inte behövs separata iOS- och Android-team.
Denna fördel har dock ett pris. Det är välkänt att Android och iOS har olika designriktlinjer.”Human Interface Guidelines”för iOS och”Material Design”för Android skiljer sig åt på många punkter, så om projektkraven föreskriver att dessa specifika operativsystemskrav ska följas för varje nativ plattform måste React Native-utvecklaren skriva plattformsspecifik kod, vilket motverkar syftet med en gemensam kodbas. Detta kan vara ett större problem när det gäller iOS, eftersom Apple ofta uppdaterar och fasar ut sina tekniker, vilket kan vara svårt att hänga med i, medan Android-appar i allmänhet har större kontroll över systemet och tillåts större frihet.
Om det däremot går bra att appen ser likadan ut på både iOS och Android, kommer användningen av React Native att avsevärt påskynda utvecklings- och underhållsprocesserna.
Det bör dock noteras att även om man har möjligheten att skriva en app som ser likadan ut på båda plattformarna, är det ändå omöjligt att skriva en app utan att skriva någon plattformsspecifik kod. Vissa komponenter ser helt enkelt bra ut på iOS men dåligt på Android och tvärtom, vilket gör att man måste finjustera just dessa specifika fall. Ändå innebär det, trots plattformsspecifikt gränssnitt i koden, en stor besparing i både pengar och tid på lång sikt att ha så mycket som 30 % gemensam kodbas.
React Native bygger på React.js, som är skrivet i JavaScript. Detta är en stor fördel med tanke på att JavaScript är ett så utbrett och populärt språk att det är mycket svårt att hitta en programmerare som inte har använt det någon gång under sin karriär.
Men vad är nackdelen med att använda JavaScript? Tja… det är ju JavaScript.
MedanJava ochSwift/Objective-Cärstarkt typade,kompilerade språk,är JavaScriptett tolkat språk somofta kallas ettotypat språk. Det innebär att dina variabler kan vara vad som helst när som helst och att en kompilator inte kommer att hjälpa dig, så om du inte ärextra försiktignär du skriver dina appar är vägen banad för attJavaScript-mardrömmarska uppstå. Medan äkta native-appar har större kontroll över variablerna och appens logik är mer förutsägbar, förlitar sig JavaScript på programmerarens erfarenhet, Lint-verktyg och automatiska tester. Betyder detta att JavaScript-program per definition har fler fel? Nej. Men det innebär att du kan komma att lägga betydligt mer tid på att leta efter det appkraschande felet som din kompilator skulle ha upptäckt åt dig i Java eller Swift.
Det är dock ett faktum att JavaScript fortfarande är ett av de mest använda programmeringsspråken i världen, och eftersom JavaScript-gemenskapen är så välutvecklad bör det i regel vara enkelt att hitta en React Native-utvecklare till ett projekt.
Alla som någon gång har arbetat i XCode eller Eclipse/Android Studio vet hur lång tid det kan ta och hur tråkigt det kan vara att vänta på att kompileringen ska bli klar. Detta kan vara särskilt frustrerande om man arbetar med en funktion som ligger flera skärmar bort från startskärmen. Det gör att även enkla uppgifter, som att ändra färgen på en vy eller texten i en etikett, blir mycket tidskrävande.
React Natives lösning på detta problem kallas”hot reloading”, vilket innebär att appen fortsätter att köras och att tillståndet (data och den skärm du befinner dig på) sparas, samtidigt som endast de ändringar som görs i koden införs. Även om funktionen långt ifrån är perfekt fungerar den bra för de flesta vanliga användningsfall och sparar mycket värdefull utvecklingstid.
Även utan att använda ”hot reloading” går det betydligt snabbare att bygga en app med React Native än med native iOS och Android, och med hjälp av funktionenför ”live reloading”kan appen laddas om automatiskt varje gång koden ändras, utan att man behöver bygga om den manuellt varje gång.
React Natives metod för att strukturera användargränssnittet ärFlexbox, som redan är mycket populärt inom webbutveckling och gör det möjligt för utvecklare att mycket enkelt skapa responsiva användargränssnitt för webben eller mobila enheter. Det är alltså en teknik som kan mäta sig med Android-plattformensXML-/Constraint-layoutmetodeller iOS-plattformensStoryboard-/XIB-/kodningsmetod med användargränssnittsbibliotek som Neon.
En betydande fördel med native-utveckling för mobil är dock att man har tillgång till alla inbyggda API:er, såsom kamera, Touch ID och GPS, samt verktyg för att skapa animationer och komplexa användargränssnitt. Det finns inget mellanlager och man kan fritt utnyttja allt som mobilplattformen har att erbjuda. React Native utmärker sig inte när det gäller att skapa komplexa användargränssnitt och animationer. Det finns visserligenAnimated API, som är en smidig lösning, men den ligger fortfarande långt efter de inbyggda funktionerna.
React renderar som standard om en komponent varje gång dess tillstånd ändras. Om det används på rätt sätt är detta tillvägagångssätt för att bygga användargränssnitt överlägset. Om det däremot inte hanteras på rätt sätt kan det leda till onödiga omrenderingar. Det är värt att notera att det i en enkeltrådig JavaScript-miljö kan uppstå prestandaproblem, och att du därför måste vara extra försiktig när du bygger ditt användargränssnitt.
Dessutom är det helt enkelt bäst att implementera vissa komplexa mobilfunktioner i native-kod. Ett exempel på detta är Apples ARKit för att skapa upplevelser med förstärkt verklighet. Ett annat exempel är appar som är mycket plattformsspecifika, till exempel appar för watchOS eller tvOS.
React Native erbjuder helt enkelt inte samma möjligheter när det gäller användargränssnitt som native-utveckling för mobiler, så för appar som kräver ett mycket komplext användargränssnitt eller avancerade animationer är det kanske inte det bästa valet. Men för appar med ett enkelt utseende är det ett bättre alternativ tack vare hur Flexbox hanterar responsiv layout för användargränssnittet, samt den enkla och intuitiva strukturen hos XML-komponenterna.
Även om React Native klarar av en stor del av användningsfallen som spänner över flera plattformar, är det omöjligt för det att täcka alla områden inom native-utveckling för mobiler. Det innebär att det alltid kommer att finnas ett behov av native-moduler. Native-moduler är i grunden kod skriven i det ursprungliga programmeringsspråket som hanterar en specifik native-funktion. Exempel på native-moduler är moduler förkamera,inbyggd bildväljare,push-meddelanden,deep linking och tjänster från tredje part somAuth0 eller Amplitude.
Dessa moduler måste kopplas samman med react-native-länk kommandot, men i de flesta fall räcker det inte, och utvecklaren måste följa specifika anvisningar för att länka den inbyggda modulen så att den fungerar på både iOS och Android.
Detta innebär alltså att i principvilken nativ kod som helstkan skrivas i det ursprungliga språket om React Native inte klarar av den, men det innebär också att React Native-utvecklare tvingas sätta sig in i de ursprungliga utvecklingsmiljöerna (XCode/Android Studio) för att kunna aktivera modulerna. En erfaren utvecklare av nativa mobilappar hittar vanligtvis snabbt ett sätt att länka biblioteket, men någon som enbart är React Native-utvecklare och aldrig har skapat en riktig nativ mobilapp kommer att stöta på många hinder innan hen äntligen får ihop allt.
Dessutom är det värt att notera att om teamet använder en molntjänst för kontinuerlig integration, till exempel Azure, kan det uppstå ännu fler problem med den inbyggda länkningen. Detta beror på att Xcode och Android Studio i molnet kan ha en annan version och konfiguration än den lokala versionen. Även om allt fungerar bra på din dator kan det hända att kompileringen inte går att genomföra på distans, och utvecklaren måste då göra ytterligare finjusteringar för att länkningen ska fungera på båda sidor.
Detsamma gäller publiceringen av appen. Om teamet inte har utvecklare med erfarenhet av native-utveckling för iOS och Android kan det bli svårt att släppa appen. Detta är främst ett problem för iOS, eftersom arbetsflödet för lansering på Android är mer okomplicerat. För att släppa en iOS-app måste React Native-utvecklare fortfarande använda Xcode för att konfigurera lanseringsrelaterade uppgifter, såsom provisioningprofiler och certifikat, vilket kan kännas överväldigande i början.
Allt detta leder till en mycket viktig slutsats:React Native är betydligt effektivare om det används av utvecklare som redan har erfarenhet av native mobilutveckling, eftersom det inte helt eliminerar behovet av att utveckla i native.
Även om de inbyggda plattformarna iOS och Android är här för att stanna, och kommer att finnas kvar under överskådlig framtid, är React Natives framtid osäker. Det stämmer visserligen att React Native-gemenskapen växer och expanderar mycket snabbt, men eftersom den nuvarande versionen av React Native fortfarande inte är 1.0 (den senaste versionen vid tidpunkten för detta artikelskrivande är 0.56) har vi ännu inte sett det bästa som React Native har att erbjuda.
Det är utvecklat av Facebook, vilket innebär att React Native-utvecklarna är helt i dess händer, eftersom det är möjligt att Facebook vid något tillfälle beslutar sig för att sluta underhålla det. Detta har hänt tidigare med Facebooksplattform för backend-as-a-service,kalladParse, som stängdes ner den 28 januari 2017, vilket tvingade alla befintliga användare att byta till en ny tjänst. Tanken på att detta skulle hända React Native är verkligen skrämmande, men det skulle kunna inträffa.
Dessutom, även om React Native i allmänhet håller jämna steg med utvecklingen inom native-utveckling, kommer det alltid att finnas en tidsfördröjning mellan att en ny funktion (till exempel Face ID) lanseras på den native plattformen och att samma funktion införs i React Native. Detta innebär att det tar längre tid att utveckla något med hjälp av den allra senaste tekniken.
En annan sak som är värd att notera är att Facebook visserligen uppdaterar React Native regelbundet, men att de inte är särskilt intresserade av att åtgärda buggar som inte direkt rör Facebook-appen. Det sätt på vilket React Native kompilerar XML till nativ kod är en så kallad ”black box”-process. Om det alltså uppstår något fel i en React Native-komponent måste du antingen vänta på att Facebook åtgärdar det, eller åtgärda det själv – vilket kräver att du går in i den nativa koden.
Är React Native värt besväret i slutändan? Svaret är:Det beror på ditt projekt.
Det viktigaste med React Native är att det fortfarande är under utveckling och att vi ännu inte har sett dess fulla potential. I framtiden kan det bli ännu kraftfullare och effektivare och möjliggöra ännu fler användningsområden, men för närvarande kan det inte helt ersätta native mobilutveckling. Däremot kan dess paradigm”skriv en gång, använd överallt”innebära enorma tids- och kostnadsbesparingar om det används i rätt projekt.
Det behöver knappast sägas att jag ser väldigt fram emot att se hur React Native kommer att utvecklas och hur det kommer att påverka mobilvärlden!☺️
