
Show HN: IHP, a batteries-included web framework built on Haskell and Nix - _query
https://ihp.digitallyinduced.com/
======
rckoepke
I really enjoyed your introduction. For the HN readers who enjoy summaries in
the comments, they open with a 10-12 sentence introduction, but the second
sentence sets up the core philosophy and primary value proposition:

> Back in the early days of the web, when server-side rendering was still a
> thing, javascript was sprinkled here and there to make a few parts of your
> web app just a little bit smoother.

It's "built on top of Haskell and Nix."

The more detailed 20 minute introduction and documentation is located at:
[https://ihp.digitallyinduced.com/Guide/](https://ihp.digitallyinduced.com/Guide/)
I think the "recipes" section provides some illuminating examples.

The creators make the following claims about durability at the end of their
introduction page:

> Lots of frameworks are already gone a year after launch. Especially in the
> fast moving JS world. But don't worry about IHP. We have been using it at
> digitally induced since 2017. It's actively used by us and our friends and
> partners. Even without external contributors we will build new features and
> do periodic maintenance releases in the future. We have big plans for IHP
> and as a profitable and independent software company we have the ability to
> actually execute them over the longterm.

I'm very skeptical of web frameworks / toolkits. While I only work on personal
projects, I tend to try to use pure HTML first, then add CSS where needed,
then add JS where needed, then add backend where needed - always striving to
minimize the amount of the next layer. This project seems to be targeted to
someone with my preferences.

I'll definitely be keeping an eye on it, and poking around with it.

~~~
Kinrany
> For the HN readers who enjoy summaries in the comments

This was a good reminder that I should at least skim the article first.

On the other hand I wonder if there's a way for HN/Reddit to help people write
summaries in comments. (Perhaps even recursively!)

------
xgenecloud
IHP includes a GUI to build postgres schema - this is really cool and much
appreciated. Databases have been existing for ages now and so are the GUI
tools to manage them. However, it's unfortunate that most web frameworks fail
to provide functionalities like this.

Working in similar space[1], I have been talking to many early customers.
Right from somebody who knows enough programming to product managers to CTOs,
the idea of having a GUI within web framework and to have CRUD APIs ready with
just few clicks gives them an amazing head start in building web apps. Getting
past this redundant phase of creating basic CRUD with no hassle means - they
can devote their energies on the business side of things. It will not be wrong
to imagine in few years this workflow will become a norm.

[1] :
[https://github.com/xgenecloud/xgenecloud](https://github.com/xgenecloud/xgenecloud)

~~~
tluyben2
> It will not be wrong to imagine in few years this workflow will become a
> norm.

I hope so too but we had this in different forms since the early 80s already
(maybe earlier) and it never got big for some reason.

~~~
xgenecloud
>> we had this in different forms since the early 80s already

Could you name them, happy to check them out.

------
hendi_
Important bit missing from the title: this is using Haskell (and Nix).

IHP is supposed to become the Django/Rails/Phoenix of Haskell.

I've been using Django professionally for since 2013, but have started using
IHP a couple of weeks ago. It's still quite early but with surprisingly few
rough edges, i.e. the developer ergonomics are much better than I expected. It
has great documentation that is improving rapidly (as opposed to many other
Haskell libraries, which provide little more than API docs or even just the
typed function definitions) and offers a refreshing take on database
management and migrations.

Some of its killer features:

\- HSX, a JSX-like template language that looks like HTML while providing type
safety

\- Auto live reloading without the need to setup anything

\- Documentation with examples: it lets you query the database without
learning about monads

\- it defines |> for you ;-)

\- type-safe, composable SQL queries:

    
    
      projects <- query @Project
        |> filterWhere (#userId, userId)
        |> filterWhere (#deleted, False)
        |> orderBy #createdAt
        |> fetch

~~~
throwaway_pdp09
I get the type-safe part, assuming it means the eventual query will produce a
predictable result set compatible with wherever it's being read into (I'm not
a haskeller), but a) SQL is easy enough to learn syntactically b) there are
good reasons not to create dynamic SQL; it's better to write it such that a
query plan can be cached (for scalability). Which is very likely possible here
but is it done?

I wonder if the person who wrote this understands SQL to sufficient depth. Not
saying either way, just asking.

~~~
fabian2k
You really can't avoid dynamic SQL if you need it for your software. For
example, if you give your users the ability to select filters to apply to the
data fetched from the DB, you will have to dynamically create the SQL unless
the number of possible filters is extremely low. Above a certain scale this
might not be feasible for predictable performance, but not everything has
billions of rows.

The choice isn't to use dynamic SQL or not in these cases, it's whether you
implement the feature that requires dynamic SQL or leave it out entirely.

~~~
hombre_fatal
Though interestingly (as you acknowledge via "if you need it") that also tends
to be the only time a traditional site/app does need it: a /search endpoint.

------
fimdomeio
I think enough time has passed that we're collectively forgetting the good
reasons why so many moved from server side rendering, which I would say it was
mostly the difficulty in make complex uis. Then it became a trend, now going
old school seems appealing.

Anyway in my particular case if I had any project that was a good fit for
server side rendering I would probably now go with php and some libraries but
probably no framework. I've been looking at some "weirdly coded 90's style php
projects". An while the code is a terrible mess there's also the magic that I
can read everything that's happening pretty quickly because it's just there or
in a file next to it and not hidden in a library and a sub-library with calls
to functions that I never seen before.

~~~
mhoad
I think the problem here is that you are setting up a situation where it is
some binary choice between the insane complexity of SPAs and everything that
entails and some random 90s style hand rolled PHP file.

There are a whole bunch of options between those two extremes and I can’t for
the life of me think why people don’t talk about them more often.

For example, I think the new Hey.com implementation hasn’t received anywhere
near the level of recognition that it probably should have.

It’s an entire email application with a single set of screens that power all
web, desktop and mobile apps, does so with all the speed of an SPA, has no
need for advanced state management, has the ability to push live updates on a
per component basis on any screen and does it all in under 40kb of JavaScript.

Seriously go and look at the source code. I’ve only seen a tiny number of
people talking about it like in this post [https://dev.to/borama/a-few-sneak-
peeks-into-hey-com-technol...](https://dev.to/borama/a-few-sneak-peeks-into-
hey-com-technology-iii-turbolinks-frames-5e4a)

But to me the past few years of SPAs are starting to look more and more like a
mistake to me where they became the rule when they should have probably been
the exception.

~~~
fastball
Unfortunately it is hard for me to comment on the hey.com web app as they
currently have restrictive registration.

The benefit of building with a de-coupled JS frontend (SPA) and an API is that
it can extended and adapted far easier than using server-delivered HTML.

If you have an API that delivers JSON/Protobuf/whatever, you can easily make
new interfaces to that backend. If you are currently delivering a web app in
HTML/JS, but decide you want a native Mac/iOS app written in Swift, you'll
just end up building an API anyway.

Sure, there are plenty of websites that wont ever need additional interfaces,
but if your goal is to make an app that _can_ easily have new interfaces added
to the mix, de-coupling is the way to start in my opinion.

~~~
juhatl
You make a good point, and this is one of the reasons why I really like the
Phoenix web framework (of the Elixir ecosystem). It firmly guides you towards
building applications where Phoenix is only a single interface to your
underlying Elixir application, and the web layer, by design, doesn't contain
business logic, but rather just gives you a web-friendly way to talk to the
application itself. The community has come up with the mantra of "Phoenix is
not your application" to drive this point home.

This approach and separation of concerns also means that building e.g. REST or
GraphQL APIs on top of your application is simple, as your web framework has
no say in how the data is actually structured or queried.

------
sdn90
Great work!

I wasn't able to find anything on deployment in the docs. What does it look
like?

I've been looking for a framework with the following requirements:

    
    
      - Functional-ish language
      - Statically typed with Result<T, E> error handling. 
      - Garbage collected. 
      - Compile time checked HTML templates, with autoformatter  and IDE support (like working with JSX/TSX in VS Code). 
      - Some kind of SQL DSL that has decent IDE support (like Ecto on Elixir, Diesel on Rust).
    

This framework checks off more of those than any framework I've seen. I'll
definitely be giving it a try.

~~~
laobiz
Deployment documentation is WIP at the moment and will be released soon. In
the future we want to release a Cloud where the deployment will be as easy as
clicking a button and having it online in a few seconds :)

------
erikw
Nix seems to be heading toward a critical mass in Germany. I use NixOS for my
work computer, and couldn't imagine using any other OS. I keep a LinkedIn
search open for nixos, and almost all of the hits are German. I'm interested
in what kind of an organization might try out something like IHP? I've had a
tough enough time introducing Typescript and more functionally oriented
patterns in my team, so my guess is that organizations that would seriously
consider IHP probably have a significantly different corporate culture.

------
roebk
A Haskell project with docs, this is a pleasant surprise.

I’ve been playing around with Phoenix recently and I’ve been missing a decent
type system (Dialyzer is pretty bad). I know very little Haskell but this
makes me want to dip my toes in.

------
tluyben2
First off, nice work!

I always thought it is better to mix client/server rendering; the 'everything
client' or 'everything server' both do not work for a large number of
applications. So why not mix them. Unfortunately not much out there battery-
included that consistently supports that model.

I did not dive into IHP (I heard about it as the RoR for Haskell) but, after
reading the introduction, I'm probably going to get depressed when I hear how
you do the inevitable client-side stuff here; there is a really good
opportunity to mix them as there is HSX and you can compile Haskell to JS. So
there should be an opportunity to appoint, where supported, some (parts of) a
page as serverside/clientside.

~~~
_query
Thanks for your feedback! :)

We have been tinkering a bit with building something close to Phoenix LiveView
with HSX. Hope we can show something in that direction later this year.

~~~
tluyben2
That sounds good; thanks for the response. Most stuff I do is in the middle
between static/dynamic; needs solid SEO and prerendered parts for various
reasons but also contains, for browsers that support it, quite a lot of
dynamic elements. Now we just use asp.net/static-with-some-react but that is
driving me bonkers.

~~~
dgb23
Static with some react sounds like a nightmare. One of the primary reasons why
many moved to JS frameworks was to have a better separation of concerns and a
single place where GUI logic resides.

May I suggest you have a look at Next.js. It lets you solve this in a very
ergonomic way. Maybe even for your existing project.

~~~
tluyben2
Yeah it is a nightmare; it is not my choice. It is the same ‘everyone uses it
so we need as well’ type of thing thrown in by partners.

Thanks for Next.js: I did not know it.

------
alexmingoia
Wow! Love it. I use my own hand rolled framework but will consider switching
to this.

------
exdsq
I've just played about with this and love what I see so far. If anyone wants a
small site set up and are willing to take a bet on this tech, let me know -
I'd be happy to collaborate and see what this is like in prod :)

------
underdeserver
Looks really cool!

I like the neat UI, auto refresh and everything. I even skimmed the 27-minute
demo video (that's a bit long guys), but I don't see any reference to testing,
making this a nonstarter for me.

~~~
_query
Hey, thanks for your feedback! :) We're internally using hspec for testing our
code. We're going to add some more documentation on using hspec with IHP soon.

------
revskill
So as i see, this is like a Rails framework with static type checking. Best of
both worlds !

I'd love to see a guide on integrating with webpack or any frontend tech in
the stack.

------
huijzer
This sounds awesome! I'm using NixOS for almost a year now and am still very
pleased with it. It can take some time to get things to work, but when it
works you'll never have to look at it again! My biggest problem with Haskell
is usually getting the dependencies right. So, the Nix package manager seems
like a good fit.

------
metalrain
This looks interesting.

I like how your code generation seems to expose most of the structure for
customization, but have you thought about having different customizable
templates for code generation? Like generating just REST API for this table vs
generating user visible views.

~~~
_query
This is something we plan to do in the future. We have been thinking about
adding a plugin system, where the plugins can provide custom code generators
to the dev environment :)

------
steve-chavez
Using Nix to handle dependencies(haskell, pg) in a framework is really cool!

But would IHP work in Windows natively? AFAICT, Nix doesn't work in Windows
unless you use WSL(and even here I'm not sure how smooth it is).

~~~
_query
Thanks for your feedback :) Running IHP with WSL works pretty well so far.
Some of our closed-beta testers have been running IHP on windows. We even made
a video to get people started easier on WSL:
[https://www.youtube.com/watch?v=fM0WTMLdmVw](https://www.youtube.com/watch?v=fM0WTMLdmVw)

------
carapace
Seems very interesting, and a move in the right direction.

What's it like to debug when something goes wrong?

------
lvass
Nitpick: Javascript is usually compiled.

------
cassepipe
What's the difference with Elm?

~~~
Kexoth
Regarding execution, Elm is for client-side rendering, whilst this is for
server-side rendering. As a language, they're very similar, one could even
argue that Elm is a subset of Haskell :-)

