React Native of native: hoe wij kiezen
Het frameworkdebat is meestal het verkeerde debat. Wat telt is of het product platformdiepte nodig heeft, en wie het over een jaar onderhoudt.
Vrijwel elk mobilegesprek begint met een frameworkvraag, en vrijwel geen enkel zou dat moeten. Het besluit volgt uit twee dingen: hoe sterk het product afhangt van platformmogelijkheden, en hoeveel mensen het over twaalf maanden onderhouden.
Voor ruwweg driekwart van de producten grijpen wij naar React Native. De reden is de economie van gelijkwaardigheid — één codebase betekent dat iOS en Android dezelfde functie op dezelfde dag opleveren, en een team van vier kan dat volhouden. Twee native codebases betekenen twee specialisten en een blijvend risico dat er één vertrekt.
Wij gaan native wanneer de waarde van het product een platformmogelijkheid is. Langdurige achtergrondverwerking, zware mediapijplijnen, complex camera- of sensorwerk, diepe widget- en watch-integratie. Dan is de brug niet het probleem; het probleem is dat u het hele project vecht om toegang tot precies datgene waar het product over gaat.
Het prestatieargument is grotendeels beslecht en wordt grotendeels misbruikt. Met de nieuwe architectuur en Hermes zitten lijstscrollen en animatie dicht genoeg tegen elkaar aan dat gebruikers het niet merken. Wat gebruikers wél merken is de koude starttijd, en dat is een engineeringdiscipline, geen eigenschap van het framework.
De vraag die wij klanten werkelijk stellen is deze: wordt deze app over een jaar onderhouden door een mobileteam of door uw bestaande webengineers met hulp? Is het het laatste, dan is een gedeelde TypeScript-codebase geen compromis maar de enige versie die het overleeft.