Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to SafariWhen comparing Fay vs Web Components, the Slant community recommends Fay for most people. In the question“What are the best solutions to "The JavaScript Problem"?” Fay is ranked 11th while Web Components is ranked 29th. The most important reason people chose Fay is:
Fay produces smaller output than pure Haskell compilers such as GHCJS; It does not need to include the whole Haskell runtime, as it drops support for features such as multi-threading, giving it fewer dependencies.
Specs
Question Ranking
Pros
Pro Small output
Fay produces smaller output than pure Haskell compilers such as GHCJS; It does not need to include the whole Haskell runtime, as it drops support for features such as multi-threading, giving it fewer dependencies.
Pro Simple, flexible, hackable FFI
As with UHC, the FFI to Javascript works with printf-style format:
max = ffi "Math.round(%1,%2)"This can simplify code needed to make calls to methods on objects, in contrast to e.g., Purescript's FFI, which requires that methods be wrapped in Javascript. Similarly to UHC, Fay also supports the use of %*, for javascript functions with arbitrary numbers of parameters, such as concat, though they must expose an explicit number of parameters to Fay.
Pro Easy to set up, with packages available on Cabal
Fay is available on Cabal, as are Fay packages, so getting up and running is as simple as typing 'cabal install'. Happstack, Snap, and Yesod packages are available on Hackage, as are bindings for JQuery and Backbone.
Pro Subset of Haskell - nothing new to learn
Since Fay is a subset of Haskell - Lazy, statically typed, and pure by default. There's no new syntax to learn, and no surprises when it comes to the semantics of your code. This extends into function names as well - Fay programmers can use familiar functions such as putStrLn to output to the console, rather than Javascript-specific versions.
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 typeclasses
This can cause some overhead.
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
