Hur kan man påskynda mjukvaruutvecklingen med JavaScript?

Definition av snabb utveckling av applikationer

Uttrycket "snabb utveckling" kan tolkas på många felaktiga sätt. För att undvika det, låt oss förklara vad våra förväntningar är. Tja, det viktigaste är budgeten. För att bygga många versioner av samma applikation behöver vi många utvecklare från flera teknikstackar och betala var och en av dem. För att bygga inbyggda mobilappar måste vi duplicera våra kod för att fungera bra på båda plattformarna - Android och iOS. Ett vanligt tillvägagångssätt är att hålla båda applikationerna likadana, använda samma API, upprätthålla samma beteende och så vidare. Som ett resultat måste vi duplicera koden för att bygga två versioner av samma applikation. JS är ett språk som gör det möjligt för oss att bygga mobilapplikationer och webbapplikationer på samma gång. Låter det omöjligt? Låt mig förklara vad jag pratar om.

Mobil? Webb? Jag bryr mig inte.

Låt oss säga att vi vill bygga en applikation som använder React-biblioteket. Detta bibliotek kan användas för att bygga webbapplikationer och mobilapplikationer med React native. De logiska mekanismerna i applikationen, såsom auktorisering, databehandling, filtrering av data och så vidare, kan göras med React-krokar. Poängen är att dessa krokar kan delas av båda versionerna av applikationen - webb och mobil. Tack vare det här alternativet har vi följande besparingar:

• Det finns ingen anledning att duplicera den kod som är ansvarig för samma sak,
• Det finns inget behov av att anlita mobilutvecklare för att implementera samma del av applikationerna,
• Det finns inget behov av att blanda olika språk för att implementera samma applikation på olika mobila plattformar (Android/iOS),
• En utvecklare kan ansvara för att implementera specifika applikationsfunktioner på alla plattformar.

För att sammanfatta det här stycket - det är inte så att en kodbas kommer att driva alla versioner av applikationen, även om vi kan dela upp den delade koden och använda den i varje version för att göra utvecklingsprocessen mycket snabbare.

Slutsats - om du vill bygga en webbapplikation och en mobilapplikation samtidigt bör du överväga biblioteket React som kan dela kodbas i mobil- och webbversionen av applikationen.

Men hur är det med backend?

För några år sedan, när man talade om backend, var det nog få som kunde föreställa sig att underhållet av den skulle vara möjligt med hjälp av ett språk som JS. Utvecklingen av detta språk är fantastisk och dess frukter kan skördas än i dag.

Vad är det jag pratar om? Om du anställer rätt person JS-utvecklarevisar det sig att de inte bara kan skriva applikationens frontend utan också backend - det vill säga vara ansvariga för bearbetning av data på servern, kommunikation med databasen, olika typer av integrationer etc. Fortfarande tveksam eller inte övertygad om det här språket? Det finns ingen anledning att ha den inställningen! Backend använder JS kan implementeras på två populära sätt - i ett utbyggbart och konfigurerbart läge, vilket express.js kan ge oss, och i ett strukturerat läge med hjälp av DI-mönstret - nest.js.

Båda lösningarna är extremt populära och driver många produktionsapplikationer vars ägare är "teknikjättar" i sin bransch. Jag tror att de har mognat tillräckligt för att övertyga dig om att välja någon av dem.

Fortfarande inte tillräckligt? I likhet med koddelning mellan webb- och mobilapplikationer kan backend dela resurser med både den förra och den senare. Nyckelordet här är TypeScript - det gör det bland annat möjligt för oss att dela en kodbas, dvs. en gemensam definition av datatyper för alla plattformar.

Med applikationer som enbart bygger på JavaScript / TypeScript stack med monolit har vi många rader kod sparade, som vi skulle behöva duplicera i inbyggda programmeringsspråk. Å andra sidan, genom att använda samma språk på alla fronter kan vi dela en enorm mängd logik mellan alla applikationer, vilket definitivt skulle påskynda den tid det tar att bygga en viss applikation. Låter inte det fantastiskt?

Kan JS driva skrivbordsapplikationer?

Det visar sig att teknik för att bygga webbläsarapplikationer är bra för att underhålla de applikationer som vi använder i sin skrivbordsform - ett bra exempel här kan vara Slack. Slack är en applikation som används för Team kommunikation - förutom standardmeddelanden har den många olika funktioner och olika typer av externa integrationer. Allt detta gör det till en av de mest populära applikationerna som främst används inom IT-branschen.

Det visar sig att Slack också använder webbteknik (och därmed JavaScript) för att bygga sitt applikationsgränssnitt. Grunden som gör det möjligt att köra sådana applikationer på skrivbordet är electron. Att skapa grafiska gränssnitt med hjälp av webbteknik gör det mycket enklare, snabbare och generellt möjligt att utveckla applikationer för olika plattformar samtidigt.

Är JS tillräckligt mogen?

Att döma av frontend-delen av applikationen finns det ingen illusion om att JS är det enda och exklusiva språket som driver ekosystemet här. För närvarande finns det inga genomförbara alternativ som kan ersätta den här delen av applikationen (även om jag tror att WebAssembly kan överraska oss i framtiden). Så när vi talar om JS:s mognad på frontend - det råder ingen tvekan om att det är det enda kungliga.

På tal om backend kan många utvecklare verka chockade eller omedelbart förneka att JS är lämpligt som programmeringsspråk på backend. Frågan måste dock analyseras objektivt.

Många molnleverantörer tillhandahåller SDK:er som gör att du direkt kan använda moln metoder. Märkligt nog är en av de mest populära flikarna, precis bredvid C#, Go och Java, är Node.js. Det visar sig att den här plattformen är idealisk för att skala och bygga applikationer baserade på mikrotjänster eller serverlös arkitektur. Slutsats - JS är ett av de mest populära språken för att utveckla applikationer baserade på mikrotjänster/serverlös arkitektur. På skärmarna nedan kan vi se att den heliga treenigheten (Google Computing Services, AWS, Azure) av molnleverantörer gör att vi kan bygga applikationer med nod.js.

När det gäller node.js-ekosystemet känner förmodligen alla till ett bibliotek som heter express.js - det är ett enkelt och okomplicerat verktyg som låter dig definiera sökvägar och sedan mata dem med lämplig data som har bearbetats ordentligt på JS-sidan. Dessutom har det mönster som används bland HTTP-förfrågningar som hanteras i express.js blivit ett av de mest populära i hela ekosystemet och är ett slags mönster för olika andra bibliotek som använder t.ex. serverlös arkitektur.

Slutsats - JS är ett språk som är tillräckligt moget för att lägga alla kort på bordet och bygga både frontend och backend. Dessutom är det ett ganska nytt språk som lätt hittar sin väg in i moderna applikationsarkitekturer. Det är fantastiskt att en programmerare som kan ett språk kan behärska båda sidorna (full stack) av en applikation.

Är JS tillräckligt snabb?

Den motor som oftast används för att exekvera JS-kod är v8, som drivs av språket C++. Den här motorn har utvecklats av Google och är avsedd för att köra applikationer för webbplattformar. En intressant sak är att den här motorn inte tolkar JS-koden. Istället gör den något som kallas "JIT" - "just in time compilation". Tack vare det behöver vi inte tolka JS-koden rad för rad, utan vi kompilerar den bara och kör den. Det går ännu snabbare och ger oss riktigt bra prestandaresultat.

Är JS tillräckligt rättvis när det gäller prestanda? Ja, det är det. Så länge du håller dina algoritmer tillräckligt rättvisa är det inga problem att använda JS på serversidan. Den andra saken är att hålla din kod asynkron som den kan vara. Med dessa metoder kan din kod hantera parallella förfrågningar utan problem. Du behöver inte bry dig om teknikbytet på grund av prestandan - särskilt inte när applikationens arkitektur är skalbar.

Jag har redan diskuterat prestanda och riktmärken i detalj i den här artikeln.

Är inte JS en sådan finurlighet bland andra språk?

Tja, det här är dussintals åsikter om att JS-språket beter sig konstigt i vissa fall och att hantera det är något som får ditt huvud att explodera under utvecklingsprocessen. Jag kan inte hålla med 🙂 Precis som alla andra språk har det flera mönster / beteenden som inte är eleganta men med förståelse för hur de fungerar och vad deras mål är att utveckla applikationer med JS är inte obehagligt.

Särskilt kommentaren "asynkron" precis före JS får en del utvecklare att rysa. Det är svårt att förstå när man inte har någon erfarenhet av det. Men det är en del av JS som gör det möjligt för oss att bygga moderna lösningar på ett enkelt sätt. Låt oss ta en titt på websockets: eftersom de är händelsebaserade kan var och en av de anslutna enheterna - användaren och servern - sända och ta emot händelser parallellt. Om koden som driver den här appen är tillräckligt asynkron och inte blockerar huvudtråden kan vi enkelt hantera tusentals förfrågningar på kort tid.

Låt oss jämföra JS och PHP i samband med websockets. PHP är ett synkront programmeringsspråk, så att lösa websocket-ämnen ger en enorm huvudvärk. Vi kan se att PHP får mönster från JS för att bygga interaktiva backend-applikationer som kan använda modern teknik, till exempel webrtc eller websockets.

Blanda ihop allt

När vi samlar ihop alla stycken kan vi konstatera några fakta:

JavaScript är ett språk som kan användas för att bygga alla typer av applikationer - från webb, till mobil, till desktop;
Program som är skrivna i JS kan dela olika kodfragment med varandra, till exempel de som ansvarar för dataformatering eller typer i Typescript;
Tack vare webbens tillväxt är den prestanda som JS erbjuder tillräckligt bra för att välja både frontend- och backend-applikationsutveckling;
Tack vare den ovanliga designen kan JavaScript stödja moderna applikationsinfrastrukturer, t.ex. websockets och WebRTC;
Genom att anlita en riktigt skicklig utvecklare kan du utnyttja dess potential på alla tillgängliga frontend som driver detta språk;
JS är ett språk som har klättrat på popularitetslistorna i flera år nu, och det finns inget som tyder på att detta kommer att förändras på något sätt.

För att ge min visserligen partiska åsikt - att dra nytta av JavaScript:s möjlighet att återanvända samma kod på alla tillgängliga fronter är något som verkligen kommer att påskynda applikationsutvecklingen och minska antalet utvecklare som är involverade i att underhålla backend för applikationer skrivna i andra tekniker. Som en bekräftelse, låt oss komma ihåg det faktum att ett stort antal så kallade IT-jättar följer detta mönster och delar en hel del kodbas över plattformar. Trots olika åsikter om detta språk måste du ta hänsyn till det faktum att statistiken över användning och tillfredsställelse med användningen av JS växer från år till år, och dess utvecklare kan lätt haka på trenden med full stack.

Läs mer om detta:

Varför du (förmodligen) bör använda Typescript

Hur undviker man att döda ett projekt med dåliga kodningsrutiner?

Strategier för datahämtning i NextJS