Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to SafariWhen comparing Haste vs Web Components, the Slant community recommends Haste for most people. In the question“What are the best solutions to "The JavaScript Problem"?” Haste is ranked 3rd while Web Components is ranked 29th. The most important reason people chose Haste is:
Haste was designed to allow both the client and server to be written as parts of the same, type-safe application. This is in stark contrast to most other options, where the client and server are considered two separate entities, resulting in extra manual validation code and more chances for type errors.
Specs
Question Ranking
Pros
Pro Client and Server as the same application
Haste was designed to allow both the client and server to be written as parts of the same, type-safe application. This is in stark contrast to most other options, where the client and server are considered two separate entities, resulting in extra manual validation code and more chances for type errors.
Pro Almost full power of Haskell
Haste supports the Haskell 2010 standard except for Template Haskell as well as most GHC extensions.
Pro Automatic, type safe program slicing
Haste lets you write client and server as a single program, automatically generating code for the server as well as the client, giving you full type safety even across the Internet.
Pro Generates small, reasonably performant code
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 Lacks some minor Haskell functionality
Lacks support for Template Haskell.
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
