When comparing Haste vs Utrecht Haskell Compiler, 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 Utrecht Haskell Compiler is ranked 18th. 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.
Ranked in these QuestionsQuestion 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 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.
Cons
Con Lacks some minor Haskell functionality
Lacks support for Template Haskell.
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.