Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

IHP – A Haskell web framework

github.com

Post reply on HN
Print view View original

11–20 of 41 posts

Re: IHP – A Haskell web framework

#11

Post by whateveracct »

lambda_obrien wrote: post #7

I love writing Haskell code, but the community desperately needs to agree on one method of install and project setup-- cabal, stack, nix, whatever-- and then make it WAY easier for new users to start projects. I'm not at all saying simplify the language for the LCD, but I have to manage all three of those tools and more and their usability is horrible. The configs are all over the place, there's 2 or 3 per project re…

You can just use ghcup and cabal. The cutover you're nix-style cabal builds has happened and they are excellent.

You can even just use ghcup and cabal but work against a Stackage LTS snapshot for added ease.

If you end up using Nix in the future, barely anything will change for you if you start with bare cabal. It's additive, not a replacement.

Same goes for if you use stack as an enhancement, although a big appeal of stack is its own CLI.

Re: IHP – A Haskell web framework

#12

Post by sshine »

ozmaverick72 wrote: post #2

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 this weekend as I wanted to convert a Flask prototype into something in a typed language. I’ve used Servant (Haskell) for other prototypes. For this particular demo, there were more JSON REST endpoints than “pages”, so both Servant and Http4s (Scala) felt more natural here to me.

Installing it was easy, even though this was my first time using Nix. I think shipping things with Nix, especially when what you ship is integrated, can be superior in Haskell to using stack or cabal. (Stack is easier, cabal is more flexible, neither handle dependencies outside of Haskell.)

I’ll definitely come back and check it out for another prototype soon. :)

Re: IHP – A Haskell web framework

#13

Post by theCodeStig »

pyuser583 wrote: post #9

Why? What’s the point? Do we need another web framework? Are Haskell programmers spending too much time writing boilerplate for their web apps? If this just a fun project then cool. I hoped the author learned something. I hope even more that they share what they learned.

Good point. Here’s a different angle. I don’t see it, that the Haskell community needs another web framework. However, the niche that Rails fills, could benefit from purity and type safety; which Haskell provides.

Re: IHP – A Haskell web framework

#14

Post by sshine »

egonschiele wrote: post #10
lambda_obrien wrote: post #7

I love writing Haskell code, but the community desperately needs to agree on one method of install and project setup-- cabal, stack, nix, whatever-- and then make it WAY easier for new users to start projects. I'm not at all saying simplify the language for the LCD, but I have to manage all three of those tools and more and their usability is horrible. The configs are all over the place, there's 2 or 3 per project re…

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.

For me, I use Stack personally, but I make sure that libraries can be built using either stack or cabal, by triggering CI with cabal.

Re: IHP – A Haskell web framework

#15

Post by _query »

dmix wrote: post #8

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. Esp…

Thanks for your thoughts!

> why in the world are the controller paths capitalized

The idea behind that is that it makes mapping from url to action easier when trying to understand how things work.

E.g. `/Posts` maps to `PostsAction`. `/NewUser` maps to `NewUserAction`.

I think longterm urls don't matter that much anymore as many browsers just hide them completly (think Safari, many mobile browsers, etc.), so we optimize them for development purposes :)

(Disclaimer: Founder of digitally induced, the company behind IHP)

Re: IHP – A Haskell web framework

#16

Post by icrbow »

egonschiele wrote: post #10
lambda_obrien wrote: post #7

I love writing Haskell code, but the community desperately needs to agree on one method of install and project setup-- cabal, stack, nix, whatever-- and then make it WAY easier for new users to start projects. I'm not at all saying simplify the language for the LCD, but I have to manage all three of those tools and more and their usability is horrible. The configs are all over the place, there's 2 or 3 per project re…

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.

Yes, but not the cabal-the-binary. You don't need both installed.

Re: IHP – A Haskell web framework

#17

Post by icrbow »

lambda_obrien wrote: post #7

I love writing Haskell code, but the community desperately needs to agree on one method of install and project setup-- cabal, stack, nix, whatever-- and then make it WAY easier for new users to start projects. I'm not at all saying simplify the language for the LCD, but I have to manage all three of those tools and more and their usability is horrible. The configs are all over the place, there's 2 or 3 per project re…

I would like to have stack backported into cabal, but Nix and others, that just entire code galaxies.

At least that isn't cmake et al.

Re: IHP – A Haskell web framework

#18

Post by _query »

ibraheemdev wrote: post #3

How does this compare to Yesod [1]? [1]: https://github.com/yesodweb/yesod

Someone from the haskell community summarized it like this [0]:

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

The main difference is that IHP is very opinionated and cares a lot about giving a great developer experience. Where Yesod gives you 5 options to do things, IHP has one way to do it. This especially applies to the infrastructure: IHP takes care of installing the compiler, libraries and also provides a built-in dev server that automatically reloads your code.

Our standardized setup allows for a super quick way to get started building real things.

Another important thing is documentation. IHP has best-in-class documentation[1] with lot's of code examples. Compare it yourself:

Yesod: https://www.yesodweb.com/page/quickstart IHP: https://ihp.digitallyinduced.com/Guide/installation.html

[0]: https://twitter.com/mattoflambda/status/1275469470559907840 [1]: https://twitter.com/smdiehl/status/1276049218654912514

Re: IHP – A Haskell web framework

#19

Post by _query »

keithnz wrote: post #5

Auto refresh seems a bit like phoenix's liveview? It sounds like the database hooks are a bit blunt, but I guess if your queries are low cost it could be quite responsive

Yes, this is very similiar. We used it extensively to build IHP Cloud [0] where we have a lot of async background processing. AutoRefresh allows the view to be updated automatically when e.g. the deployment status changes without us writing any app-specific JS code. It's takes only a single line of haskell code, so it's implemented in seconds and then really just works :)

Would we have to use AJAX polling for that or would need to write Websocket Code manually, we'd need to spend way more time on that.

[0]: https://ihpcloud.com/

Re: IHP – A Haskell web framework

#20

Post by sshine »

_query wrote: post #15
dmix wrote: post #8

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. Esp…

Thanks for your thoughts! > why in the world are the controller paths capitalized The idea behind that is that it makes mapping from url to action easier when trying to understand how things work. E.g. `/Posts` maps to `PostsAction`. `/NewUser` maps to `NewUserAction`. I think longterm urls don't matter that much anymore as many browsers just hide them completly (think Safari, many mobile browsers, etc.), so we optim…

I disagree with that perspective.

So far, hyperlinks have not gone away.

But which style of concatenation of words is surely subjective. I would have thought that FooBar -> foo-bar was the ad-hoc standard, but even then, people handle corner cases differently, such as “what if the word you’re url-ifying contains a dash?”

Post reply on HN