- 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. Especially being a dev-shop we're using it for ourselves so we don't really care about taking a community-census type approach to things. They only care about what works for creating real things.
Having gone down the Haskell road, letting someone make the hundreds of early choices for you seems to be the best way to go for early adoption. Typically the under-layers remain abstract enough for the true hackers, which also seems to be the case here (from reading about the blaze-html integration).
Which I always believe is a solid foundation for any useful framework. The demanded customizations can always be supported later. Modularization tends to come later as a project matures, but the early days it's best to take a singular path that works for the founding team until maturity is reached and wait/see if it does indeed become popular first to justify the more modular/customizable approach.
I haven't tried it myself though but I seem to be close to the target market being both a past Rails dev and a Haskell fan. So I'll keep it on the back burner for until I have time.
> 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)
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.
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 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 repo, another several global configs, the command line tools have a thousand flags and switches, the compiler language extensions are insane (i have like 30 turned on by default, and those are just the safe ones), i could continue...
This project, at least, tries to help the new user get into it quickly, I appreciate that because it helps me get my friends to try Haskell for a nontrivial use right away, then they want to invest the time to learn the rest of the Haskell toolchain bullshit.
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.
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.
I'd say this competition has been the reason for some amazing innovation. Both Nix and Stack are pretty next level compared what most other languages have going. And since there is no big corp (like Google for Golang) to order what to use, we will have competing standards for a long time.
IHP has a lot of potential and it's getting better by the day. The way I see it, its weakest point is the documentation: things like changing the default UI framework (bootstrap), integrating react or another frontend framework, giving more complex examples (with foreign keys i.e.), changing the URL style, exposing JSON endpoints, and so on.
I also didn't like the automatic generation of controllers, views, etc that it offers, I found it quite more confusing than just manually writing them out. Maybe this is because I come from Django instead of Rails, but I still wanted to point that out: IHP is full of magic, this is both good and bad.
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 out about a month ago, and my sense was it's definitely on the right track, but I wouldn't by any means put it into production yet. The UI was surprisingly useful rather than gimmicky, and the use of types was very cool. I was particularly impressed with the migrations framework, which was really easy to work with.
I didn't get too far into it, though, because at the time it didn't support the Haskell language server, which made exploring the framework hard. They've added support for that since then, so I'm looking forward to trying it again. I'd also love to hear people's experiences, if anyone has gotten further in it.
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. :)
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)
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.
I kind of like it. I haven't got far, but I think how it will work is to let it serve pages for the admin site, and provide JSON API to a stateful frontend.
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:
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.
I did a test once with Yesod (also a Haskell based server side web framework; also uses Haskell's Warp webserver), and it was very fast. I got 60ms from Rails and 2ms from Yesod in a similar scenario.
This will not be fastest (that will be the C/C++/Rust solutions), but the programming experience is very high level. I want speed in runtime performance (1) and in developer productivity (2). I'd say Rust and Haskell have interesting offerings looking at these two metrics.
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.
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.
- 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. Especially being a dev-shop we're using it for ourselves so we don't really care about taking a community-census type approach to things. They only care about what works for creating real things.
Having gone down the Haskell road, letting someone make the hundreds of early choices for you seems to be the best way to go for early adoption. Typically the under-layers remain abstract enough for the true hackers, which also seems to be the case here (from reading about the blaze-html integration).
Which I always believe is a solid foundation for any useful framework. The demanded customizations can always be supported later. Modularization tends to come later as a project matures, but the early days it's best to take a singular path that works for the founding team until maturity is reached and wait/see if it does indeed become popular first to justify the more modular/customizable approach.
I haven't tried it myself though but I seem to be close to the target market being both a past Rails dev and a Haskell fan. So I'll keep it on the back burner for until I have time.