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.
Haste language
21–30 of 78 posts
Re: Haste language
#22Re: Haste language
#23So out of all these options for Haskell ( http://www.haskell.org/haskellwiki/The_JavaScript_Problem ), what's currently got the most momentum behind it?
My impression is that Fay has been in (at least moderate) use the longest. GHCJS seems to be getting a lot more viable lately. Elm (which is only Haskellish rather than fully Haskell-compatible) isn't listed on that page, but is getting quite nice.
Re: Haste language
#24Meta-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".
I think it says a lot about the web when a simple, mostly text-only page giving an accurate description of what something is gets viewed as excellent due to how uncommon it is.
Re: Haste language
#25Was 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.
Re: Haste language
#26This is interesting (and exciting). I would love to see an implementation of TodoMVC (http://todomvc.com/) in Haste.
Re: Haste language
#27> 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…
This is a core philosophy of DerbyJS[0]. It even takes it one step further by rendering pages on both the server and the client.
I'd love to find out more about how Haste manages the intersection between client and server since it is capable of existing as a client-side only app. Hopefully it has a well defined API and writing plugins for different sources of data is clear and simple.
Re: Haste language
#28So out of all these options for Haskell ( http://www.haskell.org/haskellwiki/The_JavaScript_Problem ), what's currently got the most momentum behind it?
My impression is that Fay has been in (at least moderate) use the longest. GHCJS seems to be getting a lot more viable lately. Elm (which is only Haskellish rather than fully Haskell-compatible) isn't listed on that page, but is getting quite nice.
I usually hear that Haste produces the nicest target Javascript and GHCJS perhaps the worst... but GHCJS will probably continue to get more momentum.
Re: Haste language
#29I don't exactly understand why Haste was made into a separate dialect when it "just" has a different stdlib? > with a different set of standard libraries 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't this type of fragmentation cause huge delays in the progress of a language, ultimately? Hopeful…
This is a definitional issue more than a technical one - if you follow the link to the Haskell package documentation [1], the project actually consists of aforementioned standard library, plus a Haskell-to-JS compiler. This is a "dialect" of Haskell in the same way that we can speak of the GCC and Intel dialects of C and C++ - both compilers support the same standard, but each supports a different set of non-standard extensions. In this case, the Haste front page notes that it supports most, but not all, GHC extensions to the Haskell standard.
Re: Haste language
#30My 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?