Om du är en vanlig person i IT-branschen är chansen stor att du någon gång under din hyperproduktiva dagliga rutin med att skrolla igenom internetskräp snubblat över en av de otaliga JavaScript-memes som finns på interwebben just nu. Ja, jag har också sett dem, och jag har sett dem alla. Men även om det anses vara en bokstavlig meme i samhället, står JavaScript för närvarande som det mest använda språket i världen med 69%. Det är bra. Detta har dock inte alltid varit fallet, så idag ska vi gräva i hur, och viktigast av allt, varför ett skriptspråk dominerar programmeringslandskapet 2021.
Traditionellt sett är en redemption arc ett berättartekniskt grepp där en karaktär som är ond och destruktiv sonar sina brister och övervinner dem och förvandlas från skurk till hjälte. Men med tanke på omständigheterna och det hatkärleksförhållande som samhället har utvecklat till JavaScript (eller kanske dess ökända utvecklare?) genom åren, är det upp till läsarens hjärta att avgöra om det slutade som skurken eller hjälten ❤.
Nej, jag pratar inte om det utmärkta JavaScript-testramverket (som du absolut bör använda i dina projekt, BTW). Jag pratar om Mocha från 1995. Det stämmer - Mocha var det första namnet på det som senare skulle bli känt som JavaScript.
Allt började med Brendan Eich, som 1995 anställdes av Netscape Communications Corporation med det enda syftet att implementera Scheme (en dialekt av programmeringsspråket Lisp) i deras kommande webbläsare - Netscape 2.0. Du förstår, på 90-talet var internet en ospektakulär plats. Det hände inte mycket och det mest spännande man kunde stöta på var en bild. Av vad som helst. Naturligtvis trodde folket på Netscape att de behövde någon form av goo för att hjälpa dem att göra surfupplevelsen lite mer spännande. Java var programmeringens Michael Jordan på den tiden, men det ansågs vara för mycket för den enkelhet och användarvänlighet som de letade efter. De ville ha ett skriptspråk som skulle interagera med DOM, vara lika enkelt som HTML och CSS och likna Javas syntax. På så sätt föddes Mocha .
Mocha ärvde funktionaliteten från Scheme (ja, det mesta av den), objektorienteringen från Self (det hade objekt, OK?) och Javas syntax. Det tog Eich tio dagar att utveckla det. Tio. dagar. Låt det sjunka in en stund. Det förklarar verkligen en hel del. Namnet Mocha var inte särskilt långlivat, eftersom det döptes om till LiveScript kort efter lanseringen. Några månader senare döptes det om till JavaScript, i samförstånd med Sun Microsystems.
1997 tog European Computer Manufacturer's Association, även känd som ECMA, in JavaScript i sin Hall of Fame, vilket innebär att det uppfyllde deras ECMA-262-standard. För att göra en lång historia kort - det är en JavaScript-standard som är avsedd att säkerställa och standardisera utbyte och användning av information om webbsidor i olika webbläsare. Den skulle senare bli känd som ECMAScript som ett resultat av en kompromiss efter en hel del namntvistdrama som involverade Microsoft och Netscape. Eich avskydde namnet eftersom han tyckte att det lät som en hudsjukdom. Ju mer du vet, desto bättre.
I början användes JavaScript för att åstadkomma det som CSS gör idag med lätthet - rullgardinsmenyer, rullande text, muspekare osv. Det var ett enkelt skriptspråk. Så för att verkligen förstå den fortsatta utvecklingen av JavaScript måste du förstå hur webben fungerade förr i tiden. Duh.
Varje användaråtgärd som att klicka på en flik, skicka in ett formulär eller expandera innehåll skulle kräva att servern bearbetade händelsen och laddade en ny sida, vilket var superineffektivt. Allt innehåll på sidan försvann och sedan dök den nya sidan upp. Varje gång webbläsaren laddade om en sida på grund av en mindre förändring måste allt innehåll skickas på nytt. Detta belastade servern ytterligare och gjorde bandbredden till en begränsande prestandafaktor. Ärligt talat, från en mental synvinkel, vet jag inte hur de gjorde det. Jag får klåda bara av tanken på det.
Eftersom Internet Explorer var den obestridda kungen av webbläsare i början av 2000-talet introducerade Microsoft ett nytt bibliotek i en av sina utgåvor. De utvecklade det internt för sin första webbprodukt - Outlook och kallade det bekvämt för XMLHttpRequest-objektet . Ett underbart namn, jag vet. Det här biblioteket användes för att skicka, ta emot och begära data från en server i bakgrunden, så att webbsidan kunde uppdatera specifik information via JavaScript utan att behöva ladda om hela sidan. Jag kan inte nog betona hur viktigt detta var på bred front, eftersom det möjliggjorde en helt ny generation webbappar - SPA:er (Single Page Applications), med Gmail 2004 och Google Maps 2005 som de mer framträdande som tidigt anammade detta koncept.
Helt plötsligt började termen AJAX dyka upp ur tomma intet. Nej, det var inte fotbollsklubben, men vad var det? Kan man äta det? Det visade sig att det inte var en chokladkaka, utan en bred grupp webbtekniker som användes för att implementera webbapplikationer som kommunicerar med en server i bakgrunden, utan att störa sidans aktuella tillstånd. Close. Det är en förkortning av Asynchronous JavaScript and XML, och det var verkligen det som gjorde det möjligt för JavaScript att ta nästa steg. Det innehöll HTML och CSS för presentation, JSON eller XML för datautbyte, XMLHttpRequest-objektet för asynkron kommunikation och JavaScript ... Tja, för att binda dem. Tack, Frodo.
Inte långt efter att AJAX blev känt började de första problemen dyka upp. Det verkade som om JavaScript inte var tillräckligt moget för att hantera storskaliga applikationer enkelt, eller någon applikation alls. Ya boy var inte redo. Subtila skillnader i webbläsarimplementeringar gjorde det till en mardröm att underhålla alla typer av projekt. Världen behövde en lösning, och den behövde det snabbt. In med dig: Ramverk.
PrototypeJS, Scriptaculous och MooTools var pionjärerna som abstraherade mycket av den funktionalitet som utvecklare ville ha till ett rent och lättlärt ramverk. Den mest framträdande av dem vid den tiden var jQuery. När det lanserades 2006 sköt dess popularitet i höjden omedelbart. När jQuery senare togs i bruk av Gmail visade det att det gick att bygga större applikationer som var relativt lätta att underhålla, men redan då stod det klart att det behövdes mer företagsvänliga verktyg.
Alla kommande ramverk försökte bygga vidare på det som de tidigare var bra på, och lägga till det som de saknade. Backbone var det första ramverket vars enda syfte var att bygga SPA:er, och det åtgärdade en av de största bristerna som jQuery led av - selector- och handler-helvetet. Men det var inte förrän Adam Abrons och Misko Hevery skapade AngularJS som världen skulle få se en komplett arkitektur för utveckling av frontend-applikationer. Senare tog Hevery ett jobb på Google och tog bekvämt med sig ramverket med honom. Jag undrar om hans praktikplats var gratis eller betald.
Förutom möjligheten att bygga komponenter för återanvändning var en av AngularJS huvudfunktioner dubbelriktad databindning, vilket innebär att det fanns ett sätt att binda en modells data till HTML-markering, vilket möjliggjorde uppdateringar av DOM i realtid. Sorcery. Knockout och Meteor var ramverk som följde och tillhandahöll liknande funktioner, men det var inte i närheten av vad AngularJS hade att erbjuda vid den tiden.
År 2013 dökReactupp, och vi vet alla hur det gick. Dess utvecklare vill dock inte att man ska kalla det ett ramverk, utan snarare ett bibliotek. Ja, låt oss ” go ” med det. Så, biblioteket som heter React hamnade omedelbart i rampljuset eftersom det utvecklades av Facebook, och blev snabbt en publikfavorit. Det var väl dokumenterat, snabbt och effektivt och introducerade något som kallas Virtual DOM, ett koncept som skulle visa sig vara avgörande för att bygga smidiga webbappar med ännu snabbare och mer precisa datauppdateringar. Och det skämde bort JS-utvecklare. Det hade en brant inlärningskurva, men det skulle belöna alla som behärskade det med sina enorma möjligheter.
Jag trodde inte det.
Det känns som om någon någonstans under resans gång började ställa den här frågan till JavaScript och inte gav sig förrän svaret var jakande. Node.js spelade en avgörande roll i detta genom att utveckla en öppen, plattformsoberoende JavaScript-körtidsmiljö som låter utvecklare skriva kommandoradsverktyg och skript på serversidan utanför en webbläsare. Senare kom några personer på att det skulle vara coolt att skapa mobilappar som skriver JavaScript i form av React Native. Varför skulle man inte göra det? Google portade till och med TensorFlow, sin end-to-end open-source-plattform för maskininlärning, specifikt till JavaScript.
Men varför skulle de inte göra det? Varför skulle inte JavaScript göra allt?
JavaScript utvecklas och optimeras ytterligare via EcmaScript-konventionens uppdateringar, och under årens lopp har det förvandlats till ett moget språk. Det är supersnabbt och klientbaserat, vilket innebär att det i sig minskar serverbelastningen. Det fungerar mycket bra med andra programmeringsspråk eftersom du kan inkludera det på vilken webbsida som helst eller inuti skriptet för ett annat programmeringsspråk. JS finns också överallt och är mycket lättillgängligt. Alla kan börja skriva JavaScript i sin webbläsare just nu.
Type Coercion (ett ämne som jag kommer att täcka djupt i en annan artikel), och utöver att vara löst typat, innebär att JavaScript är mycket förlåtande och lätt att plocka upp för nybörjare. Detta ökade dess attraktionskraft ytterligare, och i slutändan är det därför det blev så populärt och varför alla tävlar om att integrera det i nästa stora grej. Det är en uppåtgående spiral som, så länge marknaden efterfrågar specifika typer av projekt som tillgodoser den genomsnittliga JS-utvecklaren (och det är en rejäl del av dem), förmodligen kommer att fortsätta att utvecklas uppåt.
Så sammanfattningsvis är JavaScript överallt eftersom det är lätt och förlåtande att lära sig. Det är så enkelt. Det är och kommer att vara en färdighet som kommer att göra dig mycket anställningsbar på praktiskt taget alla marknader i alla branscher. Det är ett faktum. Huruvida det är hälsosamt eller inte för det nuvarande programmeringslandskapet är uppe för debatt, men vid ett annat tillfälle.
