JavaScript, en av pelarna där webbinnehållstekniken vilar, har nått Quarter Century Club. Det har funnits länge nu och oavsett hur du tittar på det är dess betydelse obestridlig.
Här kommer jag att ta den ambitiösa uppgiften att analysera JavaScript-ekosystem, börjar med att beskriva historien om detta programmeringsspråk och senare täcka de olika front-end- och back-end-tekniker som finns i det. Men låt oss först svara Frågan där allt började.
JavaScript är ett programmeringsspråk som skapades av Brendan Eich 1995. Det var tiden för webbläsarkrig mellan webbläsare: Internet Explorer och Netscape Navigator kämpade för att tillhandahålla nya funktioner och det fanns ingen tid att förlora.
Herr Brendan Eich, en amerikansk teknolog, arbetade för Netscape och var tvungen att skapa ett programmeringsspråk som skulle tillåta frontend-utvecklare att bädda in små program på webbsidor, vilket gör dem mer interaktiva och dynamiska. Slutprodukten måste vara flexibel, lätt att lära sig, ha ett populärt tilltal och vara lätt att implementera.
Herr Eich hade bara tio arbetsdagar på sig att producera det första genomförandet - ett faktum som vi bekräftade med mannen själv - men mot oddsen lyckades han leverera.
Här är några befintliga programmeringsspråk som påverkade resultatet:
Språket utvecklades under namnet Mocka och, senare, publicerad tillsammans med Netscape under dess nuvarande de facto-namn: JavaScript.
En oundviklig fråga som ofta uppstår på grund av roten till namnet, som har ett ganska kort svar: Allt, förutom vissa syntaxelement som parenteser, prickar, semikolon, som uttrycker analoga konstruktioner på båda språken. Det valda namnet var ett marknadsföringsdrag av Netscape, för att visa upp sin nya skapelse piggybacks på dagens hype: Java.
Eftersom JavaScript var en framgång konstruerade Microsoft det för att konkurrera med Netscape och publicerade sin egen version under namnet JScript.
Från början fanns det flera inkompatibiliteter mellan de olika implementeringarna av språket och, för att minska effekterna av detta problem, skickade Netscape JavaScript för standardisering av Ecma internationella standardiseringsorganisation 1997.
Den resulterande standardiserade versionen fick namnet ECMAScript och uppnådde gradvis universell acceptans som språkspecifikation. Trots detta, namnet JavaScript förblev i bruk som de facto-namnet på språket.
För att lägga till nya funktioner i språket och för att bli kompatibla med andra standardiseringsorganisationers arbete, standarden har ändrats från tid till annan.
Leveranserna för varje version kallas ”ECMAScript” och här listar jag en kort beskrivning av några av de mest relevanta ändringarna för varje version.
Den första versionen av språkstandarden.
Denna version producerades 1998 när språket också var Standardiserad enligt ISO/IEC. Den uppdaterade Ecma-standarden så att den skulle matcha dokumentet som producerats av ISO/IEC.
År 1999 lades flera nya funktioner till språket. De mest iögonfallande var:
• Literaler för reguljära uttryck;
• Nya kontrolluttalanden;
• Undantagshantering.
Detta versionsutkast övergavs 2008 på grund av oenigheter om dess funktionsuppsättning. Det beslutades att produktionen var för radikal för att införas och det fanns en överenskommelse om att skapa en mellanversion innan en sådan drastisk utveckling skulle äga rum.
Den version som stödde de flesta webbläsare i början av 2016 skapades 2009. Dess mest märkbara funktioner var:
• Iterationsfunktioner i hög ordning (karta, minska, filtrera, förEach);
• JSON support;
• Getters and setters;
• Better reflection and object properties;
Just like EcmaScript 2, this spec was produced to align the Ecma standard with the document that was produced by ISO/IEC for EcmaScript 5.
This version added several big changes in 2015, namely:
• Promises.
• Modules;
• Classes;
• Block-scoped variable declarations (let);
• Arrow functions;
• Template literal;
• Spread operator;
• De-structuring assignment;
• Parameter default values;
• Rest parameters;
• Symbols;
• Generator functions.
This version only made minor changes to the language, such as adding an exponentiation operator and specifying the <Array.includes> method.
The browser support for this version is incomplete though there is a transpiler that converts ES6 code into older ES versions.
Mainly adds support for async functions.
This version expands regular expressions' toolkit as well as introducing the rest and spread operators to object literals. It finally introduces <Promise.finally> as an neat way of streamlining behavior that should always occur independently of the promise's outcome.
The tenth interaction brought <Array.flat> and <Array.flatMap> methods along with relaxing the catch block error binding that got increased attention from ES2017's introduction of async and await.
While the draft of this version is far from reaching its eleventh hour, we can already count with the Nullish Coalescing Operator and Optional Chaining Operator that will undoubtedly increase code readability.
Promises will also expand its api with allSettled, an alternative to <Promise.all> that always resolves with a description of each promises outcome wherever they resolve or get rejected.
While JavaScript started its journey addressing the necessity of making webpages more interactive and dynamic, it has come a long way and over multiple iterations it managed to also consolidate a role as a back-end language.
After conquering the back-end, the mobile world was an open field.
It was with the advent of AJAX in 1999 (standardised in 2006) that JavaScript gained a second wind. Före AJAX användes JavaScript mest för att animera och ge interaktivitet till vissa webbsidor. Men eftersom denna interaktivitet inte skulle innebära utbyte av data med servern - skulle den bara bestå av tillbehörsdisplay-logik.
Med AJAX började JavaScript utföra viktiga uppgifter i våra webbapplikationer applikationslogik, till den punkten att det numera är svårt att hitta webbapplikationer som inte kräver en webbläsare med JavaScript aktiverat för att fungera. Det var efter denna förändring som JavaScript-ekosystemet började expandera som ett programmeringsspråk på klientsidan.
De viktigaste behoven hos utvecklarna som arbetar med AJAX webbapplikationer är:
• Utföra AJAX-samtal;
• Manipulera dokumentobjektmodellen (DOM) - datastrukturen som hålls av webbläsaren som representerar webbsidans struktur;
• Reagera på användarens interaktioner.
De viktigaste JavaScript-funktionerna som tillhandahåller dessa funktioner var inte särskilt praktiska och ibland var deras beteende inte kompatibelt med olika webbläsare.
De första biblioteken som blev populära tog upp just dessa tre uppgifter och tillhandahöll en samling funktioner och objekt som gjorde dessa operationer enkla och funktionella i varje webbläsare. Några av dessa bibliotek skulle också ge många andra allmänna funktioner:
EN JavaScript-ramverk som släpptes 2005 som en del av Ruby on Rails AJAX support. Det utökade direkt många JavaScript-kärnobjekt med beteende som skulle likna Ruby-programmeringsspråket, och lade också till ett klassbaserat system till språket.
Dessa kärntillägg betraktades som besvärliga av andra programmeringssamhällen och de tillhandahållna funktionerna var konstigare än följande konkurrerande bibliotek:
Den jQuery ramverk släpptes 2006 och har - till skillnad från Prototype - låtit språket kärna som det var och snarare fokuserat på att tillhandahålla massor av funktioner relaterade till DOM, händelser, asynkronicitet och effekter.
En funktion att lyfta fram är att jQuery stöder ett plugin-system som gör det möjligt för biblioteksprogrammerare att utöka sin funktionalitet. Detta bibliotek var det mest framgångsrika biblioteket av detta slagoch blir det oumbärliga verktyget för frontend-utveckling, används nuförtiden på de flesta webbplatser.
Trots jQuery enorma popularitet, liksom dess förmåga att tillhandahålla många användbara funktioner, Det är viktigt att notera att moderna versioner av JavaScript redan tillhandahåller många av de funktioner som gjorde jQuery populärt. Kanske Du kanske inte behöver jQuery överhuvudtaget.
Det blir allt populärare att inte använda jQuery och att snarare förlita sig på antingen bara de nuvarande centrala JavaScript-funktionerna eller på bibliotek som är specialiserade på varje specifik uppgift (t.ex. hämta för AJAX-samtal).
När du använder DOM-manipuleringsbibliotek är det vanligt att behålla applikationsdata i själva DOM, så det finns DOM-manipulationsväljarfunktioner som måste anropas när du behöver komma åt eller ändra dessa data.
Denna typ av kod fylls ofta med väljarnamn och blir lätt en röra när applikationens komplexitet utvecklas. Det finns en uppsättning ramar som gör att vi kan ta itu med detta problem på ett elegant sätt genom att utnyttja applikationsmönster som liknar de berömda MVC-mönster (Model-View-Controller).
Å andra sidan det finns en ny trend där webbapplikationer är fullt laddade i webbläsaren vid den första sidladdningen, utför varje efterföljande operation via AJAX.
Denna typ av applikationer kallas Applikation på en sida (SPA) och eftersom deras kod ofta är ganska utarbetad och komplex, Det rekommenderas att välja ett av dessa ramverk när du implementerar ett SPA. Låt oss titta på några av dem.
Ryggrad är ett Model-View-Presenter (MVP) ramverk som publicerades i slutet av 2010. det är fokuserat på SPA och verkställer separationen mellan applikationslogik, displaylogik och mallar.
Kommunikationen mellan dessa enheter hanteras på ett händelsebaserat sätt och den stöder också en Router-klass som tillåter applikationerna att reagera på webbadresser och uppdatera dessa enligt de utlösta händelserna.
kantig är ett ramverk implementerat av Google som brukade följa en MVC-arkitektur och som har utvecklats till ett MVVC-ramverk. I likhet med Backbone är det fokuserat på SPA och verkställer separationen mellan applikationslogik, displaylogik och mallar.
Det är intressant att märka att Angular tillåter programmeraren att utöka HTML genom att skapa nya taggar som kan användas i mallarna och som kapslar in delar av sidan.
Ett annat särdrag är att det tillåter upprättandet av tvåvägs databindningar mellan mallarna och JavaScript-objekten som ska återges av dem.
På detta sätt kommer alla uppdateringar av dessa objekt automatiskt att utlösa HTML-uppdateringar, och - på liknande sätt - uppdateras JavaScript-objekten när deras motsvarande mallinmatningsfält ändras.
Som vi har beskrivit i de föregående avsnitten flyttade visningslagret för våra webbapplikationer från en enkel beräkningsmodell där gränssnittet som skulle visas bara var funktion av vissa data beräknade av serverkoden till något mycket mer dynamiskt och komplext, där det inte bara skulle bero på hämtad data utan också på användarinteraktioner och skript som bearbetade dessa.
Denna komplexitet översätts ofta till komplex kod som är svår att dela och resonera om. Således började vissa människor på Facebook experimentera med en enklare beräkningsmodell för att koda front-end. En beräkningsmodell som skulle göra det möjligt för oss att tänka på vad som visas på sidan igen som ett resultat av tillståndet för några få variabler istället för resultatet av interaktionen mellan en ”zillion” av Model-View-Controller-klasser.
För att få en sådan förändring att äga rum måste något radikalt hända: om vi ville att displayen bara skulle vara resultatet av att tillämpa en funktion på vissa tillståndsvariabler skulle vi behöva sluta manipulera delar av DOM direkt och istället återge varje version av skärmen som helhet.
Eftersom det skulle vara för långsamt att rendera hela DOM när du ändrar något i det, det beslutades att kartlägga DOM på en lätt representation av den som skulle vara lätt att regenerera och jämföra.
Således när vi ändrar en variabel kan vi generera en ny version av denna lätta representation och jämföra den med dess tidigare versionoch därmed beräkna vilka delar av DOM som behöver uppdateras. Vi kallar Virtual DOM till denna lätta representation av DOM.
Reagera var det första ramverket som använde en virtuell DOM. Det skapades av Facebook och arkitekturen som måste följas av applikationerna som använder den är minimal.
När det gäller MVC håller React inte fast vid det och handlar snarare bara om View-delen av koden. Med den representeras vyn som ett träd av enheter som kallas komponenter som kan vara sammansatta av andra komponenter själva.
A component holds some state, can receive properties upon creation, and knows how to render itself for a given set of properties and state variables. Whenever its state is changed, a new version of its display's Virtual DOM is rendered and compared with its previous version, and the needed DOM is updated accordingly.
If some interactions performed on a given component are to change the state of parent components, then the parent component has to pass the handling code to the subcomponent in the form of a callback. This approach guarantees that components are loosely coupled between themselves, thus making them quite easy to be reused.
One rather controversial choice taken by the creators of this framework is, instead of using HTML templates like the other frameworks, an HTML-like representation of the code is written as XHTML mixed within the JavaScript code, therefore requiring the use of a compiler that knows how to transform this JS and XHTML mix (called JSX) into HTML-generating JavaScript.
The component-based approach of React is effective for smaller applications, though for structuring bigger applications Facebook proposes an architecture called Flux, in which the state of the application is stored away of the components in something called state containers.
The original implementation of the Flux architecture was rather complex but there is a simpler one called Redux that is the most popular one and has even been used to implement application's back-ends.
Its architecture is functional and instead of directly mutating state, the programmer is meant to create new versions of it by applying reducer functions, thus allowing easy Undo/Redo and time-traveling debugging.
Vue started as a MVC framework similar to Angular but focusing on being simpler and requiring less boilerplate. The last version already features a component-based approach and a virtual-DOM in a similar way that React does.
The documentation describes it as a progressive framework, in the sense that it is thought to be progressively adopted and thus allowing a user to start by only using the view-part of the framework and later add more complexity if needed. There is a focus in reducing boilerplate and the number of files used when possible.
When developing complex Web applications people noticed that when fetching data through AJAX calls there was often under-fetching and over-fetching as well as that it was not easy to manage caching.
In order to sort out this problem Facebook developed a query language that allows describing the data each part of the interface needs. These queries are meant to be interpreted and aggregated into efficient sets of AJAX requests by a graphQL client.
There are at least two GraphQL clients available:
• Relay, the former implementation by Facebook, highly tangled together with React;
• Apollo, which strives to be a framework-agnostic project.
Despite JavaScript being used on the server side since the mid-90's, its implementations were quite slow and there was a not clear answer to how to run JavaScript in the back-end before 2008, when Google published the V8 JavaScript engine bundled together with the first version of Chrome web-browser.
When implementing the called V8 engine, Google used optimisation techniques that had both been created during the development of already forgotten programming languages compilers, namely of Self's and Strongtalk's compilers. The result was remarkably fast for a dynamically typed programming language like JavaScript, vigorously surpassing other implementations' performance.
On the other hand, both Chrome and V8 were released as open-source software (with a BSD license), thus allowing anyone to build their work on top of them and to distribute them as part of any software without having to pay royalties to Google.
It did not take long until Ryan Dahl, an american software engineer, created an environment called Node.js where JavaScript could be run on V8 away of the browser. Besides bringing V8 to the server-side, Node is also event-driven, thus allowing any blocking IO operations to be written in an non-blocking asynchronous fashion.
This way to address IO together with the speedy V8 made Node suitable to develop server-side real-time applications that required the swiftness of non-blocking IO together with the expressivity of a high-level programming language such as JavaScript.
As JavaScript's core specification is quite small and not thought for the server side, using it for such task usually requires plenty of external libraries. There is the need to have a package manager for Node, thus allowing developers to publish packages and easily retrieve libraries that are to be included in the developer's applications.
The Node Package Manager (NPM) is such package manager, just in the style of Perl's CPAN or Ruby's RubyGems.
There were some attempts to bundle both the tooling and the technologies aimed at creating full-stack applications. Here I'll talk about three of those attempts.
Meteor is a web framework that uses MongoDB as database. It uses a publish-subscribe protocol applied to resources, allowing clients to get updates when the data is updated on the server. It can be used with any client-side framework.
The MEAN stack stands for a package with the following set of technologies:
• MongoDB;
• Express;
• Angular;
• Node.
It also comes with the "mean" command-line tool, that allows generating projects, files and performing other useful command-line tasks.
The MERN Stack is similar to MEAN but focuses on React rather than Angular.
While JavaScript conquered the web, it also made advances as a mobile application development technology. It’s often chosen as a way to deal with mobile in a cross-platform way.
Apache Cordova enables the development of mobile applications using JavaScript CSS and HTML. It also supports a FFI mechanism through which the programmers can include portions of native code and easily create bridges in between JavaScript and native functionality.
While Apache Cordova allows to develop mobile applications with JavaScript, it does not provide the high-level features needed to do so. Ionic is a framework that provides such functionality: widgets, screen-transitions and other functionality. It follows an MVC architecture.
React Native applies React's component based approach to the mobile development, but instead of running JavaScript and allowing it to interact with native code it rather compiles the JavaScript to native code.
Nativescript appears as another popular framework to bring Angular and Vue.js web application to the mobile world offering an homogeneous JavaScript api to interact with mobile devices
As a browser language, JavaScript missed statements to specify dependencies between files and to tell the compiler to load these. In order to solve this problem there were two different APIs being specified and competing for this task:
• Asynchronous Module Definition (AMD);
• CommonJS Modules;
• ES6 Modules.
In the ES5 world, Node.js implemented CommonJS modules while front-end programmers preferred AMD, thus creating chaos on this field. There was thus specified a way to require modules and declare them called Universal Module Definition (UMD), which is rather ugly but makes modules compatible with both module APIs.
Anyway, this mess is being mitigated by the adoption of ES6 - that already supports a language-level constructs aimed at dealing with modules.
When using modules while developing web applications there is often the need to merge the different module files into a single file to be included by the web application. There are two libraries that allow developers to perform this task:
Browserify is the oldest web module bundler and allows developers to use the CommonJS module syntax when programming web-applications.
Webpack is a more modern web module bundler that does not only bundle JavaScript but also other assets such as images and CSS. It allows the different assets to be hot reloaded by the browser when there is a change in the modules code.
As not everybody is satisfied either with the JavaScript language or with its support by the browsers, there have been produced several transpilers which convert other programming languages into browser-supported JavaScript versions. Follows a few examples of these:
Babel is a transpiler that converts modern JavaScript into older, browser-supported JavaScript. It’s very customizable and allows cross compiling between several JavaScript versions.
Web assembly (also known as wasm) is a bytecode format now supported by all major browsers as an alternative to JavaScript. For now there are few compilers targeting Web Assembly. It should be noticed that - for now - Web Assembly does not feature a garbage collector.
Thus, when compiling to wasm one should either use a programming language that requires no garbage collector or will otherwise have to compile a runtime that enables garbage-collection together with the remaining application/module.
This transpiler, created by Microsoft, converts a gradual typed superset of JavaScript called TypeScript into JavaScript.
Flow is a static type checker developed by Facebook. As Typescript, it is a gradual typed system, though Flow is only focused on the types and does not add anything else to the language besides the type system.
Elm is a framework and a pure typed functional programming language inspired by Haskell that compiles to JavaScript and follows the same architecture as Redux, which is heavily inspired in Elm.
Unlike other static type systems, this one guarantees 100% type coverage through type inference, thus not requiring the programmer to explicitly enter any type signature at all. The type system is so safe that it does not allow any runtime exception to occur.
This is Facebook's take on using a typed functional programming language to generate JavaScript. ReasonML has O'Caml semantics and a JavaScript-friendly curly-braces-based syntax. It can be seen as an Elm's cousin who is not so keen on functional purity and who is backed by Facebook.
As projects become bigger and there is the need to transform their assets in order to run them, there's the need to write scripts that manage the execution of these transformations - something like make, ant or rake. There are two dependency-based task runners implemented in JavaScript:
An older one called Grunt - in which data that’s intermediate to the different transformation steps is kept in temporary files. And Gulp - which is a more recent one that rather uses memory instead of the temporary files.
As JavaScript is a language born out of the browser, why couldn’t we use it to develop the server side of our web applications? Express is the framework tackling this issue. It’s aimed at being minimalist (like Sinatra), though there are plenty of big libraries developed for it (e.g. Automatic Backoffice generation).
As V8 was used to create Node, it was also used as interpreter by the MongoDB document-oriented database. When interacting with the database the data is shared in JSON-like structures and the query language is about invoking JavaScript functions. This makes this database very popular amongst JavaScript developers.
Yeoman is an interactive project skeleton generator written in JavaScript. It allows to create plenty of JavaScript project types with different configurations - though it’s not only aimed at JavaScript, it may also be used to generate skeletons of Java projects, for instance.
Rails utvecklare med 10+ års erfarenhet av olika tekniker. Jag är intresserad av funktionell programmering.
Människor som läste det här inlägget tyckte också att dessa var intressanta:
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
.webp)
