Hah, no I don't have a blog, but I'm glad you enjoyed reading it! :)

I touched on this a bit, but the main thing is the compiler experience. I've written apps in Haskell compiled to JS before; specifically I was using Miso. While I very much enjoy writing Haskell -- that part was great -- the compiler is very slow, the binary is huge, and the generated code is completely incomprehensible. There are a few other disadvantages, such as runtime bulk, speed, laziness and the multitude of string types as well. Bucklescript is _so_ much faster than ghcjs and the tooling fits neatly into an established workflow (i.e. webpack, create-react-app etc). It compiles almost as fast as ES6, it has a built in code formatter, it supports JSX natively, etc.

That, plus I had been curious about trying OCaml for a while and I figured why not.

> Have you tried Scala.js by any chance?

Scala.js is amazing, but it lacks lazy loading mechanism popular in TypeScript/JavaScript ecosystem -- basically you can't create a set of "tiny" modules (since the Scala compiler + standard lib are integral to each exported module), so you wind up creating a single "app.js" that contains the world (or perhaps 2 modules, one for the frontend and another for the backend).

It works but it's not ideal -- would be amazing to be able to mixin a standalone scala compiler + standard lib module that lazy loaded modules could depend on.

Can I ask what you compare it with when you say amazing? I too liked it a lot but don't know what the state of the art is elsewhere.

Pardon me for wading through your history but you seem to have used Buckle script too- and claim that it has insane compilation speed and tiny Js size - (which would translate to a one time perf gain in download/parse/exec). How is the performance difference over the course of application? Would you still use Scala.Js if you didn't use Scala on the back end?

Also, why not create multiple scala-Js projects to do what you're looking to do? You'll have to fight SBT but if you die you're a martyr and if you survive you get to fight it another day...

> Also, why not create multiple scala-Js projects to do what you're looking to do?

That won't help. Scala.js banks heavily on whole program optimization to reduce the size of emitted Javascript. Two independent Scala.js modules will contain redundant code including likely upwards of 100kb of Scala standard library (collections, futures, etc.)

There is an issue about webpack-style code splitting support for Scala.js somewhere on github, and Sebastien said it's doable with the current architecture, so we'll likely get that eventually, but it's not there yet.

I do love working with Scala.js - great language and great interop with JS.

For all the efforts to put Haskell on the frontend, they're all lacking in some way or another and full of land mines.

Let GHC do what it does best; run it on the server.

Haskell is still a pretty awesome language tho, so using it on the frontend is pretty sweet. Nothing about the language is problematic here (with the possible exception of laziness which is one reason why I personally prefer purescript). And Miso is actually pretty awesome and easy to use. The main issue is with tooling, especially the slow compiler. My hope is that a wasm backend will be developed soon, hopefully along with subsequent speed improvements. Compiling a ton of non-DOM library code to obscure JavaScript makes no sense. Not to discredit the work of the ghcjs team, which created something pretty awesome and useful, but most of that would make a lot more sense in wasm. Beyond that, it needs bells and whistles like webpack integration and source maps. But really, despite its warts, it is quite usable for frontend and shouldn’t be discounted.