Det här inlägget postades ursprungligen i maj 2018 av Pedro Rolo och uppdaterades i maj 2020 av Andre Santos.
När man tänker på OrsakML, det faktum att det stöds av Facebook, säger inte allt. Det är en teknik som utvecklats under de senaste åren med mycket potential, inte bara på grund av påverkan av JavaScript-verktyg, men också på en kompilator till inbyggt kodperspektiv.
I den här artikeln kommer jag att titta närmare på dess uppkomst och hur andra tekniker, som React, BuckleScript eller OCaml formade dess utveckling.
OrsakML Det är den nya tekniken som Facebook använder för att utveckla React-applikationer och marknadsföra som en futuristisk version av JavaScript (ES2030 säger de).
I ett nötskal:
Reacts programmeringsstil är mycket närmare funktionell än objektorienterad programmering. Det är därför inte förvånande att upptäcka att den första React-prototypen implementerades inte i JavaScript, men i Standard ML istället.
Men när prototypen började mogna, dess författare, Jordan Walke, bestämde sig för att portera den till JavaScript och fortsätta därifrån. Det fanns inga mogna transpelare till JavaScript och också, då, världen var inte redo att acceptera ett sådant icke-vanligt programmeringsspråk och stil.
Som ett resultat, React blev populär som en teknik kopplad till JavaScript-programmeringsspråket.
Trots denna framgång inom JavaScript ekosystem, vissa människor började känna att det hände något bakom kulisserna. Andra relaterade projekt - t.ex. Redux, Alm och PureScript - började vinna popularitet, vilket drev gemenskapens tankesätt närmare de ursprungligen funktionella och statiskt typade rötterna i React.
Detta fick Facebook att tro att det kunde vara genomförbart och bekvämt att flytta React själv närmare sina rötter.
Så småningom, de fann att mycket av grunden redan var lagd för dem...
Vissa företag utvecklar sådana uppdragskritiska användargränssnitt som att använda dynamiska eller gradvis typade språk kan representera outhärdliga förluster.
Bloomberg är ett av sådana företag. Det var för Bloomberg att Hongbo Zhang arbetade och experimenterade med JavaScript-körningen, när han insåg att det inte var svårt att portera OCaml-kompilatorn till JavaScript och köra den i webbläsaren.
Verkligheten var att OCaml-kompilatorn var redan mycket modulär. Det var inte särskilt svårt att ersätta dess ursprungliga kodgenererande backend med en javascript-genererande. Med en sådan backend var det till och med möjligt att kompilera OCaml-kompilatorn till JavaScript, och därmed vara värd för BuckleScript-kompilatorn och köra den i webbläsaren.
BuckleScript föddes och ännu bättre, det släpptes av Bloomberg som programvara med öppen källkod.
Det är viktigt att notera att den ursprungliga OCaml-kompilatorn redan hade decennier av utveckling och optimeringar gjorda av Institutet för nationell forskning inom datavetenskap och automatik (INRIA). Det var en av de snabbaste kompilatorerna som finns tillgängliga för ett så starkt typkontrollerat språk.
Om Facebook tänkte göra React-ekosystemet statiskt typat, var BuckleScript verkligen en trevlig kandidat. De tycktes tro att JavaScript - med sin populära lockiga förstärkta syntax - till stor del var ansvarig för Reacts framgång.
Men de var inte naiva nog för att helt enkelt ta BuckleScript med sin OCaml-syntax. De snarare behöll OCaml-semantiken, den Backend för BuckleScript och så mycket de kunde från JavaScript-syntax.
För att behålla JavaScript-syntaxen skapade de en ytterligare parser, hanterar ett nytt språk som heter OrsakML.
Vi kan säga att det är Anledning ML är helt enkelt OCaml med en javascript-liknande curly-braced syntax.
Resultatet är förvånansvärt likt JavaScript. Till den punkten att viss JavaScript-kod kan bearbetas direkt av kompilatorn, som om det var ReasonML, med alla fördelar som en statiskt typad kompilator har och ingen kodändring alls.
Förutom arbetet med språket och kompilatorn i sig har Facebook också ägnat en del ansträngningar åt utveckla ett ReasonML-omslag runt sitt React-ramverk, med en extra funktionalitet.
Det heter Reagerande orsak. Det gör det lättare att blanda JavaScript React-komponenter med Reason-komponenter inom samma ReactJS eller Reason-applikation.
Det bör noteras att React Reason är inte bara ett omslag runt React. Det ger också några out-of-the-box-funktioner som brukade levereras med externa bibliotek som Redux och oföränderlig.
Redux är en statschef som är mycket populär bland React-projekt. Enkelt uttryckt tillåter det att organisera applikationsdomänlogiken som en uppsättning sammansatta reduceringsfunktioner, som är avsedda att uttrycka hur applikationens tillstånd ska omvandlas som externa händelser (till exempel användarinteraktioner).
När vi använder ReasonML behöver vi inte Redux längre.
ReacTreason tillståndslösa komponenter kommer redan med konceptet med en inbyggd reducerare, som är tänkt att ta hand om de problem Redux brukade ta itu med.
Funktionaliteten som tidigare tillhandahölls av Immutable implementeras på språknivå.
ReasonML (och OCaml) -operationer är oföränderliga som standard, vilket undviker de kognitiva kostnaderna och prestandakostnaderna för att använda ett externt bibliotek.
För ett tag sedan skrev jag om Almspråket. Väl, ReasonML och Elm de skiljer sig inte så mycket från varandra.
Genom att analysera deras skillnader i djup ligger det utanför den avsedda omfattningen av denna artikel, men - sammanfattningsvis - de härrör från en annan inställning till funktionell renhet och mognadsnivå för båda projekten.
Nedan hittar du en tabellsammanfattning av hur deras egenskaper matchar och hur de skiljer sig åt:
Vanliga egenskaper
Skillnader
Som du kanske märker i tabellen ovan nämns det att ReasonML kan kompileras till olika mål, inklusive inbyggd kod. Det kan göras genom att använda syntaxlagret ReasonML med den återstående ursprungliga OCaml-kompilatorn, inklusive den ursprungliga native-cod-backend.
Det finns gott om potential här. Så småningom tillåta att dela Reasons kod mellan backend och frontend eller till och med kompilera backend till inbyggd kod.
Flaggskeppsapplikationen för ReasonML är Facebook Messenger, som ursprungligen var en ReactJS-applikation som har successivt migrerats till ReasonML. Dessutom sträcker sig ReasonML: s adoption utöver Facebooks projekt och det finns många andra företag som använder det. Några av dem nämns listade i ReasonML:s dokumentationssida.
ReasonML verkar som en annan iteration, över samma ansträngningar, för att föra ett funktionellt statiskt typat språk in i JavaScript-ekosystemet.
Ändå verkar riktningen som detta projekt och dess stödjare tagit mycket mer lovande både ur marknadsförings- och teknisk synvinkel.
Det kan dra nytta av JavaScripts verktyg och avslappnad syntax medan utnyttja det arbete som utförts för OCaml, utan att glömma att det stöds av Facebook. Det finns också potential att nå olika plattformar och miljöer genom BuckleScript.
Även om ReasonML inte är den första och absolut inte den sista som försöker ta itu med dessa mål, det presenterar sig som ett försök i företagsklass, försöker vädja till smaken av mainstream.
Hittade den här artikeln användbar? Du kanske gillar dessa också!
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)
