Gå til innhold

Microsoft-fork av Facebooks React Native gjør det enklere å lage «native» apper til både Windows og Mac OS


Anbefalte innlegg

Videoannonse
Annonse

Javascript vil ALDRI være native. React Native og tilsvarende kryssplattform-rammeverk fører bare til dårlige applikasjoner. Det eneste som er native er native. Og da snakker vi om å bruke hver enkelt plattforms offisielle utviklerverktøy, ikke halvløsninger som React Native, Flutter, Xamarin, etc.

  • Innsiktsfullt 1
Lenke til kommentar
Gjest Slettet+987123849734

Selvsakt kan det være native. Hvis en compiler leser javascript koden og omkompilerer den til maskninvarekode for cpuen på den plattformen den kjører på.

Spørsmålet blir jo heller hvilke apier som kan bli tilgjengelige.

Lenke til kommentar
mittvisningsnavn skrev (6 timer siden):

Spørsmålet blir jo heller hvilke apier som kan bli tilgjengelige.

Hvis du bruker Expo (expo.io) til å lage React Native-apper har du tilgang til i hvert fall kamera, aksellerometer, GPS, filsystem, osv. Jeg er ikke utvikler selv, men har lekt meg litt med React Native, og det virker ikke som om det er særlig med begrensninger i maskinvaretilgang. Men det er sikkert alltid noen API-er man ikke har tilgang til. For eksempel fungerer ARKit (på iOS) i Expo, mens ARCore for Android ikke støttes (kanskje det støttes via noen tredjeparts pakker man kan dra inn, jeg har ikke forsket på dette).  ?

Lenke til kommentar
mittvisningsnavn skrev (7 timer siden):

Selvsakt kan det være native. Hvis en compiler leser javascript koden og omkompilerer den til maskninvarekode for cpuen på den plattformen den kjører på.

Spørsmålet blir jo heller hvilke apier som kan bli tilgjengelige.

Så langt jeg vet er det ingen javascript-compilere som lager maskinkode av javascript. Ser også for meg at det kan bli vanskelig mtp. hvor dynamisk javascrip er.

Lenke til kommentar

Med React Native er grensesnittet native-kode, mens logikken kjører i javascript. Javascript er kjemperaskt og trenger ikke nødvendigvis å bruke mye ram.

Det som er tregt er DOM i nettlesere, med React Native kommer man unna dette. Apper bygd med Electron har rykte på seg for å bruke mye minne, det er fordi det egentlig kjører Chrome i bakgrunnen. Med React Native er man heller ikke avhengig av Chrome.

  • Liker 3
Lenke til kommentar
sunsunsun skrev (3 timer siden):

Med React Native er grensesnittet native-kode, mens logikken kjører i javascript. Javascript er kjemperaskt og trenger ikke nødvendigvis å bruke mye ram.

Det som er tregt er DOM i nettlesere, med React Native kommer man unna dette. Apper bygd med Electron har rykte på seg for å bruke mye minne, det er fordi det egentlig kjører Chrome i bakgrunnen. Med React Native er man heller ikke avhengig av Chrome.

Det er nok bedre enn Electron, NW.js og tilsvarende "rammeløse nettlesere", men javascript er fremdeles et interpreted språk. Det vil ALDRI være mulig å oppnå samme ytelse med javascript som med faktisk native kode. Men at det er godt nok til de fleste enkle apper er nok riktig.

Lenke til kommentar
Kajac skrev (12 minutter siden):

Det er nok bedre enn Electron, NW.js og tilsvarende "rammeløse nettlesere", men javascript er fremdeles et interpreted språk. Det vil ALDRI være mulig å oppnå samme ytelse med javascript som med faktisk native kode. Men at det er godt nok til de fleste enkle apper er nok riktig.

I React Native kjører "business logic" som Javascript-kode i en VM, mens alt som krever høy ytelse kjører via moduler som er laget med native kode (Objective C eller Swift på iOS eller Java på Android). Så er det en "bro" som håndterer kommunikasjon mellom native-modulene og Javascript VM-en. Pga. native-koden som håndterer ting og tang som har med brukergrensesnitt, grafikk etc. å gjøre skal man få 60 fps og i hvert fall "nesten native" ytelse. Det er i hvert fall det de skryter av, så får de med mer kode-erfaring enn meg mene noe om hvorvidt det holder mål i virkeligheten. ?

  • Liker 1
Lenke til kommentar
Kurt Lekanger skrev (43 minutter siden):

I React Native kjører "business logic" som Javascript-kode i en VM, mens alt som krever høy ytelse kjører via moduler som er laget med native kode (Objective C eller Swift på iOS eller Java på Android). Så er det en "bro" som håndterer kommunikasjon mellom native-modulene og Javascript VM-en. Pga. native-koden som håndterer ting og tang som har med brukergrensesnitt, grafikk etc. å gjøre skal man få 60 fps og i hvert fall "nesten native" ytelse. Det er i hvert fall det de skryter av, så får de med mer kode-erfaring enn meg mene noe om hvorvidt det holder mål i virkeligheten. ?

Om du har business-logic som er litt krevende, så bør man også putte dette i slike native-moduler, og vipps så utvikler man native med mange unødvendige komplikasjoner.

AirBNB var blant dem som oppdaget dette, og naturlig nok da valgte å gå for 100 % native i stedet.
https://medium.com/airbnb-engineering/sunsetting-react-native-1868ba28e30a

  • Liker 1
Lenke til kommentar
Mats Magnem skrev (4 timer siden):

Xamarin kompilerer vel koden til native kode, så og si tvers gjennom med en og annen reflection.

Ja og nei. På iOS gjør den det, da Apple ikke tillater JIT-kompilering. På Android kompileres det til .NET Intermediate Language, som så kompileres JIT på enheten. Dette gjør at enkelte ting ikke er støttet i Xamarin på iOS. 

Bakdelen er at Xamarin er .NET-basert og bundler .NET runtime og en del andre biblioteker sammen med appen, så den tar veldig mye plass.

  • Liker 1
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...