IHP – A Haskell web framework

I've seen this come up on reddit ads - has anyone tried it out ? Does it live up to the claim that its Rail's for Haskell ? How does it compare to any of the other web frameworks out there ?

I tried it out about a month ago, and my sense was it's definitely on the right track, but I wouldn't by any means put it into production yet. The UI was surprisingly useful rather than gimmicky, and the use of types was very cool. I was particularly impressed with the migrations framework, which was really easy to work with.

I didn't get too far into it, though, because at the time it didn't support the Haskell language server, which made exploring the framework hard. They've added support for that since then, so I'm looking forward to trying it again. I'd also love to hear people's experiences, if anyone has gotten further in it.

I kind of like it. I haven't got far, but I think how it will work is to let it serve pages for the admin site, and provide JSON API to a stateful frontend.

Two rather insignificant observations:

- the video scaffold redirected to localhost:8000/Posts why in the world are the controller paths capitalized? So rare to see that but somehow I'm less surprised in haskell

- the name sounds a lot like i-Hop and I can't get it out of my head now and it will forever be that. First impressions have a way of sticking around

Otherwise I like the opinionated direction they chose. Especially being a dev-shop we're using it for ourselves so we don't really care about taking a community-census type approach to things. They only care about what works for creating real things.

Having gone down the Haskell road, letting someone make the hundreds of early choices for you seems to be the best way to go for early adoption. Typically the under-layers remain abstract enough for the true hackers, which also seems to be the case here (from reading about the blaze-html integration).

Which I always believe is a solid foundation for any useful framework. The demanded customizations can always be supported later. Modularization tends to come later as a project matures, but the early days it's best to take a singular path that works for the founding team until maturity is reached and wait/see if it does indeed become popular first to justify the more modular/customizable approach.

I haven't tried it myself though but I seem to be close to the target market being both a past Rails dev and a Haskell fan. So I'll keep it on the back burner for until I have time.

FWIW stack uses cabal under the hood but is far easier to use. I would not use cabal these days, stack solves a lot of the dependency issues cabal had.