5 ms·
There is a specific niche that BuckleScript and Reason can fill, and that is the sort of front-end projects that use React+Redux+ImmutableJS+TypeScript/Flow. I
by jasim 9y ago
There is a specific niche that BuckleScript and Reason can fill, and that is the sort of front-end projects that use React+Redux+ImmutableJS+TypeScript/Flow.
Instead of bolting on typing into Javascript (Flow and TS both do a good job of it btw), you could simply use a language that was designed with it. There is a huge difference in native adoption of such a core language feature vs using a transpiler that ultimately leak Javascript semantics.
If you're using immutable values through ImmutableJS-like libraries, or by just being careful to not mutate stuff - then you should try working in a language that has immutability baked in. Having confidence that you've been careful to not mutate anything in your code vs using a language that simply disallows it in the normal course of programming brings a tangible difference.
You can call BuckleScript/Reason as just a better version of Javascript with all the good things baked in. But it definitely is much more - you get to use Variants (Sum/Union types in other parlance), and more importantly, writing value-based immutable code (instead of reference based mutation) lets you rely on equational reasoning to understand your code. Your functions are pure and can be seen as though they are equations, and your whole program is a composition of these equations.
A good thing about BuckleScript/Reason vs transpiled languages like CoffeeScript is that we're fully free from Javascript's semantics. You are solidly inside OCaml, and Javascript simply doesn't leak through. You don't have to worry about JS scoping rules or how `this` works, or how ES6 classes are ultimately prototype-based. Except for a well-defined foreign-function interface that lets you use all of npm libraries or your existing JS code, once you are in the typed immutable world of OCaml, then that's all you need to think about.
All of this applies not just to BuckleScript, but any Typed FP that runs on the browser - Elm, PureScript, and I believe Scala.js as well.
But one big advantage (or disadvantage, depending upon how you look at it) of OCaml/Reason/BuckleScript is that it allows mutation if you need it. You can start out writing purely imperative code just as you would in Javascript, and slowly adopt immutable programming as you get comfortable with it. You can also rely on mutation when you need to optimize specific parts of your code.
- ng12 9y ago> You don't have to worry about JS scoping rules or how `this` works, or how ES6 classes are ultimately prototype-based I don't worry about these things. I feel like I'm writing a lot less JavaScript these days, mostly through the power of React, JSX, and ES6. I only really use Typescript to type DTOs. I just don't have enough problems to scrap everything for a completely new language.
- jasim 9y ago> I just don't have enough problems to scrap everything for a completely new language. I was not recommending that at all. I tried out Typed FP only after a project with a lot of complex data transformations (which is a sweet spot for Hindley Milner based types) and couldn't hold it all in my head. In the React world, the equivalent would be a deeply nested component hierarchy, passing around a lot of props, and having a large state-tree and correspondingly complex reducer. You can definitely use the typical Redux+TS/Flow+Immutable stack there without any issues, but I think there is a much better developer ergonomics on offer here.
- shados 9y agoJust getting rid of the "Should we do Java style OOP vs favoring more FP patterns" argument can double you productivity right there ;)
- jahewson 9y agoTypeScript is far more powerful than you think. Between const, readonly properties, Readonly<T>, ReadonlyArray<T>, readonly indexers, and type safe object spread {...} via keyof T, TypeScript provides the tools to write immutable code, fully checked by the compiler, without paying runtime costs. It also has tagged unions, product, and sum types, nullability, and extensive capabilities for typing 'this'. So I'm left to ask what exactly is the unique advantage of writing JS in OCaml? Because it's not immutability. Remember too, that OCaml has plenty of warts.
- the_duke 9y agoI like TypeScript too, but: * 'readonly' support, while nice to have, is mostly broken. It's just way too easy to coerce a readonly value into a non-readonly one, especially with nested objects. * There are no proper sum types. You can emulate tagged unions with a type field as a tag and match on that and get good compiler support for the fields, but in no way does it feel like a proper, language-supported sum type. * Javascript semantics leak through to TS all the time. Which is kind of the point, TS is supposed to be a static typing layer on top of JS. This is an advantage too: you stay close to the actual runtime and it's easy to interact with non-typescript code. But a lot of stuff still feels quite messy, like a bolted on abstraction (which it is).
- seanwilson 9y ago> * 'readonly' support, while nice to have, is mostly broken. It's just way too easy to coerce a readonly value into a non-readonly one, especially with nested objects. Do you have any example of this? To be honest, as much as I'd love immutability support built into the language, the number of bugs I get from accidentally mutating data is so low it's not something I would make a lot of effort to get. There's always Object.freeze as well which will throw an error if you try to violate immutability. > * Javascript semantics leak through to TS all the time. Which is kind of the point, TS is supposed to be a static typing layer on top of JS. Does this not happen in BuckleScript/Reason as well at the layer where you interface with JavaScript libraries? > But a lot of stuff still feels quite messy, like a bolted on abstraction (which it is). Yeah...it's practical though and has an easy plus incremental migration path. Switching to OCaml would be much bumpier.
- phillipcarter 9y agoA similar stack is Fable and F# with the Fable-Elmish library. It also works well with react/redux tooling (debugging in the browser supported), and has great tooling support in Visual Studio Code.
- jasim 9y agoAh yes, I missed mentioning F#. It is a great language have heard only good things about Fable. I'd be happy to be writing any Typed Functional language - the differences between them are inconsequential compared to anything outside the paradigm.
- Scarbutt 9y agoClojurescript is nice a option too, you get a language with better defaults and you don't have to pull in immutablejs/lodash or you favourite immutable and util library and deal between all the inconsistency between them. All the ES6/7/8 stuff is there too plus other niceties.
- fulafel 9y agoThe main competitors in the FP reactive frontend space are Elm and ClojureScript I think. Those have significant mindshare and users and good tooling.