Mobil? Nett? Jeg bryr meg ikke.<\/h2>\n
La oss si at vi \u00f8nsker \u00e5 bygge en applikasjon som bruker React<\/a> bibliotek. Dette biblioteket kan brukes til \u00e5 bygge webapplikasjoner og mobilapplikasjoner med React native. De logiske mekanismene i applikasjonen, for eksempel autorisasjon, databehandling, filtrering data<\/a> og s\u00e5 videre, kan gj\u00f8res med React-kroker. Poenget er at disse krokene kan deles av begge versjonene av applikasjonen - web og mobil. Takket v\u00e6re dette alternativet har vi f\u00f8lgende besparelser:<\/p>\n For \u00e5 oppsummere dette avsnittet - det er ikke slik at \u00e9n kodebase vil drive alle versjonene av applikasjonen, selv om vi kan dele opp den delte koden og bruke den i hver enkelt versjon for \u00e5 gj\u00f8re utviklingsprosess<\/a> virkelig raskere.<\/p>\n Konklusjon - hvis du \u00f8nsker \u00e5 bygge en webapplikasjon og en mobilapplikasjon samtidig, b\u00f8r du vurdere React-biblioteket som kan dele en kodebase i mobil- og webversjonen av applikasjonen.<\/p>\n For noen \u00e5r siden, n\u00e5r man snakket om backend, var det nok f\u00e5 som hadde forestilt seg at vedlikeholdet av den kunne v\u00e6re mulig ved hjelp av et spr\u00e5k som JS<\/strong>. Utviklingen av dette spr\u00e5ket er fantastisk, og fruktene kan h\u00f8stes den dag i dag.<\/p>\n Hva er det jeg snakker om? Hvis du ansetter den rette JS-utviklere<\/strong>viser det seg at de ikke bare kan skrive frontend av applikasjonen, men ogs\u00e5 backend - det vil si v\u00e6re ansvarlig for behandling av data p\u00e5 serveren, kommunikasjon med databasen, ulike typer integrasjoner osv. Fortsatt n\u00f8lende eller ikke overbevist om dette spr\u00e5ket? Det er ingen grunn til \u00e5 ha denne holdningen! Backend ved hjelp av JS <\/strong> kan implementeres p\u00e5 to popul\u00e6re m\u00e5ter - i en utvidbar og konfigurerbar modus, som express.js kan tilby oss, og i en strukturert modus ved hjelp av DI-m\u00f8nsteret - nest.js.<\/p>\n Begge l\u00f8sningene er ekstremt popul\u00e6re og driver mange produksjonsapplikasjoner med eiere som er \"teknologigiganter\" i sin bransje. Jeg tror de har modnet nok til \u00e5 overbevise deg om \u00e5 velge en av dem.<\/p>\n Fortsatt ikke nok? P\u00e5 samme m\u00e5te som ved deling av kode mellom nett- og mobilapplikasjoner, kan backend dele ressurser med b\u00e5de f\u00f8rstnevnte og sistnevnte. N\u00f8kkelordet \u00e5 bruke her er TypeScript<\/a> - Det gj\u00f8r det blant annet mulig \u00e5 dele en kodebase, det vil si en felles datatypedefinisjon mellom alle plattformer.<\/p>\n Med applikasjoner bygget utelukkende p\u00e5 JavaScript<\/a> <\/strong>\/ TypeScript<\/strong> Ved \u00e5 bruke monolitt kan vi spare mange kodelinjer som vi ellers m\u00e5tte ha duplisert i de opprinnelige programmeringsspr\u00e5kene. P\u00e5 den annen side, ved \u00e5 bruke samme spr\u00e5k p\u00e5 alle fronter, kan vi dele en stor mengde logikk mellom alle applikasjoner, noe som definitivt vil \u00f8ke tiden det tar \u00e5 bygge en bestemt applikasjon. H\u00f8res ikke det flott ut?<\/p>\n Det viser seg at teknologier for \u00e5 bygge nettleserapplikasjoner er gode for \u00e5 vedlikeholde de applikasjonene som vi bruker i desktopform - et godt eksempel her kan v\u00e6re Slack. Slack er en applikasjon som brukes til team<\/a> kommunikasjon - i tillegg til standard meldingsutveksling har den mange forskjellige funksjoner og ulike typer eksterne integrasjoner. Alt dette gj\u00f8r det til et av de mest popul\u00e6re programmene som hovedsakelig brukes i IT-bransjen.<\/p>\n Det viser seg at Slack ogs\u00e5 bruker webteknologier (og dermed JavaScript) for \u00e5 bygge applikasjonsgrensesnittet sitt. Grunnlaget som gj\u00f8r det mulig \u00e5 kj\u00f8re slike applikasjoner p\u00e5 skrivebordet ditt, er elektron. \u00c5 lage grafiske grensesnitt ved hjelp av webteknologier gj\u00f8r det mye enklere, raskere og generelt mulig \u00e5 utvikle applikasjoner for forskjellige plattformer samtidig.<\/p>\n N\u00e5r man ser p\u00e5 frontend-delen av applikasjonen, er det ingen illusjon om at JS <\/strong>er det eneste og eksklusive spr\u00e5ket som driver \u00f8kosystemet her. Forel\u00f8pig finnes det ingen levedyktige alternativer som kan erstatte denne delen av applikasjonen (selv om jeg tror at WebAssembly kan overraske oss i fremtiden). S\u00e5 n\u00e5r vi snakker om JS' modenhet p\u00e5 frontend - det er ingen tvil om at det er den eneste kongelige.<\/p>\n N\u00e5r vi snakker om backend, kan mange utviklere virke sjokkerte eller umiddelbart benekte at JS er egnet som programmeringsspr\u00e5k p\u00e5 backend. Saken m\u00e5 imidlertid analyseres objektivt.<\/p>\n Mange skyleverand\u00f8rer tilbyr SDK-er som lar deg bruke sky<\/a> metoder. Merkelig nok er en av de mest popul\u00e6re fanene, rett ved siden av C#, Go and Java<\/a>, er Node.js<\/a>. Det viser seg at denne plattformen er ideell for skalering og utvikling av applikasjoner basert p\u00e5 mikrotjenester<\/a> eller serverl\u00f8s arkitektur. Konklusjon - JS er et av de mest popul\u00e6re spr\u00e5kene for utvikling av applikasjoner basert p\u00e5 mikrotjenester\/serverl\u00f8s arkitektur. P\u00e5 skjermbildene nedenfor kan vi se at den hellige treenighet (Google Computing Services, AWS<\/a>, Azure<\/a>) av skyleverand\u00f8rer gj\u00f8r at vi kan bygge applikasjoner ved hjelp av node<\/a>.js.<\/p>\n N\u00e5r det gjelder node.js-\u00f8kosystemet, er sannsynligvis alle kjent med et bibliotek som heter express.js - det er et enkelt og greit verkt\u00f8y som lar deg definere stier og deretter mate dem med passende data som har blitt behandlet p\u00e5 riktig m\u00e5te p\u00e5 JS-siden. Dessuten har m\u00f8nsteret som brukes blant HTTP-foresp\u00f8rsler som h\u00e5ndteres i express.js, blitt et av de mest popul\u00e6re i hele \u00f8kosystemet og er et slags m\u00f8nster for forskjellige andre biblioteker som bruker f.eks. serverl\u00f8s arkitektur.<\/p>\n Konklusjon - JS er et spr\u00e5k som er modent nok til \u00e5 sette alle kortene p\u00e5 bordet og bygge b\u00e5de frontend og backend. I tillegg er det et ganske ferskt spr\u00e5k som lett finner veien inn i moderne applikasjonsarkitekturer. Det er flott at en programmerer som kan ett spr\u00e5k, kan mestre begge sider (full stack) av en applikasjon.<\/p>\n Den motoren som oftest brukes til \u00e5 kj\u00f8re JS-kode, er v8, som er basert p\u00e5 C++. Denne motoren er utviklet av Google og er dedikert til \u00e5 kj\u00f8re applikasjoner for webplattformer. En interessant ting er at denne motoren ikke tolker JS-koden. I stedet gj\u00f8r den det som kalles \"JIT\" - \"just in time compilation\". Takket v\u00e6re det trenger vi ikke \u00e5 tolke JS-koden linje for linje, vi bare kompilerer den og kj\u00f8rer den. Det er enda raskere og gir oss virkelig gode ytelsesresultater.<\/p>\n Er JS rettferdig nok n\u00e5r det gjelder ytelse? Ja, det er det. S\u00e5 lenge du holder algoritmene dine rettferdige nok, er det ikke noe problem \u00e5 bruke JS p\u00e5 serversiden. Den andre tingen er \u00e5 holde koden s\u00e5 asynkron som mulig. Med disse fremgangsm\u00e5tene kan koden din h\u00e5ndtere parallelle foresp\u00f8rsler uten problemer. Du trenger ikke \u00e5 bry deg om teknologibyttet p\u00e5 grunn av ytelsen - spesielt ikke n\u00e5r applikasjonens arkitektur er skalerbar.<\/p>\n Jeg har allerede diskutert ytelsen og referanseverdiene i detalj i denne artikkelen. <\/p>\n Vel, dette er dusinvis av meninger om at JS-spr\u00e5ket oppf\u00f8rer seg rart i noen tilfeller, og at h\u00e5ndtering av det er noe som vil f\u00e5 hodet ditt til \u00e5 eksplodere under utviklingsprosessen. Jeg er ikke enig \ud83d\ude42 Akkurat som alle andre spr\u00e5k har det flere m\u00f8nstre \/ oppf\u00f8rsel som ikke er elegante, men med forst\u00e5else av hvordan de fungerer og hva deres m\u00e5l er, er det ikke ubehagelig \u00e5 utvikle applikasjoner med JS.<\/p>\n Spesielt \"asynkron\" rett f\u00f8r JS f\u00e5r noen utviklere til \u00e5 gr\u00f8sse. Det er vanskelig \u00e5 forst\u00e5 n\u00e5r du ikke har noen erfaring med det. Det er imidlertid en del av JS som gj\u00f8r det mulig for oss \u00e5 bygge moderne l\u00f8sninger p\u00e5 en enkel m\u00e5te. La oss ta en titt p\u00e5 websockets: Siden de er hendelsesbaserte, kan hver av de tilkoblede enhetene - brukeren og serveren - sende ut og motta hendelser parallelt. Hvis koden som driver denne appen er asynkron nok og ikke blokkerer hovedtr\u00e5den, kan vi enkelt h\u00e5ndtere tusenvis av foresp\u00f8rsler p\u00e5 kort tid.<\/p>\n La oss sammenligne JS og PHP<\/a> med sammenheng med websockets. PHP er et synkront programmeringsspr\u00e5k, s\u00e5 det \u00e5 l\u00f8se websocket-emner gir en enorm hodepine. Vi kan se at PHP henter m\u00f8nstre fra JS for \u00e5 bygge interaktive backend-applikasjoner som kan bruke moderne teknologier, for eksempel webrtc eller websockets.<\/p>\n N\u00e5r vi samler alle avsnittene, kan vi sl\u00e5 fast noen fakta:<\/p>\n JavaScript<\/strong> er et spr\u00e5k som kan brukes til \u00e5 bygge alle slags applikasjoner - fra web, til mobil, til desktop; For \u00e5 gi min, riktignok partiske, mening - \u00e5 dra nytte av JavaScripts mulighet til \u00e5 gjenbruke den samme koden p\u00e5 alle tilgjengelige fronter er noe som helt sikkert vil \u00f8ke hastigheten p\u00e5 applikasjonsutviklingen og redusere antallet utviklere som er involvert i \u00e5 vedlikeholde bakenden av applikasjoner som er skrevet i andre teknologier. Som en bekreftelse kan vi minne om at et stort antall s\u00e5kalte IT-giganter f\u00f8lger dette m\u00f8nsteret og deler ganske mye kodebase p\u00e5 tvers av plattformer. Til tross for ulike meninger om dette spr\u00e5ket, m\u00e5 du ta hensyn til det faktum at statistikken over bruk og tilfredshet med bruken av JS <\/strong>vokser fra \u00e5r til \u00e5r, og utviklerne kan lett hekte seg p\u00e5 trenden med full stack.<\/p>\n Les mer om dette:<\/b><\/p>\n Derfor b\u00f8r du (sannsynligvis) bruke Typescript<\/a><\/p>\n Hvordan unng\u00e5r man \u00e5 drepe et prosjekt med d\u00e5rlig kodingspraksis?<\/a><\/p>\n\n
Men hva med backend?<\/h2>\n
Kan JS drive desktop-applikasjoner?<\/h2>\n
Er JS moden nok?<\/h2>\n
![\"Node.js](\"\/app\/uploads\/2024\/05\/zrzut-ekranu-2021-08-24-o-12.13.12.png\" "\\"Hurtigstart")
<\/p>\n![\"Node.js](\"\/app\/uploads\/2024\/05\/zrzut-ekranu-2021-08-24-o-12.13.25.png\" "\\"Fem")
<\/p>\nEr JS rask nok?<\/h2>\n
Er ikke JS en slik finurlighet blant andre spr\u00e5k?<\/h2>\n
Bland det hele sammen<\/h2>\n
\nProgrammer skrevet i JS kan dele ulike kodefragmenter med hverandre, for eksempel de som er ansvarlige for dataformatering eller typer i Typescript;
\nTakket v\u00e6re veksten p\u00e5 nettet er ytelsen som JS tilbyr, god nok til \u00e5 velge b\u00e5de frontend- og backend-applikasjonsutvikling;
\nTakket v\u00e6re den uvanlige designen kan JavaScript st\u00f8tte moderne applikasjonsinfrastrukturer, som websockets og WebRTC;
\nVed \u00e5 ansette en dyktig utvikler kan du utnytte potensialet i alle tilgjengelige frontend-l\u00f8sninger som driver dette spr\u00e5ket;
\nJS er et spr\u00e5k som har klatret p\u00e5 popularitetslistene i flere \u00e5r n\u00e5, og det er ingenting som tyder p\u00e5 at dette vil endre seg p\u00e5 noen m\u00e5te.<\/p>\n![\"R\u00e5dgivning](\"\/app\/uploads\/2024\/05\/cta_2.jpeg\")
<\/a><\/p>\n