Dette indlæg blev oprindeligt udgivet i maj 2018 af Pedro Rolo og opdateret i maj 2020 af Andre Santos.
Når man tænker på ÅrsagML, det faktum, at det er bakket op af Facebook, fortæller ikke det hele. Det er en teknologi, der har udviklet sig i løbet af de sidste par år med meget potentiale, ikke kun på grund af indflydelsen fra JavaScript-værktøjer, men også på et kompilator-til-native-kodeperspektiv.
I denne artikel vil jeg se nærmere på dens oprindelse, og hvordan andre teknologier, som React, BuckleScript eller OCaml formede dens udvikling.
ÅrsagML Det er den nye teknologi, der Facebook bruger til at udvikle React-applikationer og promovere som en futuristisk version af JavaScript (ES2030 siger de).
I en nøddeskal:
Reacts programmeringsstil er meget tættere på funktionel end objektorienteret programmering. Det er derfor ikke overraskende at opdage, at den første React-prototype blev ikke implementeret i JavaScript, men i Standard ML i stedet.
Men da prototypen begyndte at modnes, dets forfatter, Jordan Walke, besluttede at portere det til JavaScript og fortsætte derfra. Der var ingen modne transpilere til JavaScript, og dengang var verden heller ikke klar til at acceptere et sådant ikke-mainstream programmeringssprog og -stil.
Som et resultat React blev populær som en teknologi knyttet til JavaScript-programmeringssproget.
På trods af denne succes inden for JavaScript-økosystem, nogle mennesker begyndte at føle, at der foregik noget bag kulisserne. Andre relaterede projekter - f.eks. Redux, Elm og PureScript - begyndte at vinde popularitet og skubbede dermed samfundets tankegang tættere på de oprindeligt funktionelle og statisk typede rødder af React.
Dette fik Facebook til at tro, at det kunne være muligt og praktisk at flytte React selv tættere på sine rødder.
Til sidst, de fandt ud af, at meget af grundlaget allerede var lagt ud for dem...
Nogle virksomheder udvikler sådanne missionskritiske brugergrænseflader, at brug af dynamiske eller gradvist indtastede sprog kan udgøre uudholdelige tab.
Bloomberg er et af sådanne virksomheder. Det var for Bloomberg, at Hongbo Zhang arbejdede og eksperimenterede med JavaScript-runtime, da han indså, at det ikke var svært at portere OCaml-kompilatoren til JavaScript og køre den i browseren.
Virkeligheden var, at OCaml-kompilatoren var allerede meget modulær. Det var ikke særlig svært at erstatte sin oprindelige kodegenererende backend med en javascript-genererende. Med en sådan backend var det endda muligt at kompilere OCaml-kompilatoren til JavaScript og dermed selvhoste BuckleScript-kompilatoren og køre den i browseren.
BuckleScript blev født og endnu bedre, det blev frigivet af Bloomberg som open source-software.
Det er vigtigt at bemærke, at den originale OCaml-kompilator allerede havde årtiers udvikling og optimeringer udført af Institut Nationalt for Forskning i Informatik og Automatik (INRIA). Det var en af de hurtigste kompilatorer, der var tilgængelige for et så stærkt kontrolleret sprog.
Hvis Facebook havde til hensigt at gøre React-økosystemet statisk indtastet, var BuckleScript bestemt en god kandidat. De syntes at tro, at JavaScript - med sin populære krøllede afstivede syntaks - stort set var ansvarlig for Reacts succes.
De var dog ikke naive nok til blot at tage BuckleScript med sin OCaml-syntaks. De snarere beholdt OCaml-semantikken, den BuckleScript backend og så meget som de kunne fra JavaScript-syntaks.
For at bevare JavaScript-syntaksen oprettede de en ekstra parser, håndtering af et nyt sprog kaldet ÅrsagML.
Vi kan sige, at det er Årsag ML er simpelthen OCaml med en javascript-lignende krøllet syntaks.
Resultatet ligner overraskende JavaScript. Til det punkt, at nogle JavaScript-kode kan behandles direkte af kompilatoren, som om det var ReasonML, med alle de fordele, som en statisk skrevet compiler har, og ingen kodeændring overhovedet.
Udover arbejdet med selve sproget og kompilatoren har Facebook også brugt en vis indsats på udvikling af en ReasonML-indpakning omkring dens React-ramme, med en ekstra funktionalitet.
Det hedder React Reason. Det gør det lettere at blande JavaScript React-komponenter med Reason-komponenter inden for den samme ReactJS eller Reason-applikation.
Det skal bemærkes, at React Reason er ikke bare en wrapper omkring React. Det giver også nogle out-of-the-box-funktionaliteter, der plejede at komme med eksterne biblioteker såsom Redux og uforanderlig.
Redux er en statschef, der er meget populær blandt React-projekter. Kort sagt tillader det at organisere applikationsdomænelogikken som et sæt sammensatte reduktionsfunktioner, som er beregnet til at udtrykke, hvordan applikationens tilstand skal transformeres som eksterne begivenheder (såsom brugerinteraktioner).
Når du bruger ReasonML, har vi ikke brug for Redux længere.
ReacTreason tilstandsløse komponenter leveres allerede med konceptet med en indbygget reducer, som er beregnet til at tage sig af de problemer, Redux plejede at løse.
Funktionaliteten, der tidligere blev leveret af Immutable, implementeres på sprogniveau.
ReasonML (og OCaml) -operationer er uforanderlige som standard, hvilket undgår de kognitive omkostninger og ydeevneomkostninger ved brug af et eksternt bibliotek.
For et stykke tid siden skrev jeg om Elm-sproget. Godt, ReasonML og Elm de er ikke så forskellige fra hinanden.
Ved at analysere deres forskelle i dybde er det uden for det tilsigtede omfang af denne artikel, men - i sum - de stammer fra en anden holdning til funktionel renhed og modenhedsniveau for begge projekter.
Nedenfor kan du finde en tabeloversigt over, hvordan deres træk matcher, og hvordan de adskiller sig:
Fælles træk
Forskelle
Som du måske bemærker i tabellen ovenfor, nævnes det, at ReasonML kan kompileres til forskellige mål, herunder native kode. Det kan gøres ved at bruge ReasonML-syntakslaget med den resterende originale OCaml-kompilator, inklusive den originale native code backend.
Der er masser af potentiale her. Til sidst tillader du at dele Reasons kode mellem backend og frontend eller endda kompilere backend til native kode.
Flagskibsapplikationen til ReasonML er Facebook Messenger, som oprindeligt var en ReactJS-applikation, der er gradvist blevet migreret til ReasonML. Derudover strækker ReasonML's vedtagelse sig ud over Facebooks projekter, og der er masser af andre virksomheder, der bruger det. Nogle af dem er nævnt på listen i ReasonML's dokumentationsside.
ReasonML virker som en anden iteration over den samme indsats for at bringe et funktionelt statisk skrevet sprog ind i JavaScript-økosystemet.
Ikke desto mindre synes den retning, som dette projekt og dets støttemodtagere har taget, meget mere lovende både ud fra markedsføring og teknologiske synsvinkler.
Det kan drage fordel af JavaScripts værktøjer og afslappede syntaks mens udnyttelse af det arbejde, der er udført for OCaml, uden at glemme, at det er bakket op af Facebook. Der er også potentialet til nå forskellige platforme og miljøer gennem BuckleScript.
Selvom ReasonML ikke er den første og bestemt ikke den sidste, der forsøger at tackle disse mål, det præsenterer sig selv som et forsøg i virksomhedsklassen, forsøger at appellere til smagen af mainstream.
Fandt du denne artikel nyttig? Du kan måske også lide disse!
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)
