41 ms·

New Adventures for Elm

283 points by shoover 11y ago

deleted 11y ago
[deleted]
- Kutta 11y ago
  That's an uncharitable reading and you know it.
  - deleted 11y ago
    [deleted]
- dukerutledge 11y ago
  In frontend? Not 100%, but pretty much.
  - Drup 11y ago
    ple-ase. Not everyone spends its time buzzing. The amount of people using Elm right now is a drop in the bucket compared to the amount of people using OCaml (and F#, in more recent years). Elm is a fun new language, it has cool features and its take on FRP is interesting, but I would really like its author to stop speaking like he invented fire. I would take js_of_ocaml + FRP over Elm any time, just for the size of the ecosystem and the overall expressiveness of the language.
    - CodyReichert 11y ago
      > ... and the overall expressiveness of the language. We're looking at the same Elm, right?
      - Drup 11y ago
        Yes we are. You have to look at what you are competing against. OCaml has a much better module system (and a richer type system altogether). Purescript/Haskell got typeclasses and HKT, among lots of things. As I said, Elm is cute and interesting, but it's type system is less expressive than other languages and lacks features that I consider essential. Sure, it's better than javascript, but why not opt for the other thing that is even better, given that it also provides Elm's FRP goodness.
        ZenoArrow 11y ago
        It's a trade off between functionality and user friendliness. You can currently do more with Haskell/OCaml/F# but Elm definitely has the edge when it comes to user friendliness. If that bothers you, just think of Elm as a useful tool in expanding the pool of functional programmers.
        mercurial 11y ago
        As someone who thinks OCaml rocks (but hasn't tried js_of_ocaml), it's not terribly well marketed (on top of suffering from not being new-and-shiny). Also, making and distributing a single-page OCaml-to-JS app means learning about its build system(s) (the nicest thing to say about it is that it's not best part of the ecosystem), OPAM, etc. It's not really sold as a one-stop solution for new programmers. The other thing is that Elm comes with the "Elm architecture". A OCaml GUI app backed by the react FRP library comes with "here is an FRP library, figure out the best architecture yourself" architecture. There are other open questions such as "how can I combine this with the hundreds of thousand JS packages on NPM" and "can I use it with Webpack/Typescript/other trendy JS techs". That said, the possibility of compiling pure-OCaml libraries to JS is quite interesting.
        thinkpad20 11y ago
        > Elm is cute and interesting, but it's type system is less expressive than other languages and lacks features that I consider essential. I'd recommend watching this talk: [0]. Evan talks a lot about the decisions that went into the language, such as not having type classes or other advanced features. He makes a strong case for Elm not as a language-to-rule-them-all, but as a tool for the average programmer, who is more interested in building things than in learning about theory. The myriad language features in Haskell, OCaml, etc. are wonderful to those who understand them, but have not proven to be particularly effective at attracting those who aren't already interested in the languages. In that talk, he really made a strong case as to why Elm is valuable and relevant, even for someone such as myself, a functional programming nerd who loves learning about type theory, abstract algebra, and similar things. Also, I really don't think it's fair to say "The amount of people using Elm right now is a drop in the bucket compared to the amount of people using OCaml (and F#, in more recent years)." OCaml has been around for almost 20 years now, and F# for more than 10. Both have the backing of very large development teams. [0]: https://www.youtube.com/watch?v=oYk8CKH7OhE https://www.youtube.com/watch?v=oYk8CKH7OhE
    - dominotw 11y ago
      F# is commonly used on the frontend?
      - snuxoll 11y ago
        I'm using it in a WPF app I'm developing internally. Unfortunately all the frontend code is still very OO (I'm handling tens of thousands of records at once in a DataGrid, going full functional is not my idea of a fun time here) - but the sheer reduction in lines due to better syntax, better type safety and being able to actually use my F# backend code without everything needing a wrapper to interface with C# (without being horrible to use) is a nice benefit.
      - Drup 11y ago
        I don't know about "commonly", but: http://websharper.com/ http://websharper.com/
      - ghuntley 11y ago
        For C# (and also to a lesser extent F#) check out the ReactiveUI framework which is a FRP framework for Xamarin (iOS and Android), Universal Windows Platform, Windows Phone 8.x, Windows Forms and Windows Presentation Framework. ReactiveUI is inspired by functional reactive programming and is the father of the ReactiveCocoa (Cocoa/Swift) framework. Rather than using mutable variables which are replaced and modified in-place, ReactiveUI offers "event streams", represented by the IObserver and IObserverable types, that send values over time. https://github.com/reactiveui/ReactiveUI https://github.com/reactiveui/ReactiveUI http://reactiveui.net/ http://reactiveui.net/
      - aarpmcgee 11y ago
        There is this http://funscript.info/ http://funscript.info/
sjrd 11y ago
These are some very exciting news for Elm and its community. Well done!
sotojuan 11y ago
Congrats! I hope one day to work for NoRedInk. Elm is a big reason why.
- rtfeldman 11y ago
  Please apply! We're hiring. :) http://noredink.com/jobs http://noredink.com/jobs
  - firlefans 11y ago
    Remote US only or remote EU also?
    - deleted 11y ago
      [deleted]
    - rtfeldman 11y ago
      We currently have remote developers from the UK, Germany, and São Paulo. (We do wantjunior hires to be in the office, though, to facilitate mentoring.) We do a solid amount of pair programming, but remote pairing via ScreenHero is pretty sweet. :)
      - zapu 11y ago
        What would the requirements to apply for remote, "non-junior", position be?
        deleted 11y ago
        [deleted]
        mtoledo 11y ago
        There are more details for each position at our jobs page :) https://www.noredink.com/jobs https://www.noredink.com/jobs
    - enalicho 11y ago
ZenoArrow 11y ago
What's the best programming environment for Elm? I know there's a Light Table plugin for Elm, which I think is promising (in some ways they seem like a natural fit, whilst they started separately the direction of both was inspired at least in part by Bret Victor's ideas), but I wonder what other tools are being used to code Elm. https://github.com/rundis/elm-light https://github.com/rundis/elm-light
- redka 11y ago
  Sublime Text with Elm language support[1] does auto compilation and is plenty enough. It also comes with an extension to SublimeREPL[2] [1] https://github.com/deadfoxygrandpa/Elm.tmLanguage https://github.com/deadfoxygrandpa/Elm.tmLanguage [2] https://github.com/wuub/SublimeREPL https://github.com/wuub/SublimeREPL
- brudgers 11y ago
  I'm using Emacs. Maybe it's not the best environment for Elm. But it's consistent across languages; almost every language that I've played with has a mode; and it runs damn near everywhere including a terminal. For me, I feel it was worth the investment in the learning curve I made a couple of years ago...and keep making today. YMMV.
- bribri 11y ago
  The atom plugin is excellent
charlysisto 11y ago
Here's the path I've been following : (ruby)rjs -> prototype -> jquery -> backbone -> angular -> react -> flux -> redux -> elm... But I'm just a backend guy happy with Ror, just waiting to go on the frontline... with the proper weapons! My feeling about elm is that it's more than the new kid on the js block. It's closure without parens, it's Haskell without academy, it's Redux without facebook, it's duck-typing without quacks, it's MVC without objects and last but not least evan Czaplisky (the creaor) is the new Aaron Patterson (bright and fun!) I'm all in (but yeah I've been bitten before)...
- Touche 11y ago
  That's a lot of churn. You should stop and ask yourself if it's worth being on the cutting edge all of the time. Are you making better projects as a result of dropping "old" tech the moment something shinier comes around? Everything has tradeoffs. Elm has no server side rendering, for example.
  - deleted 11y ago
    [deleted]
  - wtetzner 11y ago
    It may not be that he's trying to be cutting edge, so much as trying all of the options to see which one he wants to use.
  - ricardobeat 11y ago
    Considering rjs and prototype are way past dead and buried, that path covers a good 6-8 years, and up until React mirrors what most client-side devs have gone through.
  - vdaniuk 11y ago
    >Are you making better projects as a result of dropping "old" tech the moment something shinier comes around? That's a lot of assumptions you are making there. Why "better projects" is the only metric considered here? Perhaps, OP utility in front end technologies is based on their learning. Or what's you reason to assume OP is dropping old tech "the moment something shinier comes around" and not after a reasonable period of exploration and trial? Prototype.js was created in 2005, 10 years ago. Angular was released in 2009. React was released in 2013. A lot of churn? Absolutely not. Someone staying current, perfecting their skills and knowledge? Good for them! The HN trend of "hipster shaming" people trying new, sometimes esoteric technologies (even if it's only for the novelty factor!) is not conductive to constructive discussions and really has no place in the community named Hacker News.
jey 11y ago
I've been looking at the options for pure-functional languages targeting JS, and it seems that PureScript is superior to Elm from a technical perspective for full-stack webdev. PureScript takes the approach of providing a full Haskell-like language that is "native" to the JS world. It has the features and type system of Haskell, but atop a cleaned up version of Javascript's semantics (e.g. strict evaluation, not lazy, by default). It's also well suited for both server and client code, and even has a C++11 backend in the works in addition to the native JS backend. In contrast, Elm is focused on front-end work and is less expressive, but emphasizes simplicity. Elm's goal of figuring out how to simplify and distill the Haskell and ML world's abstractions is an admirable one, but as an experienced programmer interested in practical work I'd rather just go with PureScript and just learn the Haskell-like abstractions along the way. It also really helps that the PureScript compiler's javascript output is "natural" and easy to understand, without any mysterious transformations involved. Have others looked at PureScript, Elm, Haste, GHCJS, etc and chosen differently?
- jeremyjh 11y ago
  Haste also generates reasonable output (it can be debugged, though it is nothing like as reasonable as purescript) and has a runtime that is only 500 lines of straightforward javascript. It had pretty haskellish runtime semantics (purescript doesn't) I was able to use my existing tools like hdevtools, and have what (with just a couple ifdefs) functions as a single code-base for client and server. But its community is just too small, its updates too sporadic. I couldn't see building a business on it. Purescript or Typescript would be the only compile-to-javascript languages I would consider for serious work.
- agrafix 11y ago
  I'm currently moving from Elm to PureScript. Here's why (from "strong" to "weak"): - Currently Elm has a sad story addressing integration with "native" javascript libraries and Elm is too opinioated in some cases, e.g. you can only use either the built-in 'Elements' or virtual-dom Elements to render frontend. This makes it hard to build modular components (see https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7SxaA https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7S... for example) - While the simple type system in Elm (e.g. no type classes, no monads, ...) makes beautiful error messages possible, it really limits the abstractions that I am used to coming from Haskell - Elm/Elm-make does not generate modules that conform to a "standard" js module system - thus it will not integrate well with other js tools - Elm syntax is lacking 'where' clauses, which results in constant reindentation of code Don't get me wrong - I liked Elm a lot; but it just does not seem mature enough to use in production - but it looks like a great language to start learning FP.
ghuntley 11y ago
For those just getting started in FRP or whom may have not seen the presentations at StangeLoop: - https://www.youtube.com/watch?v=Agu6jipKfYw https://www.youtube.com/watch?v=Agu6jipKfYw - Controlling Time and Space: understanding the many formulations of FRP by Evan Czaplicki (Elm language designer/Prezi) - https://www.youtube.com/watch?v=1XNATGjqM6U https://www.youtube.com/watch?v=1XNATGjqM6U - FRP In Practice: Taking a look at Reactive[UI/Cocoa] by Paul Betts (Slack/GitHub) - https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18 https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18 - ReactiveUI - It's pretty neat by Brendan Forster (GitHub)
open-source-ux 11y ago
My comment is off-topic and likely to annoy people here, but I'll say it anyway: that entire page appears to have been generated in Javascript. If you view source, there is no HTML at all. What would a user with a screen reader hear if he or she were to visit that page? If the page had been written in plain HTML and CSS, it might be about 10-15k in size. At the moment, written in Javascript, it's over 300K in page weight. So both inaccessible and bloated in page weight. This is really bad practice.
- epidemian 11y ago
  > What would a user with a screen reader hear if he or she were to visit that page? Well, the page still renders paragraphs and titles to good ol' <p>s and <hX>s, so i'd presume a screen reader would just read those things as the page content. Wouldn't it?
  - habitue 11y ago
    the screen reader needs to execute the javascript before it can read the tags. I'm not sure if they do that
    - girvo 11y ago
      Most do, thankfully, and have done for a while now :)
- danneu 11y ago
  Two years ago, 97.6% of screen-reader users surveyed had Javascript enabled. http://a11yproject.com/posts/myth-screen-readers-dont-use-javascript/ http://a11yproject.com/posts/myth-screen-readers-dont-use-ja...
- bphogan 11y ago
  Depends on the screenreader. And unfortunately, also depends on the screenreader + browser. If the proper HTML tags are used, and role attributes are applied, it should work fairly well. The concern, however, is the weight of the page. But don't let React fool you - they try to do the same thing - rendering HTML with JSX. And the same problems can present themselves there.
codifyhus 11y ago
Nice.
k__ 11y ago
When is back-end elm?
hassox 11y ago
As an experiment I tried rendering elm in the server. It's renders fine but I'm not sure that it doesn't re-render everything on page load. http://blog.overstuffedgorilla.com/server-side-elm-with-phoenix/ http://blog.overstuffedgorilla.com/server-side-elm-with-phoe...
nanoojaboo 11y ago
"It's unprecedented for a company our size to hire a language creator," says R.Feldman of NoRedInk. http://tech.noredink.com/post/136615783598/welcome-evan http://tech.noredink.com/post/136615783598/welcome-evan This might be true, but it's also a very smart marketing investment. I would have never visited NoRedInk otherwise, and it's the kind of company that would benefit immensely from general word of mouth discussion
wtetzner 11y ago
One of the things I found odd (or maybe just annoying) is how the Elm Architecture doc [1] keeps mentioning how you can cleanly model your code using modules. But the module system is about as primitive as you could imagine. The language would be much more expressive with ML's module system, and functors would relieve some of the pain of not having type classes. [1] https://github.com/evancz/elm-architecture-tutorial/ https://github.com/evancz/elm-architecture-tutorial/
mgold 11y ago
Most of these comments boil down to, "the food's awful and the portions are too small!". Someone wants better JS interop because Elm will be a small part of their stack; someone wants server-side and isomorphic apps because Elm will be a large part of their stack. Yes, the tooling and language features have a long way to go, and hopefully Evan will make progress while at NoRedInk. If you enjoy Haskell, you're not really Elm's target audience. If you hawkishly watch HN, you're probably not the target audience - the point is that it's sane programming for the rest of us.
arvinsim 11y ago
I am a frontend developer and I wanted to learn Haskell for a long time. But I just can't wrap my head around it. Is Elm or Purescript a good way to ease into it? If so, which one is better?
- thinkpad20 11y ago
  One of the major goals of Elm is being easy to learn, both from a language and a library point of view. PureScript is, for better or worse, no simpler than Haskell as a language, with all of the power of Haskell but its complexity as well. Elm is going to be much more approachable, and has a major focus on readable documentation and simple, straightforward concepts. It takes trade offs in language features in exchange, but is probably a better bet for someone who wants to get up and running quickly.
  - codygman 11y ago
    > PureScript is, for better or worse, no simpler than Haskell as a language, with all of the power of Haskell but its complexity as well Is it really no simpler? A few common complexity complaints i hear about Haskell that don't apply to purescript in order of frequency: - Haskell is lazy by default - has too many language extensions - records pollute global namespace - has fmap and map - $ is confusing
    - Kutta 11y ago
      Except that Purescript uses the liberty from Haskell legacy libraries to become even more hardcore on algebra and categoric language. The relatively small user base also consist of experienced Haskellers, and the libraries tend to be quite advanced. For example, the "basic component" in the beginning of the Halogen tutorial already mentions natural transformations (which made me instantly intrigued, personally, but I'm one of those experienced Haskellers).
      - purescript 11y ago
        > to become even more hardcore on algebra and categoric language In some of the standard libraries, yes, that's true. However, it's possible to use PureScript without the standard libraries, and use alternatives such as Preface (a teaching library) or Neon (an alternative to Prelude) https://github.com/paf31/purescript-preface https://github.com/paf31/purescript-preface http://pursuit.purescript.org/packages/purescript-neon/0.1.1 http://pursuit.purescript.org/packages/purescript-neon/0.1.1

283 points by shoover 11y ago

deleted 11y ago

[deleted]

Kutta 11y ago
That's an uncharitable reading and you know it.
- deleted 11y ago
  [deleted]
dukerutledge 11y ago
In frontend? Not 100%, but pretty much.
- Drup 11y ago
  ple-ase. Not everyone spends its time buzzing. The amount of people using Elm right now is a drop in the bucket compared to the amount of people using OCaml (and F#, in more recent years). Elm is a fun new language, it has cool features and its take on FRP is interesting, but I would really like its author to stop speaking like he invented fire. I would take js_of_ocaml + FRP over Elm any time, just for the size of the ecosystem and the overall expressiveness of the language.
  - CodyReichert 11y ago
    > ... and the overall expressiveness of the language. We're looking at the same Elm, right?
    - Drup 11y ago
      Yes we are. You have to look at what you are competing against. OCaml has a much better module system (and a richer type system altogether). Purescript/Haskell got typeclasses and HKT, among lots of things. As I said, Elm is cute and interesting, but it's type system is less expressive than other languages and lacks features that I consider essential. Sure, it's better than javascript, but why not opt for the other thing that is even better, given that it also provides Elm's FRP goodness.
      - ZenoArrow 11y ago
        It's a trade off between functionality and user friendliness. You can currently do more with Haskell/OCaml/F# but Elm definitely has the edge when it comes to user friendliness. If that bothers you, just think of Elm as a useful tool in expanding the pool of functional programmers.
        mercurial 11y ago
        As someone who thinks OCaml rocks (but hasn't tried js_of_ocaml), it's not terribly well marketed (on top of suffering from not being new-and-shiny). Also, making and distributing a single-page OCaml-to-JS app means learning about its build system(s) (the nicest thing to say about it is that it's not best part of the ecosystem), OPAM, etc. It's not really sold as a one-stop solution for new programmers. The other thing is that Elm comes with the "Elm architecture". A OCaml GUI app backed by the react FRP library comes with "here is an FRP library, figure out the best architecture yourself" architecture. There are other open questions such as "how can I combine this with the hundreds of thousand JS packages on NPM" and "can I use it with Webpack/Typescript/other trendy JS techs". That said, the possibility of compiling pure-OCaml libraries to JS is quite interesting.
      - thinkpad20 11y ago
        > Elm is cute and interesting, but it's type system is less expressive than other languages and lacks features that I consider essential. I'd recommend watching this talk: [0]. Evan talks a lot about the decisions that went into the language, such as not having type classes or other advanced features. He makes a strong case for Elm not as a language-to-rule-them-all, but as a tool for the average programmer, who is more interested in building things than in learning about theory. The myriad language features in Haskell, OCaml, etc. are wonderful to those who understand them, but have not proven to be particularly effective at attracting those who aren't already interested in the languages. In that talk, he really made a strong case as to why Elm is valuable and relevant, even for someone such as myself, a functional programming nerd who loves learning about type theory, abstract algebra, and similar things. Also, I really don't think it's fair to say "The amount of people using Elm right now is a drop in the bucket compared to the amount of people using OCaml (and F#, in more recent years)." OCaml has been around for almost 20 years now, and F# for more than 10. Both have the backing of very large development teams. [0]: https://www.youtube.com/watch?v=oYk8CKH7OhE https://www.youtube.com/watch?v=oYk8CKH7OhE
  - dominotw 11y ago
    F# is commonly used on the frontend?
    - snuxoll 11y ago
      I'm using it in a WPF app I'm developing internally. Unfortunately all the frontend code is still very OO (I'm handling tens of thousands of records at once in a DataGrid, going full functional is not my idea of a fun time here) - but the sheer reduction in lines due to better syntax, better type safety and being able to actually use my F# backend code without everything needing a wrapper to interface with C# (without being horrible to use) is a nice benefit.
    - Drup 11y ago
      I don't know about "commonly", but: http://websharper.com/ http://websharper.com/
    - ghuntley 11y ago
      For C# (and also to a lesser extent F#) check out the ReactiveUI framework which is a FRP framework for Xamarin (iOS and Android), Universal Windows Platform, Windows Phone 8.x, Windows Forms and Windows Presentation Framework. ReactiveUI is inspired by functional reactive programming and is the father of the ReactiveCocoa (Cocoa/Swift) framework. Rather than using mutable variables which are replaced and modified in-place, ReactiveUI offers "event streams", represented by the IObserver and IObserverable types, that send values over time. https://github.com/reactiveui/ReactiveUI https://github.com/reactiveui/ReactiveUI http://reactiveui.net/ http://reactiveui.net/
    - aarpmcgee 11y ago
      There is this http://funscript.info/ http://funscript.info/

sjrd 11y ago

These are some very exciting news for Elm and its community. Well done!

sotojuan 11y ago

Congrats! I hope one day to work for NoRedInk. Elm is a big reason why.

rtfeldman 11y ago
Please apply! We're hiring. :) http://noredink.com/jobs http://noredink.com/jobs
- firlefans 11y ago
  Remote US only or remote EU also?
  - deleted 11y ago
    [deleted]
  - rtfeldman 11y ago
    We currently have remote developers from the UK, Germany, and São Paulo. (We do wantjunior hires to be in the office, though, to facilitate mentoring.) We do a solid amount of pair programming, but remote pairing via ScreenHero is pretty sweet. :)
    - zapu 11y ago
      What would the requirements to apply for remote, "non-junior", position be?
      - deleted 11y ago
        [deleted]
      - mtoledo 11y ago
        There are more details for each position at our jobs page :) https://www.noredink.com/jobs https://www.noredink.com/jobs
  - enalicho 11y ago

ZenoArrow 11y ago

What's the best programming environment for Elm? I know there's a Light Table plugin for Elm, which I think is promising (in some ways they seem like a natural fit, whilst they started separately the direction of both was inspired at least in part by Bret Victor's ideas), but I wonder what other tools are being used to code Elm. https://github.com/rundis/elm-light https://github.com/rundis/elm-light

redka 11y ago
Sublime Text with Elm language support[1] does auto compilation and is plenty enough. It also comes with an extension to SublimeREPL[2] [1] https://github.com/deadfoxygrandpa/Elm.tmLanguage https://github.com/deadfoxygrandpa/Elm.tmLanguage [2] https://github.com/wuub/SublimeREPL https://github.com/wuub/SublimeREPL
brudgers 11y ago
I'm using Emacs. Maybe it's not the best environment for Elm. But it's consistent across languages; almost every language that I've played with has a mode; and it runs damn near everywhere including a terminal. For me, I feel it was worth the investment in the learning curve I made a couple of years ago...and keep making today. YMMV.
bribri 11y ago
The atom plugin is excellent

charlysisto 11y ago

Here's the path I've been following : (ruby)rjs -> prototype -> jquery -> backbone -> angular -> react -> flux -> redux -> elm... But I'm just a backend guy happy with Ror, just waiting to go on the frontline... with the proper weapons! My feeling about elm is that it's more than the new kid on the js block. It's closure without parens, it's Haskell without academy, it's Redux without facebook, it's duck-typing without quacks, it's MVC without objects and last but not least evan Czaplisky (the creaor) is the new Aaron Patterson (bright and fun!) I'm all in (but yeah I've been bitten before)...

Touche 11y ago
That's a lot of churn. You should stop and ask yourself if it's worth being on the cutting edge all of the time. Are you making better projects as a result of dropping "old" tech the moment something shinier comes around? Everything has tradeoffs. Elm has no server side rendering, for example.
- deleted 11y ago
  [deleted]
- wtetzner 11y ago
  It may not be that he's trying to be cutting edge, so much as trying all of the options to see which one he wants to use.
- ricardobeat 11y ago
  Considering rjs and prototype are way past dead and buried, that path covers a good 6-8 years, and up until React mirrors what most client-side devs have gone through.
- vdaniuk 11y ago
  >Are you making better projects as a result of dropping "old" tech the moment something shinier comes around? That's a lot of assumptions you are making there. Why "better projects" is the only metric considered here? Perhaps, OP utility in front end technologies is based on their learning. Or what's you reason to assume OP is dropping old tech "the moment something shinier comes around" and not after a reasonable period of exploration and trial? Prototype.js was created in 2005, 10 years ago. Angular was released in 2009. React was released in 2013. A lot of churn? Absolutely not. Someone staying current, perfecting their skills and knowledge? Good for them! The HN trend of "hipster shaming" people trying new, sometimes esoteric technologies (even if it's only for the novelty factor!) is not conductive to constructive discussions and really has no place in the community named Hacker News.

jey 11y ago

I've been looking at the options for pure-functional languages targeting JS, and it seems that PureScript is superior to Elm from a technical perspective for full-stack webdev. PureScript takes the approach of providing a full Haskell-like language that is "native" to the JS world. It has the features and type system of Haskell, but atop a cleaned up version of Javascript's semantics (e.g. strict evaluation, not lazy, by default). It's also well suited for both server and client code, and even has a C++11 backend in the works in addition to the native JS backend. In contrast, Elm is focused on front-end work and is less expressive, but emphasizes simplicity. Elm's goal of figuring out how to simplify and distill the Haskell and ML world's abstractions is an admirable one, but as an experienced programmer interested in practical work I'd rather just go with PureScript and just learn the Haskell-like abstractions along the way. It also really helps that the PureScript compiler's javascript output is "natural" and easy to understand, without any mysterious transformations involved. Have others looked at PureScript, Elm, Haste, GHCJS, etc and chosen differently?

jeremyjh 11y ago
Haste also generates reasonable output (it can be debugged, though it is nothing like as reasonable as purescript) and has a runtime that is only 500 lines of straightforward javascript. It had pretty haskellish runtime semantics (purescript doesn't) I was able to use my existing tools like hdevtools, and have what (with just a couple ifdefs) functions as a single code-base for client and server. But its community is just too small, its updates too sporadic. I couldn't see building a business on it. Purescript or Typescript would be the only compile-to-javascript languages I would consider for serious work.
agrafix 11y ago
I'm currently moving from Elm to PureScript. Here's why (from "strong" to "weak"): - Currently Elm has a sad story addressing integration with "native" javascript libraries and Elm is too opinioated in some cases, e.g. you can only use either the built-in 'Elements' or virtual-dom Elements to render frontend. This makes it hard to build modular components (see https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7SxaA https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7S... for example) - While the simple type system in Elm (e.g. no type classes, no monads, ...) makes beautiful error messages possible, it really limits the abstractions that I am used to coming from Haskell - Elm/Elm-make does not generate modules that conform to a "standard" js module system - thus it will not integrate well with other js tools - Elm syntax is lacking 'where' clauses, which results in constant reindentation of code Don't get me wrong - I liked Elm a lot; but it just does not seem mature enough to use in production - but it looks like a great language to start learning FP.

ghuntley 11y ago

For those just getting started in FRP or whom may have not seen the presentations at StangeLoop: - https://www.youtube.com/watch?v=Agu6jipKfYw https://www.youtube.com/watch?v=Agu6jipKfYw - Controlling Time and Space: understanding the many formulations of FRP by Evan Czaplicki (Elm language designer/Prezi) - https://www.youtube.com/watch?v=1XNATGjqM6U https://www.youtube.com/watch?v=1XNATGjqM6U - FRP In Practice: Taking a look at Reactive[UI/Cocoa] by Paul Betts (Slack/GitHub) - https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18 https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18 - ReactiveUI - It's pretty neat by Brendan Forster (GitHub)

open-source-ux 11y ago

My comment is off-topic and likely to annoy people here, but I'll say it anyway: that entire page appears to have been generated in Javascript. If you view source, there is no HTML at all. What would a user with a screen reader hear if he or she were to visit that page? If the page had been written in plain HTML and CSS, it might be about 10-15k in size. At the moment, written in Javascript, it's over 300K in page weight. So both inaccessible and bloated in page weight. This is really bad practice.

epidemian 11y ago
> What would a user with a screen reader hear if he or she were to visit that page? Well, the page still renders paragraphs and titles to good ol' <p>s and <hX>s, so i'd presume a screen reader would just read those things as the page content. Wouldn't it?
- habitue 11y ago
  the screen reader needs to execute the javascript before it can read the tags. I'm not sure if they do that
  - girvo 11y ago
    Most do, thankfully, and have done for a while now :)
danneu 11y ago
Two years ago, 97.6% of screen-reader users surveyed had Javascript enabled. http://a11yproject.com/posts/myth-screen-readers-dont-use-javascript/ http://a11yproject.com/posts/myth-screen-readers-dont-use-ja...
bphogan 11y ago
Depends on the screenreader. And unfortunately, also depends on the screenreader + browser. If the proper HTML tags are used, and role attributes are applied, it should work fairly well. The concern, however, is the weight of the page. But don't let React fool you - they try to do the same thing - rendering HTML with JSX. And the same problems can present themselves there.

codifyhus 11y ago

Nice.

k__ 11y ago

When is back-end elm?

hassox 11y ago

As an experiment I tried rendering elm in the server. It's renders fine but I'm not sure that it doesn't re-render everything on page load. http://blog.overstuffedgorilla.com/server-side-elm-with-phoenix/ http://blog.overstuffedgorilla.com/server-side-elm-with-phoe...

nanoojaboo 11y ago

"It's unprecedented for a company our size to hire a language creator," says R.Feldman of NoRedInk. http://tech.noredink.com/post/136615783598/welcome-evan http://tech.noredink.com/post/136615783598/welcome-evan This might be true, but it's also a very smart marketing investment. I would have never visited NoRedInk otherwise, and it's the kind of company that would benefit immensely from general word of mouth discussion

wtetzner 11y ago

One of the things I found odd (or maybe just annoying) is how the Elm Architecture doc [1] keeps mentioning how you can cleanly model your code using modules. But the module system is about as primitive as you could imagine. The language would be much more expressive with ML's module system, and functors would relieve some of the pain of not having type classes. [1] https://github.com/evancz/elm-architecture-tutorial/ https://github.com/evancz/elm-architecture-tutorial/

mgold 11y ago

Most of these comments boil down to, "the food's awful and the portions are too small!". Someone wants better JS interop because Elm will be a small part of their stack; someone wants server-side and isomorphic apps because Elm will be a large part of their stack. Yes, the tooling and language features have a long way to go, and hopefully Evan will make progress while at NoRedInk. If you enjoy Haskell, you're not really Elm's target audience. If you hawkishly watch HN, you're probably not the target audience - the point is that it's sane programming for the rest of us.

arvinsim 11y ago

I am a frontend developer and I wanted to learn Haskell for a long time. But I just can't wrap my head around it. Is Elm or Purescript a good way to ease into it? If so, which one is better?

thinkpad20 11y ago
One of the major goals of Elm is being easy to learn, both from a language and a library point of view. PureScript is, for better or worse, no simpler than Haskell as a language, with all of the power of Haskell but its complexity as well. Elm is going to be much more approachable, and has a major focus on readable documentation and simple, straightforward concepts. It takes trade offs in language features in exchange, but is probably a better bet for someone who wants to get up and running quickly.
- codygman 11y ago
  > PureScript is, for better or worse, no simpler than Haskell as a language, with all of the power of Haskell but its complexity as well Is it really no simpler? A few common complexity complaints i hear about Haskell that don't apply to purescript in order of frequency: - Haskell is lazy by default - has too many language extensions - records pollute global namespace - has fmap and map - $ is confusing
  - Kutta 11y ago
    Except that Purescript uses the liberty from Haskell legacy libraries to become even more hardcore on algebra and categoric language. The relatively small user base also consist of experienced Haskellers, and the libraries tend to be quite advanced. For example, the "basic component" in the beginning of the Halogen tutorial already mentions natural transformations (which made me instantly intrigued, personally, but I'm one of those experienced Haskellers).
    - purescript 11y ago
      > to become even more hardcore on algebra and categoric language In some of the standard libraries, yes, that's true. However, it's possible to use PureScript without the standard libraries, and use alternatives such as Preface (a teaching library) or Neon (an alternative to Prelude) https://github.com/paf31/purescript-preface https://github.com/paf31/purescript-preface http://pursuit.purescript.org/packages/purescript-neon/0.1.1 http://pursuit.purescript.org/packages/purescript-neon/0.1.1