Hoe softwareontwikkeling versnellen met JavaScript?

Definitie van snelle ontwikkeling van toepassingen

De uitdrukking "snelle ontwikkeling" kan op veel verkeerde manieren worden geïnterpreteerd. Laten we, om dit te voorkomen, uitleggen wat onze verwachtingen zijn. Het belangrijkste is het budget. Om veel versies van dezelfde applicatie te bouwen, hebben we veel ontwikkelaars van verschillende technische stacks nodig en moeten we ze allemaal betalen. Om native mobiele apps te bouwen, moeten we onze code om goed te werken op beide platformen - Android en iOS. Een gebruikelijke aanpak is om beide applicaties gelijk te houden, dezelfde API te gebruiken, hetzelfde gedrag te behouden enzovoort. Als gevolg daarvan moeten we de code dupliceren om twee versies van dezelfde applicatie te bouwen. JS is een taal waarmee we tegelijkertijd mobiele applicaties en webapplicaties kunnen bouwen. Klinkt dat onmogelijk? Laat me uitleggen waar ik het over heb.

Mobiel? Web? Het maakt me niet uit.

Laten we zeggen dat we een applicatie willen bouwen die gebruik maakt van de React bibliotheek. Deze bibliotheek kan worden gebruikt voor het bouwen van webapplicaties en mobiele applicaties met React native. De logische mechanismen van de applicatie, zoals autorisatie, computing, het filteren van gegevens enzovoort, kunnen worden uitgevoerd met React hooks. Het punt is dat deze haken kunnen worden gedeeld door beide versies van de applicatie - web en mobiel. Dankzij deze optie hebben we de volgende saves:

• Het is niet nodig om de code die verantwoordelijk is voor hetzelfde te dupliceren,
• Het is niet nodig om native mobiele ontwikkelaars in te huren om hetzelfde deel van applicaties te implementeren,
• Het is niet nodig om verschillende talen te mengen om dezelfde applicatie op verschillende mobiele platformen (Android/iOS) te implementeren,
• Eén ontwikkelaar kan verantwoordelijk zijn voor het implementeren van specifieke applicatiefuncties op alle platformen.

Om deze paragraaf samen te vatten - het is niet zo dat één codebase alle versies van de applicatie zal aandrijven, hoewel we de gedeelde code kunnen splitsen en in elke versie gebruiken om het ontwikkelproces echt sneller te maken.

Conclusie - als je tegelijkertijd een webapplicatie en een mobiele applicatie wilt bouwen, overweeg dan de React bibliotheek die een codebase kan delen in de mobiele en webversie van de applicatie.

Maar hoe zit het met de achterkant?

Als we het een paar jaar geleden over de backend hadden, zouden waarschijnlijk maar weinig mensen zich kunnen voorstellen dat het onderhoud daarvan mogelijk zou zijn met behulp van een taal als JS. De ontwikkeling van deze taal is verbazingwekkend en de vruchten ervan kunnen tot op de dag van vandaag worden geplukt.

Waar heb ik het over? Als je de juiste JS-ontwikkelaarsHet blijkt dat ze niet alleen de voorkant van de applicatie kunnen schrijven, maar ook de achterkant - dat wil zeggen, verantwoordelijk zijn voor het verwerken van gegevens op de server, communicatie met de database, verschillende soorten integraties, enz. Twijfel je nog of ben je niet overtuigd van deze taal? Er is geen reden voor deze houding! Backend gebruiken JS kan op twee populaire manieren worden geïmplementeerd - in een uitbreidbare en configureerbare modus, die express.js ons kan bieden, en in een gestructureerde modus met behulp van DI pattern - nest.js.

Beide oplossingen zijn erg populair en drijven veel productietoepassingen aan waarvan de eigenaars "technologiereuzen" in hun branche zijn. Ik denk dat ze volwassen genoeg zijn om je te overtuigen een van beide te kiezen.

Nog steeds niet genoeg? Vergelijkbaar met het delen van code tussen web- en mobiele applicaties, kan de backend bronnen delen met zowel de eerste als de laatste. Het sleutelwoord dat we hier moeten gebruiken is TypeScript - het stelt ons onder andere in staat om een codebase te delen, d.w.z. een gemeenschappelijke gegevenstype-definitie voor alle platformen.

Met applicaties die alleen gebouwd zijn op de JavaScript / TypeScript Stapelen met monolith bespaart ons veel regels code die we zouden moeten dupliceren in native programmeertalen. Aan de andere kant, door op alle fronten dezelfde taal te gebruiken, kunnen we een enorme hoeveelheid logica delen tussen alle applicaties, wat de tijd waarin een bepaalde applicatie gebouwd kan worden zeker zou versnellen. Klinkt dat niet geweldig?

Kan JS desktopapplicaties aandrijven?

Het blijkt dat technologieën voor het bouwen van browserapplicaties geweldig zijn voor het onderhouden van die applicaties die we in hun desktopvorm gebruiken - een goed voorbeeld hiervan kan Slack zijn. Slack is een toepassing die wordt gebruikt voor team communicatie - afgezien van standaardberichten, beschikt het over veel verschillende functionaliteiten en verschillende soorten externe integraties. Dit alles maakt het een van de populairste applicaties die voornamelijk in de IT-industrie worden gebruikt.

Het blijkt dat Slack ook webtechnologieën (en dus JavaScript) gebruikt om zijn applicatie-interface te bouwen. De basis die het mogelijk maakt om zulke applicaties op je desktop te draaien is elektron. Het maken van grafische interfaces met behulp van webtechnologieën maakt het veel eenvoudiger, sneller en in het algemeen mogelijk om applicaties voor verschillende platforms tegelijk te ontwikkelen.

Is JS volwassen genoeg?

Aan het frontend-gedeelte van de applicatie te zien, is er geen illusie dat JS is de enige en exclusieve taal die het ecosysteem hier aandrijft. Voorlopig zijn er geen haalbare alternatieven die dit deel van de applicatie kunnen vervangen (hoewel ik denk dat WebAssembly ons in de toekomst kan verrassen). Dus, over de volwassenheid van JS aan de voorkant gesproken - er is geen twijfel mogelijk dat het de enige koninklijke is.

Als we het over de backend hebben, lijken veel ontwikkelaars misschien geschokt of ontkennen ze meteen dat JS geschikt is als programmeertaal voor de backend. De zaak moet echter objectief worden geanalyseerd.

Veel cloud-providers bieden SDK's waarmee je direct gebruik kunt maken van cloud methoden. Vreemd genoeg is een van de populairste tabbladen, direct naast C#, Go en Javais Node.js. Het blijkt dat dit platform ideaal is voor het schalen en bouwen van toepassingen op basis van microservices of serverloze architectuur. Conclusie - JS is een van de populairste talen voor het ontwikkelen van toepassingen op basis van een microservices/serverloze architectuur. Op de onderstaande schermen kunnen we zien dat de heilige drie-eenheid (Google Computing Services, AWSAzure) van cloudproviders kunnen we applicaties bouwen met behulp van knooppunt.js.

Wat betreft het node.js-ecosysteem, is waarschijnlijk iedereen bekend met een bibliotheek genaamd express.js - het is een eenvoudige en ongecompliceerde tool waarmee je paden kunt definiëren en deze vervolgens kunt voeden met geschikte gegevens die op de juiste manier zijn verwerkt aan de JS-kant. Bovendien is het patroon dat wordt gebruikt onder HTTP-verzoeken die worden afgehandeld in express.js een van de populairste geworden in het hele ecosysteem en is het een soort patroon voor verschillende andere bibliotheken die bijvoorbeeld een serverloze architectuur gebruiken.

Conclusie - JS is een taal die volwassen genoeg is om alle kaarten op te zetten en zowel frontend als backend te bouwen. Daarnaast is het een vrij frisse taal die gemakkelijk zijn weg vindt in moderne applicatiearchitecturen. Het is geweldig dat een programmeur die één taal kent beide kanten (full stack) van een applicatie kan beheersen.

Is JS snel genoeg?

Welnu, de engine die het vaakst wordt gebruikt voor het uitvoeren van JS-code is v8, aangedreven door de taal C++. Deze engine is ontwikkeld door Google en is speciaal bedoeld om toepassingen voor webplatforms uit te voeren. Interessant is dat deze engine de JS-code niet interpreteert. In plaats daarvan doet het iets dat "JIT" wordt genoemd - "just in time compilation". Dankzij dit hoeven we de JS-code niet regel voor regel te interpreteren, we compileren het gewoon en voeren het uit. Het is zelfs sneller en geeft ons echt mooie prestatieresultaten.

Is JS eerlijk genoeg over prestaties? Ja, dat is het zeker. Zolang je je algoritmes eerlijk genoeg houdt, is het geen probleem om JS aan de serverkant te gebruiken. Het andere is om je code zo asynchroon mogelijk te houden. Met deze werkwijzen kan je code zonder problemen parallelle verzoeken afhandelen. Je hoeft je geen zorgen te maken over het wisselen van technologie vanwege de prestaties - vooral als de architectuur van de applicatie schaalbaar is.

Ik heb de prestaties en benchmarks al in detail besproken in dit artikel.

Is JS niet zo'n eigenaardigheid onder andere talen?

Nou, dit zijn tientallen meningen dat de JS-taal zich in sommige gevallen raar gedraagt en dat het hanteren ervan iets is dat je hoofd doet ontploffen tijdens het ontwikkelproces. Daar kan ik het niet mee eens zijn 🙂 Net als elke andere taal heeft JS verschillende patronen/gedragingen die niet elegant zijn, maar als je begrijpt hoe ze werken en wat hun doelen zijn, is het ontwikkelen van applicaties met JS niet onaangenaam.

Vooral de opmerking "asynchroon" vlak voor JS doet sommige ontwikkelaars huiveren. Het is moeilijk te begrijpen als je er geen ervaring mee hebt. Het is echter een onderdeel van JS waarmee we op een eenvoudige manier moderne oplossingen kunnen bouwen. Laten we eens kijken naar websockets: omdat ze event-gebaseerd zijn - elk van de verbonden eenheden - de gebruiker en de server kunnen parallel events uitzenden en ontvangen. Als de code die deze app voedt asynchroon genoeg is en de hoofddraad niet blokkeert, kunnen we gemakkelijk duizenden verzoeken in korte tijd verwerken.

Laten we JS en PHP met de context van websockets. PHP is een synchrone programmeertaal, dus het oplossen van websocket onderwerpen geeft een enorme hoofdpijn. We kunnen zien dat PHP patronen uit JS haalt om interactieve backend applicaties te bouwen die moderne technologieën kunnen gebruiken, zoals webrtc of websockets.

Meng alles door elkaar

Als we alle paragrafen samenvatten, kunnen we een paar feiten noemen:

JavaScript is een taal die kan worden gebruikt om allerlei soorten toepassingen te bouwen - van web tot mobiel tot desktop;
Toepassingen geschreven in JS kunnen verschillende codefragmenten met elkaar delen, zoals de fragmenten die verantwoordelijk zijn voor gegevensopmaak of types in Typescript;
Dankzij de groei van het web zijn de prestaties die JS biedt goed genoeg om te kiezen voor zowel frontend- als backendapplicatieontwikkeling;
Dankzij het ongebruikelijke ontwerp kan de JavaScript moderne applicatie-infrastructuren ondersteunen, zoals websockets en WebRTC;
Door een goed opgeleide ontwikkelaar in te huren, kun je het potentieel ervan benutten op elke beschikbare frontend die deze taal ondersteunt;
JS is een taal die nu al enkele jaren de hitlijsten aan het beklimmen is, en er is geen indicatie dat dit op enige manier zal veranderen.

Om mijn weliswaar bevooroordeelde mening te geven - gebruik maken van JavaScript's optie om dezelfde code te hergebruiken op alle beschikbare fronten is iets dat de ontwikkeling van applicaties zeker zal versnellen en het aantal ontwikkelaars zal verminderen dat betrokken is bij het onderhouden van de backend van applicaties die geschreven zijn in andere technologieën. Laten we ter bevestiging het feit in herinnering roepen dat een groot aantal zogenaamde IT-giganten dit patroon volgt en een behoorlijk deel van de codebase deelt over verschillende platforms. Ondanks verschillende meningen over deze taal, moet je rekening houden met het feit dat de gebruiksstatistieken en de tevredenheid over het gebruik van JS van jaar tot jaar groeien en de ontwikkelaars kunnen gemakkelijk aanhaken bij de trend van full stack.

Lees meer:

Waarom je (waarschijnlijk) Typescript zou moeten gebruiken

Hoe help je een project niet om zeep met slechte codeerpraktijken?

Strategieën voor het ophalen van gegevens in NextJS