IHP, a batteries-included web framework built on Haskell and Nix
github.comI've looked at IHP briefly a number of times and the thing that always turns me off it is the fact that it's perhaps _too_ batteries included.
When I read the pricing page on IHP's site, and see something like "Email confirmation" (for authentication) having a price associated with it, it makes me assume that IHP is sufficiently locked down that I couldn't just build that feature myself. Either it's not, and I can do, and I've got the wrong impression, or it is, and I worry that IHP having that much control over my codebase will make other things that it doesn't support much harder than with other frameworks.
I'm all for the business model of well integrated, well supported plugins for the framework, but a closed, tightly controlled development environment that I can't break out of as I feel is necessary isn't something I'd bet a company on.
Thanks for the feedback!
Check out the docs for email confirmation here: https://ihp.digitallyinduced.com/Guide/authentication.html#e... You'll see that most parts of the confirmation workflow actually happen inside your application. Only the actual controller implementation is part of IHP pro, and it's just 20 lines of code. So you can easy implement this yourself.
Generally IHP uses a lot of standard libraries of the Haskell ecosystem. So you can always break out of IHP when things don't work. It's not much more lock in than other frameworks in the space :)
Some more background on the ideas behind the pricing can be found here btw: https://ihp.digitallyinduced.com/Guide/ihp-pro.html
I don't understand how can you make MySQL support and role-based access control paid features. Are they not open source?
Yes, the paid features are part of a closed source fork of IHP
Thanks, that does address my concerns well.
IHP is basically the rails/laravel/django of Haskell. If you haven't tried Haskell before or think Haskell is only about monads and math, give it a try and be surprised :)
Some links if you want to try out IHP:
- Intro video demoing how to build apps with IHP: https://www.youtube.com/watch?v=UbDtS_mUMpI
- Docs to get started: https://ihp.digitallyinduced.com/Guide/index.html
- IHP reviews: https://www.g2.com/products/ihp/reviews
Happy to answer any questions on IHP :)
One of the great things about Django/Rails (and I guess Laravel, but I have no experience) is the ecosystem of packages that integrate well with them.
For example, with Django, there are a ton of packages that integrate well with things like Models, the Forms subsystem, Middleware, Template rendering, Cache backends, etc.
Is there a similar ecosystem with IHP? Are the extension points there in the framework to allow those sorts of packages to integrate seamlessly?
My past experience with Haskell web frameworks was that there weren't many packages for common things, and that when there were they took quite a bit of integration work to use nicely.
We don't have a comparable ecosystem yet, but IHP uses many popular Haskell libraries under the hood. So many normal Haskell libraries integrate very well, as the underlying data structures are always exposed. Functional programs compose well in general due to it's stateless nature, that helps as well.
IHP also comes with a lot of things you'd typically use external packages for (e.g. Auth).
In general the IHP experience is very different from other Haskell web frameworks and much more batteries included, so a lot of apps typically don't need any external packages at all.
> My past experience with Haskell web frameworks was that there weren't many packages for common things, and that when there were they took quite a bit of integration work to use nicely.
Congralulations, you read an email address out of a database! Commiserations, it was parsed into a LazyByteString and the rest of your stack demands a Text or a String or a CuneiformCodepointArray or whatever...
IHP actually provides a `cs` (cs as an abbrev for convertString) function that is always in scope. With that function you can easily convert between all different string types.
Nice one. This sort of usability thing sounds simple enough, but having it is really nice, especially for newcomers.
Isn't Yesod also like the Rails of Haskell?
Here's a quote from someone in the Haskell community that says it well https://twitter.com/mattoflambda/status/1275469470559907840
> You thought Yesod was Rails? Nope. Yesod is a highly modular library for developing web applications with a few opinions and some scaffolds.
> IHP is Rails - all the components are glued together in a way that makes modularity difficult.
>25 dollars a month for solo projects
>125 dollars a month per seat for companies
That's.. irregular. I really have nothing nice to say about this model, so I'll just leave a really good conf talk here. The part around 8:30 is really pertinent to this situation. https://youtu.be/VBwWbFpkltg
Just to clarify: The basic version of IHP is free and open source. The IHP Pro subscription is only if you want some closed source features.
IHP users that built business critical apps with IHP actually liked it very much that we've introduced the subscription. It gives people more confidence that the framework will still be there in the longterm future.
You can find some more thoughts on this here: https://ihp.digitallyinduced.com/blog/6392ad84-e96a-46ce-9ab...
I have no problem with the business model, if it creates a sustainable business and means good support, then great.
However, I would prefer to be able to use the features in development (before production) without paying. The features don't really bring any value until they're in front of users, so asking for payment before this value is realised is a hard sell.
For personal projects I'm just never going to commit to a monthly payment before I put something in front of potentially paying users. For company projects justifying expenses during the experimentation phase is a hard enough problem that I'd just not bother.
Note: I'm not including support in any of this, I realise that support costs money regardless of when it happens.
I understand that the private fork makes licencing hard for this way of charging, but it would be great to see nonetheless.
> For company projects justifying expenses during the experimentation phase is a hard enough problem that I'd just not bother.
Seems like you're probably costing yourself a lot of money then. We make the decision to buy instead of build quite often in this phase precisely because the economics make so much sense.
On the contrary, I just wouldn't experiment with it.
Experiments get left on, subscriptions get left lying around, people leave, documentation doesn't get written for early prototypes, and so they end up costing a lot of money. $25/mo isn't a lot, but finding out 4 years later that it's still going after that week you were interested in Haskell is an expensive mistake.
In small companies the processes for getting sign off for these sorts of expenditures are often not developed enough, and so doing it is a pain for an experiment. In big companies it's easier in some ways but might come with more box ticking necessary to get it to happen, or more business justification.
What's the supposed difficulty to just use Cabal and not Nix? I had alot of difficulties running into Nix installation issues not along ago.
What resources does Nix handle for IHP? I can guess ostgres and the sql ui.
Looks nice. Can you explain what exactly "full stack" means in this case? I see "Auto live reloading using virtual DOM in development mode". But not production? So it's not doing any SPA-style client side DOM updates?