Why yet another Haskell to Javascript compiler?
Existing implementations either produce huge code, require a fair amount of work to get going, or both. With Haste, the idea is to give you a drop-in replacement for GHC that generates relatively lean code. (emphasis mine)

For each module, convert STG to a clunky abstract variant of JS, perform a few simplifications to cut down on code size and improve readability somewhat, then dump that to a binary intermediate file, along with a graph of dependencies between functions. Then link everything together by walking the dependency graph, starting at Main.main, and dump every encountered function to JS.

There will be a quite detailed writeup eventually (it's part of my MSc thesis).

The plan is to hold the presentation before midsummer, before the entire audience disappears on vacation, unless Koen decides that "this is crap, you'll have to do it all over" the next time I see him. :)

Last time I tried GHCJS, (which was several months ago, as the stand alone build instructions currently produce a binary that dies with a "can't find ~/.ghcjs/ghc-7.4.1somethingsomething/settings" error message - any suggestions on how best to get around that?) the output was in the ballpark of 10 megabytes of JS for the example and its dependencies.

For my small example (https://github.com/valderman/glosie/tree/hsglosie), the Haste output is 53 kilobytes, 25% of which is the RTS and the vast majority of the rest is dependencies, so I don't know if I'd call that huge, particularly considering that UHC (the only other HS -> JS compiler I've actually been able to test lately) does the same "several megabytes of dependencies" thing GHCJS used to(?) do.

I would be very interested to see what he compiled to get that sort of output. Haste should produce relatively nice code by default; if it doesn't, then as far as I'm concerned it's completely broken and needs to be fixed.

hi, I was comparing intermediate code output size for GHCJS and Haste, before eliminating unused functions, and found the generated code to be similar in size. I'm don't recall why i did it this way, but it might be because i couldn't get some part of Haste or GHCJS to work, or maybe because the elimination will not really work in the application i have in mind.

GHCJS does the same dependency analysis as Haste: if you look inside the generated .js files, you can see function-level dependencies. The GHCJS linker does dead code elimination on some main module, exporting its functions to JS, and generating a loader for each. The resulting javascript is split into several files, so that pages that need Main.function1 do not always need to load the dependencies for Main.function2 (but dependencies shared by both are always in a single file, so that functions aren't loaded twice).

Usability has been a problem for GHCJS, with the only really working option building a patched GHC that outputs Javascript for everything it builds. I've been improving the standalone compiler and hope that this will be a usable option soon. The procedure for installing diagrams-svg for example is something like this:

cabal update

cabal install ghcjs

ghcjs-boot --auto

cabaljs install diagrams-svg

ghcjs-pkg list

This installs ghcjs, then builds the core libraries (ghc-prim, integer-gmp, base) from a downloaded ghc source package (if you don't use --auto, run the ghcjs-boot command from a configured ghc source tree that has at least stage 1 built) and registers them into a ghcjs-specific package database. These changes are very new and likely to work only on Linux.

Get them from the new official repository at https://github.com/ghcjs/ghcjs (Hamish Mackenzie has contributed a lot of improvements recently, but they weren't merged in Victors repository. Since Victor himself does not have much time to work on GHCJS anymore we decided to move everything to a new organization).

All in all, it looks like GHCJS's and Haste's goal and approach are extremely similar. Both compile STG to javascript and do dead code elimination. Based on intermediate code size, I expect final code size, after running Closure Compiler, to be very similar, but i have to admit that i haven't tested this properly. A few differerences from my point of view (feel free to expand/correct!)

GHCJS has some RTS features that Haste does not support (integer-gmp with google closure bignums, a scheduler with MVars etc, weak refs with finalizers, trampoline calling convention with location information for exceptions, conversion of Data.Text to/from JS String)

hi, I was comparing intermediate code output size for GHCJS and Haste, before eliminating unused functions, and found the generated code to be similar in size.

I see. Well, that's another story then; the intermediate bundles keep quite a lot of information around that gets discarded later on. I was kind of worried that some annoying corner case caused the linker to do something stupid. :)

A few differerences from my point of view (feel free to expand/correct!)

Seems fairly accurate to me. Haste is GPLv3 mostly in order to use cereal-derive, so that may or may not change in the future. It also has trampolining, though it's turned off by default.

Haste supports interaction with native JS code using the FFI extension which, according to the GitHub page, GHCJS doesn't. (It used to, why doesn't it anymore? I'm guessing you had to move to an explicit stack in order to support threading, which I imagine would break FFI?)

EDIT: I also imagine, though I this is pure speculation as I haven't managed to get GHCJS working yet, that the threading RTS of GHCJS may have a rather drastic impact on performance and, though to a lesser extent, code size. I'll investigate this when I have the time.

I haven't done much with threading yet since i've only been contributing to GHCJS for a short time, but the goal is of course to support as much of the Haskell forkIO lightweight threading as possible (for example when accessing remote files on the server, where under the hood the RTS uses asynchronous javascript calls with callbacks, but to the user it looks like a regular blocking haskell call that can be forkIO'd).

At least running recursive things like processing very long lists does not cause stack overflows in javascript. There was a problem with finalizing weak refs, but that was fixed recently.

That said, the project really needs a good test suite to monitor not only correctness of results but also performance and memory usage in the major javascript engines. There are some plans to do that, but it's not started yet.

You're not writing Haskell as browser code. It's Haskell to Javascript. You're writing haskell converted into javascript for your browser code. I'm trying to understand why someone would spend the time to support javascript in this way, when our collective efforts should be spent moving away from javascript.

You mean by writing browsers that use a scripting language other than javascript? By all means, go for it. In the meantime we'll still need sane ways to generate javascript of this decade's browsers, and solutions like this point the way.

What "most profitable company" thinks javascript is a good language? Google is the only big profit maker I can think of that makes extensive use of javascript, and they sure don't like it. They wrote their own java->javascript compiler, and are trying to get a replacement language (dart) added to browsers because javascript is so bad.

Perhaps you should take a deep breath and actually learn JS. Then you might see that it's not the language itself that is the root of your problems.

Perhaps it is you that needs to do the learning. Javascript is on par with PHP, it is an absolutely terrible language.

My response was to the phrase "JS is worthless". I didn't say anything about other people's opinion of it. In any case, besides Google, companies that certainly make money on it include Facebook, Github, <insert whatever webapp money maker here>. It may not be the perfect language - but certainly isn't worthless.

Your point about GWT is fair.

Perhaps it is you that needs to do the learning. Javascript is on par with PHP, it is an absolutely terrible language.

In any case, besides Google, companies that certainly make money on it include Facebook, Github, <insert whatever webapp money maker here>. It may not be the perfect language - but certainly isn't worthless.

Those companies don't make money on javascript, they use javascript incidentally in the process of making money. That is like saying whatever brand of floor cleaner they use is of high quality by virtue of being used by profitable companies. If any other language were embedded in browsers they would be using it, they didn't choose javascript, they are stuck with it. That is not an endorsement. Google is the only one in that list that genuinely needs some kind of browser embedded language in order to do portions of their business, and they obviously aren't thrilled about it.

I don't think characterizing one of the worst languages ever created, with absolutely no redeeming qualities whatsoever as "worthless" is particularly outrageous. Just because people are forced to use it doesn't make it worthwhile. Rather than take the typical php/mysql route of "it is possible to have a successful company in spite of using php/mysql/javascript, therefore they are just as good as anything else", how about expanding on what exactly makes javascript good?

Not sure exactly where "not worthless" became "high quality" in our exchange.

one of the worst languages ever created, with absolutely no redeeming qualities whatsoever

You say things like these and then complain about the lack of substantive arguments on the contrary. For example, JS and Python/Ruby have more in common than you think. There is plenty of material (including a book) detailing how you can avoid the design-flaws of JS to reveal a quite usable dynamic language. Nobody is claiming it is a superior or high-quality language, but it's certainly not worthless.

In any case I have a feeling you won't be persuaded to think differently, and I don't really mind.

Excellent! I take it you've nominated yourself to undertake this endeavor? I'll be looking forward to your contributions. Seeing how Google, Mozilla, Microsoft, and Apple are all the best of friends and love coming to a consensus, I'm sure your project will be a shoo in. In the mean time, I'll be halting all of my client-side development until you feel comfortable with your first release. Take your time. We don't want to rush you the same way Netscape rushed Brendan.