Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to SafariWhen comparing GHCJS vs Web Components, the Slant community recommends GHCJS for most people. In the question“What are the best solutions to "The JavaScript Problem"?” GHCJS is ranked 8th while Web Components is ranked 29th. The most important reason people chose GHCJS is:
With a Haskell backend, GHCJS enables code sharing. In combination with the power of Haskell as a language, this enables an extremely tight integration of the client side with the server side, where all the communications take place in a type-safe manner and even transparently if desired.
Specs
Question Ranking
Pros
Pro Full Stack Code Sharing
With a Haskell backend, GHCJS enables code sharing. In combination with the power of Haskell as a language, this enables an extremely tight integration of the client side with the server side, where all the communications take place in a type-safe manner and even transparently if desired.
Pro All of Haskell, with the same tools you're used to
No need to learn new syntax or semantics, and no need to install and learn a bunch of new tools - it's just GHC.
Pro Mature language and community
Pro Terse
Haskell is a very terse language, particularly due to its type inference. This means there's nothing to distract from the intent of the code, making it very readable. This is in sharp contrast to languages like Java, where skimming code requires learning which details can be ignored. Haskell's terseness also lends itself to very clear inline examples in textbooks, and makes it a pleasure to read through code even on a cellphone screen.
Pro Quick Feedback
It's often said that, in Haskell, if it compiles, it works. This short feedback loop can speed up learning process, by making it clear exactly when and where mistakes are made.
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 Large runtime
GHCJS supports the entire Haskell runtime, the Javascript it outputs tends to be quite large. This is in contrast to options such as Fay, which save some overhead by not supporting some features such as multi-threading.
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
