JavaScript, en af søjlerne, hvor webindholdsteknikken hviler, har nået Quarter Century Club. Det har eksisteret i lang tid nu, og uanset hvordan du ser på det, er dets betydning ubestridelig.
Her vil jeg tage den ambitiøse opgave analyse af JavaScript-økosystem, startende med at beskrive historien om dette programmeringssprog og senere dække de forskellige front-end- og back-end-teknologier, der findes i det. Men lad os først svare Spørgsmålet hvor det hele begyndte.
JavaScript er et programmeringssprog, der blev oprettet af Brendan Eich i 1995. Det var tidspunktet for browserkrige mellem browsere: Internet Explorer og Netscape Navigator kæmpede for at levere nye funktioner, og der var ingen tid at tabe.
Hr. Brendan Eich, en amerikansk teknolog, arbejdede for Netscape og måtte oprette et programmeringssprog, der ville tillade front-end udviklere at integrere små programmer på websider, hvilket gør dem mere interaktive og dynamiske. Det endelige produkt skulle være fleksibelt, let at lære, have en populær appel og være let implementerbart.
Hr. Eich havde kun 10 arbejdsdage til at producere den første gennemførelse - en kendsgerning, som vi bekræftede med manden selv - men mod oddsene lykkedes det ham at levere.
Her er nogle eksisterende programmeringssprog, der påvirkede resultatet:
Sproget blev udviklet under navnet Mokka og senere udgivet sammen med Netscape under dets nuværende de-facto-navn: JavaScript.
Et uundgåeligt spørgsmål, der ofte opstår på grund af roden til navnet, der har et ret kort svar: Alt undtagen nogle syntakselementer som parenteser, prikker, semikolon, der udtrykker analoge konstruktioner på begge sprog. Det valgte navn var et marketingskridt fra Netscape, for at fremvise sin nye skabelse piggyback på dagens hype: Java.
Da JavaScript var en succes, omkonstruerede Microsoft det for at konkurrere med Netscape og udgav sin egen version under navnet JScript.
Fra begyndelsen var der flere uforeneligheder mellem de forskellige implementeringer af sproget, og for at reducere virkningen af dette problem indsendte Netscape JavaScript til standardisering af Ecma Internationale standardiseringsorganisation i 1997.
Den resulterende standardiserede version blev navngivet ECMAScript og opnåede gradvist universel accept som sprogspecifikation. På trods af dette forblev navnet JavaScript i brug som de facto-navnet på sproget.
For at tilføje nye funktioner til sproget og for at blive kompatible med andre standardiseringsorganisationers arbejde standarden har ændret sig fra tid til anden.
Leverancerne for hver version er kendt som „ECMAScript“, og her vil jeg liste en kort beskrivelse af nogle af de mest relevante ændringer for hver.
Den første version af sprogstandarden.
Denne version blev produceret i 1998, da sproget også var Standardiseret af ISO/IEC. Det opdaterede Ecma-standarden, så den ville matche dokumentet produceret af ISO/IEC.
I 1999 blev der tilføjet flere nye funktioner til sproget. De mest iøjnefaldende var:
• Regulære udtryksbogstaver;
• Nye kontrolerklæringer;
• Undtagelseshåndtering.
Dette udkast blev opgivet i 2008 på grund af uenigheder om dets funktionssæt. Det blev besluttet, at produktionen var for radikal til at blive introduceret, og der var en aftale om at oprette en mellemversion, før en sådan drastisk udvikling ville finde sted.
Den version, der understøttede de fleste browsere i begyndelsen af 2016, blev oprettet i 2009. Dens mest mærkbare funktioner var:
• Iterationsfunktioner i høj orden (kort, reducere, filtrere, forAach);
• JSON-understøttelse;
• Gettere og settere;
• Bedre refleksion og objektegenskaber;
Ligesom ECMAScript 2 blev denne specifikation produceret for at tilpasse Ecma-standarden til det dokument, der blev produceret af ISO/IEC til ECMAScript 5.
Denne version tilføjede flere store ændringer i 2015, nemlig:
• løfter.
• Moduler;
• Klasser;
• Variabeldeklarationer med blokområde (lad);
• Pilefunktioner;
• Skabelon bogstavelig;
• Spreadoperatør;
• Afstrukturering af opgave;
• Parameter standardværdier;
• Hvileparametre;
• Symboler;
• Generatorfunktioner.
Denne version kun lavet mindre ændringer <Array.includes>til sproget, såsom at tilføje en eksponentieringsoperator og specificere metoden.
Browserunderstøttelsen til denne version er ufuldstændig, selvom der er en transpiler, der konverterer ES6-kode til ældre ES-versioner.
Tilføjer hovedsageligt understøttelse af async-funktioner.
Denne version udvider regulære udtryksværktøjssæt samt introducerer hvile og spredt operatorer til objektbogstaver. Det endelig introducerer <Promise.finally>som en pæn måde at strømline adfærd på, der altid skal forekomme uafhængigt af løftets resultat.
Den tiende interaktion bragte <Array.flat>og <Array.flatMap>metoder sammen med lempelse af fangstblokfejlbinding, der fik øget opmærksomhed fra ES2017s introduktion af asynkron og vente.
Mens udkastet til denne version langt fra når sit ellevte time, vi kan allerede tælle med Nullish Coalescing-operatør og Valgfri kædeoperatør det vil utvivlsomt øge kodelæsbarheden.
<Promise.all>Promises vil også udvide sin api med AllSettled, et alternativ til det løser altid med en beskrivelse af hvert løftes resultat uanset hvor de løser eller bliver afvist.
Mens JavaScript startede sin rejse med at adressere nødvendigheden af at gøre websider mere interaktive og dynamiske, er det kommet langt, og gennem flere iterationer lykkedes det også at konsolidere en rolle som back-end-sprog.
Efter at have erobret bagenden var mobilverdenen et åbent felt.
Det var med fremkomsten af AJAX i 1999 (standardiseret i 2006) fik JavaScript endnu en vind. Før AJAX blev JavaScript mest brugt til at animere og give interaktivitet til nogle websider. Men da denne interaktivitet ikke ville indebære udveksling af data med serveren - ville den kun bestå af tilbehørsdisplay-logik.
Med AJAX begyndte JavaScript at udføre nøgleopgaver i vores web-applikations-applikationslogik, til det punkt, at det i dag er svært at finde web-applikationer, der ikke kræver en browser med JavaScript aktiveret for at fungere. Det var efter denne ændring, at JavaScript-økosystemet begyndte at ekspandere som et programmeringssprog på klientsiden.
De vigtigste behov hos udviklerne, der arbejder med AJAX webapplikationer, er:
• Udførelse af AJAX opkald;
• Manipulering af Document Object Model (DOM) - datastrukturen, der opbevares af browseren, der repræsenterer websidens struktur;
• Reagere på brugerens interaktioner.
De centrale JavaScript-funktioner, der leverede disse funktioner, var ikke særlig praktiske, og nogle gange var deres adfærd ikke kompatibel med forskellige browsere.
De første biblioteker, der blev populære, behandlede netop disse tre opgaver og leverede en samling funktioner og objekter, der gjorde disse operationer nemme og funktionelle i enhver browser. Nogle af disse biblioteker vil også give masser af andre generelle funktioner:
EN JavaScript-ramme der blev udgivet i 2005 som en del af Ruby on Rails AJAX support. Det udvidede direkte mange JavaScript-kerneobjekter med adfærd, der ville ligne Ruby-programmeringssproget, og tilføjede også et klassebaseret system til sproget.
Disse kerneudvidelser blev betragtet som besværlige af andre programmeringssamfund, og de leverede funktioner var underligere end følgende konkurrerende bibliotek:
Den jQuery ramme blev udgivet i 2006 og har - i modsætning til Prototype - ladet sproget kerne som det var og snarere fokuseret på at levere masser af funktionaliteter relateret til DOM, begivenheder, asynkronicitet og effekter.
En funktion at fremhæve er, at jQuery understøtter et plugin-system, der gør det muligt for biblioteksprogrammerere at udvide sin funktionalitet. Dette bibliotek var det mest succesrige bibliotek af denne artog bliver det uundværlige værktøj til Front-end udvikling, bruges i dag på de fleste hjemmesider.
På trods af jQuery's enorme popularitet, såvel som dens evne til at levere mange nyttige funktionaliteter, Det er vigtigt at bemærke, at moderne versioner af JavaScript allerede giver mange af de funktionaliteter, der gjorde jQuery populær. Måske Du har muligvis ikke brug for jQuery i det hele taget.
Det bliver mere og mere populært ikke at bruge jQuery og snarere at stole på enten kun de aktuelle centrale JavaScript-funktioner eller på biblioteker, der er specialiserede i hver specifik opgave (f.eks. Fetch til AJAX-opkald).
Mens du bruger DOM-manipulationsbiblioteker, er det almindeligt at opbevare applikationsdataene i selve DOM, så der er DOM-manipulationsvælgerfunktioner, der skal kaldes, når du har brug for at få adgang til eller ændre disse data.
Denne form for kode er ofte fyldt med selektornavne og bliver let et rod, efterhånden som applikationens kompleksitet udvikler sig. Der er et sæt rammer, der giver os mulighed for at løse dette problem på en elegant måde ved at udnytte applikationsmønstre, der ligner de berømte Model-View-Controller (MVC) mønster.
På den anden side der er en nylig tendens, hvor web-applikationer er fuldt indlæst i browseren ved den første sideindlæsning, udfører alle efterfølgende operationer via AJAX.
Denne form for applikationer kaldes Applikation på én side (SPA) og da deres kode ofte er ret detaljeret og kompleks, det anbefales at vælge en af disse rammer, når du implementerer en SPA. Lad os se på nogle af dem.
Rygrad er en Model-View-Presenter (MVP) ramme udgivet i slutningen af 2010. det er fokuseret på SPA'er og håndhæver adskillelsen mellem applikationslogik, displaylogik og skabeloner.
Kommunikationen mellem disse enheder styres på en hændelsesbaseret måde, og den understøtter også en Router-klasse, der gør det muligt for applikationerne at reagere på webadresser og opdatere disse i henhold til de udløste begivenheder.
kantet er en ramme implementeret af Google, der plejede at følge en MVC-arkitektur, og som har udviklet sig til en MVVC-ramme. I lighed med Backbone er det fokuseret på SPA'er og håndhæver adskillelsen mellem applikationslogik, displaylogik og skabeloner.
Det er interessant at bemærke, at Angular giver programmøren mulighed for at udvide HTML ved at oprette nye tags, der kan bruges i skabelonerne, og som indkapsler dele af siden.
Et andet særpræg er, at det tillader etablering af tovejs databindinger mellem skabelonerne og JavaScript-objekterne, der skal gengives af dem.
På denne måde vil enhver opdatering af disse objekter automatisk udløse HTML-opdateringer, og - på lignende måde - opdateres JavaScript-objekterne, når deres tilsvarende skabeloninputfelter ændres.
Som vi har beskrevet i de foregående afsnit, flyttede displaylaget i vores webapplikationer fra en simpel beregningsmodel, hvor grænsefladen, der skulle vises, kun var funktion af nogle data beregnet af serverkoden til noget meget mere dynamisk og komplekst, hvor det ville afhænge ikke kun af de hentede data, men også af brugerinteraktioner og scripts, der behandlede disse.
Denne kompleksitet oversætter sig ofte til kompleks kode, der er svær at dele og ræsonnere om. Således begyndte nogle mennesker på Facebook at eksperimentere med en enklere beregningsmodel til at kode front-end. En beregningsmodel, der giver os mulighed for at tænke på, hvad der vises på siden igen som et resultat af tilstanden af nogle få variabler i stedet for resultatet af interaktionen mellem en „zillion“ af Model-View-Controller-klasser.
For at få en sådan ændring til at finde sted, måtte der ske noget radikalt: hvis vi ønskede, at displayet kun skulle være resultatet af at anvende en funktion på nogle tilstandsvariabler, ville vi være nødt til at stoppe med at manipulere dele af DOM direkte og i stedet gengive hver version af displayet som helhed.
Da gengivelse af hele DOM, når du ændrer noget i det, ville være for langsomt, det blev besluttet at kortlægge DOM på en let repræsentation af den, der ville være let at regenerere og sammenligne.
Således når vi ændrer en variabel, er vi i stand til at generere en ny version af denne lette repræsentation og sammenligne den med dens tidligere versionog dermed beregne, hvilke dele af DOM der skal opdateres. Vi kalder Virtual DOM til denne lette repræsentation af DOM.
Reagere var den første ramme til at bruge en Virtual DOM. Det blev oprettet af Facebook, og arkitekturen, der skal følges af applikationerne, der bruger den, er minimal.
Med hensyn til MVC holder React sig ikke til det og handler snarere kun om View-delen af koden. Med det er visningen repræsenteret som et træ af enheder kaldet komponenter, der kan være sammensat af andre komponenter selv.
En komponent har en vis tilstand, kan modtage egenskaber ved oprettelse og ved, hvordan man gengiver sig selv for et givet sæt egenskaber og tilstandsvariabler. Hver gang dens tilstand ændres, gengives en ny version af skærmens virtuelle DOM og sammenlignes med dens tidligere version, og den nødvendige DOM opdateres i overensstemmelse hermed.
Hvis nogle interaktioner udført på en given komponent skal ændre tilstanden for overordnede komponenter, skal den overordnede komponent videregive håndteringskoden til underkomponenten i form af et tilbagekald. Denne tilgang garanterer, at komponenter er løst koblet indbyrdes, hvilket gør dem ret nemme at genbruge.
Et ret kontroversielt valg taget af skaberne af denne ramme er, at i stedet for at bruge HTML-skabeloner som de andre rammer, skrives en HTML-lignende repræsentation af koden som XHTML blandet i JavaScript-koden, hvilket kræver brug af en compiler, der ved, hvordan man transformerer denne JS- og XHTML-blanding (kaldet JSX) til HTML-genererende JavaScript.
Den komponentbaserede tilgang til React er effektiv til mindre applikationer, men til strukturering af større applikationer foreslår Facebook en arkitektur kaldet Flux, hvor applikationens tilstand gemmes væk fra komponenterne i noget, der kaldes tilstandscontainere.
Den oprindelige implementering af Flux-arkitekturen var ret kompleks men der er en enklere, der hedder Redux det er den mest populære og er endda blevet brugt til at implementere applikationens back-ends.
Dens arkitektur er funktionel, og i stedet for direkte muterende tilstand er programmøren beregnet til at oprette nye versioner af den ved at anvende reduktionsfunktioner, hvilket muliggør let Ando/Redo og tidsrejsende fejlfinding.
Vue startede som en MVC-ramme svarende til Angular, men fokuserede på at være enklere og kræve mindre boilerplate. Den sidste version har allerede en komponentbaseret tilgang og en Virtual-DOM på en lignende måde som React gør.
Dokumentationen beskriver det som en progressiv ramme, i den forstand, at det menes at blive gradvist vedtaget og dermed give en bruger mulighed for at starte med kun at bruge visningsdelen af rammen og senere tilføje mere kompleksitet, hvis det er nødvendigt. Der er fokus på at reducere boilerplate og antallet af filer, der bruges, når det er muligt.
Ved udvikling af komplekse webapplikationer bemærkede folk, at når der hentes data gennem AJAX-opkald, var der ofte underhenting og overhentning, samt at det ikke var let at administrere caching.
For at løse dette problem udviklede Facebook et forespørgselssprog, der gør det muligt at beskrive de data, hver del af grænsefladen har brug for. Disse forespørgsler er beregnet til at blive fortolket og aggregeret til effektive sæt af AJAX anmodninger af en GraphQL-klient.
Der er mindst to GraphQL-klienter tilgængelige:
• Relæ, den tidligere implementering af Facebook, meget sammenfiltret sammen med React;
• Apollo, som stræber efter at være et rammeagnostisk projekt.
På trods af at JavaScript blev brugt på serversiden siden midten af 90'erne, var implementeringerne ret langsomme, og der var et ikke klart svar på, hvordan man kører JavaScript i back-end før 2008, da Google offentliggjorde V8 JavaScript-motoren bundtet sammen med den første version af Chrome-webbrowseren.
Ved implementering af den opfordrede V8-motor, Google brugte optimeringsteknikker, der begge var blevet skabt under udviklingen af allerede glemte programmeringssprogkompilatorer, nemlig Selfs og Strongtalk's kompilatorer. Resultatet var bemærkelsesværdigt hurtigt for et dynamisk indtastet programmeringssprog som JavaScript, hvilket kraftigt overgik andre implementeringers ydeevne.
På den anden side blev både Chrome og V8 frigivet som open source-software (med en BSD-licens), hvilket gjorde det muligt for enhver at bygge deres arbejde oven på dem og distribuere dem som en del af enhver software uden at skulle betale royalties til Google.
Det tog ikke lang tid, før Ryan Dahl, en amerikansk softwareingeniør, skabte et miljø kaldet Node.js hvor JavaScript kunne køres på V8 væk fra browseren. Udover at bringe V8 til serversiden er Node også hændelsesdrevet, hvilket gør det muligt at skrive eventuelle blokerende IO-operationer på en ikke-blokerende asynkron måde.
Denne måde at adressere IO sammen med den hurtige V8 gjorde Node velegnet til at udvikle realtidsapplikationer på serversiden, der krævede hurtigheden af ikke-blokerende IO sammen med ekspressiviteten af et programmeringssprog på højt niveau som JavaScript.
Da JavaScripts kernespecifikation er ret lille og ikke tænkt på serversiden, kræver det normalt masser af eksterne biblioteker at bruge den til en sådan opgave. Der er behov for at have en pakkehåndtering til Node, hvilket giver udviklere mulighed for at udgive pakker og nemt hente biblioteker, der skal inkluderes i udviklerens applikationer.
Den Nodepakkehåndtering (NPM) er sådan pakkehåndtering, lige i stil med Perls CPAN eller Ruby's RubyGems.
Der var nogle forsøg på at samle både værktøjet og teknologierne, der havde til formål at skabe full-stack applikationer. Her vil jeg tale om tre af disse forsøg.
Meteor er en webramme, der bruger MongoDB som database. Den bruger en publicerings-abonneringsprotokol, der anvendes på ressourcer, så klienter kan få opdateringer, når dataene opdateres på serveren. Det kan bruges med enhver ramme på klientsiden.
Den BETYDE stack står for en pakke med følgende sæt teknologier:
• MongoDB;
• Ekspres;
• Vinklet;
• Knude.
Det leveres også med det „gennemsnitlige“ kommandolinjeværktøj, der gør det muligt at generere projekter, filer og udføre andre nyttige kommandolinjeopgaver.
MERN Stack ligner MEAN, men fokuserer på React snarere end Angular.
Mens JavaScript erobrede internettet, gjorde det også fremskridt som en mobil applikationsudviklingsteknologi. Det vælges ofte som en måde at håndtere mobil på en cross-platform måde.
Apache Cordova muliggør udvikling af mobile applikationer ved hjælp af JavaScript CSS og HTML. Det understøtter også en FFI-mekanisme, hvorigennem programmører kan inkludere dele af native kode og nemt oprette broer mellem JavaScript og native funktionalitet.
Mens Apache Cordova tillader at udvikle mobile applikationer med JavaScript, giver det ikke de funktioner på højt niveau, der er nødvendige for at gøre det. Ionic er en ramme, der giver sådan funktionalitet: widgets, skærmovergange og anden funktionalitet. Det følger en MVC-arkitektur.
React Native anvender Reacts-komponentbaseret adgang til mobiludviklingen, men i stedet for at køre JavaScript og lade det interagere med native kode kompilerer det snarere JavaScript til native kode.
Nativescript fremstår som en anden populær ramme til at bringe Angular og Vue.js webapplikation til mobilverdenen, der tilbyder en ensartet JavaScript-API til at interagere med mobile enheder
Som browsersprog, JavaScript gemte sætninger for at specificere afhængigheder mellem filer og for at bede kompilatoren om at indlæse disse. For at løse dette problem var der to forskellige API'er, der blev specificeret og konkurreret om denne opgave:
• Asynkron moduldefinition (AMD);
• CommonJS-moduler;
• ES6-moduler.
I ES5-verdenen implementerede Node.js CommonJS-moduler, mens front-end-programmerere foretrak AMD, hvilket skabte kaos på dette felt. Der blev således specificeret en måde at kræve moduler på og erklære dem kaldet Universalmoduldefinition (UMD), hvilket er ret grimt, men gør moduler kompatible med begge modul-API'er.
Under alle omstændigheder hjælper denne rod ved vedtagelsen af ES6 - der allerede understøtter konstruktioner på sprogniveau, der sigter mod at håndtere moduler.
Når du bruger moduler, mens du udvikler webapplikationer, er der ofte behov for at fusionere de forskellige modulfiler til en enkelt fil, der skal inkluderes af webapplikationen. Der er to biblioteker, der giver udviklere mulighed for at udføre denne opgave:
Browserify er den ældste webmodulbundter og giver udviklere mulighed for at bruge CommonJS-modulets syntaks, når de programmerer webapplikationer.
Webpack er en mere moderne webmodulbundler, der ikke kun samler JavaScript, men også andre aktiver såsom billeder og CSS. Det gør det muligt at genindlæse de forskellige aktiver i browseren, når der er en ændring i modulkoden.
Da ikke alle er tilfredse med hverken JavaScript-sproget eller dets understøttelse af browsere, er der blevet produceret flere transpilere, der konverterer andre programmeringssprog til browserunderstøttede JavaScript-versioner. Herefter følger et par eksempler på disse:
Babel er en transpiller, der konverterer moderne JavaScript til ældre, browserunderstøttet JavaScript. Det kan tilpasses meget og tillader krydskompilering mellem flere JavaScript-versioner.
Websamling (også kendt som wasm) er et bytecodeformat, der nu understøttes af alle større browsere som et alternativ til JavaScript. I øjeblikket er der få kompilatorer, der er målrettet mod Web Assembly. Det skal bemærkes, at Web Assembly indtil videre ikke har en affaldssamler.
Når du kompilerer til wasm, skal du således enten bruge et programmeringssprog, der ikke kræver nogen affaldssamler, eller på anden måde bliver nødt til at kompilere en runtime, der muliggør indsamling af affald sammen med den resterende applikation/modul.
Denne transpiler, oprettet af Microsoft, konverterer et gradvist indtastet supersæt af JavaScript kaldet TypeScript ind i JavaScript.
Flow er en statisk type checker udviklet af Facebook. Som Typescript er det et gradvist skrevet system, selvom Flow kun er fokuseret på typerne og ikke tilføjer noget andet til sproget udover typesystemet.
Elm Det er en ramme og en rent typet funktionelt programmeringssprog inspireret af Haskell der kompilerer til JavaScript og følger den samme arkitektur som Redux, som er stærkt inspireret af Elm.
I modsætning til andre statiske typesystemer garanterer denne 100% typegodkendelse gennem typeinferens, hvilket ikke kræver, at programmereren eksplicit indtaster nogen typeunderskrift overhovedet. Typesystemet er så sikkert, at det ikke tillader nogen runtime-undtagelse.
Dette er Facebooks adgang til at bruge et indtastet funktionelt programmeringssprog til at generere JavaScript. ReasonML har O'Caml-semantik og en JavaScript-venlig curly-braces-baseret syntaks. Det kan ses som en Elms fætter, der ikke er så opsat på funktionel renhed, og som støttes af Facebook.
Efterhånden som projekterne bliver større, og der er behov for at transformere deres aktiver til at køre dem, er der behov for at skrive scripts, der styrer udførelsen af disse transformationer - noget som at lave, ante eller rive. Der er to afhængighedsbaserede opgaveløsninger implementeret i JavaScript:
En ældre, der hedder Grynt - hvor data, der er mellemliggende for de forskellige transformationstrin, opbevares i midlertidige filer. Og Gulp - hvilket er en nyere, der bruger mindre hukommelse i stedet for midlertidige filer.
Da JavaScript er et sprog født ud af browseren, hvorfor kunne vi ikke bruge det til at udvikle serversiden af vores webapplikationer? Express er rammen for at tackle dette problem. Det sigter mod at være minimalistisk (som Sinatra), selvom der er masser af store biblioteker udviklet til det (f.eks. Automatisk BackOffice-generation).
Da V8 blev brugt til at oprette Node, blev den også brugt som tolk af MongoDB dokumentorienterede database. Når du interagerer med databasen, deles dataene i JSON-lignende strukturer, og forespørgselsprogrammet handler om at kalde JavaScript-funktioner. Dette gør denne database meget populær blandt JavaScript-udviklere.
Yeoman er en interaktiv projektskeletgenerator skrevet i JavaScript. Det giver mulighed for at oprette masser af JavaScript-projekttyper med forskellige konfigurationer - selvom det ikke kun er rettet mod JavaScript, kan det også bruges til at generere skeletter af Java-projekter, for eksempel.
Rails-udvikler med 10+ års erfaring med forskellige teknologier. Jeg er interesseret i funktionel programmering.
People who read this post, also found these interesting:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
