When comparing Happstack Lite vs Servant, the Slant community recommends Servant for most people. In the question“What are the best Haskell web frameworks for building RESTful web services?” Servant is ranked 3rd while Happstack Lite is ranked 4th. The most important reason people chose Servant is:
Routes are defined end-to-end with type declarations. This allows your API to be introspective, serving its own documentation and derived query code, via jQuery for Javascript and `servant-client` for Haskell.
Ranked in these QuestionsQuestion Ranking
Pros
Pro Has extensive documentation
There is extensive documentation and tutorials for Happstack and Happstack Lite available for use. Documentation and tutorials help programmers write their code; with so many options, programmers will have an easy time learning the framework.
Pro Molded through 7+ years of feedback
Happstack has been around for over seven years. During this time developers used the framework and offered feedback to improve it. As a result, it is stable and unlikely to have major changes. Happstack Lite was created from all of this feedback
Pro Shares all of its components on gitHub
Having open source means that developers can customize the framework and offer suggestions and solutions to the code.
Pro Automatic documentation and Haskell/JS query generation
Routes are defined end-to-end with type declarations. This allows your API to be introspective, serving its own documentation and derived query code, via jQuery for Javascript and servant-client
for Haskell.
Pro Excellent documentation
We Haskellers are accustomed to flying completely blind when using many libraries, luckily with Servant this isn’t the case. It features comprehensive tutorials, literate haskell examples for many use cases and great Haddock documentation for everything else.
Pro No Template Haskell
Everything is done within the confines of the existing type system, which helps keep compile times down.
Pro Nice ecosystem
Fairly large ecosystem of related modules for additional functionality.
Cons
Con Handles exceptions poorly
When an exception occurs on the server, the error gets printed. By seeing an error that makes no sense to the user, his experience is negatively impacted. Having a negative experience can mean a user never visits the site again.
Con Allows bad code by not enforcing logic separation
Happstack allows developers to write code for controllers, routing, and models together. Doing so will dirty the code and make maintenance harder.
Con Complicated internals
Extending Servant's existing functionality can be made difficult by the complexity of its type level machinery. Lucky most use cases are able to avoid this.
Con Route specifications and implementations are only connected by their position in a large type list
You actually have to count the index of the entry where you changed the specification, and then go and change the entry at the same index in the list of implementation methods. There is no other indication that the two are connected. This along with complex and verbose route definitions, makes it very hard to safely make changes to an API.
Con Route definitions are more verbose and complicated than other options
You are required to define a number of separate complicated types and their implementations which are usually spread out over a number of files. This makes it hard to figure out the API.