When comparing PureScript vs Web Components, the Slant community recommends PureScript for most people. In the question“What are the best solutions to "The JavaScript Problem"?” PureScript is ranked 5th while Web Components is ranked 29th. The most important reason people chose PureScript is:
Has Typeclasses and RankNTypes
Specs
Ranked in these QuestionsQuestion Ranking
Pros
Pro Higher kinded types
Has Typeclasses and RankNTypes

Pro High performance FFI code
The Eff monad, which is used for FFI code, optimizes out calls to bind, and supports tail call optimization, resulting in clean, efficient Javascript. The psc compiler also specifically recognizes the ST monad, and transforms scoped variables into mutable Javascript variables, for even more efficient code.
Pro Type safety
Compiling should be your first unit test. A tight type system (static and hopefully strong) will catch many logic errors that are often difficult to spot through debugging. In languages like PureScript, if it compiles, it often runs properly.
Pro Pure functional language
You cannot have side effects, unless a function is explicitly defined as so.
Pro Modules can be compiled to CommonJS
Modules compiled to CommonJS can be included with 'require', making it incredibly simple to call Purescript code from Javascript.
Pro Has row polymorphism and extensible effects
Pro FFI
FFI system is quite good and easy to use. You can import functions curried or not curried. Records and arrays use native JS objects and arrays.
Pro Thorough documentation
The Purescript website has fairly thorough documentation for all of the language's features, and the Purescript blog contains several examples of practical usage.
Pro Awesome web frameworks
Thermite (React)
Halogen (VDOM, similar to ELM)
And hit these up with Signals, Isolated/(Managed?) Components, powerful functions and FFI

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 Lots of dependencies needed to get started
Purescript is written in Haskell, but meant to be used with Node.js. As a result, to get started , users must install ghc, cabal, node.js, grunt, and bower. Purescript also has its own compiler, and different semantics form Haskell, and so even after installing, there's still some overhead to getting productive with Purescript.
Con Lack of good IDE/tooling support
Con Documentation not updated
Con Ecosystem not stable
Con Restrictive FFI
Functions exported are all curried, and must be called as such from Javascript. The FFI syntax for importing Javascript functions, while slightly simpler and more readable than UHC/Fay's, means that calls to methods on objects must be wrapped to pass the object explicitly as a parameter.
Con Slow compilation
On large project, for example Halogen

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
