Incredibly happy to see this. This could tip the balance in favour of Haskell as a viable platform for web development, given it is as or better performing than something like Go.
I know HAppS advocated an approach of using static HTML with Javascript for content/dom stuff. From http://happs.org/:
HAppS does not come with a server-side templating system. We prefer the pattern of developing static web pages and using AJAX to populate them with dynamic content.
Does Happstack take the same approach? Can anyone comment on how this architecture affects googlebot and other spiders?
You can pretty much use any old approach you'd like with Happstack. I am using it right now and it is very modular.
You could conceivably use the Text.HTML module to make your own pages in the functional style. You can use HStringTemplate a la psp and php. Or you can do the fun, bloated and awful web 2.0 thing and write an ass-ton of javascript to do everything in the ajax-y fashion, and just use happstack to serve up json.
A similar situation holds for the MACID data store. It looked ok to me, but I wanted to play with some distributed DBs instead (e.g. Mongo and Couch), and it works just fine there too.
The important thing is that if you understand how HTTP works, how requests are served up, etc., then you can pretty much hit the ground running with happstack, without having to set up Apache and learn cgi or set up Tomcat and figure out how to get the default permissions on Ubuntu to work. So in that regard, it seems much closer to RoR than the traditional approach.
I've been using HStringTemplate on top of happstack quite happily. REST would be fairly easy to achieve using this approach.
I would venture to suggest that most people would find it easier to adapt happstack directly to their needs than trying to use happs at this point in time.
"A realistic way to use Happstack with macid is to write an alpha version of an application using macid (no database), and then add some other type of persistent hard drive storage (probably database) outside of macid only if it becomes necessary.
This raises the question: if you are eventually going to have to put in a database back end, why use macid at all?
The -- perhaps slightly depressing answer -- is that you probably won't have to put in a database back end, because your app won't be so successful that this is required."
Now this is ridiculous. That's the way you guys are going to convince people to use Haskell for reald world apps?
Don't get me wrong, I'd like to see Haskell winning in territories occupied by other languages, but this looks just like another piece of Haskell code written for the sake of being written in Haskell.
Happstack's been around for a long time, and has been used in a number of production systems (including at Deutsche Bank). They're certainly trying some interesting things.
> convince people to use Haskell for reald world apps?
The vision all along was that the vast majority of web apps could be written in a MACID style -- they're not huge sites -- so make that as easy as possible.
Yeah it's a bit sad if people really downvote like that.
Anyway I'd like to have another point for the people who may think I desecrated holy shrine of Haskell. It's a quite long response and may seem like bashing but there's a conclusion at the end, so if you'd like to downvote please read to the end at least.
GHC is very nice piece of high-tech. I like coding in it and I am looking forward to have new cases when it would be the right choice. But there are not many, in my case.
Some of the difficulties are in the people's attitude which determines the quality of tools, docs and stuff. Most coders don't have big expectations: apart from the toolchain to create the code they need a platform to share the pieces of code they create. Such platform can be loved or hated (Gems, CPAN are mostly loved, Maven is mostly hated). What do we have here in Haskell world? Cabal, pretty coll stuff, except of one thing: upgrade is broken, so you have to eventually take care of your packages by hand. So it started great, but the actual implementation didn't catch some quality and nobody seems to care.
Next thing, a bigger piece of code: Darcs. Great idea, had some performance issues, probably fixed recently. Well it seems that at the time they were fixed lots of people didn't care as they were using git already. Yeah, git, whose manpage says it's "the stupid content tracker" and it really is. It has nothing like theory of patches which finds the coupling of code changes automagically. But git established some good practices which actually enable people to manage code changes in a very sophisticated way, even if these are crude hacks the end user doesn't see it. So git won. Worse is better? Maybe just pragmatic is better?
Now the cited Happstack & macid. Another cool piece of high tech which seems a bit unfinished (those limits and scalability issues). it's perfectly ok that something is unfinished. In fact, it's great that the authors were kind enough to share their hard work. But let's look what's the general attitude towards fixing the issues. It isn't: "let us help get rid of these issues". It's: "There are issues and I don't care, and you shouldn't care too". WTF?
Do you see a common pattern in those 3 examples?
- great theoretical idea
- nice implementation, but reached some limit
- "we left the rest as an exercise", "we really don't care", "it's cool already because it's Haskell"
Got it?
Looks like if you want to participate in improving the actual Haskell stuff you have no choice but accept such attitude. Which is unacceptable for many coders around, I guess. If you ask me, I tried, but was turned off. I can sacrifice my time for learning state monads as the knowledge gained will benefit me anyway, but I don't want to waste my time struggling with people's defeatist attitude.
Now the political incorrect rant ends. You can start breathing normally ;)
14 comments
[ 0.98 ms ] story [ 32.5 ms ] threadHAppS does not come with a server-side templating system. We prefer the pattern of developing static web pages and using AJAX to populate them with dynamic content.
Does Happstack take the same approach? Can anyone comment on how this architecture affects googlebot and other spiders?
* HTML/XML/etc templating via HStringTemplate, HSP, or Text.XHtml with server-side templating,
happstack is not happs, and emphasies pragmatism.
You could conceivably use the Text.HTML module to make your own pages in the functional style. You can use HStringTemplate a la psp and php. Or you can do the fun, bloated and awful web 2.0 thing and write an ass-ton of javascript to do everything in the ajax-y fashion, and just use happstack to serve up json.
A similar situation holds for the MACID data store. It looked ok to me, but I wanted to play with some distributed DBs instead (e.g. Mongo and Couch), and it works just fine there too.
The important thing is that if you understand how HTTP works, how requests are served up, etc., then you can pretty much hit the ground running with happstack, without having to set up Apache and learn cgi or set up Tomcat and figure out how to get the default permissions on Ubuntu to work. So in that regard, it seems much closer to RoR than the traditional approach.
http://tutorial.happstack.com/tutorial/macid-limits
"A realistic way to use Happstack with macid is to write an alpha version of an application using macid (no database), and then add some other type of persistent hard drive storage (probably database) outside of macid only if it becomes necessary.
This raises the question: if you are eventually going to have to put in a database back end, why use macid at all?
The -- perhaps slightly depressing answer -- is that you probably won't have to put in a database back end, because your app won't be so successful that this is required."
Now this is ridiculous. That's the way you guys are going to convince people to use Haskell for reald world apps?
Don't get me wrong, I'd like to see Haskell winning in territories occupied by other languages, but this looks just like another piece of Haskell code written for the sake of being written in Haskell.
> convince people to use Haskell for reald world apps?
The project is not the language.
If you want regular old approaches to web apps, there's libraries for that ( http://hackage.haskell.org/packages/archive/pkg-list.html#ca... ) in Haskell. But there's also happstack if you like their approach.
The vision all along was that the vast majority of web apps could be written in a MACID style -- they're not huge sites -- so make that as easy as possible.
Point is that the tutorial section I cited discouraged serious use of the stuff it's supposed to promote.
Anyway I'd like to have another point for the people who may think I desecrated holy shrine of Haskell. It's a quite long response and may seem like bashing but there's a conclusion at the end, so if you'd like to downvote please read to the end at least.
GHC is very nice piece of high-tech. I like coding in it and I am looking forward to have new cases when it would be the right choice. But there are not many, in my case.
Some of the difficulties are in the people's attitude which determines the quality of tools, docs and stuff. Most coders don't have big expectations: apart from the toolchain to create the code they need a platform to share the pieces of code they create. Such platform can be loved or hated (Gems, CPAN are mostly loved, Maven is mostly hated). What do we have here in Haskell world? Cabal, pretty coll stuff, except of one thing: upgrade is broken, so you have to eventually take care of your packages by hand. So it started great, but the actual implementation didn't catch some quality and nobody seems to care.
Next thing, a bigger piece of code: Darcs. Great idea, had some performance issues, probably fixed recently. Well it seems that at the time they were fixed lots of people didn't care as they were using git already. Yeah, git, whose manpage says it's "the stupid content tracker" and it really is. It has nothing like theory of patches which finds the coupling of code changes automagically. But git established some good practices which actually enable people to manage code changes in a very sophisticated way, even if these are crude hacks the end user doesn't see it. So git won. Worse is better? Maybe just pragmatic is better?
Now the cited Happstack & macid. Another cool piece of high tech which seems a bit unfinished (those limits and scalability issues). it's perfectly ok that something is unfinished. In fact, it's great that the authors were kind enough to share their hard work. But let's look what's the general attitude towards fixing the issues. It isn't: "let us help get rid of these issues". It's: "There are issues and I don't care, and you shouldn't care too". WTF?
Do you see a common pattern in those 3 examples? - great theoretical idea - nice implementation, but reached some limit - "we left the rest as an exercise", "we really don't care", "it's cool already because it's Haskell"
Got it?
Looks like if you want to participate in improving the actual Haskell stuff you have no choice but accept such attitude. Which is unacceptable for many coders around, I guess. If you ask me, I tried, but was turned off. I can sacrifice my time for learning state monads as the knowledge gained will benefit me anyway, but I don't want to waste my time struggling with people's defeatist attitude.
Now the political incorrect rant ends. You can start breathing normally ;)
http://gitit.net