Deploying an IHP Project to Fly.io (nathanjaremko.com)

Most of IHP is available open source and free. Like 99% of it. The IHP Pro features are mostly targeted at people making money with IHP (e.g. companies and freelancers). The idea is that the Pro plan provides a longterm incentive for maintaining the framework. When we make a great framework that creates a lot of value for developers, we will have a lot of paying customers. When we have a lot of paying customers, we can be sure that IHP will be actively developed far into the future.

If you want to learn a bit more about the ideas why we added the paid plan to IHP, check the initial announcement post here https://ihp.digitallyinduced.com/blog/6392ad84-e96a-46ce-9ab... :)

I am a paying IHP user, working on it commercially, and I for one support the paid plan.

If I used it for pure hobby, the paid version features wouldn't really matter that much to me anyway, but professionally these are timesavers.

I always get help, and I don't feel bad asking for support. I get listened to when suggesting improvements, and many times they do the job of implementing well thought out suggestions.

It's not purely based on devs working on it on their free time (although some do that as well). The core maintainers have a real incentive to keep the framework going strong.

The paid features are stuff like third-party oauth and Stripe, and does not bring limitations on the framework itself.

So that's some arguments, although biased, by being a fan of the framework :)

(I’m the author) The only feature in the paid list that I’d agree with you on was support for building docker images. I thought it was silly to charge for <15 lines of nix code that do something so fundamental for a web framework, so I wrote this blog post and convinced the maintainers to make it a free feature.

Now I think the remaining stuff is fine, paying for a stripe integration and oauth libraries doesn’t trigger any alarms for me, personally.

I think another element is if you are a single or part of a small team of developers you realize quite quickly the value IHP adds to your project in terms of time savings:SES, Sentry, deployment... Etc. Also When you rely on IHP for anything in production you end up exploring some of the more remote corners of the design and I've found the quality is still very high even for niche features. From this perspective paying the monthly fee to keep the team developing IHP interested becomes a very good investment.

WSL is not "Windows" at that point though.. From Docker's perspective you're building on Linux.

I think theres a downstream dependency that requires it. I just tested locally and the build fails with

> error: getting status of '{...}/Config/nix/nixpkgs-config.nix': No such file or directory

(I’m the author) The issue isn’t nix builds in general, those work fine on MacOS, the issue is cross compiling a Linux docker image, which can be much trickier. I usually end up just relying on the github CI to build it, but nix has some nice remote builder functionality that might also be worth looking into.

what

IHP is a Ruby on Rails style framework in Haskell while CLOG is a GUI framework in Common Lisp. They don't have that many overlapping use cases though both a awesome.

Also nothing wrong with IHP offering commercial features. Developers need to eat.

(I’m the author) It’s only slightly more work, but what you get in return is a reproducible dev shell, a reproducible build, and a final docker image with over 100 very granular, optimally ordered layers. That last bit makes the diff of consecutive images much smaller, which can be nice.