31–40 of 78 posts
Was the Haste site made with Haste? The top links do nothing when viewing it on my (somewhat older) phone so I'm curious how well sites degrade in different browsers and devices.
It looks like: http://haste-lang.org/main.js ...and yes, I tried disabling JavaScript and it doesn't work.
I did play with an alternative approach Yesod+Fay; where Yesod is the webframework and Fay the compiler of Haskell to JS. This approach is a bit more traditional in sense that the server-side app and the client-side app are separate (with some code shared by both).
I wrote a blog on how to get a Yesod+Fay example app setup on a recent Ubuntu:
http://www.hoppinger.com/blog/haskell-in-the-browser-setting...
With Haste the server-side and client-side code live side-by-side in the same files. I "got it" by reading this code:
https://github.com/valderman/haste-compiler/blob/master/exam...
For what I understand Haste does client-sever communication over websockets and yields webapps that are full-JS (therefore difficult to do SEO).
I often read the people are afraid of debugging with compiled JS; I must say that since I need a lot less debugging when using when compiling Haskell to JS. So far all my debugging needs are fulfilled with simple print/alert/console.log statements.
So out of all these options for Haskell ( http://www.haskell.org/haskellwiki/The_JavaScript_Problem ), what's currently got the most momentum behind it?
It's not useful information regarding the usefulness of this but I am curious.
How is it more useful than Yesod ( http://www.yesodweb.com/ ) and other existing web app frameworks in Haskell?
Haste is not "more useful"; but it's approach is quite different.
Read my other comment on this page for more info on the differences.
> In essence, Haste lets you write your client-server web application as a single, type-safe program, rather than two separate programs that just happen to talk to each other over some web API as is traditional. I've been thinking about this same idea recently and find it very attractive. As programmers we don't explicitly control how our RAM communicates with the CPU; we let the underlying abstractions handle it. Wh…
(a) Does the abstraction actually lead to productivity gains in the long run, including time spent on debugging a possibly leaky abstraction?
(b) Does controlling these things manually enable you to provide a user experience that is sufficiently better to at least cover the costs of any lost productivity?
For any particular abstraction to be viable the answers need to be yes/no.
For abstracting away CPU/RAM communications the answers are clearly yes/no. But what are the answers for the abstraction that the OP referred to?
My big worry here is debugging. With, say, CoffeeScript, my code translates trivially and it's easy to map my JS back to the source. But it seems like it'd be a lot more complicated here. I'd love to hear the perspective of someone who's used this for real -- was that an issue?
> In essence, Haste lets you write your client-server web application as a single, type-safe program, rather than two separate programs that just happen to talk to each other over some web API as is traditional. I've been thinking about this same idea recently and find it very attractive. As programmers we don't explicitly control how our RAM communicates with the CPU; we let the underlying abstractions handle it. Wh…
Meta-comment: this is an excellently written landing page. All the comments about the explanation prose you usually see on HN when a language or library is introduced could be rewritten as "Make it more like Haste's landing page".