Haste language

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

&gt; 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.<p>I&#x27;ve been thinking about this same idea recently and find it very attractive. As programmers we don&#x27;t explicitly control how our RAM communicates with the CPU; we let the underlying abstractions handle it. Why don&#x27;t we have similar abstractions for when a client-side program (CPU) needs to access something on the server (RAM)?<p>Does anyone know of other tools trying to accomplish this? I&#x27;m not a Haskeller but am tempted to dive in just for this feature.

I don&#x27;t exactly understand why Haste was made into a separate dialect when it &quot;just&quot; has a different stdlib?<p>&gt; with a different set of standard libraries<p>Is there a technical reason why it would be ill advised to just make Haste itself into a separate library that can be included into the regular Haskell ecosystem? Doesn&#x27;t this type of fragmentation cause huge delays in the progress of a language, ultimately?<p>Hopefully it&#x27;s obvious that I&#x27;m entirely not knowledgeable about these things and that I&#x27;d love for someone to explain this to me.

I&#x27;m a bit disappointed this is getting so little response here. It&#x27;s clearly trying to improve the state of the art of web app dev, and in a powerful language, to boot.<p>Do you really think we&#x27;re going to be writing raw JS the whole time? The trajectory of computing has always been to build higher levels of abstraction, especially when the implementation technology is kludgy.

Haste is looking more and more awesome! However, we&#x27;ve taken the route of clojurescript&#x2F;om for building on top of a Haskell web app. cljs just seems a bit more &quot;there&quot; as a compiles to js language. I would have loved to have used something like Haste or Fay, but for right now (taking a deep breath and giving up the type safety) I think the clojurescript eco-system looks the stronger for functional programming in the browser. The browser repl from emacs&#x2F;lighttable is also a pretty impossible feature to beat!

So out of all these options for Haskell (<a href="http://www.haskell.org/haskellwiki/The_JavaScript_Problem" rel="nofollow">http:&#x2F;&#x2F;www.haskell.org&#x2F;haskellwiki&#x2F;The_JavaScript_Problem</a>), what&#x27;s currently got the most momentum behind it?

I&#x27;ve been thinking for a while about reimplementing a large CoffeeScript (horrible language) project that we have at my work in Haskell, just to see if it could work, how easy it would be, how much smaller it would be, and if I could get the same or better performance out of it without going crazy. One of the demands of the existing software is that it both run in the browser, and server-side. This project is awesome because I could reimplement it in Haskell, and run a binary version on the server, with a JS version in the browser. Very cool! Now if I could only convince my company to switch...<p>By the way, on the &quot;Try Haste&quot; project, it would be nice to see the generated JS output, as they do on the &quot;Try CoffeeScript&quot; page. Even though it&#x27;s not really meant to be looked at in javascript, it&#x27;s informative for those who know a bit about both languages to see what kind of transformations are taking place.

<a href="http://ocsigen.org/js_of_ocaml/" rel="nofollow">http:&#x2F;&#x2F;ocsigen.org&#x2F;js_of_ocaml&#x2F;</a> is a similar project for OCaml.

My big worry here is debugging. With, say, CoffeeScript, my code translates trivially and it&#x27;s easy to map my JS back to the source. But it seems like it&#x27;d be a lot more complicated here. I&#x27;d love to hear the perspective of someone who&#x27;s used this for real -- was that an issue?

This is interesting (and exciting). I would love to see an implementation of TodoMVC (<a href="http://todomvc.com/" rel="nofollow">http:&#x2F;&#x2F;todomvc.com&#x2F;</a>) in Haste.

How is it more useful than Yesod (<a href="http://www.yesodweb.com/" rel="nofollow">http:&#x2F;&#x2F;www.yesodweb.com&#x2F;</a>) and other existing web app frameworks in Haskell?

Haste is a great approach to compile Haskell to JS. But I yet have to play with it...<p>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).<p>I wrote a blog on how to get a Yesod+Fay example app setup on a recent Ubuntu:<p><a href="http://www.hoppinger.com/blog/haskell-in-the-browser-setting-up-yesod-and-fay" rel="nofollow">http:&#x2F;&#x2F;www.hoppinger.com&#x2F;blog&#x2F;haskell-in-the-browser-setting...</a><p>With Haste the server-side and client-side code live side-by-side in the same files. I &quot;got it&quot; by reading this code:<p><a href="https://github.com/valderman/haste-compiler/blob/master/examples/sendfile/sendfile.hs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;valderman&#x2F;haste-compiler&#x2F;blob&#x2F;master&#x2F;exam...</a><p>For what I understand Haste does client-sever communication over websockets and yields webapps that are full-JS (therefore difficult to do SEO).<p>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&#x2F;alert&#x2F;console.log statements.

<p><pre><code> While a certain increase in code size over hand-rolled Javascript is unavoidable, an optimized but uncompressed Haste program is normally less than 3x the size of an equivalent hand-written program, making the latency penalty of using Haste minimal. </code></pre> A type safe environment is most useful for large(r) applications; you don&#x27;t really need it for your 200 or 2000 SLOC jQuery script.<p>But larger applications quickly grow quite a bit, reaching a megabyte or multiple is not uncommon in the land of GMail and similar apps.<p>Growing your JavaScriot &quot;binary&quot; size by a factor of three might be a problem for such applications. It doesn&#x27;t sound that much, but the difference between download, parsing, and running 1 MB of JS vs 3 MB of JS is several hundred milliseconds on a very good connection and a beefy desktop machine.

Should really have a link to the great examples: <a href="https://github.com/valderman/haste-compiler/tree/master/examples" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;valderman&#x2F;haste-compiler&#x2F;tree&#x2F;master&#x2F;exam...</a>

Was the Haste site made with Haste? The top links do nothing when viewing it on my (somewhat older) phone so I&#x27;m curious how well sites degrade in different browsers and devices.

These layers upon layers just seem painful to me.

What exactly is the use-case for this? Can&#x27;t quite get it from the site.