When comparing Utrecht Haskell Compiler vs Web Components, the Slant community recommends Utrecht Haskell Compiler for most people. In the question“What are the best solutions to "The JavaScript Problem"?” Utrecht Haskell Compiler is ranked 17th while Web Components is ranked 29th. The most important reason people chose Utrecht Haskell Compiler is:
No need to learn any new semantics, it's just a switch to a different compiler.
Specs
Ranked in these QuestionsQuestion Ranking
Pros
Pro It's just Haskell
No need to learn any new semantics, it's just a switch to a different compiler.
Pro Flexible FFI
UHC uses a printf-like syntax for its FFI, which is flexible enough to minimize the need for wrapper functions, when, e.g., calling methods on objects. It also supports %*
, for working with functions that take arbitrary parameters, such as concat
.
UHC also has support for wrapper imports and dynamic imports, for passing Haskell functions as callbacks to Javascript, or dealing with curried Javascript functions, respectively.

Pro Great for small—likely published—reusable libraries
Very extendable as a single-import base layer for visual controls and probably also something like a react-redux Provider.

Pro Works with any framework
Less recreation of the wheel and fewer wrappers.

Pro Fallback styling when not yet defined
Before a component's script defines the custom element—either as the page is loading or with JavaScript disabled—it can be temporarily styled via :not(:defined)
. This may prevent the need for SSR.

Pro Customizable templates via custom-recognized "slots"
slot="name"
and <slot name="name">
for customizing a component's HTML in specific areas of its shadow DOM. Also fallbacks when not defined.

Pro Stylable via custom-exposed "parts"
::part(name)
pseudo-element for styling elements within a component's shadow DOM.
Cons
Con No support for Language Extensions
No support for things like Arrow Syntax - this is particularly a disadvantage when compared to options like Elm (which was designed around good syntax for Arrowized FRP), if you're looking to do Functional Reactive front-end development.

Con Not well-suited for application wiring
Having to serialize/deserialize data between components is not convenient. You'll probably still need a [light/simple] framework. Some things are still quite nice, such as using the light DOM -- think <option>
with <select>
and <datalist>
.

Con SSR is potentially more difficult
…if you need more than CSS' :not(:defined)
, that is.
Check out this video to see how the creator of SkateJS handled it: https://www.youtube.com/watch?v=yT-EsESAmgA
