Mobiel? Web? Het maakt me niet uit.<\/h2>\n
Laten we zeggen dat we een applicatie willen bouwen die de React<\/a> 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, berekenen, filteren gegevens<\/a> enzovoort, kunnen worden gedaan met React-haken. 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 besparingen:<\/p>\n Om deze paragraaf samen te vatten - het is niet zo dat \u00e9\u00e9n codebase alle versies van de applicatie zal aandrijven, hoewel we de gedeelde code kunnen splitsen en in elke op gebruiken om de ontwikkelingsproces<\/a> echt sneller.<\/p>\n 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.<\/p>\n 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<\/strong>. De ontwikkeling van deze taal is verbazingwekkend en de vruchten ervan kunnen tot op de dag van vandaag worden geplukt.<\/p>\n Waar heb ik het over? Als je de juiste JS-ontwikkelaars<\/strong>Het 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 <\/strong> kan op twee populaire manieren worden ge\u00efmplementeerd - in een uitbreidbare en configureerbare modus, die express.js ons kan bieden, en in een gestructureerde modus met behulp van DI pattern - nest.js.<\/p>\n 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.<\/p>\n 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 hier gebruikt moet worden is TypeScript<\/a> - Het stelt ons onder andere in staat om een codebase te delen, d.w.z. een gemeenschappelijke gegevenstype-definitie voor alle platformen.<\/p>\n Met applicaties die alleen gebouwd zijn op de JavaScript<\/a> <\/strong>\/ TypeScript<\/strong> 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?<\/p>\n Het blijkt dat technologie\u00ebn 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<\/a> 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.<\/p>\n Het blijkt dat Slack ook webtechnologie\u00ebn (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\u00ebn maakt het veel eenvoudiger, sneller en in het algemeen mogelijk om applicaties voor verschillende platforms tegelijk te ontwikkelen.<\/p>\n Aan het frontend-gedeelte van de applicatie te zien, is er geen illusie dat JS <\/strong>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.<\/p>\n 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.<\/p>\n Veel cloud-providers bieden SDK's waarmee je direct gebruik kunt maken van cloud<\/a> methoden. Vreemd genoeg is een van de populairste tabbladen, direct naast C#, Go en Java<\/a>is Node.js<\/a>. Het blijkt dat dit platform ideaal is voor het schalen en bouwen van applicaties gebaseerd op microservices<\/a> 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, AWS<\/a>, Azuur<\/a>) van cloudproviders kunnen we applicaties bouwen met behulp van knooppunt<\/a>.js.<\/p>\n 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\u00ebren 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.<\/p>\n 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 \u00e9\u00e9n taal kent beide kanten (full stack) van een applicatie kan beheersen.<\/p>\n 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.<\/p>\n 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.<\/p>\n Ik heb de prestaties en benchmarks al in detail besproken in dit artikel. <\/p>\n 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 \ud83d\ude42 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.<\/p>\n 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.<\/p>\n Laten we JS en PHP<\/a> 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\u00ebn kunnen gebruiken, zoals webrtc of websockets.<\/p>\n Als we alle paragrafen samenvatten, kunnen we een paar feiten noemen:<\/p>\n JavaScript<\/strong> is een taal die kan worden gebruikt om allerlei soorten toepassingen te bouwen - van web tot mobiel tot desktop; 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\u00ebn. 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 <\/strong>van jaar tot jaar groeien en de ontwikkelaars kunnen gemakkelijk aanhaken bij de trend van full stack.<\/p>\n Lees meer:<\/b><\/p>\n Waarom je (waarschijnlijk) Typescript zou moeten gebruiken<\/a><\/p>\n Hoe help je een project niet om zeep met slechte codeerpraktijken?<\/a><\/p>\n\n
Maar hoe zit het met de achterkant?<\/h2>\n
Kan JS desktopapplicaties aandrijven?<\/h2>\n
Is JS volwassen genoeg?<\/h2>\n
![\"Node.js](\"\/app\/uploads\/2024\/05\/zrzut-ekranu-2021-08-24-o-12.13.12.png\" "\\"Cloud")
<\/p>\n![\"Node.js](\"\/app\/uploads\/2024\/05\/zrzut-ekranu-2021-08-24-o-12.13.25.png\" "\\"Snelstarts")
<\/p>\nIs JS snel genoeg?<\/h2>\n
Is JS niet zo'n eigenaardigheid onder andere talen?<\/h2>\n
Meng alles door elkaar<\/h2>\n
\nToepassingen geschreven in JS kunnen verschillende codefragmenten met elkaar delen, zoals de fragmenten die verantwoordelijk zijn voor gegevensopmaak of types in Typescript;
\nDankzij de groei van het web zijn de prestaties die JS biedt goed genoeg om te kiezen voor zowel frontend- als backendapplicatieontwikkeling;
\nDankzij het ongebruikelijke ontwerp kan de JavaScript moderne applicatie-infrastructuren ondersteunen, zoals websockets en WebRTC;
\nDoor een goed opgeleide ontwikkelaar in te huren, kun je het potentieel ervan benutten op elke beschikbare frontend die deze taal ondersteunt;
\nJS 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.<\/p>\n![\"Advies](\"\/app\/uploads\/2024\/05\/cta_2.jpeg\")
<\/a><\/p>\n