Some time in 2011, Opa appears, but apparently nobody wants to learn yet another server-side language. I don’t know anyone who has used this in production.
In December 2011, I came up with ji, a means of controlling a web page from a Haskell web service, which later was renamed to threepenny-gui and is now maintained by Heinrich Apfelmus to this day. It turned out to be extremely powerful; I wrote an IRC-like app in which people could chat on a web page in a page of code. However, in the end it wasn’t to be for mainstream web dev; a good point that Michael Snoyman made was that it had a high server-side cost, and did not scale to multiple servers. In the end, threepenny-gui is a great library to consider for cross-platform desktop programs (such as with Electron).
In January 2012, I experimented with UHC. My experience was similar to GHCJS. I tried some basic experiments, but the heavy runtime that came along with it wasn’t attractive to me. It felt like I would spend half my time maintaining it aside from the applications I might’ve written with it.
In March 2012, Evan Czaplicki announced that his thesis on Elm was complete. The emphasis on FRP drew me (and probably others, at the time) away from it, as FRP was seen as green, experimental and impractical. Indeed, in 2016, Evan wrote A Farewell to FRP. Elm used to be all about FRP, and then it wasn’t. “I might argue that Elm was never about FRP,” writes Evan. I imagine this contributed to Elm’s growing success. Today, Elm is not my choice because it lacks type-classes.
In September 2012, I authored the Fay compiler, which was a Haskell subset compiler. I was inspired by Elm and Roy. The idea was to re-use the GHC compiler for type-checking, and separately do codegen with haskell-src-exts without type information. As a result, it didn’t support type-classes, and didn’t compile basically any of Hackage. But it was useful enough and simple enough to get use in the community and at FP Complete, where we used it for the web-based IDE, which had about 15k lines of Fay code in it.
To add some additional context, at the time, I wrote:
My approach to the problem, as with everyone else, has long been: well, we can’t do anything about it, let’s just wait for Google to complete their native client project and hope that it breaks the market.
In October 2013, Phil Freeman announced PureScript, a strict, pure, Haskell-like language with row-polymorphism that compiled to JS with no runtime. I think it was seen as an interesting concept, but it wasn’t until a few years later that PureScript came back on my radar as a practical language.
Around late 2014, at FP Complete, we were ready to try GHCJS again. Luite Stegeman had been working hard on it and bringing it to life. In August of 2014, Simon Meier released blaze-react, which was a GHCJS-based React.js binding with an Elm-style of processing events as a sum type. This re-ignited interest, at least from my perspective. Although we were doubtful that the Elm architecture scaled. Fay is officially out of the picture.
In April 2015, we whipped up a similar package called ghcjs-react, which implemented React without the Elm-style processing of events as a sum type. I wrote the experimental stackage-view tool based on this library; which we thought would be a good litmus test both of GHCJS and our react bindings. It was awkward, but when it worked, it worked well.
I will note that, we’re slow on the up-take. React.js was released in May 2013, and we twigged onto it as a good way to write UIs around 2015. Partly in thanks to the Clojure library Om.
Also in April 2015, Ryan Trinkle presented his new library Reflex, with a very compelling talk. I wrote at the time:
The video is quite comprehensible, it may be the first FRP demo I’ve seen that isn’t mired in nomenclature I don’t understand, builds up from small components but doesn’t bore me with unrealistic counters or sliders, and has some real world products written in it. 10/10 talk, count me interested.
In Jan 2016, some of the FP Complete team started learning Reflex and using it on a large client pilot project. Experience reports can be summed up as: mind-bending but eye-opening in the same way learning Haskell was. Awkward to express some things, but also unquestionably composable and re-usable. Groans and grumbles about GHCJS being heavy, slow and brittle.
In Jan 2015, Slam Data start their Halogen library for PureScript.
During 2015 and 2016, Tim Dysinger is a growing advocate for PureScript at FP Complete internal discussions.
In October 2016, I’m using PureScript with React.js bindings to make internal demo UIs for FP Complete. I’m enjoying it a lot. We have an engineering meeting about PureScript vs other technologies.
December 2016, Michael Snoyman comments on Slack:
PureScript seems like it’s doing everything right.
April 2017, Michael Snoyman writes a PureScript + Halogen version of his one-time-pad toy app. At the time, I’m not interested in Halogen. It looks complicated, and I’m still enjoying React.
August 2018, it has been decided that we will use PureScript to build a UI for a cryptocurrency client at FP Complete. I’m happy about that. I decide to give Halogen a try. After initial pain, I end up loving it.
November 2018, we briefly discuss whether Rust+WASM is a new possible contender. We’ll have to wait for WASM to become supported on all browsers, especially mobile.
December 2018, we have a dev meeting on the state of frontend development. Our meeting notes are long and detailed, the brief summary: we don’t feel comfortable with GHCJS, Reflex is great but also costly (double novelty budget), Halogen is a better architecture than Elm. PureScript and Halogen come out as the best possible choice. Other things considered: ClojureScript, TypeScript, Rust, ReasonML, Elm, OCaml.
In retrospect, if it was marketed in the same way Elm was, and less “academic”, it may have taken off. But it could just be that it arrived before anyone was ready to try alternative languages. Or perhaps its syntax could have matched Haskell. Comparatively, PureScript has row types too.↩