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

21–30 of 41 posts

Re: IHP – A Haskell web framework

#21

Post by themmes »

sshine wrote: post #20
_query wrote: post #15

Earlier quoted context omitted.

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?”

I consider this 'an opinion to get started quickly', it's easy to change if you wish ;-)

Re: IHP – A Haskell web framework

#22

Post by themmes »

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'm using it for a hobby project! It's been great to actually be able to quickly build something while learning haskell, the folks on the slack are helpful and it's inspiring to see how quickly the framework develops.

I don't have any experience with Rails or other haskell frameworks.

Re: IHP – A Haskell web framework

#25

Post by unhammer »

etherio wrote: post #24

I wonder how this framework performs on speed. Rails is really nice but somewhat on the slow side, would be cool if the haskell alternative was more efficient.

https://github.com/TechEmpower/FrameworkBenchmarks/pull/6006 I suppose we'll see next time techempower runs their benchmarks :)

Re: IHP – A Haskell web framework

#26

Post by feanaro »

_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…

Please let's not help with the efforts to hide the URL by spreading this sentiment. It's a misguided move that will only make users more helpless and the web more mysterious for them.

I'm increasingly encountering users that have trouble understanding that they should copy the URL to someone if they want to share a web page with them. Humans are logical creatures: if they see a part of the system that is constant, they will deduce that it could not have had an impact on the part that is changing. In the case of the URL this is an incorrect conclusion, but the UX from bad actors like Apple and Google is steering the user towards it.

If the intent is to show the host more prominently, then the URL should be visually split into the (more prominent) host part and the path part. The path part should not be simply hidden.

Re: IHP – A Haskell web framework

#27

Post by asplake »

sshine wrote: post #12
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…

Interesting. I too am waiting for something ML-typed to tempt me away from Python/Flask. I render mostly server-side but based on services that actually or potentially serve JSON (it’s all one process but I’m careful that services don’t leak model objects)

Re: IHP – A Haskell web framework

#29

Post by johnbonachon »

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 do know there's not a single/unique way of installing dependencies, etc. But the IHP docs are enough clear to set up a project and install everything in just a moment. Maybe the Haskell community doesn't have a clear choice, but the people of DI have made that very simple.

Re: IHP – A Haskell web framework

#30

Post by LockAndLol »

_query wrote: post #18
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…

So yesod to IHP is like expressjs to meteor, fastapi or flask to django?
Post reply on HN