Triplets on board

Triplets: family of functional programming languages - in the same web project

This post is a form of inquiry: if you like the conception presented here and feel that it may be relevant for more verbose audience, please share your toughts or just clap. If the subject turn to be not only my solitary perception, I will move it to the dedicated page and elaborate the subject extensively.

This post is also my first public blog post ever (and in a foreign language — mind the gap). It is also a part of F# Advent Calendar in english initiative. Thanks Sergey for organising this!

Update: To be clear: triplets has the learning purpose. I know that maintaining 3 languages may be a burden for some people and expensive.

I’m not advocating to push 3 languages in the same project. I’m creating a project with triplets for my own and for educational purposes to provide insights how they differs and which language should be applied or avoided in particular activity. I’m also creating tools to for those who want to follow the experiment


Around 2 years ago I was a big fan of doing everything in the same language/platform. I was a solid C#/F# developer but also marginalized java script programmer (gently speaking). At the same time I knew that front-end development is inevitable sooner or later as the progress in UI discipline was amazing and many of the front-end specifics moved to be the required skills, not only ‘a nice to have’.

That is why I’ve tried Websharper and have been playing with it for around half a year, then resigned. Apparently getting acquainted with the “isolated” framework turned to require almost the same amount of time and dedication as just switching to the brand new js world. Feeling that the world is running away from me, I have decided ultimately to learn all of those Node, React, Redux, Webpack, TypeScript, Visual Studio Code (and more) family.

I have never done so steep learning curve and learned as much as during last 1.5 year. The fact that my skills matrix size doubled is not so important. What is important is the fact that effectively I am no longer a fan of one language for everythink. But I am also the biggest advocate of functional programming in the web as never before.


Web application development becomes more and more complicated and definitely it will be even more thanks to VR/AR (Virtual and Augmented Reality), Serverless Architecture (Azure Functions), map centric components complexity and general manipulations of data comming from all those inputs.

State management is the top application of functional programming principles in the SPA realm right now and is frequently explained especially to the begginers as the main advantage and huge improvement over switch statement from imperative languages. This is a good approach, however saying that FP is replacement for the Redux library is a big oversimplication and a big underestimation of the FP power.

We can introduce FP into SPA applications in two flavours:

  • Orchestration: state management, runtime, messages service bus, handling events in an asynchronous way
  • Business logic: algorithms & data processing, complex UI management, everything that can be moved from server-side to client-side

With the presence of ReasonML and Elm languages we can simply say that the first way of applying FP in SPA is pretty much prevalent. The second can be only noticed in very innovative or financial startups. However in a 2–5 years period FP will be the main paradigm in the complex front-end development. As things are getting more complex, we will need the languages that are easier to reason about, maintain, combine and supported by the mainstream companies as well.

Why not F# everywhere

Fable: put your F# in the web

Frankly we have the great Fable project with all that tooling and community better than never. Thanks to the community: doing full-stack in F# now is fully possible. But it is reasonable?

I do not think so.

I personally hate the cliche “right tool for the right job” but this time it fits well here.
I can define 3 layers of front-end development (how sick it sounds!):
- orchestration layer — building user interfaces, DOM virtualization, state management 
- business logic layer — business value 
- component layer — UI parts that are isolated and reusable, can be threaten s separated application

We can use Fable for all of these 3 layers however for some tasks it more looks like kinda bindings, not an idiomatic approach. Even if we are always up to date with the partner’s releases, there is still some kind of conceptual burden. Functional discipline benefits are blurred here and may be even counterdecisive to go back to OOP approaches for some people.

So what is the alternative?

  • Elm — pure web functional language with strict web approach yet production ready. Releases are not so often but very well tought. Elm-ish style of coding is also available in Fable.
  • ReasonML — “facebook” language based on OCaml with good React binding and a lot of investment in the horizon — not to be missed!
  • and last but not least already mentioned Fable — “put your F# in the web”

All 3 languages are a part of the same ML family and are there for a while. Are very similar, share common root and sytax. F# has the greatest power and capabilities, other two are strictly web oriented so by design they will never be so powerfull as F# but can be a good complement.

Meet triplets

I think that by learning and exercising all three langauges we may achieve the noticeable growth in the history of functional web programming:

- business continuity (thanks to React)
- keep up with innovations (thanks to Reason, fable)
- availability (js, typescript)

- strict web approach (Elm)
- great programming language power for the hardest parts (F#)
- amazing tooling


Triplets is a combination/approach/architecture of usage of 3 functional programming languages from the same ML family: F#, Reason (OCaml) and Elm in a web application context:
F# for the web business logic
ReasonML/ReasonReact as a SPA framework and DOM virtualization, state management
Elm for crucial components that must be simple and consistent. Elm is targeted to be pure and as much web natural as possible so we must follow it.

There is also a stepfather in this family: TypeScript, hosting language, used for all the things functional programming is not required or not reasonable to use: bundling, quick proof of concept, prototyping

Is there any chance for adoption at all?

I know what you’re already saying behind my back : “C# developers can’t switch to just one functional programming language, how the hell can they consider learning many of them?” The answer is simple and not discoverable: the need is the mother of inventions. If a developer don’t see that he is working on application with a lot amount of data operations and that OOP is a burden rather that a tool, he won’t switch. They may call it the creation of niche in the another niche. But I can see the opposite: combining 3, very similar languages with slighly different target may push forward the functional programming market as never before. As SPA applications are getting more and more complex, with the data amount as big as in the serverside, there will be much more demand — so we need provide the supply.

Way of working

I’m going to follow the startup’s approach which is often applied in any marketing activity: first convince that we really have the problem and that the developers need the solution (triplets here). I also need to make the differences in languages negligible: we need a seamless way to pass json objects between those 3 languages and between the .NET backend. We need to know the information passing style between state, component life and business logic. We also need to handle the asyncronity in a well defined manner. We need to know which language should cooperate with particular js libraries and which not. So despite the similarity, still we have plenty to address.

I’m doing a startup project for some time now. I have done most of it in TypeScript but I’ve been keeping space for Fable, Reason, Elm components from the early inception in my solution and webpack context as well.

As the added value of the project become more and more complicated, I am thinking to switch totally to the mentioned tripple of languages. As the reasoning about certain programming concepts seems to be not specific to my project only, I am thinking to provide extracted tools chain (packages, plugins) along with guides when, why and how use particular languages for particular tasks.

Next posts:

  • code (finally!)
  • node/dotnetcore packages for triplets
  • a lot of proves that we really have the problem and really need the “triplets”

For the time being (as a promise/allegory) look at the rare sneak camera shot of triplets looking at a sleeping TypeScript and getting out of control

About the author

I love functional programming, graph databases and Azure platform — everything that is data-driven related. I’m writing a code and reading books about software and data asynchronously. I mean: a lot! I’m a very good observer and want to transform my skills and passion to something big, useful and fun.

I am also a great advocate of this approach: GOTO 2015 • One Hacker Way by Erik Meijer.