6 ms·

IHP, a batteries-included web framework built on Haskell and Nix

72 points by _query 4y ago

belmont_sup 4y ago
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.
_query 4y ago
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 https://www.youtube.com/watch?v=UbDtS_mUMpI - Docs to get started: https://ihp.digitallyinduced.com/Guide/index.html https://ihp.digitallyinduced.com/Guide/index.html - IHP reviews: https://www.g2.com/products/ihp/reviews https://www.g2.com/products/ihp/reviews Happy to answer any questions on IHP :)
- danpalmer 4y ago
  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.
  - _query 4y ago
    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.
  - zero_shift 4y ago
    > 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...
    - _query 4y ago
      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.
      - danpalmer 4y ago
        Nice one. This sort of usability thing sounds simple enough, but having it is really nice, especially for newcomers.
- whateveracct 4y ago
  Isn't Yesod also like the Rails of Haskell?
  - _query 4y ago
    Here's a quote from someone in the Haskell community that says it well https://twitter.com/mattoflambda/status/1275469470559907840 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.
danpalmer 4y ago
I'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.
- _query 4y ago
  Thanks for the feedback! Check out the docs for email confirmation here: https://ihp.digitallyinduced.com/Guide/authentication.html#email-confirmation 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 https://ihp.digitallyinduced.com/Guide/ihp-pro.html
  - danpalmer 4y ago
    Thanks, that does address my concerns well.
  - nextaccountic 4y ago
    I don't understand how can you make MySQL support and role-based access control paid features. Are they not open source?
    - 4y ago
activitypea 4y ago
>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 https://youtu.be/VBwWbFpkltg
- _query 4y ago
  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-9ab5-1d9523d48b23-announcing-the-new-ihp-developer-subscription-ihp-v0-14 https://ihp.digitallyinduced.com/blog/6392ad84-e96a-46ce-9ab...
  - danpalmer 4y ago
    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.
    - lgas 4y ago
      > 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.
dimal 4y ago
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?

72 points by _query 4y ago

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.

_query 4y ago

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 https://www.youtube.com/watch?v=UbDtS_mUMpI - Docs to get started: https://ihp.digitallyinduced.com/Guide/index.html https://ihp.digitallyinduced.com/Guide/index.html - IHP reviews: https://www.g2.com/products/ihp/reviews https://www.g2.com/products/ihp/reviews Happy to answer any questions on IHP :)

danpalmer 4y ago
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.
- _query 4y ago
  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.
- zero_shift 4y ago
  > 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...
  - _query 4y ago
    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.
    - danpalmer 4y ago
      Nice one. This sort of usability thing sounds simple enough, but having it is really nice, especially for newcomers.
whateveracct 4y ago
Isn't Yesod also like the Rails of Haskell?
- _query 4y ago
  Here's a quote from someone in the Haskell community that says it well https://twitter.com/mattoflambda/status/1275469470559907840 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.

danpalmer 4y ago

I'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.

_query 4y ago
Thanks for the feedback! Check out the docs for email confirmation here: https://ihp.digitallyinduced.com/Guide/authentication.html#email-confirmation 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 https://ihp.digitallyinduced.com/Guide/ihp-pro.html
- danpalmer 4y ago
  Thanks, that does address my concerns well.
- nextaccountic 4y ago
  I don't understand how can you make MySQL support and role-based access control paid features. Are they not open source?
  - 4y ago

activitypea 4y ago

>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 https://youtu.be/VBwWbFpkltg

_query 4y ago
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-9ab5-1d9523d48b23-announcing-the-new-ihp-developer-subscription-ihp-v0-14 https://ihp.digitallyinduced.com/blog/6392ad84-e96a-46ce-9ab...
- danpalmer 4y ago
  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.
  - lgas 4y ago
    > 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.

dimal 4y ago

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?