Raison D'être - miso
Miso was written for those who want the simplicity of an Elm interface without sacrificing typeclasses and allowing type-sharing between server and client.
A lot of web dev becomes boilerplate -- serializing and transferring state is a large part of the work of web dev. Type sharing ensures correct-by-construction serialization between server / client amidst any changes to your business logic data types, allows you to focus on your apps core offerings as opposed to minutia.
The Haskell ecosystem has many great libraries that compile w/o any problems on the frontend.
Programming with threads and synchronization primitives is now first class in the browser.
Compared to Elm’s ports feature, the GHCJS FFI is a much simpler way to interface with third-party libs. Also, Haskell supports typeclasses, and Generic programming, a rich lens library, etc.
You’ll be working directly at the intersection of a lot of interesting developments in GHC, specifically around cross compilation, syntax, lenses. Any new advancements to GHC has an impact on your frontend code. Also, many PhDs use, love and contribute to Miso. These people tend to be very smart, empathetic and intellectually curious as opposed to dogmatic and contentious that can be found in the software engineering industry at large today.
A one-tool-to-rule them all for dev, build, and deploy. While not easy, deterministic builds are the future and help one to sleep at night (I’ve found). It can be used solely for personal dev, or for an entire organization, and anything in between.
If your Haskell web framework does not handle the tedious task of DOM manipulation for you, you have been failed as a library consumer IMO. Miso has a very well-tested, simple recursive micro virtual DOM diffing library that can exist standalone and can detect regressions in performance via a benchmark suite.
Unlike many other ivory tower libraries in Haskell, Miso maintains a simple interface. Many different common abstractions were explored in the early stages of development (free monads, FRP, etc.) and found lacking, unnecessary or replaceable by a simpler solution without sacrificing features. Miso does not attempt to hide behind complex type-level abstractions and blame end-users for their lack of understanding. As opposed to a top-down approach that shoe-horns an abstraction into an environment where it does not belong, Miso takes a bottom-up approach to fully understand its environment, the browser, it’s APIs, the DOM and its short-comings and provide a simple commonly-used abstraction to the end-user that can scale to large applications. This also makes it easier for newcomers to Haskell to get up and running quickly.
Several companies are using miso in production for various things in their company, from full product to internal tools / data visualization.
Due to the rose tree structure of both the DOM and HTML, pre-rendering increases load-time and overall UX along with correct SEO.